[Bug c/46899] compiler optimization

2010-12-13 Thread eskil at obsession dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899 --- Comment #11 from Eskil Steenberg 2010-12-13 14:09:46 UTC --- Hi > The execution of an undefined operation produces an undefined value, and > any further operation becomes undefined. My argument is that, at compile time this isn't known. Jus

[Bug c/46899] compiler optimization

2010-12-12 Thread sch...@linux-m68k.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899 --- Comment #10 from Andreas Schwab 2010-12-13 00:21:09 UTC --- The execution of an undefined operation produces an undefined value, and any further operation becomes undefined.

[Bug c/46899] compiler optimization

2010-12-12 Thread eskil at obsession dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899 --- Comment #9 from Eskil Steenberg 2010-12-12 22:23:36 UTC --- Hi > No, it is possible because the value is undefined so both the if being > false and the printout happening can happen. But undefined still means that the variable c has a value

[Bug c/46899] compiler optimization

2010-12-12 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899 --- Comment #8 from Andrew Pinski 2010-12-12 21:52:40 UTC --- >This output should not be possible No, it is possible because the value is undefined so both the if being false and the printout happening can happen.

[Bug c/46899] compiler optimization

2010-12-12 Thread eskil at obsession dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899 --- Comment #7 from Eskil Steenberg 2010-12-12 21:46:18 UTC --- Hi > No, it is undefined at runtime. This again is not an undefined behavior > at > compile time but rather at runtime. What that means is the behavior > cannot be > diagnosed (at

[Bug c/46899] compiler optimization

2010-12-12 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899 --- Comment #6 from Andrew Pinski 2010-12-12 21:02:55 UTC --- >it is undefined at compile time? No, it is undefined at runtime. This again is not an undefined behavior at compile time but rather at runtime. What that means is the behavior cann

[Bug c/46899] compiler optimization

2010-12-12 Thread eskil at obsession dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899 --- Comment #5 from Eskil Steenberg 2010-12-12 12:30:15 UTC --- Hi >>void my_func(unsigned short a, unsigned short c) >>{ >>unsigned int b; >> >>b = a * c; > > There is no overflow here since this unsigned integers wrap and don't > overf

[Bug c/46899] compiler optimization

2010-12-12 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|

[Bug c/46899] compiler optimization

2010-12-12 Thread eskil at obsession dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899 --- Comment #3 from Eskil Steenberg 2010-12-12 09:09:54 UTC --- Hi > (In reply to comment #1) >> There is no integer overflow in the code provided at all. Sorry it underflows. How about this: void my_func(unsigned short a, unsigned short c) {

[Bug c/46899] compiler optimization

2010-12-11 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899 --- Comment #2 from Andrew Pinski 2010-12-12 01:55:56 UTC --- (In reply to comment #1) > There is no integer overflow in the code provided at all. Even if there was, the standard says the behavior is undefined which means anything can happen.

[Bug c/46899] compiler optimization

2010-12-11 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899 --- Comment #1 from Andrew Pinski 2010-12-12 01:54:16 UTC --- There is no integer overflow in the code provided at all.