Re: ACATS c460008 and VRP (was: Bootstrap failure on trunk: x86_64-linux-gnu)

Re: ACATS c460008 and VRP (was: Bootstrap failure on trunk: x86_64-linux-gnu)

[Richard Kenner]

    It looks like this one needs overflow checking to pass (-gnato):

ACATS should aways be run with -gnato since that's the only way to
get the behavior mandated by RM.  Why are we running it without it?  Is
this new?  Certainly -gnato was used during validations.

    Richard, Arnaud, could you check amongst GNAT experts if for such
    types (non power of two modulus), it's not worth enabling overflow
    checks by default now that we have VRP doing non trivial
    optimisations? People using non power of two modulus are not caring
    for performance anyway, so having a compliant implementation by
    default won't harm.

Hardly worth writing the code to bother with that given how rare
such things are ...

Re: ACATS c460008 and VRP (was: Bootstrap failure on trunk: x86_64-linux-gnu)

[Laurent GUERBY]

On Wed, 2006-03-01 at 18:48 -0500, Richard Kenner wrote:
>     It looks like this one needs overflow checking to pass (-gnato):
> 
> ACATS should aways be run with -gnato since that's the only way to
> get the behavior mandated by RM.  Why are we running it without it?  Is
> this new?  Certainly -gnato was used during validations.

On GCC we use -gnato on tests known to need it
(/gcc/testsuite/ada/acats/overflow.lst) since we want to test
flags the typical GCC/Ada user does use and not what official validation
requires (which is -gnato -gnatE IIRC).

VRP might now force us to update the overflow list but I'm not sure
about switching to a full -gnato everywhere.

>     Richard, Arnaud, could you check amongst GNAT experts if for such
>     types (non power of two modulus), it's not worth enabling overflow
>     checks by default now that we have VRP doing non trivial
>     optimisations? People using non power of two modulus are not caring
>     for performance anyway, so having a compliant implementation by
>     default won't harm.
> 
> Hardly worth writing the code to bother with that given how rare
> such things are ...

True.

Laurent

Re: ACATS c460008 and VRP

[Robert Dewar]

Laurent GUERBY wrote:

> VRP might now force us to update the overflow list but I'm not sure
> about switching to a full -gnato everywhere.

well you can expect some fiddling each version if you work this way

Re: ACATS c460008 and VRP

[Laurent GUERBY]

On Thu, 2006-03-02 at 01:34 +0100, Robert Dewar wrote:
> Laurent GUERBY wrote:
> 
> > VRP might now force us to update the overflow list but I'm not sure
> > about switching to a full -gnato everywhere.
> 
> well you can expect some fiddling each version if you work this way

The list for -gnato tests hasn't changed since it's initial
import into GCC in 2003-10-27, and was present in early
versions of acats4gnat may be a year before. Not yet in the
"fiddling each version" category :).

Laurent

Re: ACATS c460008 and VRP

[Robert Dewar]

Laurent GUERBY wrote:
> On Thu, 2006-03-02 at 01:34 +0100, Robert Dewar wrote:
>> Laurent GUERBY wrote:
>>
>>> VRP might now force us to update the overflow list but I'm not sure
>>> about switching to a full -gnato everywhere.
>> well you can expect some fiddling each version if you work this way
> 
> The list for -gnato tests hasn't changed since it's initial
> import into GCC in 2003-10-27, and was present in early
> versions of acats4gnat may be a year before. Not yet in the
> "fiddling each version" category :).

It might be worth noting in documentation somewhere that this procedure
for running ACATS (using different switches on different tests) does
not conform to the standardized procedure for running these tests
(standardized = relevant ISO standard).

Re: ACATS c460008 and VRP

[Laurent GUERBY]

