Now I also found which -O2 optimization is the trouble maker: -ftree-vrp

gcc -O -o t t.c #OK
gcc -O -ftree-vrp -o t t.c #FAIL
gcc -ftree-vrp -o t t.c #OK!!!

So -ftree-vrp needs one of -O optimizations to help him make troubles!

Borut

-------- Original Message --------
Subject: Fwd: Fwd: Re: [sdcc-devel] gcc integer promotion-ftree-vrp
Date: Thu, 29 Jul 2010 00:12:27 +0200
From: Borut Razem <borut.razem@siol.net>
To: Maarten Brock <sourceforge.brock@dse.nl>


> I still don't understand why it doesn't fail on regtests!

Now I get it: regtests are compiled without -O2.
Regtest make probably inherits CFLAGS env. variable from the parent make, which defines CFLAGS without -O2. I'm still investigating it...

So we can omit -O2 from regstest makefile CFLAGS, or leave it there as a reminder of gcc (potential) bug ;-)

Borut




-------- Original Message --------
Subject: Fwd: Re: [sdcc-devel] gcc integer promotion
Date: Wed, 28 Jul 2010 23:57:00 +0200
From: Borut Razem <borut.razem@siol.net>
To: Maarten Brock <sourceforge.brock@dse.nl>


It pass also with -O1.

I tried to compile the small example on cf-x86 snapshot build machine, and the behavior is the same. I still don't understand why it doesn't fail on regtests!

I seems a gcc bug to me. -O2 means a combination of optimizations, which can be included one by one. Before filing a bug we should find out which optimization in the -O2 set is the one making troubles.

Borut

-------- Original Message --------
Subject: Re: [sdcc-devel] gcc integer promotion
Date: Wed, 28 Jul 2010 23:29:48 +0200
From: Borut Razem <borut.razem@siol.net>
To: sourceforge.brock@dse.nl


On 07/28/2010 11:00 PM, Maarten Brock wrote:
> Hi Borut,
>
> I'd say vus must be promoted to signed int unless
> short==int which is not the case for gcc on either 32 or
> 64 bit x86 (I have 32 bit VM's: Debian on VMware and
> Ubuntu on Virtualbox). So vus * vus is also int and so
> is the literal 1.
>
>    

Yes, right. It was stupid question to ask, but the architecture 
differences were the first thing that came into my mind...

> I can only guess that optimizations forget the promotion
> rules and keep everything unsigned and possibly short.
> Even inserting explicit int casts did not solve it.
>
>    

Yes, it is the optimiser: with -O2 fails, without -O2 it pass.

> But why doesn't it fail on the compile farm machines?
> And apparently also not when isolated. Should we file a
> bug report to gcc?
>
>    

No idea!

> Maarten
>
>    
>> Hi Maarten,
>>
>> it fails on my machine (64bit Ubuntu 10.04) too. I didn't bother too
>> much since nobody else complained and regtests are also OK, so I thought
>> that something is wrong in my source tree..
>>
>> I tried to compile just:
>> ---8<---
>> #include<assert.h>
>>
>> void
>> main(void)
>> {
>>     volatile unsigned short vus = 0xfffe;
>>     assert (vus * vus<  1);
>> }
>> --->8---
>>
>> and the assertion doesn't fail!!!???
>>
>> What is vus * vus supposed to be promoted to? If it is unsigned long,
>> then it might have to do with the 32/64 bit architecture: long is 32 bit
>> on 32 but cpu and 64 bit on 64 bit cpu on Linux... If not, I don't have
>> a clue :-(
>>
>> Borut
>>
>> On 07/28/2010 09:32 PM, Maarten Brock wrote:
>>      
>>> Hi,
>>>
>>> Since a while I get a failing regression test for the host target (gcc)
>>> for literalop.c.
>>> It fails on:
>>>
>>> volatile unsigned short vus = 0xfffe;
>>> assert (vus * vus<   1);
>>>
>>> And this happens on both gcc 4.3.2 and 4.4.1. Yet I don't see it fail in
>>> the daily snapshots.
>>> I don't understand this and I could not find anything about it either.
>>> Any ideas?
>>>
>>> Greetings,
>>> Maarten
>>>
>>> ------------------------------------------------------------------------------
>>> The Palm PDK Hot Apps Program offers developers who use the
>>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>>> of $1 Million in cash or HP Products. Visit us here for more details:
>>> http://p.sf.net/sfu/dev2dev-palm
>>> _______________________________________________
>>> sdcc-devel mailing list
>>> sdcc-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/sdcc-devel
>>>
>>>
>>>        
>>      
>
>
>