This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate


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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]