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/30911] VRP fails to eliminate range checks in Ada code



------- Comment #53 from ebotcazou at gcc dot gnu dot org  2008-03-30 09:15 -------
I should have been more careful, there are wrong premises:

> Yes.  Amazing, isn't it ;)  The important thing to keep in mind is that
> all "target" variables must be in the range 10..20, and all "source"
> variables in the range 0..100 (see the definitions
> type S is range 0 .. 100; <-- S corresponds to Source_Type in Join_Equal
> type T is range 10 .. 20; <-- T corresponds to Target_Type in Join_Equal
> ).
> What does "must be in the range" mean?  Firstly, the program behaviour is
> undefined if a variable is outside its range.

That's not true.  The reference to an invalid value doesn't result in
undefined behavior, it is a bounded error, and the result must be some
predictable non-erroneous implementation-defined behavior.

> Secondly, the language requires the compiler to check at the point of the
> call that the values passed to the Join_Equal subprogram are in the right
> ranges.

There is no such requirement and GNAT doesn't do that by default, you need to
pass -gnatVi on the command line to activate validity check for in arguments.

> Anyway, the practical upshot is that VRP is allowed to assume that
> source_first and source_last have values in the range 0..100, and
> target_first and target_last have values in the range 10..20.  Using
> this, it should be able to eliminate all of the compiler inserted range 
> checking.

Since the premises are wrong, the conclusion doesn't hold.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911


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