--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-08 08:39 ---
The middle-end trusts the C++ frontends TYPE_MIN/MAX_VALUE which is according
to the C++ standard the range for an (unsigned) integer type with a precision
just as wide as to represent all values in the enum.
I did
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-08 08:40 ---
Oh, and actually I don't think this bug is a wrong-code bug but at most
a quality of implementation issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43680
--- Comment #7 from manu at gcc dot gnu dot org 2010-04-08 09:02 ---
(In reply to comment #1)
Don't we already have a warning that warns about assigning values outside the
range of an enum?
pr43680.C:14:26: warning: the result of the conversion is unspecified because
â5â is
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-04-08 10:48
---
I did want to remove that optimization at some point but people complained
that it was highly useful (the C++ FE can still set TYPE_PRECISION
accordingly if it wants to, but TYPE_MIN/MAX_VALUE cannot really be
--- Comment #9 from bangerth at gmail dot com 2010-04-08 12:53 ---
I'm not saying we *should* apply a mask (in fact, I think that would be
silly). But we *could*, and if we did then VRP's actions might lead to
faster but not different code.
All I want to say is that VRP is a powerful
--- Comment #10 from jason at gcc dot gnu dot org 2010-04-08 15:57 ---
@7: But -Wconversion only warns if it knows the constant value, it doesn't warn
about converting from an arbitrary int variable such as (importantly) a loop
counter.
@5: It seems appropriate to me for VRP to
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-04-08 22:30
---
See also:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41425
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37281
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36170
--- Comment #12 from jason at gcc dot gnu dot org 2010-04-09 04:44 ---
Created an attachment (id=20343)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20343action=view)
patch
This patch causes the compiler to avoid this optimization while preserving all
the related warnings (except
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Known to fail||4.3.5 4.4.3
--- Comment #1 from bangerth at gmail dot com 2010-04-07 23:16 ---
(In reply to comment #0)
I think the C++ standard can definitely be read to allow this optimization
I would most definitely think so. 7.2/6 specifically says that the values
an enum variable can take on are, in your
--- Comment #2 from jason at gcc dot gnu dot org 2010-04-08 02:58 ---
Except that the conversion is defined to produce an unspecified value, not
undefined behavior. A strict reading of that suggests to me that the compiler
is supposed to truncate on conversion so the resulting value is
--- Comment #3 from bangerth at math dot tamu dot edu 2010-04-08 03:18
---
Subject: Re: G++ is too aggressive in optimizing away bounds checking with
enums
Except that the conversion is defined to produce an unspecified
value, not undefined behavior. A strict reading of that
--- Comment #4 from jason at gcc dot gnu dot org 2010-04-08 05:19 ---
Yes, that's my interpretation as well. But it's not what we do now, and
requiring a mask on conversion seems like it would hurt performance more than
just doing the comparison.
--
14 matches
Mail list logo
