Hello,
since this long-standing problem just hit me again, I had a quick look at test failures in our farm that appear to occur whenever the directory name contains a string that is being checked for via a "scan-assembler" test, e.g.:
+FAIL: gcc.target/arm/sat-1.c scan-assembler-times ssat 4 +FAIL: gcc.target/arm/sat-1.c scan-assembler-times usat 4
I had been assuming this happens because the directory name somehow finds its name into the assembler file, e.g. via a .file directive or DWARF data, and therefore an additional instance of the search string is being detected erroneously.
However, when I attemted to re-create the scenario by building myself within a directory that has the same name, but on my local machine, the tests when through fine. And indeed, inspecting the assembler source shows that that there is no debug info at all; while there is a .file directive, it contains just the file base name without any directory name; and in fact the directory name does not show up at all within the assembler file.
Something must still be different in the runs that take place on the build farm; but I currently do not understand what that might be.
Michael, is there a way to interact with the build process on the build farm machines themselves to try and find out what's going on here?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
On 6 March 2012 16:55, Ulrich Weigand Ulrich.Weigand@de.ibm.com wrote:
Hello,
since this long-standing problem just hit me again, I had a quick look at test failures in our farm that appear to occur whenever the directory name contains a string that is being checked for via a "scan-assembler" test, e.g.:
+FAIL: gcc.target/arm/sat-1.c scan-assembler-times ssat 4 +FAIL: gcc.target/arm/sat-1.c scan-assembler-times usat 4
I had been assuming this happens because the directory name somehow finds its name into the assembler file, e.g. via a .file directive or DWARF data, and therefore an additional instance of the search string is being detected erroneously.
However, when I attemted to re-create the scenario by building myself within a directory that has the same name, but on my local machine, the tests when through fine. And indeed, inspecting the assembler source shows that that there is no debug info at all; while there is a .file directive, it contains just the file base name without any directory name; and in fact the directory name does not show up at all within the assembler file.
Something must still be different in the runs that take place on the build farm; but I currently do not understand what that might be.
Is it possible that the version string has the name of the branch ? That's the only thing I can think of that could be different and could cause this problem.
In this : http://ex.seabright.co.nz/build/gcc-linaro-4.7+bzr114970~uweigand~usatssat-4...
I see -
/scratch/cbuild/slave/slaves/oort1/gcc-linaro-4.7+bzr114970~uweigand~usatssat-4.7/gcc/default/build/gcc/xgcc version 4.7.0 20120214 (experimental) [gcc-linaro/usatssat-4.7 revision 114970] (GCC)
Is it the version string rather than the directory name ?
Ramana
Michael, is there a way to interact with the build process on the build farm machines themselves to try and find out what's going on here?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
Ramana Radhakrishnan ramana.radhakrishnan@linaro.org wrote:
Is it possible that the version string has the name of the branch ? That's the only thing I can think of that could be different and could cause this problem.
In this : http://ex.seabright.co.nz/build/gcc-linaro-4.7 +bzr114970~uweigand~usatssat-4.7/logs/x86_64-natty-cbuild259-oort1- x86_64r1/gcc-testsuite.txt
I see -
/scratch/cbuild/slave/slaves/oort1/gcc-linaro-4.7 +bzr114970~uweigand~usatssat-4.7/gcc/default/build/gcc/xgcc version 4.7.0 20120214 (experimental) [gcc-linaro/usatssat-4.7 revision 114970] (GCC)
Is it the version string rather than the directory name ?
Ah, good catch! This would certainly explain it, since the version string appears in the assembler source via the .ident directive the compiler always adds ...
I guess one could try to change the testsuite scripts to ignore .ident for scan-assembler purposes. But a much simpler fix seems to be to just not add the branch name to the version string when building the compiler in the first place; since those compilers are just used for testing, it doesn't really seem necessary.
Michael, any thoughts on this?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
On Wed, Mar 7, 2012 at 8:01 AM, Ulrich Weigand Ulrich.Weigand@de.ibm.com wrote:
Ramana Radhakrishnan ramana.radhakrishnan@linaro.org wrote:
Is it possible that the version string has the name of the branch ? That's the only thing I can think of that could be different and could cause this problem.
In this : http://ex.seabright.co.nz/build/gcc-linaro-4.7 +bzr114970~uweigand~usatssat-4.7/logs/x86_64-natty-cbuild259-oort1- x86_64r1/gcc-testsuite.txt
I see -
/scratch/cbuild/slave/slaves/oort1/gcc-linaro-4.7 +bzr114970~uweigand~usatssat-4.7/gcc/default/build/gcc/xgcc version 4.7.0 20120214 (experimental) [gcc-linaro/usatssat-4.7 revision 114970] (GCC)
Is it the version string rather than the directory name ?
Ah, good catch! This would certainly explain it, since the version string appears in the assembler source via the .ident directive the compiler always adds ...
I guess one could try to change the testsuite scripts to ignore .ident for scan-assembler purposes. But a much simpler fix seems to be to just not add the branch name to the version string when building the compiler in the first place; since those compilers are just used for testing, it doesn't really seem necessary.
Michael, any thoughts on this?
(LP: #913997)
I use a modified stamp_branch.sh when exporting the merge request which sets the branch to gcc-linaro/branch-name. I've modified this and fired a test run with 'cmp' in the name which historically fails on x86_64 and i686.
Let's see how it goes...
-- Michael
linaro-toolchain@lists.linaro.org
-
Michael Hope -
Ramana Radhakrishnan -
Ulrich Weigand