--- 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 #24 from jason at gcc dot gnu dot org 2010-05-04 04:47 ---
G++ 4.6 will no longer optimize away the exit condition unless -fstrict-enums
is specified.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from jwakely dot gcc at gmail dot com 2010-01-28 10:13
---
(In reply to comment #14)
So does the C++ standard say that it is acceptable for the compiler to drop
support for an out-of-range enumeration value in a way that the programmer has
no idea it happens--but
--- 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 compiler
--- 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, the other
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-01-27 19:10
---
Well the behavior as defined by the C++ standard is explicitly unspecified so
GCC is ok to what it does.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
--- 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 warnings or errors. And I'm
--- Comment #15 from pinskia at gcc dot gnu dot org 2010-01-27 20:24
---
Think of overflow, it is overflowing the range. We don't warn for integer
overflow for loops as that would make the noise level huge for most code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
--- 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 #17 from pinskia at gcc dot gnu dot org 2010-01-27 20:43
---
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.
Is it? unsigned integers
--- 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 least
--- Comment #19 from pinskia at gcc dot gnu dot org 2010-01-27 21:08
---
Try:
#include stdio.h
main()
{
for (signed char i = 1 ; i = -2 ; i++)
{
printf( %d , i);
}
}
The first one will never overflow the integer range as you have i = 127 which
is always true with
--- Comment #20 from pinskia at gcc dot gnu dot org 2010-01-27 21:10
---
(In reply to comment #19)
Try:
Actually that code is defined as signed char++ is defined to be signed char =
(signed char) ((int)i + 1); by the C/C++ promotion rules.
#include stdio.h
main()
{
for (signed i
--- 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 in the
--- 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 assumption that it need
--- Comment #10 from paolo dot carlini at oracle dot com 2010-01-20 15:48
---
Too bad, yes.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-01-20 17:40
---
Patches welcome to add diagnostics to the C++ frontend.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
--- 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=19661action=view)
Preprocessed version of the test.cpp file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
--- 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=19662action=view)
Compiler output ready to feed to assembler--the problem can be seen here.
--
--- 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
--- 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=19663action=view)
ARM gcc 4.4.1 output at assembler input level.
This shows the same problem in gcc for the ARM.
--
--- 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=19664action=view)
Assembler input which works correctly compiled at -O1
In this sample, the exit condition is properly tested
--- 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_enum_value'. So
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-19 23:56 ---
This testcase also uses out of range enum value, so has undefined behavior as
well. For ENUM_VALUE_LAST which is a power of 2 minus 1 the for loop condition
still lets the body to be executed, then id =
--- 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 out.
So now my question is
25 matches
Mail list logo
