I have found some code that produces different results
depending upon  whether optimisation is turned on.
Optimisation O3 inlines, optimises, and doesn't generate
an overflow, thus  both red then green are turned on.
Without optimisation, the function is called, there is an
overflow in the  second case, and only the red is turned on.
Not sure if this is already documented or not, but it seemed
worth pointing out just in case.

void TestFunction(s32 TestVar)
{
 if ((TestVar + 100) < 0)
 {
  Port(TurnOn, RedLed);  // Turn Red Led On
 }
 else
 {
  Port(TurnOn, GreenLed);  // Turn Green Led On
 }
}


int main(void)
{
 TestFunction(-200);

 TestFunction(0x7ffffff0);

 while(1);
}

(disclamer: yes I have posted to gnu.gcc without any comment, and
yes, I know port is not a valid c statement, its just illustrating the 
point)

On Dec 8, 11:45 am, "Paul" <-> wrote:
> I have found some code that produces different results
> depending upon  whether optimisation is turned on.
> Optimisation O3 inlines, optimises, and doesn't generate
> an overflow, thus  both red then green are turned on.
> Without optimisation, the function is called, there is an
> overflow in the  second case, and only the red is turned on.
> Not sure if this is already documented or not, but it seemed
> worth pointing out just in case.
>
> void TestFunction(s32 TestVar)
> {
>  if ((TestVar + 100) < 0)
>  {
>   Port(TurnOn, RedLed);  // Turn Red Led On
>  }
>  else
>  {
>   Port(TurnOn, GreenLed);  // Turn Green Led On
>  }
>
> }
>
> int main(void)
> {
>  TestFunction(-200);
>
>  TestFunction(0x7ffffff0);
>
>  while(1);
>
> }
>
> (disclamer: yes I have posted to gnu.gcc without any comment, and
> yes, I know port is not a valid c statement, its just illustrating the
> point)

Signed integer conversion out of range is implementation-defined. Read
the docs of your implementation about it, and you'll find out why this
occurs. (assuming s32 means 31 value bits 1 signed bit)

On Dec 8, 10:45=A0pm, "Paul" <-> wrote:
> I have found some code that produces different results
> depending upon =A0whether optimisation is turned on.
>
> void TestFunction(s32 TestVar)
> {
> =A0if ((TestVar + 100) < 0)
> =A0 Port(TurnOn, RedLed); =A0// Turn Red Led On
> =A0else
> =A0 Port(TurnOn, GreenLed); =A0// Turn Green Led On
> }
>
> int main(void)
> {
> =A0TestFunction(-200);
> =A0TestFunction(0x7ffffff0);
> }

I'm assuming "s32" is a 32-bit signed int.
The C standard does not define what happens
when the result of an addition is too big for
the signed type in question. When you add 100
to 0x7fffffff0, the behaviour is undefined.

Practically speaking, what this means is that
the compiler may optimise its code, based on
the assumption that your code does not do anything
undefined. In this particular instance, the
compiler may have done something like rearranging
the test to be:
  if ( TestVar < -100 )
when optimisation was on. You could check the
intermediate assembly to see for sure.

On Dec 8, 9:45=A0am, "Paul" <-> wrote:
> I have found some code that produces different results
> depending upon =A0whether optimisation is turned on.
> Optimisation O3 inlines, optimises, and doesn't generate
> an overflow, thus =A0both red then green are turned on.
> Without optimisation, the function is called, there is an
> overflow in the =A0second case, and only the red is turned on.
> Not sure if this is already documented or not, but it seemed
> worth pointing out just in case.
>
> void TestFunction(s32 TestVar)
> {
> =A0if ((TestVar + 100) < 0)
> =A0{
> =A0 Port(TurnOn, RedLed); =A0// Turn Red Led On
> =A0}
> =A0else
> =A0{
> =A0 Port(TurnOn, GreenLed); =A0// Turn Green Led On
> =A0}
>
> }
>
> int main(void)
> {
> =A0TestFunction(-200);
>
> =A0TestFunction(0x7ffffff0);
>
> =A0while(1);
>
> }
>
> (disclamer: yes I have posted to gnu.gcc without any comment, and
> yes, I know port is not a valid c statement, its just illustrating the
> point)

The second function call leads to an arithmetic overflow, which
invokes undefined behaviour, which means anything can happen. In this
case, apparently you get different behaviour of the program with and
without compiler optimisation. This is just one of the many things
that could happen with undefined behaviour. Not the compilers fault,
but the programmer's fault.

Paul wrote:
> 
> I have found some code that produces different results depending
> upon whether optimisation is turned on.  Optimisation O3 inlines,
> optimises, and doesn't generate an overflow, thus  both red then
> green are turned on. Without optimisation, the function is called,
> there is an overflow in the  second case, and only the red is
> turned on. Not sure if this is already documented or not, but it
> seemed worth pointing out just in case.

