Automatics in Equivalences failures

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Automatics in Equivalences failures

Mark Eggleston
Thanks to Tobias Burnius for fixing the dg directives in test cases.

Now that the test cases for "Automatics in equivalence" (svn revision
274565) are actually being run, test failures are occurring.

I've investigated the test failures for auto-in-equiv_3.f90:

- -O1, -O2, -O3 and -Os fail
- -O1 fails because the check of address fails due to a 40 byte
difference in location of the stack
- -O2, -O3 and -Os fail due the evaluation of an .and. operation
returning .false. when both operands are .true..

The test case could be better and should probably be replaced with a
better one.

I've discovered that -finit-local-zero doesn't work if the local
variable is in an equivalence statement where at least one the variables
has an AUTOMATIC attribute.

What is the best way of dealing with this? Reverting the commit and
resubmitting a corrected patch when it's been fixed?

regards,

Mark


--
https://www.codethink.co.uk/privacy.html

Reply | Threaded
Open this post in threaded view
|

Re: Automatics in Equivalences failures

Tobias Burnus-3
Hi Mark, hi all,

On 9/30/19 11:06 AM, Mark Eggleston wrote:
> Thanks to Tobias Burnius for fixing the dg directives in test cases.

Well, I only committed the patch – and saw the fallout. Manfred did the
actual patch (thanks!).


> I've investigated the test failures for auto-in-equiv_3.f90:
>
> - -O1, -O2, -O3 and -Os fail
> - -O1 fails because the check of address fails due to a 40 byte
> difference in location of the stack
> - -O2, -O3 and -Os fail due the evaluation of an .and. operation
> returning .false. when both operands are .true..
>
> The test case could be better and should probably be replaced with a
> better one.
> […]
> What is the best way of dealing with this? Reverting the commit and
> resubmitting a corrected patch when it's been fixed?


If you think that you will fix in relatively soonish, simply leave it as
is. When creating patches, one watches for new fails and ignores
existing fails.

If it takes longer, one could XPASS it (expected to pass, but know to
currently fail) – or one could apply "-O0" to dg-options, such that this
test case only gets compiled (n-times) with -O0 instead of having
different optimization options.

Cheers,

Tobias

Reply | Threaded
Open this post in threaded view
|

Re: Automatics in Equivalences failures

Mark Eggleston
In reply to this post by Mark Eggleston

On 30/09/2019 10:06, Mark Eggleston wrote:

> Thanks to Tobias Burnius for fixing the dg directives in test cases.
>
> Now that the test cases for "Automatics in equivalence" (svn revision
> 274565) are actually being run, test failures are occurring.
>
> I've investigated the test failures for auto-in-equiv_3.f90:
>
> - -O1, -O2, -O3 and -Os fail
> - -O1 fails because the check of address fails due to a 40 byte
> difference in location of the stack
> - -O2, -O3 and -Os fail due the evaluation of an .and. operation
> returning .false. when both operands are .true..
>
> The test case could be better and should probably be replaced with a
> better one.
>
> I've discovered that -finit-local-zero doesn't work if the local
> variable is in an equivalence statement where at least one the
> variables has an AUTOMATIC attribute.
On further investigation I find that local variables are not initialised
if the EQUIVALENCE attribute is set (build_default_init_expr). So this
is expected behaviour. So back to the drawing board for a suitable test
case.
>
> What is the best way of dealing with this? Reverting the commit and
> resubmitting a corrected patch when it's been fixed?
>
> regards,
>
> Mark
>
>
--
https://www.codethink.co.uk/privacy.html

Reply | Threaded
Open this post in threaded view
|

[PATCH, Fortran] Fix Automatics in equivalence test cases was Re: Automatics in Equivalences failures

Mark Eggleston
Please find attached a patch to replace the test cases for "Automatic in
equivalence".

ChangeLog:

     Mark Eggleston <[hidden email]>

     * gfortran.dg/auto_in_equiv_1.f90: Deleted.
     * gfortran.dg/auto_in_equiv_2.f90: Deleted.
     * gfortran.dg/auto_in_equiv_3.f90: Deleted.
     * gfortran.dg/automatics_in_equivalence_1.f90: New test.
     * gfortran.dg/automatics_in_equivalence_2.f90: New test.

OK to commit?

regards,

Mark

On 30/09/2019 13:18, Mark Eggleston wrote:

>
> On 30/09/2019 10:06, Mark Eggleston wrote:
>> Thanks to Tobias Burnius for fixing the dg directives in test cases.
>>
>> Now that the test cases for "Automatics in equivalence" (svn revision
>> 274565) are actually being run, test failures are occurring.
>>
>> I've investigated the test failures for auto-in-equiv_3.f90:
>>
>> - -O1, -O2, -O3 and -Os fail
>> - -O1 fails because the check of address fails due to a 40 byte
>> difference in location of the stack
>> - -O2, -O3 and -Os fail due the evaluation of an .and. operation
>> returning .false. when both operands are .true..
>>
>> The test case could be better and should probably be replaced with a
>> better one.
>>
>> I've discovered that -finit-local-zero doesn't work if the local
>> variable is in an equivalence statement where at least one the
>> variables has an AUTOMATIC attribute.
> On further investigation I find that local variables are not
> initialised if the EQUIVALENCE attribute is set
> (build_default_init_expr). So this is expected behaviour. So back to
> the drawing board for a suitable test case.
>>
>> What is the best way of dealing with this? Reverting the commit and
>> resubmitting a corrected patch when it's been fixed?
>>
>> regards,
>>
>> Mark
>>
>>
--
https://www.codethink.co.uk/privacy.html


0001-Replace-test-cases-for-Automatics-in-equivalence.patch (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH, Fortran] Fix Automatics in equivalence test cases was Re: Automatics in Equivalences failures

Jakub Jelinek
On Wed, Oct 02, 2019 at 02:36:55PM +0100, Mark Eggleston wrote:
> ChangeLog:
>
>     Mark Eggleston <[hidden email]>
>
>     * gfortran.dg/auto_in_equiv_1.f90: Deleted.
>     * gfortran.dg/auto_in_equiv_2.f90: Deleted.
>     * gfortran.dg/auto_in_equiv_3.f90: Deleted.
>     * gfortran.dg/automatics_in_equivalence_1.f90: New test.
>     * gfortran.dg/automatics_in_equivalence_2.f90: New test.

Why the so long testcase names?  Just replacing the first old test with the
new one would be IMHO better.

> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/automatics_in_equivalence_2.f90
> @@ -0,0 +1,37 @@
> +! { dg-do run }
> +! { dg-options "-fdec-static -frecursive -fno-automatic" }
...

1) if the test is the same, the only difference is in dg- directives,
it is easier to just include the other test.
2) if -frecursive -fno-automatic is the same as -fno-automatic, then
the test is not valid unless you use explicit recursive keyword, because
then you recurse on something that shouldn't be called recursively, right?

> +! { dg-warning "Flag '-fno-automatic' overwrites '-frecursive'" "warning" { target *-*-* } 0 }

I think you want one runtime test (e.g. the one you wrote in
automatics_in_equivalence_1.f90) and the rest just dg-do compile tests that
will check the original or gimple dumps to verify what happened in addition
to checking diagnostics (none) from the compilation, one testing the
default, another -fno-automatic, but in both cases without -frecursive.

        Jakub