[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks

2008-12-27 Thread pinskia at gcc dot gnu dot org
--- Comment #16 from pinskia at gcc dot gnu dot org 2008-12-28 02:48 --- This is still a dup of bug 3506, we don't optimize volatile at all. *** This bug has been marked as a duplicate of 3506 *** -- pinskia at gcc dot gnu dot org changed: What|Removed

[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks

2007-08-18 Thread paulmck at linux dot vnet dot ibm dot com
--- Comment #15 from paulmck at linux dot vnet dot ibm dot com 2007-08-18 22:12 --- (In reply to comment #13) (In reply to comment #11) The main concern on the recent LKML thread appeared to be code size rather than speed. One should note this only helps CISC based processors,

[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks

2007-08-18 Thread paulmck at linux dot vnet dot ibm dot com
--- Comment #14 from paulmck at linux dot vnet dot ibm dot com 2007-08-18 22:08 --- (In reply to comment #7) One should note this is actually hard to do without changing the code for 3506 also. And of course if the volatile variable in the 3506 example code was an MMIO register,

[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks

2007-08-17 Thread pinskia at gcc dot gnu dot org
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-18 01:10 --- One should note this is actually hard to do without changing the code for 3506 also. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks

2007-08-17 Thread pinskia at gcc dot gnu dot org
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-08-18 01:11 --- PS you should have reported this first to debian since you are using their modified version of GCC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks

2007-08-17 Thread pinskia at gcc dot gnu dot org
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-18 01:12 --- s/debian/Ubuntu/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102

[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks

2007-08-17 Thread pinskia at gcc dot gnu dot org
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-08-18 01:13 --- Actually as I understand it, the expanded version is slightly faster under newer x86's anyways as they don't have an extra decode stage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102

[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks

2007-08-17 Thread paulmck at linux dot vnet dot ibm dot com
--- Comment #11 from paulmck at linux dot vnet dot ibm dot com 2007-08-18 01:21 --- (In reply to comment #10) Actually as I understand it, the expanded version is slightly faster under newer x86's anyways as they don't have an extra decode stage. The main concern on the recent LKML

[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks

2007-08-17 Thread paulmck at linux dot vnet dot ibm dot com
--- Comment #12 from paulmck at linux dot vnet dot ibm dot com 2007-08-18 01:23 --- (In reply to comment #9) s/debian/Ubuntu/ Please accept my apologies for skipping that step -- I wasn't aware of this. Should I replicate this bug at Ubuntu, or is this strictly advice for future bug

[Bug middle-end/33102] volatile excessively suppresses optimizations in range checks

2007-08-17 Thread pinskia at gcc dot gnu dot org
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-08-18 01:25 --- (In reply to comment #11) The main concern on the recent LKML thread appeared to be code size rather than speed. One should note this only helps CISC based processors, it will not help stuff like PowerPC