RE: [PATCH, testsuite] MIPS: Skip msa-builtins-err.c if there is no assembly output.

2016-12-14 Thread Toma Tabacu
Committed as r243639.

Regards,
Toma

> -Original Message-
> From: Matthew Fortune
> Sent: 13 December 2016 13:46
> To: Toma Tabacu; gcc-patches@gcc.gnu.org
> Cc: catherine_mo...@mentor.com
> Subject: RE: [PATCH, testsuite] MIPS: Skip msa-builtins-err.c if there is no
> assembly output.
> 
> Toma Tabacu <toma.tab...@imgtec.com> writes:
> > >
> > > It's a shame this is the only way to deal with this but I see aarch64
> > > have to resort to the same thing for error checking tests.
> > >
> >
> > I have looked into this some more and I 've found that the solution I
> > proposed is incomplete.
> >
> > The problem is that if no linker plugin is found, -fno-fat-lto-objects
> > is not passed on, so the test isn't skipped and it will fail because -
> > flto doesn't do assembly generation by default and the errors will not
> > be triggered.
> >
> > This can be fixed by adding -ffat-lto-objects as a test option for error
> > tests, as shown in the patch below.
> >
> > The thing is, this already happens for scan-assembler & friends behind-
> > the-scenes, but not for dg-error, because the former are run through
> > force_conventional_output, while the latter is not.
> >
> > A nicer solution would be to have a new directive which would do nothing
> > except for the force_conventional_output part, thus forcing assembly
> > generation, but this may be overkill.
> >
> > Regards,
> > Toma
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/mips/msa-builtins-err.c (dg-options): Use
> >  -ffat-lto-objects to guarantee assembly generation.
> 
> OK, thanks for investigating. Slight tweak to the changelog we just say
> what changed in the changelog not why. You covered 'why' in the code
> comment. This is just:
> 
> (dg-options): Add -ffat-lto-objects option.
> 
> Thanks,
> Matthew


RE: [PATCH, testsuite] MIPS: Skip msa-builtins-err.c if there is no assembly output.

2016-12-13 Thread Matthew Fortune
Toma Tabacu  writes:
> >
> > It's a shame this is the only way to deal with this but I see aarch64
> > have to resort to the same thing for error checking tests.
> >
> 
> I have looked into this some more and I 've found that the solution I
> proposed is incomplete.
> 
> The problem is that if no linker plugin is found, -fno-fat-lto-objects
> is not passed on, so the test isn't skipped and it will fail because -
> flto doesn't do assembly generation by default and the errors will not
> be triggered.
> 
> This can be fixed by adding -ffat-lto-objects as a test option for error
> tests, as shown in the patch below.
> 
> The thing is, this already happens for scan-assembler & friends behind-
> the-scenes, but not for dg-error, because the former are run through
> force_conventional_output, while the latter is not.
> 
> A nicer solution would be to have a new directive which would do nothing
> except for the force_conventional_output part, thus forcing assembly
> generation, but this may be overkill.
> 
> Regards,
> Toma
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/mips/msa-builtins-err.c (dg-options): Use
>-ffat-lto-objects to guarantee assembly generation.

OK, thanks for investigating. Slight tweak to the changelog we just say
what changed in the changelog not why. You covered 'why' in the code
comment. This is just:

(dg-options): Add -ffat-lto-objects option.

Thanks,
Matthew


RE: [PATCH, testsuite] MIPS: Skip msa-builtins-err.c if there is no assembly output.

2016-12-12 Thread Toma Tabacu
> 
> It's a shame this is the only way to deal with this but I see aarch64 have
> to resort to the same thing for error checking tests.
> 

I have looked into this some more and I 've found that the solution I proposed
is incomplete.

The problem is that if no linker plugin is found, -fno-fat-lto-objects is not
passed on, so the test isn't skipped and it will fail because -flto doesn't do
assembly generation by default and the errors will not be triggered.

This can be fixed by adding -ffat-lto-objects as a test option for error tests,
as shown in the patch below.

The thing is, this already happens for scan-assembler & friends
behind-the-scenes, but not for dg-error, because the former are run through
force_conventional_output, while the latter is not.

A nicer solution would be to have a new directive which would do nothing except
for the force_conventional_output part, thus forcing assembly generation,
but this may be overkill.

Regards,
Toma

gcc/testsuite/ChangeLog:

* gcc.target/mips/msa-builtins-err.c (dg-options): Use
 -ffat-lto-objects to guarantee assembly generation.

diff --git a/gcc/testsuite/gcc.target/mips/msa-builtins-err.c 
b/gcc/testsuite/gcc.target/mips/msa-builtins-err.c
index 041b7f5..68244d6 100644
--- a/gcc/testsuite/gcc.target/mips/msa-builtins-err.c
+++ b/gcc/testsuite/gcc.target/mips/msa-builtins-err.c
@@ -1,6 +1,8 @@
 /* Test builtins for MIPS MSA ASE instructions */
 /* { dg-do compile } */
-/* { dg-options "-mfp64 -mhard-float -mmsa" } */
+/* { dg-options "-mfp64 -mhard-float -mmsa -ffat-lto-objects" } */
+/* Because this test only uses dg-error, we need to guarantee assembly
+   generation ourselves by using -ffat-lto-objects. */
 
 #include 


RE: [PATCH, testsuite] MIPS: Skip msa-builtins-err.c if there is no assembly output.

2016-12-09 Thread Matthew Fortune
Toma Tabacu  writes:
> The msa-builtins-err.c test is failing in the following configuration:
> -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects
> This is because the errors it is checking for are triggered by assembly
> generation, which is prevented by -fno-fat-lto-objects.
> 
> This patch fixes this by adding a dg-skip-if for -fno-fat-lto-objects.
> 
> Tested with mips-mti-elf.
> 
> Regards,
> Toma Tabacu
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/mips/msa-builtins-err.c (dg-skip-if): Do not run the test
>   if -fno-fat-lto-objects is present.

You don't need the (dg-skip-if) here, no specific reason but people
don't tend to do it.

It's a shame this is the only way to deal with this but I see aarch64 have
to resort to the same thing for error checking tests.

Thanks for the fix, OK to commit.

Matthew