--- Comment #25 from tony3 at GarlandConsulting dot us 2010-05-04 16:06
---
(In reply to comment #24)
> G++ 4.6 will no longer optimize away the exit condition unless -fstrict-enums
> is specified.
>
I'm very encouraged by this. Thanks for responding to this concern
--- Comment #23 from tony3 at GarlandConsulting dot us 2010-01-28 17:16
---
Jonathan,
Thanks for explaining that operation outside the norm is unspecified such
that the compiler can do anything and everything.
>I think a warning for this would be helpful, but asking for the compi
--- Comment #21 from tony3 at GarlandConsulting dot us 2010-01-27 22:24
---
Thanks for that last example which does illustrate a condition where -O0
terminates and -O2 never does. So we've established there are other looping
situations where the compiler does the same thing as i
--- Comment #18 from tony3 at GarlandConsulting dot us 2010-01-27 20:56
---
Thanks for the correction - I missed that aspect.
However, a signed version of my simple example still upholds what I'm trying to
comment on: it behaves the same way regardless of optimization level (at
--- Comment #16 from tony3 at GarlandConsulting dot us 2010-01-27 20:39
---
Your analogy is helpful, but a bit like comparing apples with oranges. The
reason being that the compiler executes integer overflow loops identically for
all optimization settings.
The following program
--- Comment #14 from tony3 at GarlandConsulting dot us 2010-01-27 20:03
---
Yes, I'm now aware that gcc "meets the minimal requirements" of the C++
standard. That isn't my point. My point is whether what it does is acceptable
behavior given that there are no warn
--- Comment #12 from tony3 at GarlandConsulting dot us 2010-01-27 19:01
---
Here's a modified version of the original code which is intended to show just
how arbitrary the compiler optimization is from a programmer's perspective.
Here are two loops: one exits as expected,
--- Comment #9 from tony3 at GarlandConsulting dot us 2010-01-20 15:42
---
I am reopening this bug if only because I'd like to get a response to my
previous comments.
I can appreciated that, in your view, the compiler is 'technically correct' in
making the assumpti
--- Comment #8 from tony3 at GarlandConsulting dot us 2010-01-20 00:18
---
I see what you mean. I was looking at the "wrong side" of the "<=" and not
thinking about the reality that it would have to exceed the last valid value.
Pretty obvious once you point it o
--- Comment #6 from tony3 at GarlandConsulting dot us 2010-01-19 23:05
---
There is a related bug here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36170
But unlike that bug which uses an out-of-range enum value, this case does not.
We are testing 'value <= max_valid_en
--- Comment #5 from tony3 at GarlandConsulting dot us 2010-01-19 22:58
---
Created an attachment (id=19664)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19664&action=view)
Assembler input which works correctly compiled at -O1
In this sample, the exit condition is p
--- Comment #4 from tony3 at GarlandConsulting dot us 2010-01-19 22:56
---
Created an attachment (id=19663)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19663&action=view)
ARM gcc 4.4.1 output at assembler input level.
This shows the same problem in gcc for
--- Comment #3 from tony3 at GarlandConsulting dot us 2010-01-19 22:54
---
Here is the compiler information:
g++ -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--infodir=/usr/share/info --mandir=/usr/share
--- Comment #2 from tony3 at GarlandConsulting dot us 2010-01-19 22:53
---
Created an attachment (id=19662)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19662&action=view)
Compiler output ready to feed to assembler--the problem can be seen here.
--
http://gcc.
--- Comment #1 from tony3 at GarlandConsulting dot us 2010-01-19 22:53
---
Created an attachment (id=19661)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19661&action=view)
Preprocessed version of the test.cpp file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
n optimized out.
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tony3 at GarlandConsulting dot us
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
16 matches
Mail list logo
