tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Revert "better constant handling for expr_cond"


From: grischka
Subject: Re: [Tinycc-devel] Revert "better constant handling for expr_cond"
Date: Tue, 19 Jul 2011 19:26:31 +0200
User-agent: Thunderbird 2.0.0.24 (Windows/20100228)

Joe Soroka wrote:
On Sat, Jul 16, 2011 at 7:17 AM, grischka <address@hidden> wrote:
Message from the slush pile QC:

Issue:
   http://repo.or.cz/w/tinycc.git/commitdiff/d7d84588
Observation:
   caused an ICE in a stage-1 gcc 2.95 made by this tcc
   while compiling itself for stage-2.
Details:
   not available ;)

Hey, sorry about this.  One of the things I'm trying to do is build a
test suite so I can feel more comfortable about making changes like
this.  Any chance you can give me a little bit of detail ;) on the
ICE?  Were there any details given by the ICE like a stack trace or
anything?  Could you possibly do it all again with the broken bit, tar
up whatever's there after the ICE and upload it somewhere?

No, really, there is nothing useful.

However, I've now tried to find a case where your patch would
not work.  See this:
    printf("%.1f\n", 0 ? (printf("A"), 3.0) : (printf("B"), 4));
It should print
    B4.0
but with your patch it would print
    AB0.0

So it prints "A" which it should not.  And it does not cast 4 to
double 4.0 which it should because 3.0 is double.  I did not
know that, but Fabrice gave an hint:
    /* cast operands to correct type according to ISOC rules */

Plus there might be other things wrong with the patch that this
example does not show.  Not trivial, you see?

I have an
idea for how to do the thing I wanted to do with less impact, but I'll
be afraid it will cause the same problem again.  If not, no big deal,
I'll just try another version of the patch and you revert it if it
causes problems.

I'd suggest to forget this for now.

Anyway we should not force TCC to do something what is was not
written for.  It is waste of time.  If we want optimized code,
then TCC wants an optimizer.  That is how it is.  Possible but
non-trivial.

Other topic:  I've seen you did something with the macro preprocessor.
Could you make some progress there?

I've attached the cpp tests from the pcc compiler.
    http://pcc.ludd.ltu.se/

Just in case you have fun to try how far TCC can get on this
area.  (I've tried it some time ago, it was, well, ...)

--- grischka

Please reply to the mailing list or use "Reply to all".

Attachment: cpp-tests.tar.bz2
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]