[Bug c/33292] New: optimizer optimizes out a piece of code

2007-09-03 Thread nicolas at dyalog dot com 
the optimizer skips a function call that should not be skipped.


-- 
   Summary: optimizer optimizes out a piece of code
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nicolas at dyalog dot com
 GCC build triplet: x86_64-pc-linux-gnu
  GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33292

[Bug c/33292] optimizer optimizes out a piece of code

2007-09-03 Thread nicolas at dyalog dot com 


--- Comment #1 from nicolas at dyalog dot com  2007-09-03 12:26 ---
Created an attachment (id=14153)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14153&action=view)
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.00 seconds
Slept -1188821606.219786 seconds

Output of debug version :
Going to sleep 1.00 seconds
Slept 1.004632 seconds


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33292

[Bug c/33292] optimizer optimizes out a piece of code

2007-09-03 Thread nicolas at dyalog dot com 


--- Comment #2 from nicolas at dyalog dot com  2007-09-03 14:07 ---
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 ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33292

[Bug c/33292] optimizer optimizes out a piece of code

2007-09-03 Thread nicolas at dyalog dot com 


--- Comment #4 from nicolas at dyalog dot com  2007-09-03 16:08 ---
That's what I feared I have lots of those in my code...
Thanks for the quick reply anyway =)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33292