On Sat, 2006-03-04 at 07:29 -0500, Robert Dewar wrote:
> Laurent GUERBY wrote:
> > On Thu, 2006-03-02 at 01:34 +0100, Robert Dewar wrote:
> >> Laurent GUERBY wrote:
> >>
> >>> VRP might now force us to update the overflow list but I'm not sure
> >>> about switching to a full -gnato everywhere.
> >> well you can expect some fiddling each version if you work this way
> > 
> > The list for -gnato tests hasn't changed since it's initial
> > import into GCC in 2003-10-27, and was present in early
> > versions of acats4gnat may be a year before. Not yet in the
> > "fiddling each version" category :).
> 
> It might be worth noting in documentation somewhere that this procedure
> for running ACATS (using different switches on different tests) does
> not conform to the standardized procedure for running these tests
> (standardized = relevant ISO standard).

This was implied in README.ACATS4GNAT of my original separate packaging
"acats4gnat", but it looks like I forgot to add it to the GCC sources, I
will propose a patch shortly.

Laurent

<<
[...]
Date: Wed, 22 Nov 2000 00:56:03 +0100

Just a few notes on the ACATS scripts made available:

- The acats4gnat script are not designed to do an official validation,
just as a way to get all executable tests to run as easily as
possible, and for this purpose I've tried to keep them as simple as
possible. Non executable tests are not even looked at.

- Adaptation to a cross environment should be easy since the script
uses the regular "gnatmake" command, and there is one line to launch
the test executable. I haven't tried to do so yet.

- The scripts ACT uses (and Joel mentions) are far more complicated
because they're addressing the process of a real Ada validation, and I
worked on them while working for ACT, but I believe Gary Dismukes
wrote the initial version of them.

- ACT has kindly contributed their ACATS configuration files which I
hacked a bit.

- I worked for ACT, but I no longer do, at my new work we're client of
ACT services in the non-embedded work.

- We're all waiting for the GNAT sources integration into GCC CVS
repository, which should solve a lot of problems with GNAT/RTEMS.

- When this happens I'll try to provide an integrated GCC/Ada testing
driver, and GNAT/RTEMS support is high on the list ;-).

- Feel free to contact me through this list or at <guerby@acm.org> if
you need help, answers, have suspicious looking failures or have
contribution to make. I read my personal email from 2000 to 2300 Paris
time, if I don't answer after a week, please resend, this is a
processing mistake on my side ;-).
>>

Re: ACATS c460008 and VRP (was: Bootstrap failure on trunk: x86_64-linux-gnu)

[Richard Kenner]

> On GCC we use -gnato on tests known to need it
> (/gcc/testsuite/ada/acats/overflow.lst) since we want to test
> flags the typical GCC/Ada user does use and not what official validation
> requires (which is -gnato -gnatE IIRC).

But you're running a test that's *part* of the official validation and
it assumes the options that implement the full language (including overflow
checks).  I don't see the relevance of what options the "typical user"
specifies: this isn't typical user *code*!

Re: ACATS c460008 and VRP (was: Bootstrap failure on trunk: x86_64-linux-gnu)

[Richard Kenner]

> Richard, Arnaud, could you check amongst GNAT experts if for such types
> (non power of two modulus), it's not worth enabling overflow checks by
> default now that we have VRP doing non trivial optimisations? People
> using non power of two modulus are not caring for performance anyway, so
> having a compliant implementation by default won't harm.

I don't think that either of us are the best people to ask, but my sense
is that it's not a great idea to have the default overflow handling differ
between types.  For one thing, what option would then disable overflow
checking for those types?

-gnato is required for ACATS tests because you need -gnato for RM compliance.

Re: ACATS c460008 and VRP (was: Bootstrap failure on trunk: x86_64-linux-gnu)

[Laurent GUERBY]

The test still fails at -O2 -gnato... All the current FAIL
still fail with -gnato, and we even have two additional failures
(unexpected constraint_error):

c45532e 
c45532g

So we have to look carefully at what the front-end does with modular
types here.

Note that cxa4025, cxa4028, cxa4033 are likely to be due to coding
error in the RTS.

Laurent