This sort of behaviour normally indicates that you have violated
some applicable C rule.

> 
> void TestFunction(s32 TestVar) {
>  if ((TestVar + 100) < 0)  {
>   Port(TurnOn, RedLed);  // Turn Red Led On
>  }
>  else {
>   Port(TurnOn, GreenLed);  // Turn Green Led On
>  }
> }
> 
> int main(void) {
>  TestFunction(-200);
>  TestFunction(0x7ffffff0);
>  while(1);
> }
> 
> (disclamer: yes I have posted to gnu.gcc without any comment, and
> yes, I know port is not a valid c statement, its just illustrating
> the point)

In this case we have no idea what the type s32 is, but my guess is
that you have exceeded its maximum value.  Your code is not
compilable - it is missing various includes, definitions etc.  I
have also modified it slightly to take less room in the message. 
In addition // comments are not advisable in Internet messages -
use /* ... */, which wrap.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

On Mon, 8 Dec 2008 01:54:48 -0800 (PST), vippstar@gmail.com wrote in
comp.lang.c:

> On Dec 8, 11:45 am, "Paul" <-> wrote:
> > I have found some code that produces different results
> > depending upon  whether optimisation is turned on.
> > Optimisation O3 inlines, optimises, and doesn't generate
> > an overflow, thus  both red then green are turned on.
> > Without optimisation, the function is called, there is an
> > overflow in the  second case, and only the red is turned on.
> > Not sure if this is already documented or not, but it seemed
> > worth pointing out just in case.
> >
> > void TestFunction(s32 TestVar)
> > {
> >  if ((TestVar + 100) < 0)
> >  {
> >   Port(TurnOn, RedLed);  // Turn Red Led On
> >  }
> >  else
> >  {
> >   Port(TurnOn, GreenLed);  // Turn Green Led On
> >  }
> >
> > }
> >
> > int main(void)
> > {
> >  TestFunction(-200);
> >
> >  TestFunction(0x7ffffff0);
> >
> >  while(1);
> >
> > }
> >
> > (disclamer: yes I have posted to gnu.gcc without any comment, and
> > yes, I know port is not a valid c statement, its just illustrating the
> > point)
> 
> Signed integer conversion out of range is implementation-defined. Read
> the docs of your implementation about it, and you'll find out why this
> occurs. (assuming s32 means 31 value bits 1 signed bit)

Signed integer conversion if not happening here, at all.  Signed
integer overflow is, and the behavior is undefined.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

>I have found some code that produces different results
>depending upon  whether optimisation is turned on.

Part of the point of undefined behavior is to allow the compiler
to do what it wants without worrying about certain problems.
Different optimization levels may do different things.

>Optimisation O3 inlines, optimises, and doesn't generate
>an overflow, thus  both red then green are turned on.

Signed overflow causes undefined behavior.
I'm assuming that s32 is a signed 32-bit integer.
With the numbers in your program, this will cause
signed overflow.

On Dec 9, 5:21 am, Jack Klein <jackkl...@spamcop.net> wrote:
> On Mon, 8 Dec 2008 01:54:48 -0800 (PST), vipps...@gmail.com wrote in
> comp.lang.c:
>
>
>
> > On Dec 8, 11:45 am, "Paul" <-> wrote:
> > > I have found some code that produces different results
> > > depending upon  whether optimisation is turned on.
> > > Optimisation O3 inlines, optimises, and doesn't generate
> > > an overflow, thus  both red then green are turned on.
> > > Without optimisation, the function is called, there is an
> > > overflow in the  second case, and only the red is turned on.
> > > Not sure if this is already documented or not, but it seemed
> > > worth pointing out just in case.
>
> > > void TestFunction(s32 TestVar)
> > > {
> > >  if ((TestVar + 100) < 0)
> > >  {
> > >   Port(TurnOn, RedLed);  // Turn Red Led On
> > >  }
> > >  else
> > >  {
> > >   Port(TurnOn, GreenLed);  // Turn Green Led On
> > >  }
>
> > > }
>
> > > int main(void)
> > > {
> > >  TestFunction(-200);
>
> > >  TestFunction(0x7ffffff0);
>
> > >  while(1);
>
> > > }
>
> > > (disclamer: yes I have posted to gnu.gcc without any comment, and
> > > yes, I know port is not a valid c statement, its just illustrating the
> > > point)
>
> > Signed integer conversion out of range is implementation-defined. Read
> > the docs of your implementation about it, and you'll find out why this
> > occurs. (assuming s32 means 31 value bits 1 signed bit)
>
> Signed integer conversion if not happening here, at all.  Signed
> integer overflow is, and the behavior is undefined.

I'm sorry, you're right. I thought something happened in TestFunction
(0x7ffffff0) but then I realized what number that is. I see the
overflow now too.