Re: Bug in gcc.c for_each_path() (leads to invalid crt0.o selection)?
On 06/12/16 18:09, Joseph Myers wrote: On Tue, 6 Dec 2016, Sebastian Huber wrote: thanks for the detailed explanation. I guess, then the root cause for my problem is that the Newlib provided crt0.o files in the build tree are not in the same relative location of the installation tree. In the build tree, they reside in a "newlib" subdirectory. I changed the Newlib build flags set by GCC to use -L instead of -B and this seems to work (comment is wrong now). Does it make sense to submit such a patch or has it maybe some nasty side-effects? I don't know what the effects of such a change might be. Using -L instead of -B had the same problems. My attempt to fix this problem is this patch: https://sourceware.org/ml/newlib/2016/msg01145.html -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
GCC Subversion tree conflicts
While checking out the latest GCC SVN branch (rev. 243,465 as of December 08, 2016), the following conflicts were detected by subversion: [subversion output] Summary of conflicts: Tree conflicts: 34 Tree conflict on 'gcc/INSTALL' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: h (r) - accept current working copy state (p) - resolve the conflict later [postpone] (q) - postpone all remaining conflicts (h) - show this help (also '?') Words in square brackets are the corresponding --accept option arguments. Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/INSTALL' Tree conflict on 'gcc/config' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/config' Tree conflict on 'gcc/contrib' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/contrib' Tree conflict on 'gcc/fixincludes' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/fixincludes' Tree conflict on 'gcc/gcc' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/gcc' Tree conflict on 'gcc/gnattools' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/gnattools' Tree conflict on 'gcc/gotools' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/gotools' Tree conflict on 'gcc/include' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/include' Tree conflict on 'gcc/intl' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/intl' Tree conflict on 'gcc/libada' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/libada' Tree conflict on 'gcc/libatomic' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/libatomic' Tree conflict on 'gcc/libbacktrace' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/libbacktrace' Tree conflict on 'gcc/libcc1' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/libcc1' Tree conflict on 'gcc/libcilkrts' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/libcilkrts' Tree conflict on 'gcc/libcpp' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/libcpp' Tree conflict on 'gcc/libdecnumber' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/libdecnumber' Tree conflict on 'gcc/libffi' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/libffi' Tree conflict on 'gcc/libgcc' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/libgcc' Tree conflict on 'gcc/libgfortran' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/libgfortran' Tree conflict on 'gcc/libgo' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/libgo' Tree conflict on 'gcc/libgomp' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h) help: r Resolved conflicted state of 'gcc/libgomp' Tree conflict on 'gcc/libiberty' > local dir unversioned, incoming dir add upon update Select: (r) mark resolved, (p) postpone, (q) quit resolution, (h)
gcc-6-20161208 is now available
Snapshot gcc-6-20161208 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20161208/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 243467 You'll find: gcc-6-20161208.tar.bz2 Complete GCC MD5=99218a771c7dc60504793ba237f72e46 SHA1=178e3a72f76162966da57bcd0cb4094d0b3bed2c Diffs from 6-20161201 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
strange test failures
I'm seeing failures in a few C tests that I'm not sure what to make
out of. The tests fail due to undefined symbols while linking even
though they're not meant to link. Among these are a number (but not
all) of the gcc.dg/divmod-[1-6]{-simode}.c tests.
FAIL: gcc.dg/divmod-1.c (test for excess errors)
The log shows that they are being built without the -S option:
spawn -ignore SIGHUP /opt/notnfs/msebor/build/gcc-78622/gcc/xgcc
-B/opt/notnfs/msebor/build/gcc-78622/gcc/
/opt/notnfs/msebor/src/gcc/gcc-78622/gcc/testsuite/gcc.dg/divmod-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2
-fdump-tree-widening_mul-details -lm -o ./divmod-1.exe
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
...
When I run make check-c I get these same failures in different tests.
In successful builds the logs show that the tests are only assembled
(i.e., compiled with -S), never linked.
I can reproduce this on two different x86_64 machines but so far
only with my patches to GCC (the middle end but none of these tests
or the GCC .exp files). Is it possible that somehow my changes cause
this? (The removal of the -S option.) Am I missing something about
how GCC tests are run?
Thanks
Martin
PS I also see other strange errors like
RROR: tcl error sourcing
/opt/notnfs/msebor/src/gcc/gcc-78622/gcc/testsuite/gcc.c-torture/execute/execute.exp.
ERROR: unmatched open brace in list
ERROR: tcl error sourcing
/opt/notnfs/msebor/src/gcc/gcc-78622/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp.
ERROR: torture-init: torture_without_loops is not empty as expected
Re: strange test failures
On 12/08/2016 04:47 PM, Martin Sebor wrote:
I'm seeing failures in a few C tests that I'm not sure what to make
out of. The tests fail due to undefined symbols while linking even
though they're not meant to link. Among these are a number (but not
all) of the gcc.dg/divmod-[1-6]{-simode}.c tests.
FAIL: gcc.dg/divmod-1.c (test for excess errors)
The log shows that they are being built without the -S option:
spawn -ignore SIGHUP /opt/notnfs/msebor/build/gcc-78622/gcc/xgcc
-B/opt/notnfs/msebor/build/gcc-78622/gcc/
/opt/notnfs/msebor/src/gcc/gcc-78622/gcc/testsuite/gcc.dg/divmod-1.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2
-fdump-tree-widening_mul-details -lm -o ./divmod-1.exe
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
...
When I run make check-c I get these same failures in different tests.
In successful builds the logs show that the tests are only assembled
(i.e., compiled with -S), never linked.
I can reproduce this on two different x86_64 machines but so far
only with my patches to GCC (the middle end but none of these tests
or the GCC .exp files). Is it possible that somehow my changes cause
this? (The removal of the -S option.) Am I missing something about
how GCC tests are run?
IIRC the default for a dg test is to compile, but not assemble or run.
The log shows that it's trying to go through the link step.
Thanks
Martin
PS I also see other strange errors like
RROR: tcl error sourcing
/opt/notnfs/msebor/src/gcc/gcc-78622/gcc/testsuite/gcc.c-torture/execute/execute.exp.
ERROR: unmatched open brace in list
ERROR: tcl error sourcing
/opt/notnfs/msebor/src/gcc/gcc-78622/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp.
ERROR: torture-init: torture_without_loops is not empty as expected
This all sounds like you've got a mucked up testsuite/lib directory or
something like that. I'd start by verifying the contents of your
testsuite/lib directory.
I did a testrun on Dec 7 on the trunk and didn't see any of these problems.
jeff
