User account creation filtered due to spam.

Bug 33292 - optimizer optimizes out a piece of code
Summary: optimizer optimizes out a piece of code
Status: RESOLVED DUPLICATE of bug 21920
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.1.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2007-09-03 12:17 UTC by Nicolas
Modified: 2007-09-10 16:05 UTC (History)
16 users (show)

See Also:
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:

preprocessed source of a repro (7.96 KB, text/plain)
2007-09-03 12:26 UTC, Nicolas

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas 2007-09-03 12:17:41 UTC
the optimizer skips a function call that should not be skipped.
Comment 1 Nicolas 2007-09-03 12:26:19 UTC
Created attachment 14153 [details]
preprocessed source of a repro

Sorry guys the repro is a bit complicated but i could NOT narrow it down any further. I can't understand what triggers this optimizer bug.

I refer to the optimized version when compiled with :
gcc delayopt.i -o delayopt -O3 -ggdb3 -Wall
And to the debug version when compiled with :
gcc delayopt.i -o delayopt -ggdb3 -Wall

The function that the optimizer skips is TimeValToFileTime().

If you look at the optimized disassembly, you will see that asyncSleep() does the follwing routine which is the optimized call to TimeValToFileTime() :
  400675:       imul   $0x989680,%rax,%rax
  40067c:       lea    (%rbx,%rbx,4),%rbx
  400680:       lea    (%rax,%rbx,2),%rbx
whereas nt_async_delay() doesn't and therefore uses a bad value for the variable "curr".

Output of optimized version :
Going to sleep 1.000000 seconds
Slept -1188821606.219786 seconds

Output of debug version :
Going to sleep 1.000000 seconds
Slept 1.004632 seconds
Comment 2 Nicolas 2007-09-03 14:07:52 UTC
after a bit more work it seems optimized out because diff64() doesn't observe strict aliasing... 
that was tricky because it was not the diff64() code that was snipped out but TimeValToFileTime()...
I think the compiler should either warn (strict aliasing) in diff64, or not remove TimeValToFileTime()...
Or did I miss something ?
Comment 3 Richard Biener 2007-09-03 15:20:58 UTC
The cast to (void *) disables the alias warning.  This was done on purpose, so
it's unfortunate that this in some cases makes debugging harder.

*** This bug has been marked as a duplicate of 21920 ***
Comment 4 Nicolas 2007-09-03 16:08:09 UTC
That's what I feared.... I have lots of those in my code...
Thanks for the quick reply anyway =)