[patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[Steve Ellcey]

The test gcc.dg/torture/mips-sdata-1.c fails when compiled with
-fno-fat-lto-objects because when that option is used no assembly code
is output and thus the scan does not find the '.sdata' line.

Checked with the mips-mti-elf target.  OK to checkin?

Steve Ellcey
sellcey@mips.com

2012-11-05  Steve Ellcey  <sellcey@mips.com>

	* gcc.dg/torture/mips-sdata-1.c: Skip on -fno-fat-lto-objects.


diff --git a/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c b/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
index 8ffd4d8..53c9e4f 100644
--- a/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
+++ b/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
@@ -1,6 +1,7 @@
 /* Check that sdata-accesses are applied regardless of size or ABI.  */
 /* { dg-options -mexplicit-relocs } */
 /* { dg-do compile { target mips*-*-elf* } } */
+/* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } { "" } } */
 
 struct s { int x[4]; };
 struct s my_struct __attribute__((__section__(".sdata")));

Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[Richard Sandiford]

"Steve Ellcey " <sellcey@mips.com> writes:
> diff --git a/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c b/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
> index 8ffd4d8..53c9e4f 100644
> --- a/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
> +++ b/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
> @@ -1,6 +1,7 @@
>  /* Check that sdata-accesses are applied regardless of size or ABI.  */
>  /* { dg-options -mexplicit-relocs } */
>  /* { dg-do compile { target mips*-*-elf* } } */
> +/* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } { "" } } */
>  
>  struct s { int x[4]; };
>  struct s my_struct __attribute__((__section__(".sdata")));

The other tests that hit this problem have -ffat-lto-objects in the
dg-options line, so we might as well do the same here for consistency.
That's OK if it works.

Thanks,
Richard

Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[Richard Sandiford]

Richard Sandiford <rdsandiford@googlemail.com> writes:
> "Steve Ellcey " <sellcey@mips.com> writes:
>> diff --git a/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c b/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
>> index 8ffd4d8..53c9e4f 100644
>> --- a/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
>> +++ b/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c
>> @@ -1,6 +1,7 @@
>>  /* Check that sdata-accesses are applied regardless of size or ABI.  */
>>  /* { dg-options -mexplicit-relocs } */
>>  /* { dg-do compile { target mips*-*-elf* } } */
>> +/* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } { "" } } */
>>  
>>  struct s { int x[4]; };
>>  struct s my_struct __attribute__((__section__(".sdata")));
>
> The other tests that hit this problem have -ffat-lto-objects in the
> dg-options line, so we might as well do the same here for consistency.
> That's OK if it works.

Sorry, scratch that.  I'd missed that it wasn't in gcc.target/mips
(although arguably it should be).

This sort of thing should usually be handled automatically by
scan-assembler, and is for me:

/foo/gcc/xgcc -B/foo/gcc/ /bar/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c  -fno-diagnostics-show-caret  -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -mexplicit-relocs -ffat-lto-objects -S   -isystem /foo/mipsisa64-elf/soft-float/newlib/targ-include -isystem /bar/newlib/libc/include  -EB -msoft-float -o mips-sdata-1.s

So the test passes all variations here.  I wonder what's different in
your case?

Richard

Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[Steve Ellcey]

On Mon, 2012-11-05 at 20:38 +0000, Richard Sandiford wrote:

> This sort of thing should usually be handled automatically by
> scan-assembler, and is for me:
> 
> /foo/gcc/xgcc -B/foo/gcc/ /bar/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c  -fno-diagnostics-show-caret 
> -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -mexplicit-relocs -ffat-lto-objects -S  
> -isystem /foo/mipsisa64-elf/soft-float/newlib/targ-include -isystem /bar/newlib/libc/include  -EB
> -msoft-float -o mips-sdata-1.s
> 
> So the test passes all variations here.  I wonder what's different in
> your case?
> 
> Richard

Well that is weird.  I took out my change and I still see the error:

Executing on
host: /local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/xgcc
-B/local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/ /local/home/sellcey/nightly/src/gcc/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c  -fno-diagnostics-show-caret   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  -mexplicit-relocs -S    -o mips-sdata-1.s    (timeout = 300)
spawn /local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/xgcc
-B/local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/ /local/home/sellcey/nightly/src/gcc/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c -fno-diagnostics-show-caret -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -mexplicit-relocs -S -o mips-sdata-1.s^M
PASS: gcc.dg/torture/mips-sdata-1.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
FAIL: gcc.dg/torture/mips-sdata-1.c  -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects   scan-assembler gp_?rel\\(my_struct


Do you know where the -ffat-lto-objects option in your run came from?  I
don't have that in my results and my tree is up-to-date.

Steve

Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[Richard Sandiford]

Steve Ellcey <sellcey@mips.com> writes:
> On Mon, 2012-11-05 at 20:38 +0000, Richard Sandiford wrote:
>> This sort of thing should usually be handled automatically by
>> scan-assembler, and is for me:
>> 
>> /foo/gcc/xgcc -B/foo/gcc/ /bar/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c  -fno-diagnostics-show-caret 
>> -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -mexplicit-relocs -ffat-lto-objects -S  
>> -isystem /foo/mipsisa64-elf/soft-float/newlib/targ-include -isystem /bar/newlib/libc/include  -EB
>> -msoft-float -o mips-sdata-1.s
>> 
>> So the test passes all variations here.  I wonder what's different in
>> your case?
>> 
>> Richard
>
> Well that is weird.  I took out my change and I still see the error:
>
> Executing on
> host: /local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/xgcc
> -B/local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/ /local/home/sellcey/nightly/src/gcc/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c  -fno-diagnostics-show-caret   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  -mexplicit-relocs -S    -o mips-sdata-1.s    (timeout = 300)
> spawn /local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/xgcc
> -B/local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/ /local/home/sellcey/nightly/src/gcc/gcc/testsuite/gcc.dg/torture/mips-sdata-1.c -fno-diagnostics-show-caret -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -mexplicit-relocs -S -o mips-sdata-1.s^M
> PASS: gcc.dg/torture/mips-sdata-1.c  -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects  (test for excess errors)
> FAIL: gcc.dg/torture/mips-sdata-1.c  -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects   scan-assembler gp_?rel\\(my_struct
>
>
> Do you know where the -ffat-lto-objects option in your run came from?  I
> don't have that in my results and my tree is up-to-date.

gcc.dg.exp has:

if [check_effective_target_lto] {
    # When having plugin test both slim and fat LTO and plugin/nonplugin
    # path.
    if [check_linker_plugin_available] {
      set LTO_TORTURE_OPTIONS [list \
	  { -O2 -flto -fno-use-linker-plugin -flto-partition=none } \
	  { -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects }
      ]
      set gcc_force_conventional_output "-fcfat-lto-objects"
    } else {
      set LTO_TORTURE_OPTIONS [list \
	  { -O2 -flto -flto-partition=none } \
	  { -O2 -flto }
      ]
    }
}

and scanasm.exp has:

proc scan-assembler_required_options { args } {
    global gcc_force_conventional_output
    return $gcc_force_conventional_output
}

(similarly for scan-assembler-not, etc.).  Those options are then
supposed to be added by gcc.dg.exp:gcc-dg-test-1:

    # Let { dg-final { action } } force options as returned by an
    # optional proc ${action}_required_options.
    upvar 2 dg-final-code finalcode
    foreach x [split $finalcode "\n"] {
	set finalcmd [lindex $x 0]
	if { [info procs ${finalcmd}_required_options] != "" } {
	    set req [${finalcmd}_required_options]
	    if { $req != "" } {
		lappend extra_tool_flags $req
	    }
	}
    }

    if { $extra_tool_flags != "" } {
	lappend options "additional_flags=$extra_tool_flags"
    }

    set comp_output [$target_compile "$prog" "$output_file" "$compile_type" $options]

Does it work for you if you run it separately?  E.g. with:

    make check-gcc RUNTESTFLAGS=dg-torture.exp=mips-sdata-1.c

Richard

Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[Steve Ellcey]

On Mon, 2012-11-05 at 21:28 +0000, Richard Sandiford wrote:

> Does it work for you if you run it separately?  E.g. with:
> 
>     make check-gcc RUNTESTFLAGS=dg-torture.exp=mips-sdata-1.c
> 
> Richard

Hm, I configured GCC with '--enable-languages=c,c++', I think this might
set ENABLE_LTO to '0' and cause check_effective_target_lto to return
FALSE and cause the -ffat-lto-objects flag to not be added.  Of course
this raises the question of why it is trying to do lto testing if I
didn't configure it in.  I will add 'lto' to my configure line and see
if that fixes the problem.

Steve Ellcey
sellcey@mips.com

Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[Steve Ellcey]

On Mon, 2012-11-05 at 13:40 -0800, Steve Ellcey wrote:

> Hm, I configured GCC with '--enable-languages=c,c++', I think this might
> set ENABLE_LTO to '0' and cause check_effective_target_lto to return
> FALSE and cause the -ffat-lto-objects flag to not be added.  Of course
> this raises the question of why it is trying to do lto testing if I
> didn't configure it in.  I will add 'lto' to my configure line and see
> if that fixes the problem.
> 
> Steve Ellcey
> sellcey@mips.com

OK, that was a red herring.  The problem isn't
check_effective_target_lto but check_linker_plugin_available.
This is returning false because my compile can't find crt0.o.

% /local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/xgcc
-B/local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/ -v x.c
-Tmti32.ld  -o x

 /local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/collect2 -EB
-mips32r2 -melf32btsmip -o
x /local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/crti.o /local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/crtbegin.o -L/local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc /tmp/ccgdsofE.o -lgcc -lgcc /local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/crtend.o /local/home/sellcey/nightly/obj-mips-mti-elf/gcc/final/gcc/crtn.o -T mti32.ld
/local/home/sellcey/nightly/install-mips-mti-elf/mips-mti-elf/bin/ld:
cannot find crt0.o
collect2: error: ld returned 1 exit status



If I run the compiler from the installed location, everything is fine:


% install-mips-mti-elf/bin/mips-mti-elf-gcc -v x.c -Tmti32.ld -o x

 /local/home/sellcey/nightly/install-mips-mti-elf/libexec/gcc/mips-mti-elf/4.8.0/collect2 -EB -mips32r2 -melf32btsmip -o x /local/home/sellcey/nightly/install-mips-mti-elf/lib/gcc/mips-mti-elf/4.8.0/crti.o /local/home/sellcey/nightly/install-mips-mti-elf/lib/gcc/mips-mti-elf/4.8.0/crtbegin.o -L/local/home/sellcey/nightly/install-mips-mti-elf/lib/gcc/mips-mti-elf/4.8.0 -L/local/home/sellcey/nightly/install-mips-mti-elf/lib/gcc/mips-mti-elf/4.8.0/../../../../mips-mti-elf/lib /tmp/cczngIXe.o -lgcc -lgcc /local/home/sellcey/nightly/install-mips-mti-elf/lib/gcc/mips-mti-elf/4.8.0/crtend.o /local/home/sellcey/nightly/install-mips-mti-elf/lib/gcc/mips-mti-elf/4.8.0/crtn.o -T mti32.ld


I am not sure how ld is supposed to find crt0.o in the uninstalled
setup, it exists in obj-mips-mti-elf/newlib/mips-mti-elf/libgloss/mips.
Maybe it should find it in the installed location, it is there because I
have made and installed newlib before building and testing GCC.

Steve Ellcey
sellcey@mips.com

Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[Richard Sandiford]

Steve Ellcey <sellcey@mips.com> writes:
> I am not sure how ld is supposed to find crt0.o in the uninstalled
> setup, it exists in obj-mips-mti-elf/newlib/mips-mti-elf/libgloss/mips.

The newlib and libgloss flags are usually added by the dejagnu
baseboard file.  E.g. for mips-sim.exp:

set_board_info cflags "[libgloss_include_flags] [newlib_include_flags]"
set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags]"

Richard

Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[Steve Ellcey]

On Mon, 2012-11-05 at 22:55 +0000, Richard Sandiford wrote:
> Steve Ellcey <sellcey@mips.com> writes:
> > I am not sure how ld is supposed to find crt0.o in the uninstalled
> > setup, it exists in obj-mips-mti-elf/newlib/mips-mti-elf/libgloss/mips.
> 
> The newlib and libgloss flags are usually added by the dejagnu
> baseboard file.  E.g. for mips-sim.exp:
> 
> set_board_info cflags "[libgloss_include_flags] [newlib_include_flags]"
> set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags]"
> 
> Richard

Yup, I have those in my baseboard file.  When you configure GCC for a
mips-*-elf target, do you use --with-sysroot=XXXXX?  I don't, and the
build seems to work fine, but I was wondering if this is why GCC
couldn't find crt0.o until after it had been installed (into the same
directory home as newlib was installed to).