On Thu, 2006-03-02 at 00:37 +0100, Laurent GUERBY wrote:
> Ok this test is checking a corner case of the language, namely
> non power of two modular types.
> 
> It looks like this one needs overflow checking to pass (-gnato):
> 
> $ gnatmake -f -I../../../support/ c460008.adb
> gcc -c -I../../../support/ c460008.adb
> gcc -c -I./ -I../../../support/ -I- /home/guerby/work/gcc/build/build-head-20060301T130355/gcc/testsuite/ada/acats/support/report.adb
> gnatbind -aO./ -I../../../support/ -I- -x c460008.ali
> gnatlink c460008.ali
> $ ./c460008
> 
> ,.,. C460008 ACATS 2.5 06-03-02 00:28:43
> ---- C460008 Check that conversion to a modular type raises
>                 Constraint_Error when the operand value is outside the
>                 base range of the modular type.
>    * C460008 Fix expected Constraint_Error D2S Dynamic, Negative.
>    - C460008 Value of 251 not properly converted.
>    * C460008 Fix expected Constraint_Error D2S Static,  Over_Mod.
>    - C460008 Value of 204 not properly converted.
>    * C460008 Fix expected Constraint_Error D28 Static, Negative.
>    - C460008 Value of 255 not properly converted.
>    * C460008 Fix expected Constraint_Error D28 Static,  At_Mod.
>    - C460008 Value of 0 not properly converted.
>    * C460008 Fix expected Constraint_Error D28 Dynamic, Over_Mod.
>    - C460008 Value of 209 not properly converted.
> **** C460008 FAILED ****************************.
> 
> $ gnatmake -f -gnato -I../../../support/ c460008.adb
> gcc -c -gnato -I../../../support/ c460008.adb
> gcc -c -I./ -gnato -I../../../support/ -I- /home/guerby/work/gcc/build/build-head-20060301T130355/gcc/testsuite/ada/acats/support/report.adb
> gnatbind -aO./ -I../../../support/ -I- -x c460008.ali
> gnatlink c460008.ali
> $ ./c460008
> 
> ,.,. C460008 ACATS 2.5 06-03-02 00:27:21
> ---- C460008 Check that conversion to a modular type raises
>                 Constraint_Error when the operand value is outside the
>                 base range of the modular type.
> ==== C460008 PASSED ============================.
> 
> I'm rerunning the whole testsuite on x86_64-linux with an edited
> gcc/testsuite/ada/acats/run_all.sh that includes -gnato for all tests:
> 
> gnatflags="-gnatws -gnato"
> 
> We'll see what new ACATS FAIL go away.
> 
> Richard, Arnaud, could you check amongst GNAT experts if for such types
> (non power of two modulus), it's not worth enabling overflow checks by
> default now that we have VRP doing non trivial optimisations? People
> using non power of two modulus are not caring for performance anyway, so
> having a compliant implementation by default won't harm.
> 
> Laurent
> 
> On Wed, 2006-03-01 at 15:35 -0700, Jeffrey A Law wrote:
> > Here's the next segment in the ongoing saga of VRP vs Ada...
> > Not surprisingly we have another case where an object gets a
> > value outside of its TYPE_MIN_VALUE/TYPE_MAX_VALUE defined range.
> > 
> > Investigating the c460008 testsuite failure we have the following
> > code for Fixed_To_Short before VRP runs:
> > 
> > 
> > 
> > 
> >   # BLOCK 4
> >   # PRED: 3 (fallthru,exec)
> >   D.1294_13 = D.1294_12;
> >   D.1309_32 = for_the_value_31 /[rd] 1000000000;
> >   D.1310_33 = (UNSIGNED_64) D.1309_32;
> >   if (D.1310_33 > 255) goto <L0>; else goto <L1>;
> >   # SUCC: 5 (true,exec) 6 (false,exec)
> > 
> >   # BLOCK 5 
> >   # PRED: 4 (true,exec)
> > <L0>:;
> >   __gnat_rcheck_10 ("c460008.adb", 162);
> >   # SUCC: 13 (ab,eh,exec) 18 (ab,eh,exec) 29 (ab,eh,exec)
> >   
> >   # BLOCK 6
> >   # PRED: 4 (false,exec)
> > <L1>:;
> >   iftmp.78_63 = D.1309_32;
> >   iftmp.78_64 = D.1309_32;
> >   D.1316_65 = (c460008__unsigned_edge_8) D.1309_32;
> >   if (D.1316_65 == 255) goto <L3>; else goto <L4>;
> >   # SUCC: 7 (true,exec) 8 (false,exec)
> > 
> > D.1309_32's type has the range [0x8000000000000000,0x7fffffffffffffff]
> > with 64bit precision.
> > 
> > In block #6 we cast the value of D.1309_32 into a smaller type,
> > specifically c460008__unsigned_edge_8 and store the result into
> > D.1316_64 which has type c460008__unsigned_edge_8.
> > 
> > c460008__unsigned_edge_8's range is [ ,254] with 8 bit precision.
> > 
> > Note carefully that with the range [ ,254] (according to
> > TYPE_MIN_VALUE/TYPE_MAX_VALUE) that the test
> > 
> > if (D.1316_65 == 255)
> > 
> > Must always be false.  So VRP, as expected, wipes out test
> > completely.
> > 
> > The problem (of course) is D.1316_65 can and does actually hold
> > values outside the range [ ,254] at runtime.  For example, it could
> > hold the value 255 if D.1309_32 had the value 255, which would occur
> > if for_the_value_31 held the value 255000000000.
> > 
> > Someone with a better knowledge of Ada is going to need to step
> > in here, but based on the type information provided by the Ada
> > front-end, VRP is doing the right thing here.
> > 
> > 
> > Jeff
> > 
> > 

