| Message ID | 853292c5-73e0-4fbe-8174-1734f559dd5d@EXCHHUB01.MIPS.com |
|---|---|
| State | New |
| Headers | show |
"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
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
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
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
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
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
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
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
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
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
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
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")));