Steve Ellcey
sellcey@mips.com

Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[Richard Sandiford]

Steve Ellcey <sellcey@mips.com> writes:
> On Mon, 2012-11-05 at 22:55 +0000, Richard Sandiford wrote:
>> Steve Ellcey <sellcey@mips.com> writes:
>> > I am not sure how ld is supposed to find crt0.o in the uninstalled
>> > setup, it exists in obj-mips-mti-elf/newlib/mips-mti-elf/libgloss/mips.
>> 
>> The newlib and libgloss flags are usually added by the dejagnu
>> baseboard file.  E.g. for mips-sim.exp:
>> 
>> set_board_info cflags "[libgloss_include_flags] [newlib_include_flags]"
>> set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags]"
>> 
>> Richard
>
> Yup, I have those in my baseboard file.  When you configure GCC for a
> mips-*-elf target, do you use --with-sysroot=XXXXX?  I don't, and the
> build seems to work fine, but I was wondering if this is why GCC
> couldn't find crt0.o until after it had been installed (into the same
> directory home as newlib was installed to).

No, same here: I don't use --with-sysroot for the newlib targets.
Do you build a unified gcc+newlib tree?  If not, I don't think
the above boilerplate works; you'll have to use something else
instead.  E.g. install newlib first, change your board files
to match your build tree setup, or add links from the gcc build
directory to the newlib one.  But unified trees are simpler really
(i.e. a newlib and libgloss symlink in the gcc tree).

