Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c
On Mon, 2012-11-05 at 23:22 +, 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 sell...@mips.com
[patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c
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
sell...@mips.com
2012-11-05 Steve Ellcey sell...@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
Steve Ellcey sell...@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 rdsandif...@googlemail.com writes:
Steve Ellcey sell...@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
On Mon, 2012-11-05 at 20:38 +, 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
Steve Ellcey sell...@mips.com writes:
On Mon, 2012-11-05 at 20:38 +, 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
On Mon, 2012-11-05 at 21:28 +, 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 sell...@mips.com
Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c
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 sell...@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 sell...@mips.com
Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c
Steve Ellcey sell...@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
On Mon, 2012-11-05 at 22:55 +, Richard Sandiford wrote: Steve Ellcey sell...@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=X? 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 sell...@mips.com
Re: [patch, testsuite, mips] Fix gcc.dg/torture/mips-sdata-1.c
Steve Ellcey sell...@mips.com writes: On Mon, 2012-11-05 at 22:55 +, Richard Sandiford wrote: Steve Ellcey sell...@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=X? 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
On Mon, 2012-11-05 at 23:22 +, 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 sell...@mips.com
