This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 11 Aug 2011 13:41:24 +0000
- Subject: [Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate
- Auto-submitted: auto-generated
- References: <bug-49911-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49911
--- Comment #15 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-08-11 13:41:24 UTC ---
(In reply to comment #11)
> > So, Eric - are you still objecting to make VRP and the middle-end aligned
> > by ignoring TYPE_MIN/MAX_VALUE in VRP?
>
> Just to give a bit of context to the reader: this problem bit the Ada compiler
> since VRP had been introduced in 2004. At the time, the consensus was that the
> Ada compiler was lying to the middle-end, because objects of type T could have
> values that are outside [TYPE_MIN_VALUE:TYPE_MAX_VALUE] in some cases and this
> breaks an invariant of the middle-end. So we changed the Ada compiler in 2009.
>
> If it appears that the previous consensus was short-sighted and should now be
> reversed, fine with me, but please document what TYPE_MIN_VALUE/TYPE_MAX_VALUE
> mean under the new one. And if they don't mean anything, then remove them.
No, they still mean "nothing", but VRP assumes they are the canonical
value according to precision/signedness. Which C and C++ do not follow.
Unfortunately the C and C++ maintainers do not care (and probably have
a harder job "fixing" this because they lack the nice separation of
the "real" frontend and the interface to GENERIC).
As they mean "nothing" I would like to make VRP not assume anything about
them (and VRP is really the only one caring for TYPE_MIN/MAX_VALUE apart from
array domain uses).