This is the mail archive of the gcc-patches@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]

Re: Handling non-constant bounds in extract_range_from_cond


    But the whole point of 'Valid is to have a way to tell the compiler to
    forget about these optimizations, so performance isn't really
    an argument.

I wasn't making performance as an argument, but I still think it's overkill
to invent some mechanism to tell the optimizer not to optimize something just
for this case.

    X in Foo can be optimized at will, just as X <= B, etc...

    X'Valid shoud not, that's the usefullness of this construct.

Although technically speaking, you're right, and generally more Ada
programmers read the standard than C programmers, it may still be unfriendly
to do this.  Robert just opened an internal bug report at ACT early yesterday
afternoon suggesting it would be "friendlier" to convert "X in Foo" to
X'Valid in the above case.

And the motivation was a bug report from a programmer at one of the largest
defense contractors who said, in part, "Moreover, the Text_IO statements I
added to Restore_Daemon_Data_From_Restart (see output file out.txt) show
surprising behavior: Port_Number'First and 'Last are 7300 and 11000 as
expected, but my if-tests on lines 126 and 132 that should raise
Obsolete_File do not do so."

Those tests are "if Element.Port_Number not in Port_Number_Type" and
	 
      if    Element.Port_Number < Port_Number_Type'First
         or Element.Port_Number > Port_Number_Type'Last

So my feeling is that standing to the letter of the language standard
here is actively unhelpful given that legitimate opportunities to
apply this optimization are few and far between.


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