Re: ACATS c460008 and VRP (was: Bootstrap failure on trunk: x86_64-linux-gnu)

[Eric Botcazou]

> Richard, Arnaud, could you check amongst GNAT experts if for such types
> (non power of two modulus), it's not worth enabling overflow checks by
> default now that we have VRP doing non trivial optimisations? People
> using non power of two modulus are not caring for performance anyway, so
> having a compliant implementation by default won't harm.

Changing compilation options to paper over potential bugs is IMHO not the best 
approach, especially if the new options are little used.  And the current 
implementation of -gnato makes it a "heavy" option, not a "light" one.

-- 
Eric Botcazou

Re: ACATS c460008 and VRP (was: Bootstrap failure on trunk: x86_64-linux-gnu)

[Richard Kenner]

    On GCC we use -gnato on tests known to need it
    (/gcc/testsuite/ada/acats/overflow.lst) since we want to test flags
    the typical GCC/Ada user does use and not what official validation
    requires (which is -gnato -gnatE IIRC).

Well that would make the most sense if the code in the ACATS tests was
typical of what users *write* but, as we both know, it's mostly
boundary cases in the language ...

ACATS c460008 and VRP (was: Bootstrap failure on trunk: x86_64-linux-gnu)

[Laurent GUERBY]

Ok this test is checking a corner case of the language, namely
non power of two modular types.

It looks like this one needs overflow checking to pass (-gnato):

$ gnatmake -f -I../../../support/ c460008.adb
gcc -c -I../../../support/ c460008.adb
gcc -c -I./ -I../../../support/ -I- /home/guerby/work/gcc/build/build-head-20060301T130355/gcc/testsuite/ada/acats/support/report.adb
gnatbind -aO./ -I../../../support/ -I- -x c460008.ali
gnatlink c460008.ali
$ ./c460008

,.,. C460008 ACATS 2.5 06-03-02 00:28:43
---- C460008 Check that conversion to a modular type raises
                Constraint_Error when the operand value is outside the
                base range of the modular type.
   * C460008 Fix expected Constraint_Error D2S Dynamic, Negative.
   - C460008 Value of 251 not properly converted.
   * C460008 Fix expected Constraint_Error D2S Static,  Over_Mod.
   - C460008 Value of 204 not properly converted.
   * C460008 Fix expected Constraint_Error D28 Static, Negative.
   - C460008 Value of 255 not properly converted.
   * C460008 Fix expected Constraint_Error D28 Static,  At_Mod.
   - C460008 Value of 0 not properly converted.
   * C460008 Fix expected Constraint_Error D28 Dynamic, Over_Mod.
   - C460008 Value of 209 not properly converted.
