This is the mail archive of the gcc@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: ACATS c460008 and VRP (was: Bootstrap failure on trunk: x86_64-linux-gnu)


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


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