FWIW, on mine, the plugin test was:

/foo/gcc/xgcc -B/foo/gcc/ linker_plugin24984.c -fno-diagnostics-show-caret -flto -fuse-linker-plugin -isystem /foo/mipsisa64-elf/./newlib/targ-include -isystem /bar/newlib/libc/include -B/foo/mipsisa64-elf/./libgloss/mips/ -L/foo/mipsisa64-elf/./libgloss/mips -L/bar/libgloss/mips -B/foo/mipsisa64-elf/./newlib/ -L/foo/mipsisa64-elf/./newlib -lm -Tidt.ld -o linker_plugin24984.exe

where the expected libgloss and newlib flags are there.  If you are
using a unified tree and those flags aren't showing up in your run,
it might be worth sticking a puts after your "set ldflags ..." line to
see what setting you have (i.e. to see whether newlib_link_flags is
going wrong, or whether the flags are somehow being dropped).

Richard

Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[Steve Ellcey]

On Mon, 2012-11-05 at 23:22 +0000, Richard Sandiford wrote:

> No, same here: I don't use --with-sysroot for the newlib targets.
> Do you build a unified gcc+newlib tree?  If not, I don't think
> the above boilerplate works; you'll have to use something else
> instead.  E.g. install newlib first, change your board files
> to match your build tree setup, or add links from the gcc build
> directory to the newlib one.  But unified trees are simpler really
> (i.e. a newlib and libgloss symlink in the gcc tree).
> 
> Richard

I don't build in a unified tree, so I guess that is the problem.
I may try one of your suggestions to see if I can get one to work but it
is interesting that the tests themselves work, it is just this check for
lto that fails.  I guess it is because with the tests, the
newlib/libgloss flags in dejagnu take care of finding things but with
the lto test run by the *.exp script we don't have that.

Steve Ellcey
sellcey@mips.com

Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c

[Steve Ellcey]

On Mon, 2012-11-05 at 23:22 +0000, Richard Sandiford wrote:

> No, same here: I don't use --with-sysroot for the newlib targets.
> Do you build a unified gcc+newlib tree?  If not, I don't think
> the above boilerplate works; you'll have to use something else
> instead.  E.g. install newlib first, change your board files
> to match your build tree setup, or add links from the gcc build
> directory to the newlib one.  But unified trees are simpler really
> (i.e. a newlib and libgloss symlink in the gcc tree).

> Richard

It looks like using --with-sysroot and --with-build-sysroot took care of
the problem so my patch is not needed.

Steve Ellcey
sellcey@mips.com