**** C460008 FAILED ****************************.

$ gnatmake -f -gnato -I../../../support/ c460008.adb
gcc -c -gnato -I../../../support/ c460008.adb
gcc -c -I./ -gnato -I../../../support/ -I- /home/guerby/work/gcc/build/build-head-20060301T130355/gcc/testsuite/ada/acats/support/report.adb
gnatbind -aO./ -I../../../support/ -I- -x c460008.ali
gnatlink c460008.ali
$ ./c460008

,.,. C460008 ACATS 2.5 06-03-02 00:27:21
---- C460008 Check that conversion to a modular type raises
                Constraint_Error when the operand value is outside the
                base range of the modular type.
==== C460008 PASSED ============================.

I'm rerunning the whole testsuite on x86_64-linux with an edited
gcc/testsuite/ada/acats/run_all.sh that includes -gnato for all tests:

gnatflags="-gnatws -gnato"

We'll see what new ACATS FAIL go away.

Richard, Arnaud, could you check amongst GNAT experts if for such types
(non power of two modulus), it's not worth enabling overflow checks by
default now that we have VRP doing non trivial optimisations? People
using non power of two modulus are not caring for performance anyway, so
having a compliant implementation by default won't harm.

Laurent

On Wed, 2006-03-01 at 15:35 -0700, Jeffrey A Law wrote:
> Here's the next segment in the ongoing saga of VRP vs Ada...
> Not surprisingly we have another case where an object gets a
> value outside of its TYPE_MIN_VALUE/TYPE_MAX_VALUE defined range.
> 
> Investigating the c460008 testsuite failure we have the following
> code for Fixed_To_Short before VRP runs:
> 
> 
> 
> 
>   # BLOCK 4
>   # PRED: 3 (fallthru,exec)
>   D.1294_13 = D.1294_12;
>   D.1309_32 = for_the_value_31 /[rd] 1000000000;
>   D.1310_33 = (UNSIGNED_64) D.1309_32;
>   if (D.1310_33 > 255) goto <L0>; else goto <L1>;
>   # SUCC: 5 (true,exec) 6 (false,exec)
> 
>   # BLOCK 5 
>   # PRED: 4 (true,exec)
> <L0>:;
>   __gnat_rcheck_10 ("c460008.adb", 162);
>   # SUCC: 13 (ab,eh,exec) 18 (ab,eh,exec) 29 (ab,eh,exec)
>   
>   # BLOCK 6
>   # PRED: 4 (false,exec)
> <L1>:;
>   iftmp.78_63 = D.1309_32;
>   iftmp.78_64 = D.1309_32;
>   D.1316_65 = (c460008__unsigned_edge_8) D.1309_32;
>   if (D.1316_65 == 255) goto <L3>; else goto <L4>;
>   # SUCC: 7 (true,exec) 8 (false,exec)
> 
> D.1309_32's type has the range [0x8000000000000000,0x7fffffffffffffff]
> with 64bit precision.
> 
> In block #6 we cast the value of D.1309_32 into a smaller type,
> specifically c460008__unsigned_edge_8 and store the result into
> D.1316_64 which has type c460008__unsigned_edge_8.
> 
> c460008__unsigned_edge_8's range is [ ,254] with 8 bit precision.
> 
> Note carefully that with the range [ ,254] (according to
> TYPE_MIN_VALUE/TYPE_MAX_VALUE) that the test
> 
> if (D.1316_65 == 255)
> 
> Must always be false.  So VRP, as expected, wipes out test
> completely.
> 
> The problem (of course) is D.1316_65 can and does actually hold
> values outside the range [ ,254] at runtime.  For example, it could
> hold the value 255 if D.1309_32 had the value 255, which would occur
> if for_the_value_31 held the value 255000000000.
> 
> Someone with a better knowledge of Ada is going to need to step
> in here, but based on the type information provided by the Ada
> front-end, VRP is doing the right thing here.
> 
> 
> Jeff
> 
>