[Bug target/56975] New: [regression] dllimport broken on i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975
Bug #: 56975
Summary: [regression] dllimport broken on i686-pc-cygwin
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: da...@gcc.gnu.org
Created attachment 29880
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29880
preprocessed testcase
Attempting to reference a dllimported symbol with current HEAD causes an ICE
with an unrecognized insn. This breaks bootstrap at stage1 building libgcc.
Here's a testcase using stage1 cc1.exe from a failed build dir:
$ cat foo.i
void *foo (void);
__attribute__((dllimport)) void * __attribute__((__stdcall__)) bar(const char *
lpModuleName);
void *
foo (void)
{
void *ptr = bar ((const char *)0);
return ptr;
}
DKAdmin@ubik /gnu/gcc/obj/i686-pc-cygwin/libgcc
$ /gnu/gcc/obj/./gcc/cc1.exe -fpreprocessed foo.i -quiet -mtune=generic
-march=i686 -auxbase-strip crtbegin.o -g -g -g0 -O2 -O2 -O2 -Wextra -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -version -finhibit-size-directive
-fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder
-fno-tree-vectorize -fno-stack-protector -fno-omit-frame-pointer -o foo.s
GNU C (GCC) version 4.9.0 20130416 (experimental) (i686-pc-cygwin)
compiled by GNU C version 4.7.2, GMP version 4.3.2, MPFR version
3.0.1-p4, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.9.0 20130416 (experimental) (i686-pc-cygwin)
compiled by GNU C version 4.7.2, GMP version 4.3.2, MPFR version
3.0.1-p4, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 31da135ea647c81f0b254283fbd2bab6
foo.i: In function ‘foo’:
foo.i:11:1: error: unrecognizable insn:
}
^
(insn 6 5 7 2 (set (reg:SI 61)
(symbol_ref:SI ("bar@4") [flags 0x441] ))
foo.i:9 -1
(nil))
foo.i:11:1: internal compiler error: in extract_insn, at recog.c:2150
foo.i:11:1: internal compiler error: Aborted
Aborted (core dumped)
DKAdmin@ubik /gnu/gcc/obj/i686-pc-cygwin/libgcc
$
[Bug target/56975] [regression] dllimport broken on i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975 --- Comment #9 from Dave Korn 2013-04-19 18:18:19 UTC --- Kai's patch applied cleanly for me vs. Revision: 197992 and allowed my failed build to proceed as far as stage 3 where it failed on libjava (known issue). I'm going to rerun the build from clean and try some tests.
[Bug middle-end/46674] [4.6 Regression] Weak alias is mistakenly optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674 --- Comment #12 from Dave Korn 2010-12-19 11:14:23 UTC --- Author: davek Date: Sun Dec 19 11:14:19 2010 New Revision: 168047 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168047 Log: PR middle-end/46674 PR middle-end/46221 * varasm.c (symbol_alias_set_t): New typedef for derived pointer_set wrapper class. (symbol_alias_set_create): New wrapper function. (symbol_alias_set_destroy): Likewise. (symbol_alias_set_contains): Likewise. (symbol_alias_set_insert): Likewise. (compute_visible_aliases): Use the above and return symbol_alias_set_t, not a pointer_set. (remove_unreachable_alias_pairs): Adjust likewise to match. (finish_aliases_1): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/varasm.c
[Bug middle-end/46221] [4.6 Regression] huge number of c++ testsuite failures, libstdc++.so alias missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221 --- Comment #27 from Dave Korn 2010-12-19 11:14:23 UTC --- Author: davek Date: Sun Dec 19 11:14:19 2010 New Revision: 168047 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168047 Log: PR middle-end/46674 PR middle-end/46221 * varasm.c (symbol_alias_set_t): New typedef for derived pointer_set wrapper class. (symbol_alias_set_create): New wrapper function. (symbol_alias_set_destroy): Likewise. (symbol_alias_set_contains): Likewise. (symbol_alias_set_insert): Likewise. (compute_visible_aliases): Use the above and return symbol_alias_set_t, not a pointer_set. (remove_unreachable_alias_pairs): Adjust likewise to match. (finish_aliases_1): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/varasm.c
[Bug middle-end/46674] [4.6 Regression] Weak alias is mistakenly optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674 Dave Korn changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Dave Korn 2010-12-19 11:17:27 UTC --- Fully fixed now, I trust.
[Bug middle-end/46221] [4.6 Regression] huge number of c++ testsuite failures, libstdc++.so alias missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46221 Dave Korn changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #28 from Dave Korn 2010-12-19 11:18:37 UTC --- Problems (PR46674) with this fix now resolved.
[Bug c++/47218] New: [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 Summary: [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: da...@gcc.gnu.org Sometime between 2010-12-22 and rev.167484, something changed in the behaviour of the C++ compiler w.r.t the way it handles non-virtual thunks. I have just discovered this while working on a patch for PR43601; a compiler built from trunk on the earlier date reproduces the problem described there, ending in an out-of-memory error during the final link: Creating library file: /tmp/wx/obj-x-ming-new/lib/libwx_mswd_core-2.8.dll.a/opt/ mingw-new/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/bin/ld: fina l link failed: Memory exhausted collect2: ld returned 1 exit status ... whereas a compiler built from r.167484 emits a whole lot of multiple-definition errors, and stops before trying to complete the link: Creating library file: /tmp/wx/obj-x-ming-clean/lib/libwx_based-2.8.dll.abasedll_wfstream.o:/tmp/wx/wxWidgets-2.8.11/src/common/wfstream.cpp:407: multiple definition of `non-virtual thunk to wxFFileStream::~wxFFileStream()' basedll_filesys.o:/tmp/wx/wxWidgets-2.8.11/src/common/filesys.cpp:697: first defined here basedll_wfstream.o:/tmp/wx/wxWidgets-2.8.11/src/common/wfstream.cpp:407: multiple definition of `non-virtual thunk to wxFFileStream::~wxFFileStream()' basedll_filesys.o:/tmp/wx/wxWidgets-2.8.11/src/common/filesys.cpp:697: first defined here basedll_wfstream.o:/tmp/wx/wxWidgets-2.8.11/src/common/wfstream.cpp:407: multiple definition of `non-virtual thunk to wxFileStream::~wxFileStream()' basedll_filesys.o:/tmp/wx/wxWidgets-2.8.11/src/common/filesys.cpp:697: first defined here basedll_wfstream.o:/tmp/wx/wxWidgets-2.8.11/src/common/wfstream.cpp:407: multiple definition of `non-virtual thunk to wxFileStream::~wxFileStream()' basedll_filesys.o:/tmp/wx/wxWidgets-2.8.11/src/common/filesys.cpp:697: first defined here basedll_zipstrm.o:/tmp/wx/wxWidgets-2.8.11/src/common/zipstrm.cpp:2423: multiple definition of `non-virtual thunk to wxFFileStream::~wxFFileStream()' basedll_filesys.o:/tmp/wx/wxWidgets-2.8.11/src/common/filesys.cpp:697: first defined here basedll_zipstrm.o:/tmp/wx/wxWidgets-2.8.11/src/common/zipstrm.cpp:2423: multiple definition of `non-virtual thunk to wxFFileStream::~wxFFileStream()' basedll_filesys.o:/tmp/wx/wxWidgets-2.8.11/src/common/filesys.cpp:697: first defined here basedll_zipstrm.o:/tmp/wx/wxWidgets-2.8.11/src/common/zipstrm.cpp:2423: multiple definition of `non-virtual thunk to wxFileStream::~wxFileStream()' basedll_filesys.o:/tmp/wx/wxWidgets-2.8.11/src/common/filesys.cpp:697: first defined here basedll_zipstrm.o:/tmp/wx/wxWidgets-2.8.11/src/common/zipstrm.cpp:2423: multiple definition of `non-virtual thunk to wxFileStream::~wxFileStream()' basedll_filesys.o:/tmp/wx/wxWidgets-2.8.11/src/common/filesys.cpp:697: first defined here basedll_registry.o:/tmp/wx/wxWidgets-2.8.11/src/msw/registry.cpp:1428: multiple definition of `non-virtual thunk to wxFFileStream::~wxFFileStream()' basedll_filesys.o:/tmp/wx/wxWidgets-2.8.11/src/common/filesys.cpp:697: first defined here basedll_registry.o:/tmp/wx/wxWidgets-2.8.11/src/msw/registry.cpp:1428: multiple definition of `non-virtual thunk to wxFFileStream::~wxFFileStream()' basedll_filesys.o:/tmp/wx/wxWidgets-2.8.11/src/common/filesys.cpp:697: first defined here basedll_registry.o:/tmp/wx/wxWidgets-2.8.11/src/msw/registry.cpp:1428: multiple definition of `non-virtual thunk to wxFileStream::~wxFileStream()' basedll_filesys.o:/tmp/wx/wxWidgets-2.8.11/src/common/filesys.cpp:697: first defined here basedll_registry.o:/tmp/wx/wxWidgets-2.8.11/src/msw/registry.cpp:1428: multiple definition of `non-virtual thunk to wxFileStream::~wxFileStream()' basedll_filesys.o:/tmp/wx/wxWidgets-2.8.11/src/common/filesys.cpp:697: first defined here collect2: ld returned 1 exit status In both cases the build was configured with a cygwin-x-mingw cross compiler using the same command line: $ /tmp/wx/wxWidgets-2.8.11/configure --with-msw --enable-debug --enable-debug_gdb --enable-shared 2>&1 --host=i686-pc-mingw32 More once I've diagnosed what's going on in some of the generated object files. I've marked this major as it could easily affect a whole lot of c++ library builds, but may reduce that severity if it turns out to be something unusual that wx is doing. However it's still a regression.
[Bug bootstrap/47215] [4.6 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47215 Dave Korn changed: What|Removed |Added CC||davek at gcc dot gnu.org --- Comment #4 from Dave Korn 2011-01-07 20:27:01 UTC --- (In reply to comment #3) > I am just about to test a patch for this. Java misses to build some > type-nodes, Yeah, see also http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00921.html (ignore the linked PR though, it was a red herring.)
[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 Dave Korn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.07 21:05:02 Ever Confirmed|0 |1 --- Comment #1 from Dave Korn 2011-01-07 21:05:02 UTC --- Yeah, confirmed that. With the older compiler the NVT is emitted in a comdat section as you'd expect: the symbols ... [6421](sec 2101)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x __ZThn32_N13wxFFileStreamD1Ev [6427](sec 2103)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x __ZThn32_N13wxFFileStreamD0Ev ... point to sections (note MS numbers sections from 1, objdump from zero) like so: 2100 .text$_ZThn32_N13wxFFileStreamD1Ev 000c 0002d368 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE, LINK_ONCE_DISCARD (COMDAT __ZThn32_N13wxFFileStreamD1Ev 6421) 2102 .text$_ZThn32_N13wxFFileStreamD0Ev 000c 0002d3e0 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE, LINK_ONCE_DISCARD (COMDAT __ZThn32_N13wxFFileStreamD0Ev 6427) With the latest trunk however, the same symbols ... [6419](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x0fa8 __ZThn32_N13wxFFileStreamD1Ev [6423](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 0) 0x0fb2 __ZThn32_N13wxFFileStreamD0Ev ... both point to section 1: the .text section. 0 .text 0fd0 0001633c 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE This being replicated across all object files, no wonder we have multiple defintion errors. It's a bug that the NVT doesn't get emitted in a comdat, I expect. (I think I remember some kind of recent change to section handling that I saw fly past on the patches list, wonder if it could be related.)
[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 --- Comment #4 from Dave Korn 2011-01-08 16:35:31 UTC --- (In reply to comment #3) > A simple test in PR47116: > http://gcc.gnu.org/bugzilla/attachment.cgi?id=22866 Thankyou, that should make debugging it easier :)
[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 --- Comment #5 from Dave Korn 2011-01-08 18:06:07 UTC --- Bug is caused by the change at rev 167795 applied to fix PR46667. http://gcc.gnu.org/viewcvs?view=revision&revision=167795
[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 --- Comment #6 from Dave Korn 2011-01-08 19:00:25 UTC --- (In reply to comment #5) > Bug is caused by the change at rev 167795 applied to fix PR46667. > > http://gcc.gnu.org/viewcvs?view=revision&revision=167795 Full details at http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00446.html: >" It turns out that resolve_unique_function() is not called at all for the thunk function any more, where previously it was called from assemble_start_function called from cgraph_expand_function. This is because gimple_expand_cfg() isn't called for these thunk functions; they are emitted through a call chain that looks like: > (gdb) bt > #0 assemble_start_function (decl=0x7fe32f00, > fnname=0x7fe41860 "_ZThn4_N7FooBase3BarEv") > at /gnu/gcc/gcc-patched/gcc/varasm.c:1524 > #1 0x007aa73c in cgraph_expand_function (node=0x7ff80c30) > at /gnu/gcc/gcc-patched/gcc/cgraphunit.c:1328 > #2 0x007ad210 in cgraph_optimize () > at /gnu/gcc/gcc-patched/gcc/cgraphunit.c:1567 > #3 0x007ad69a in cgraph_finalize_compilation_unit () > at /gnu/gcc/gcc-patched/gcc/cgraphunit.c:1031 > #4 0x004ce825 in cp_write_global_declarations () > at /gnu/gcc/gcc-patched/gcc/cp/decl2.c:3974 > #5 0x0080ed6d in toplev_main (argc=14, argv=0x5079f78) > at /gnu/gcc/gcc-patched/gcc/toplev.c:591 > #6 0x0060699f in main (argc=Cannot access memory at address 0x0 > ) at /gnu/gcc/gcc-patched/gcc/main.c:36 " That's the main part of it.
[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 Dave Korn changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 --- Comment #7 from Dave Korn 2011-01-09 00:47:15 UTC --- Created attachment 22932 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22932 proposed patch Ensures thunks get a section name assigned in cgraphunit.c#assemble_thunk(). Taking this for a bootstrap/test cycle.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 Dave Korn changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.09 17:25:25 AssignedTo|unassigned at gcc dot |davek at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #49 from Dave Korn 2011-01-09 17:30:31 UTC --- Created attachment 22935 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22935 trial patch brings the earlier change that nathan made to always keep dllexported inlines under control of a command-line flag. Before: --snip-- make[1]: Leaving directory `/tmp/wx/obj-x-ming-clean/utils/wxrc' Creating library file: /tmp/wx/obj-x-ming-clean/lib/libwx_mswd_core-2.8.dll.a/op t/mingw-pr43601-clean/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/ bin/ld: final link failed: Memory exhausted collect2: ld returned 1 exit status make: *** [/tmp/wx/obj-x-ming-clean/lib/wxmsw28d_core_gcc_custom.dll] Error 1 real79m46.081s user50m1.166s sys 5m45.723s $ du -cxsh lib/*.dll 59M lib/wxbase28d_gcc_custom.dll 1.4Mlib/wxbase28d_net_gcc_custom.dll 512Klib/wxbase28d_xml_gcc_custom.dll 61M total --snip-- ... and after ... --snip-- Creating library file: /tmp/wx/obj-x-ming-new/lib/libwx_mswd_aui-2.8.dll.a Creating library file: /tmp/wx/obj-x-ming-new/lib/libwx_mswd_richtext-2.8.dll.a Creating library file: /tmp/wx/obj-x-ming-new/lib/libwx_mswd_xrc-2.8.dll.a real39m32.531s user21m52.641s sys4m53.111s $ du -cxsh lib/*.dll 33M lib/wxbase28d_gcc_custom.dll 1.3Mlib/wxbase28d_net_gcc_custom.dll 512Klib/wxbase28d_xml_gcc_custom.dll 5.2Mlib/wxmsw28d_adv_gcc_custom.dll 2.2Mlib/wxmsw28d_aui_gcc_custom.dll 117Mlib/wxmsw28d_core_gcc_custom.dll 4.7Mlib/wxmsw28d_html_gcc_custom.dll 576Klib/wxmsw28d_qa_gcc_custom.dll 4.2Mlib/wxmsw28d_richtext_gcc_custom.dll 8.2Mlib/wxmsw28d_xrc_gcc_custom.dll 176Mtotal --snip-- Needs testcase + doco before I can submit it.
[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 --- Comment #9 from Dave Korn 2011-01-10 00:33:35 UTC --- Author: davek Date: Mon Jan 10 00:33:32 2011 New Revision: 168624 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168624 Log: gcc/ChangeLog: PR c++/47218 * cgraphunit.c (assemble_thunk): Call resolve_unique_section. gcc/testsuite/ChangeLog: PR c++/47218 * g++.dg/other/pr47218-1.C: New test file. * g++.dg/other/pr47218.C: Likewise. * g++.dg/other/pr47218.h: New supporting header. Added: trunk/gcc/testsuite/g++.dg/other/pr47218-1.C trunk/gcc/testsuite/g++.dg/other/pr47218.C trunk/gcc/testsuite/g++.dg/other/pr47218.h Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47218] [4.6.0 regression] C++ multiple definitions of non-virtual thunk problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47218 Dave Korn changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Dave Korn 2011-01-10 00:53:45 UTC --- Done.
[Bug c++/41201] #pragma GCC target ("sse2") doesn't alter __SSE2__ in C++ (as it does in C)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41201 Dave Korn changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|davek at gcc dot gnu.org|unassigned at gcc dot ||gnu.org
[Bug bootstrap/46037] --enable-stage1-languages=c,lto --enable-languages=c,lto --with-build-config=bootstrap-lto fails on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46037
--- Comment #4 from Dave Korn 2011-01-10 15:28:51
UTC ---
(In reply to comment #2)
> the optimize attribute isn't used in the preprocessed file but only the
> target attribute which is supported. Thus, "worksforme".
Target attributes must be implying optimisation attributes. Bug depends also
on --with-{arch,tune,fpmath} settings. I'll try and reproduce it on
x86_64-linux, it should be possible if I choose the right settings - will reply
again later.
(In reply to comment #3)
> It would be interesting to know if COFF's lto support has the same issues
> (since they share the same backend design for lto support).
No, it's not related to the backend lto support at all; the sorry comes from
the lto output streamer. It does depend on the backend's attribute handling
though.
(See also PR41201, vaguely related.)
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 Dave Korn changed: What|Removed |Added Keywords||patch URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-01/msg01432.htm ||l Known to work||3.4.5 Version|4.5.0 |4.6.0 Known to fail||4.3.4, 4.5.0, 4.6.0 --- Comment #51 from Dave Korn 2011-01-21 04:17:24 UTC --- Patch submitted.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 Dave Korn changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #52 from Dave Korn 2011-01-26 01:50:14 UTC --- Committed rev.169268. http://gcc.gnu.org/viewcvs?view=revision&revision=169268 (Then added the missing PR refs to the changelogss in the next rev: http://gcc.gnu.org/viewcvs?view=revision&revision=169269)
[Bug target/40125] libgcc_s DLL installed in wrong directory in cross toolchain
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40125
Dave Korn changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||FIXED
Target Milestone|--- |4.6.0
--- Comment #8 from Dave Korn 2011-01-26 03:33:14
UTC ---
Author: davek
Date: Wed Jan 26 03:33:09 2011
New Revision: 169272
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169272
Log:
PR target/40125
* configure.ac (AM_LTLDFLAGS): Add -bindir option for windows DLLs.
* configure: Regenerate.
Modified:
trunk/libffi/ChangeLog
trunk/libffi/configure
trunk/libffi/configure.ac
--- Comment #9 from Dave Korn 2011-01-26 04:20:02
UTC ---
Author: davek
Date: Wed Jan 26 04:19:58 2011
New Revision: 169274
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169274
Log:
gcc/ChangeLog:
PR target/40125
* config.gcc (i[34567]86-*-pe | i[34567]86-*-cygwin*): Select suitable
t-dlldir{,-x} fragment for build and add it to tmake_file.
(i[34567]86-*-mingw* | x86_64-*-mingw*): Likewise.
* Makefile.in (libgcc.mvars): Also export SHLIB_DLLDIR to libgcc.
* config/i386/t-dlldir: New file.
(SHLIB_DLLDIR): Define.
* config/i386/t-dlldir-x: New file.
(SHLIB_DLLDIR): Define.
* config/i386/t-cygming: Error out if SHLIB_DLLDIR is not set.
(SHLIB_INSTALL): Use it.
libgcc/ChangeLog:
PR target/40125
* configure.ac: Call ACX_NONCANONICAL_TARGET.
(toolexecdir): Calculate and AC_SUBST.
(toolexeclibdir): Likewise.
* Makefile.in (target_noncanonical): Import.
(toolexecdir): Likewise.
(toolexeclibdir): Likewise.
* configure: Regenerate.
Added:
trunk/gcc/config/i386/t-dlldir
trunk/gcc/config/i386/t-dlldir-x
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/config.gcc
trunk/gcc/config/i386/t-cygming
trunk/libgcc/ChangeLog
trunk/libgcc/Makefile.in
trunk/libgcc/configure
trunk/libgcc/configure.ac
--- Comment #10 from Dave Korn 2011-01-26 04:25:51
UTC ---
Those two commits should take care of it.
[Bug target/47468] New: FAIL: tmpdir-g++.dg-struct-layout-1/*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47468 Summary: FAIL: tmpdir-g++.dg-struct-layout-1/* Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: da...@gcc.gnu.org Configuring GCC with "'--with-arch=native' '--with-tune=native'" on i686-pc-cygwin. All the g++ testsuite struct layout compat tests have compile failures: FAIL: tmpdir-g++.dg-struct-layout-1/t001 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t001 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t002 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t002 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t003 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t003 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t004 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t004 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t005 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t005 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t006 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t006 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t007 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t007 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t008 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t008 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t009 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t009 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t010 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t010 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t011 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t011 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t012 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t012 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t013 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t013 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t014 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t014 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t015 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t015 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t016 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t016 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t017 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t017 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t018 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t018 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t019 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t019 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t020 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t020 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t021 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t021 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t022 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t022 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t023 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t023 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t024 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t024 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t025 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp_compat_x_tst.o-cp_compat_y_tst.o execute FAIL: tmpdir-g++.dg-struct-layout-1/t027 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t027 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t028 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t028 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t029 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t029 cp_compat_y_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t030 cp_compat_x_tst.o compile FAIL: tmpdir-g++.dg-struct-layout-1/t030 cp_compat_y all of which are of the same form: spawn /gnu/gcc/obj-pr43601/gcc/testsuite/g++/../../g++ -B/gnu/gcc/obj-pr43601/gcc/testsuite/g++/../../ -nostdinc++ -I/gnu/gcc/obj-pr43601/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin -I/gnu/gcc/obj-pr43601/i686-pc-cygwin/libstdc++-v3/include -I/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/gnu/gcc/gcc/libstdc++-v3/include/backward -I/gnu/gcc/gcc/libstdc++-v3/te
[Bug target/47468] FAIL: tmpdir-g++.dg-struct-layout-1/*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47468 --- Comment #1 from Dave Korn 2011-01-26 04:47:09 UTC --- Created attachment 23128 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23128 preprocessed source for testcase (first failing test) This is what causes: FAIL: tmpdir-g++.dg-struct-layout-1/t001 cp_compat_x_tst.o compile
[Bug target/47468] FAIL: tmpdir-g++.dg-struct-layout-1/*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47468 Dave Korn changed: What|Removed |Added Target||i686-pc-cygwin Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.26 04:50:09 CC||hjl.tools at gmail dot com Host||i686-pc-cygwin Ever Confirmed|0 |1 Build||i686-pc-cygwin --- Comment #2 from Dave Korn 2011-01-26 04:50:09 UTC --- HJ, you offered to take a look at what's causing this problem. Any ideas?
[Bug lto/46652] undefined reference to '__udivdi3' with -flto -fuse-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46652 Dave Korn changed: What|Removed |Added CC||davek at gcc dot gnu.org --- Comment #7 from Dave Korn 2011-01-26 15:19:43 UTC --- (In reply to comment #6) > Gold was updated to handle this well for binutils 2.11.1, so H.J.'s branch. > We still have issues with mainline GNU LD. Dave, what about getting this > fixed > the gold way? Seems worth investigating. I'll take a look at it starting tomorrow sometime.
[Bug target/45325] [4.6 Regression] target attribute doesn't work with -march=i586
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325 --- Comment #15 from Dave Korn 2011-01-28 15:28:33 UTC --- (In reply to comment #14) > The test is invalid on i[345]86-*-* without also enabling -msse. Does the same apply to libcpp/lex.c? i.e. Is that code invalid unless compiled with -msse2? LTO bootstrap with arch=i686,tune=generic was still broken last time I checked.
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 Dave Korn changed: What|Removed |Added CC||davek at gcc dot gnu.org --- Comment #22 from Dave Korn 2011-01-31 17:22:55 UTC --- (In reply to comment #21) > The problem is that first one is defined as prevailing_def_ironly while it is > not an definition, just use of the symbol. Correct would be to have > PREVAILING_DEF_IRONLY on the second and PREEMTED_IR on the first. > We probably should add sanity check that functions with PREVAILING_DEFs are > always analyzed and vars finalized. > > As observer by Richard, it comes from resolution file already: > abs-1.o 3 > 70 262910e5 PREEMPTED_IR main_test > main.o 3 > 76 e5772d37 PREVAILING_DEF_IRONLY main_test > should be the other way around > > I am quite convinced that we are seeing GNU LD bug and adding Dave Korn to CC > thus. Looking into it.
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #23 from Dave Korn 2011-01-31 18:53:30 UTC --- (In reply to comment #21) > The problem is that first one is defined as prevailing_def_ironly while it is > not an definition, just use of the symbol. Correct would be to have > PREVAILING_DEF_IRONLY on the second and PREEMTED_IR on the first. > We probably should add sanity check that functions with PREVAILING_DEFs are > always analyzed and vars finalized. > > As observer by Richard, it comes from resolution file already: > abs-1.o 3 > 70 262910e5 PREEMPTED_IR main_test > main.o 3 > 76 e5772d37 PREVAILING_DEF_IRONLY main_test > should be the other way around Why would you expect to see PREEMPTED_IR? There is only one definition of main_test; I would expect RESOLVED_IR. Rather than swapped, aren't they just plain wrong? > I am quite convinced that we are seeing GNU LD bug and adding Dave Korn to CC > thus. I also think you must be seeing a bug in LD, but haven't reproduced it yet; on both x86_64-linux and i686-cygwin I get the same correct resolution file: davek@gcc10:~/binutils/obj-gcc/gcc/pr47274$ cat *.res 3 abs-1.o 2 79 7d1d28a3 PREVAILING_DEF_IRONLY main_test 93 7d1d28a3 PREVAILING_DEF_IRONLY abs_called abs-1-lib.o 2 110 4db0e4c5 RESOLVED_IR inside_main 112 4db0e4c5 RESOLVED_IR abs_called main.o 4 79 8cf841f3 PREVAILING_DEF main 85 8cf841f3 PREVAILING_DEF_IRONLY link_error 89 8cf841f3 RESOLVED_IR main_test 99 8cf841f3 PREVAILING_DEF_IRONLY inside_main What endian-ness are the ppc and hppa targets?
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #25 from Dave Korn 2011-01-31 19:40:52 UTC --- (In reply to comment #24) > > What endian-ness are the ppc and hppa targets? > > hppa is big. I believe ppc is also big. > > Dave Probably the first time this code has been tested on a big endian machine. Maybe some field's being read wrong out of the symbols or something. If one of you could try the whole thing with "--save-temps -v -Wl,-v -Wl,--verbose", and attach the various .o and @ arg files (some of which still get left in /tmp) and the log of the build output, I may be able to run far enough through the link with just a cross binutils to get to the symbol resolution stage and debug it.
[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31827 --- Comment #12 from Dave Korn 2011-02-01 04:03:02 UTC --- (In reply to comment #11) > Recreated this on linux x86_64 with gcc 4.6-20110129. Running ulimit -a shows > me that the default stack limit is 8192 and increasing this to 18000 allows > the > test to complete at all optimization levels that are tested by make check. > Running at 17000 fails. This has gotten worse over the past couple of months; I fixed it on cygwin a while ago by turning up the stack size, finding that it needed somewhere between 10MB and 12MB on that target; now it's just started failing again. I don't know at what point we should consider this a compile-time performance regression. Paolo, even a 30% reduction seems like a good idea to me; why not submit that patch you developed?
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #28 from Dave Korn 2011-02-01 06:59:58 UTC --- It looks like the problem is much earlier than the linker; it looks like the IR symtabs in the input object files are being generated incorrectly. Here are the real symbol tables: $ ./obj/binutils/.libs/nm-new.exe *.o abs-1-lib.o: 0001 C __gnu_lto_v1 U abort T abs U abs_called U inside_main 0024 T labs abs-1.o: 0001 C __gnu_lto_v1 U abort U abs B abs_called T main_test main.o: 0001 C __gnu_lto_v1 0004 C inside_main T main U main_test And here are the IR symtabs (I built a cross GCC just far enough to get the liblto_plugin): $ ./obj/binutils/.libs/nm-new.exe --plugin ./obj-xgcc/lto-plugin/.libs/cyglto_p lugin-0.dll *.o abs-1-lib.o: T abs T abs_called T inside_main abs-1.o: T abs T abs_called T main_test main.o: T inside_main T main T main_test To confirm that the symtabs really are wrong in the object files, rather than that the plugin is misreading them, here's a binary dump from one: $ ./obj/binutils/.libs/objdump.exe -h abs-1-lib.o abs-1-lib.o: file format elf32-hppa-linux Sections: Idx Name Size VMA LMA File off Algn 0 .text 0058 0034 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .data 008c 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 008c 2**0 ALLOC 3 .gnu.lto_.jmpfuncs.29f392e1 0019 008c 2**0 CONTENTS, READONLY, EXCLUDE 4 .gnu.lto_.pureconst.29f392e1 0016 00a5 2**0 CONTENTS, READONLY, EXCLUDE 5 .gnu.lto_abs.29f392e1 0192 00bb 2**0 CONTENTS, READONLY, EXCLUDE 6 .gnu.lto_labs.29f392e1 0189 024d 2**0 CONTENTS, READONLY, EXCLUDE 7 .gnu.lto_.cgraph.29f392e1 003c 03d6 2**0 CONTENTS, READONLY, EXCLUDE 8 .gnu.lto_.vars.29f392e1 0018 0412 2**0 CONTENTS, READONLY, EXCLUDE 9 .gnu.lto_.refs.29f392e1 001b 042a 2**0 CONTENTS, READONLY, EXCLUDE 10 .gnu.lto_.statics.29f392e1 0014 0445 2**0 CONTENTS, READONLY, EXCLUDE 11 .gnu.lto_.decls.29f392e1 02ab 0459 2**0 CONTENTS, READONLY, EXCLUDE 12 .gnu.lto_.symtab.29f392e1 0048 0704 2**0 CONTENTS, READONLY, EXCLUDE 13 .gnu.lto_.opts 0012 074c 2**0 CONTENTS, READONLY, EXCLUDE 14 .PARISC.unwind 0020 0760 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 15 .comment 0042 0780 2**0 CONTENTS, READONLY $ ./obj/binutils/.libs/objcopy.exe -j .gnu.lto_.symtab.29f392e1 abs-1-lib.o sym s-abs-1-lib.o $ ./obj/binutils/.libs/objdump.exe -s syms-abs-1-lib.o syms-abs-1-lib.o: file format elf32-hppa-linux Contents of section .gnu.lto_.symtab.29f392e1: 61627300 abs. 0010 4669 6e736964 655f6d61 696e ..Finside_main.. 0020 00656162 .eab 0030 735f6361 6c6c6564 s_called 0040 0067...g The format of the IR symtab entries is: (variable-length) NUL-terminated name (variable-length) NUL-terminated comdat group (1 byte) symbol kind from LDPK_ enumeration (1 byte) symbol visibility from LDPV_ enumeration (8 bytes) 64-bit symbol size (4 bytes) 32-bits symbol aux info. As you can see, this symtab claims that abs-1-lib.o defines inside_main 61627300 abs. 0010 4669 6e736964 655f6d61 696e ..Finside_main.. \/ \/\/\/\/ \/\/\/\/ \/\/\/\/ name++ + comdat-+ 0020 00656162 .eab \/\/ kind--+ + 0 = LDPK_DEF vis-+ 0 = LDPV_DEFAULT 0030 735f6361 6c6c6564 s_called 0040 0067...g So the problem is that the object files are being written incorrectly in the first place, I think. Indeed, the contents of abs-1-lib.s look that way: .section.gnu.lto_.symtab.29f392e1,"",@progbits .stringz"abs" .stringz"" .stringz"" .stringz"" .stringz"" .stringz"" .stringz"" .stringz""
[Bug middle-end/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31827 --- Comment #14 from Dave Korn 2011-02-01 17:37:08 UTC --- (In reply to comment #13) > [ ... ] -fsplit-stack [ ... ] need for gold as host linker [ ... ] One of the ELF guys will have to answer that one for you!
[Bug lto/47274] [4.6 regression] ICE in lto_varpool_replace_node, at lto-symtab.c:306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47274 --- Comment #30 from Dave Korn 2011-02-01 19:17:04 UTC --- *** Bug 47287 has been marked as a duplicate of this bug. ***
[Bug lto/47287] FAIL: gcc.c-torture/execute/builtins/20010124-1.c execution with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47287 Dave Korn changed: What|Removed |Added Status|WAITING |RESOLVED CC||davek at gcc dot gnu.org Resolution||DUPLICATE --- Comment #12 from Dave Korn 2011-02-01 19:17:04 UTC --- I could be wrong (reopen the bug if I turn out to be mistaken), but I'll bet this is the same as PR47274: the IR symtabs are being generated incorrectly in the source .o files. To confirm, run the failing command again with --save-temps, and look for the .gnu.lto_.symtab.* sections; if you see a lot of stuff like this: .stringz"Finside_main" .stringz"" .stringz"" .stringz"" .stringz"" (to be precise, if there are more than two NUL bytes trailing the name), then it's the same bug. *** This bug has been marked as a duplicate of bug 47274 ***
[Bug lto/47527] [4.6 regression] -flto -flto-partition=none broken for arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47527 Dave Korn changed: What|Removed |Added Status|WAITING |RESOLVED CC||davek at gcc dot gnu.org Resolution||INVALID --- Comment #4 from Dave Korn 2011-02-12 17:48:46 UTC --- Hi guys, yes, this is definitely a linker bug, what must be happening is that there's some kind of private data not getting copied from the real BFD for the file into the dummy replacement BFD used to hold the linker symbols. I'm working on plugin api fixes right now, I'll take a look at how to fix this. Definitely not a GCC bug, so closing, but I'll come back here to mention the fix once I've posted it.
[Bug lto/47527] [4.6 regression] -flto -flto-partition=none broken for arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47527 --- Comment #5 from Dave Korn 2011-02-12 20:27:18 UTC --- Created attachment 23321 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23321 potential fix With this patch, ld doesn't check the arch/mach/lang/etc. of dummy IR-only BFDs any more. Ramana, I don't have a cross-compiler handy; is it possible you could check if this solves the problem?
[Bug lto/43157] Segmentation fault in aggregate_value_p, asm aliases do not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43157 Dave Korn changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Dave Korn 2011-02-14 01:08:17 UTC --- Verified that the problem was indeed fixed by the patch in comment 8.
[Bug lto/46652] undefined reference to '__udivdi3' with -flto -fuse-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46652 Dave Korn changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #8 from Dave Korn 2011-02-14 01:31:15 UTC --- Closing this PR, since, as discussed, it is a binutils bug: http://sourceware.org/bugzilla/show_bug.cgi?id=12305
[Bug bootstrap/52513] gcc-4.7.0-RC-20120302 fails to build for i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52513 Dave Korn changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX --- Comment #3 from Dave Korn 2012-03-07 13:36:52 UTC --- (In reply to comment #2) > (In reply to comment #1) > > 4.6 should be broken as well for you? > Oops. I reported wrong in my OP. I've actually been using a home-built 4.6.2 > for some time now... and it is the host compiler for this build: I had no problems building the RC using: binutils 2.22.51-1 cygwin 1.7.9-1 gcc4 4.5.3-3 gmp 4.3.2-1 make 3.82.90-1 mpfr 3.0.1-1 > > Can you check why configure thinks spawnve is available in process.h > > (contrary to the warning we see in your snippet)? > Sorry, I may not have been clear on this. Google reported that spawnve lives > in > process.h. A quick search on my filesystem shows that spawnve actually lives > in > , not as expected by pex-unix.c. > Perhaps the file moved recently (since 1.7.9 or 10)? I've sent mail to the > cygwin list to see if anybody there knows. Meanwhile, soft-linking process.h > to > where gcc expects it lets the compile continue. Right, I think this is a cygwin bug. The /usr/include/cygwin dir is private, you're not supposed to #include files from there directly, they should be indirectly included from within other system header files. If process.h is a public header, it shouldn't have been moved there. Ah. In fact, I see from the reply to your email there that it is indeed an acknowledged error in 1.7.10 and fixed already in 1.7.11. Since the .10 release was buggy in several other important ways, I don't think it's important to support it, we'll just tell people they need to upgrade. Closing as WONTFIX.
[Bug libstdc++/51135] [4.7 Regression] SIGSEGV during exception cleanup on win32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51135 Dave Korn changed: What|Removed |Added CC||davek at gcc dot gnu.org --- Comment #2 from Dave Korn 2011-12-05 15:10:54 UTC --- Doesn't reproduce on Cygwin, and I don't have a current mingw cross compiler handy. It would be best if Kai can look at this as I'm up to my neck in ada at the moment, if he hasn't found time in the next four or five days I'll try and investigate.
[Bug bootstrap/38388] parallel install failures in install-{libiberty,gnatlib}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38388 Dave Korn changed: What|Removed |Added Target|x86_64-gnu-linux| Status|RESOLVED|REOPENED Last reconfirmed||2011-12-06 CC||davek at gcc dot gnu.org Version|4.4.0 |4.7.0 Resolution|FIXED | Ever Confirmed|0 |1 --- Comment #9 from Dave Korn 2011-12-06 22:43:46 UTC --- [ Reopened because the gnatlib bug is still present. Removed target, because it is not target-specific. Not sure if bootstrap is still the right component or if it should be ada, so will leave that to discretion of bug maintainers. ] I saw this myself earlier, and asked about it on the GCC list at http://gcc.gnu.org/ml/gcc/2011-12/msg00050.html - On 03/12/2011 12:16, Dave Korn wrote: > Running "make -j8 install" in a fresh build of head, I saw loads of the > following error messages coming out in the log: > >> cp: cannot create regular file >> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-ztmoau.adb': >> File exists cp: cannot create regular file >> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-ztmoio.adb': >> File exists cp: cannot create regular file >> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-zttest.ads': >> File exists cp: cannot create regular file >> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-zzboio.ads': >> File exists cp: cannot create regular file >> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/ada.ads': >> File exists cp: cannot create regular file >> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/directio.ads': >> File exists > [ ... snip ... ] > > Sure enough, all the files did exist, so I guess it must have been trying to > install them twice. Before I try digging deeper, I thought I'd quickly ask: > Does anyone else see this? (Is it perhaps something that wouldn't show up on > a different host, such as linux, owing to differing filesystem semantics?) Okay, confirmed; I wonder why this isn't causing problems for anyone else? The issue is that there are two dependency chains that lead to the "install-gnatlib" target in the gcc/ada/gcc-interface/Makefile.in-derived Makefile in $objdir: [1] top level "make install" -> $objdir/$target/libada/Makefile "install: install-gnatlib" -> "install-gnatlib:" -> $objdir/gcc/ada/Makefile(*) "install-gnatlib:" -> $objdir/gcc/ada/gcc-interface/Makefile "install-gnatlib:". [2] top level "make install" -> $objdir/gcc/Makefile "install: install-common" -> "install-common: lang.install-common" -> "lang.install-common: ada.install-common" -> $(srcdir)/ada/gcc-interface/Make-lang.in "ada.install-common" -> "install-gnatlib" -> $objdir/gcc/ada/Makefile(*) "install-gnatlib:" -> $objdir/gcc/ada/gcc-interface/Makefile "install-gnatlib:". The two paths merge at (*), and so a parallel top-level make can end up running both of them at the same time. That gets broken, because the install-gnatlib target begins by wiping and recreating the install dirs: > install-gnatlib: ../stamp-gnatlib-$(RTSDIR) > # Create the directory before deleting it, in case the directory is > # a list of directories (as it may be on VMS). This ensures we are > # deleting the right one. > -$(MKDIR) $(DESTDIR)$(ADA_RTL_OBJ_DIR) > -$(MKDIR) $(DESTDIR)$(ADA_INCLUDE_DIR) > $(RMDIR) $(DESTDIR)$(ADA_RTL_OBJ_DIR) > $(RMDIR) $(DESTDIR)$(ADA_INCLUDE_DIR) > -$(MKDIR) $(DESTDIR)$(ADA_RTL_OBJ_DIR) > -$(MKDIR) $(DESTDIR)$(ADA_INCLUDE_DIR) Depending how out-of-sync the two separate sub-makes are, this results in an incomplete installation. Here's what happened in my latest test: > make[2]: Entering directory `/gnu/gcc/obj3/i686-pc-cygwin/libada' > make -C ../.././gcc/ada "MAKEOVERRIDES=" "LDFLAGS=" "LN_S=ln -s" > "SHELL=/bin/sh" "GNATLIBFLAGS=-W -Wall -gnatpg -nostdinc " "GNATLIBCFLAGS=-g > -O2 " "GNATLIBCFLAGS_FOR_C=-W -Wall -g -O2 -fexceptions -DIN_RTS > -DHAVE_GETIPINFO " "PICFLAG_FOR_TARGET=" "THREAD_KIND=native" "TRACE=no" > "MULTISUBDIR=" "libsubdir=/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0" "objext=.o&
[Bug ada/864] --program-suffix is ignored (for ada)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864 Dave Korn changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #20 from Dave Korn 2011-12-07 00:42:31 UTC --- And re-reopened. In the patch applied at comment 10, this code from Program_Name ... if End_Of_Prefix > 1 then Start_Of_Suffix := End_Of_Prefix + Prog'Length + 1; end if; ... means that it only recognizes a suffix if there is also a prefix, i.e. it only works for cross-compilers. The documentation suggests this is deliberate: function Program_Name (Nam : String; Prog : String) return String_Access; -- In the native compilation case, Create a string containing Nam. In the -- cross compilation case, looks at the prefix of the current program being -- run and prepend it to Nam. For instance if the program being run is -- -gnatmake and Nam is "gcc", the returned value will be a pointer -- to "-gcc". In the specific case where AAMP_On_Target is set, the -- name "gcc" is mapped to "gnaamp", and names of the form "gnat*" are -- mapped to "gnaamp*". This function clobbers Name_Buffer and Name_Len. -- Also look at any suffix, e.g. gnatmake-4.1 -> "gcc-4.1". Prog is the -- default name of the current program being executed, e.g. "gnatmake", -- "gnatlink". ... but why? The native behaviour is wrong and it seems incorrect to me that it should have different semantics from the cross-compiler case. I would also very much like to see the patch in comment 16 applied. There is now a second report open at bug 51095, I will mark it as a dup. Are there copyright or licensing reasons why it would have to be submitted by RG, or does posting it in BZ count as an assignment?
[Bug ada/51095] "make install" with --program-suffix does not install the bin/gnat* binaries with that suffix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51095 Dave Korn changed: What|Removed |Added Status|NEW |RESOLVED CC||davek at gcc dot gnu.org Resolution||DUPLICATE --- Comment #3 from Dave Korn 2011-12-07 00:45:10 UTC --- Confirmed. I would also like to see the patch in Attachment 18256 applied. I have re-opened bug 864 because there is (what I think is) a bug in the patch that was applied to resolve it. Since it's open again, we may as well resume the discussion here, so I'm marking this bug as a dup. *** This bug has been marked as a duplicate of bug 864 ***
[Bug ada/864] --program-suffix is ignored (for ada)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864 Dave Korn changed: What|Removed |Added CC||mark at grondar dot org --- Comment #21 from Dave Korn 2011-12-07 00:45:10 UTC --- *** Bug 51095 has been marked as a duplicate of this bug. ***
[Bug ada/51095] "make install" with --program-suffix does not install the bin/gnat* binaries with that suffix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51095 --- Comment #4 from Dave Korn 2011-12-07 00:46:18 UTC --- > we may as well resume the discussion here "there", not "here", sorry for any confusion.
[Bug other/39933] make clean fails in libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39933 Dave Korn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-12-08 CC||davek at gcc dot gnu.org Version|4.4.0 |4.7.0 Ever Confirmed|0 |1 Known to fail||4.4.0 --- Comment #3 from Dave Korn 2011-12-08 12:08:34 UTC --- Still present on HEAD at r.182098, with some minor differences in the error messages for me: make[1]: -B/n/10/davek/usr/x86_64-unknown-linux-gnu/bin/: Command not found make[1]: Entering directory `/home/davek/gcc/obj.clean/x86_64-unknown-linux-gnu/libgcc' make[1]: -B/n/10/davek/usr/x86_64-unknown-linux-gnu/bin/: Command not found make[1]: -B/n/10/davek/usr/x86_64-unknown-linux-gnu/bin/: Command not found /bin/sh: line 0: test: !=: unary operator expected rm -f config.h libgcc_tm.h stamp-h stmp-ldirs libgcc.map Makefile:165: *** Recursive variable `AR_FOR_TARGET' references itself (eventually). Stop. make[1]: Leaving directory `/home/davek/gcc/obj.clean/x86_64-unknown-linux-gnu/libgcc' make: *** [clean-stage3-target-libgcc] Error 2
[Bug other/39933] make clean fails in libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39933 Dave Korn changed: What|Removed |Added CC||ich at az2000 dot de --- Comment #4 from Dave Korn 2011-12-08 12:10:28 UTC --- *** Bug 40322 has been marked as a duplicate of this bug. ***
[Bug other/40322] make clean fails (/bin/bash: -/: invalid option)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40322 Dave Korn changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||davek at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Dave Korn 2011-12-08 12:10:28 UTC --- Same as bug 39933. *** This bug has been marked as a duplicate of bug 39933 ***
[Bug other/45994] During 'make clean', some variables not propagating properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45994 Dave Korn changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||davek at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Dave Korn 2011-12-08 12:10:35 UTC --- Same as bug 39933. *** This bug has been marked as a duplicate of bug 39933 ***
[Bug other/39933] make clean fails in libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39933 Dave Korn changed: What|Removed |Added CC||phantall at gmail dot com --- Comment #5 from Dave Korn 2011-12-08 12:10:35 UTC --- *** Bug 45994 has been marked as a duplicate of this bug. ***
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #56 from Dave Korn 2011-04-07 15:15:14 UTC --- What works for me on Cygwin, and so may well also work for anyone using MSYS, is setting the heap_chunk_in_mb registry parameter to some value in the range 1024 - 1536. I use 1024 myself and that gives me sufficient headroom to link libgcj dll, which is huge; if it works for that, it's likely to help with wx dll as well. http://cygwin.com/cygwin-ug-net/setup-maxmem.html
[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447 --- Comment #5 from Dave Korn 2011-04-07 15:49:29 UTC --- Well, this is basically a weakness in the pass-through solution implemented for PR 42690; it only knows about the compilers stdlibs, and doesn't process any user-specified libs on the command line. In the general case that's how things ought to be: LTRANS only generates new references to builtins/libcalls, not any of the user's code. However when you use -nostdlib and pass libgcc as if it were a user library, as in case 3, the pass-through mechanism doesn't know that it's actually a compiler runtime rather than user library and doesn't pass it through. The correct fix is going to be in the linker, not the compiler, by implementing a second library scan pass and obsoleting the pass-through mechanism. I've got a revised version of that experimental patch that I'll attach to this PR for reference.
[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447 --- Comment #6 from Dave Korn 2011-04-07 15:51:30 UTC --- Created attachment 23913 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23913 WIP patch Work in progress: see comment at start of do_rescan_work() re DT_NEEDED libs, but should be worth trying.
[Bug lto/48447] LTO link fails to link libgcc correctly when -nostdlib option is specified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48447 --- Comment #9 from Dave Korn 2011-04-07 22:22:51 UTC --- (In reply to comment #8) > > The correct fix is going to be in the linker, not the compiler, by > > implementing > > a second library scan pass and obsoleting the pass-through mechanism. I've > > got > > a revised version of that experimental patch that I'll attach to this PR for > > reference. > > How does this affect circular dependencies between user supplied libraries. ld > used to resolve these ok, and from the outside it seems like a similar > problem. It doesn't affect them at all. This problem only arises because the LTRANS phase (when the plugin invokes lto-wrapper to recompile all the IR files that it has claimed) sometimes creates new undefined references that weren't in the LTO symbol tables in the original IR. However, it is guaranteed that these references are only ever going to be to functions that the compiler knows about itself as builtins, so will only ever result in references to the various compiler language runtimes and the core system libraries; for user-supplied functions. LTO creates symbol tables in the IR files that drive the linker's initial symbol resolution process, and these symbol tables will contain explicit references to any external functions that aren't part of the language and compiler runtimes; it however deliberately omits references to compiler builtins, since they may well be optimised out during LTRANS. So, everything related to user-supplied functions should behave identically regardless of LTO, either with or without this extra patch to cause GCC to rescan the libraries.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #61 from Dave Korn 2011-04-21 00:40:17 UTC --- (In reply to comment #59) > I review the patch, and found that we can add "-fno-keep-inline-dllexport" to > the compiler option, and then, the compiler and linker stage works well. But > the wxWidgets release mono dll's size is so large.(about 17M) In newer versions of GCC there is also a lot more debug info and Dwarf-2 exception table data that didn't used to be there. Stripping the dll and/or building a compiler with SJLJ rather than dwarf exceptions might help, although SJLJ trades off executable size for slower runtime. (Badly; dwarf exceptions only take CPU time when one is actually thrown, whereas SJLJ exceptions take CPU time every time you enter or exit a try block. Since exceptions are meant to be exceptional conditions that only happen occasionally, this tradeoff is probably worthwhile on desktop platforms where memory is not in short supply, but SJLJ might still be better on embedded platforms where memory is so critical that slower runtime performance might be the preferable option.)
[Bug 43601] (c++) Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #25 from Dave Korn 2010-09-24 05:00:16 UTC --- I'm going to be working on a patch in this area in the next few weeks (I want to make the dllexport/dllimport attributes work on C++ namespaces), and I can probably do something about this issue while I'm in there anyway. Before I put a bunch of time into that, however, I'd like to see actual diagnosis of what's in the different .o files so that I know that I won't be wasting my time, e.g. what if the extra emitted functions is actually only contributing 10% of this growth in file sizes and the other 90% comes from debug info or EH tables? If something like that did turn out to be the case, then the effort would be wasted as the new option wouldn't actually solve your link-time problems anyway. So I would like to see some proper detailed analysis on object files establishing exactly what constitutes all this bloat and where it comes from before I commit to what might be the wrong path of action. [ Vadim, it's no use sending me off-list mail if your domain doesn't accept replies from gmail.com! Email addresses @gcc.gnu.org are just redirectors to maintainers' primary accounts. ] -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug testsuite/45851] New: FAIL: gcc.dg/lto/20090210 link test with WHOPR owing to bad -pthread option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45851
Summary: FAIL: gcc.dg/lto/20090210 link test with WHOPR owing
to bad -pthread option.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: da...@gcc.gnu.org
>From original post at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01076.html:
On 15/07/2010 19:08, Rainer Orth wrote:
> > * The TLS tests in libobjc failed because they weren't linked with
> > -pthread. I've implemented and used dg-add-options tls to handle
> > this. Only gcc.dg/lto/20090210_0.c needs an explict
> > dg-extra-ld-options "-pthread" since dg-lto-do tests don't work with
> > dg-add-options.
> > gcc/testsuite:
> > * gcc.dg/lto/20090210_0.c: Add -pthread for *-*-solaris2.[89].
Hi Rainer,
I have a problem on i686-pc-cygwin caused by this part of your patch:
> > diff -r c7b371acdb35 gcc/testsuite/gcc.dg/lto/20090210_0.c
> > --- a/gcc/testsuite/gcc.dg/lto/20090210_0.c Mon Jul 12 16:03:30 2010 +0200
> > +++ b/gcc/testsuite/gcc.dg/lto/20090210_0.c Thu Jul 15 18:27:58 2010 +0200
> > @@ -1,5 +1,7 @@
> > /* { dg-lto-do run } */
> > /* { dg-suppress-ld-options {-fPIC} } */
> > +/* { dg-require-effective-target tls } */
> > +/* { dg-extra-ld-options "-pthread" { target *-*-solaris2.[89] } } */
> > int foo (int x)
> > {
> >return x;
As far as I can tell, dg-extra-ld-options doesn't take a target modifier in
the way you've used there, so that "-pthread" is in effect on all targets and
breaks the testcase on targets which don't support that option. See proc
lto-get-options-main in gcc/testsuite/lto.exp. Perhaps you could extend it to
work with a target selector? Or maybe there's some other way you could get
the -pthread flag passed on Solaris (only)?
cheers,
DaveK
Here's gcc.log around where the failure occurs:
Executing on host: /gnu/gcc/obj-tfmode-fenv/gcc/xgcc
-B/gnu/gcc/obj-tfmode-fenv/gcc/ -O0 -fwhopr -c -o c_lto_20090210_0.o
/gnu/gcc/gcc-unpatched/gcc/testsuite/gcc.dg/lto/20090210_0.c(timeout = 300)
spawn /gnu/gcc/obj-tfmode-fenv/gcc/xgcc -B/gnu/gcc/obj-tfmode-fenv/gcc/ -O0
-fwhopr -c -o c_lto_20090210_0.o
/gnu/gcc/gcc-unpatched/gcc/testsuite/gcc.dg/lto/20090210_0.c
PASS: gcc.dg/lto/20090210 c_lto_20090210_0.o assemble, -O0 -fwhopr
Executing on host: /gnu/gcc/obj-tfmode-fenv/gcc/xgcc
-B/gnu/gcc/obj-tfmode-fenv/gcc/ -O0 -fwhopr -fPIC -c -o c_lto_20090210_1.o
/gnu/gcc/gcc-unpatched/gcc/testsuite/gcc.dg/lto/20090210_1.c(timeout = 300)
spawn /gnu/gcc/obj-tfmode-fenv/gcc/xgcc -B/gnu/gcc/obj-tfmode-fenv/gcc/ -O0
-fwhopr -fPIC -c -o c_lto_20090210_1.o
/gnu/gcc/gcc-unpatched/gcc/testsuite/gcc.dg/lto/20090210_1.c
/gnu/gcc/gcc-unpatched/gcc/testsuite/gcc.dg/lto/20090210_1.c:1:0: warning:
-fPIC ignored for target (all code is position independent) [enabled by
default]
output is:
/gnu/gcc/gcc-unpatched/gcc/testsuite/gcc.dg/lto/20090210_1.c:1:0: warning:
-fPIC ignored for target (all code is position independent) [enabled by
default]
PASS: gcc.dg/lto/20090210 c_lto_20090210_1.o assemble, -O0 -fwhopr
Executing on host: /gnu/gcc/obj-tfmode-fenv/gcc/xgcc
-B/gnu/gcc/obj-tfmode-fenv/gcc/ c_lto_20090210_0.o c_lto_20090210_1.o -O0
-fwhopr -pthread -o gcc-dg-lto-20090210-01(timeout = 300)
spawn /gnu/gcc/obj-tfmode-fenv/gcc/xgcc -B/gnu/gcc/obj-tfmode-fenv/gcc/
c_lto_20090210_0.o c_lto_20090210_1.o -O0 -fwhopr -pthread -o
gcc-dg-lto-20090210-01
xgcc: error: unrecognized option '-pthread'
compiler exited with status 1
output is:
xgcc: error: unrecognized option '-pthread'
FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O0
-fwhopr
UNRESOLVED: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o execute
-O0 -fwhopr
[Bug testsuite/45851] FAIL: gcc.dg/lto/20090210 link test with WHOPR owing to bad -pthread option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45851 Dave Korn changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.10.01 01:30:26 AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Dave Korn 2010-10-01 01:30:26 UTC --- Hi Rainer; Cc'ing you as requested back before you went on vacation.
[Bug middle-end/45935] New: Many g++.dg/gomp failures with ICE in expand_omp_taskreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45935 Summary: Many g++.dg/gomp failures with ICE in expand_omp_taskreg Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: da...@gcc.gnu.org Created attachment 21988 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=21988 sample failing testcase Running /gnu/gcc/gcc-unpatched/gcc/testsuite/g++.dg/gomp/gomp.exp ... FAIL: g++.dg/gomp/block-0.C (internal compiler error) FAIL: g++.dg/gomp/block-0.C (test for excess errors) FAIL: g++.dg/gomp/block-11.C (internal compiler error) FAIL: g++.dg/gomp/block-11.C (test for excess errors) FAIL: g++.dg/gomp/for-12.C (internal compiler error) FAIL: g++.dg/gomp/for-12.C (test for excess errors) FAIL: g++.dg/gomp/for-13.C (internal compiler error) FAIL: g++.dg/gomp/for-13.C (test for excess errors) FAIL: g++.dg/gomp/for-14.C (internal compiler error) FAIL: g++.dg/gomp/for-14.C (test for excess errors) FAIL: g++.dg/gomp/for-15.C (internal compiler error) FAIL: g++.dg/gomp/for-15.C (test for excess errors) FAIL: g++.dg/gomp/macro-1.C (internal compiler error) FAIL: g++.dg/gomp/macro-1.C (test for excess errors) FAIL: g++.dg/gomp/macro-2.C (internal compiler error) FAIL: g++.dg/gomp/macro-2.C (test for excess errors) FAIL: g++.dg/gomp/macro-3.C (internal compiler error) FAIL: g++.dg/gomp/macro-3.C (test for excess errors) FAIL: g++.dg/gomp/parallel-1.C (internal compiler error) FAIL: g++.dg/gomp/parallel-1.C (test for excess errors) FAIL: g++.dg/gomp/parallel-3.C (internal compiler error) FAIL: g++.dg/gomp/parallel-3.C (test for excess errors) FAIL: g++.dg/gomp/pr24849.C (internal compiler error) FAIL: g++.dg/gomp/pr24849.C (test for excess errors) FAIL: g++.dg/gomp/pr25874.C (internal compiler error) FAIL: g++.dg/gomp/pr25874.C (test for excess errors) FAIL: g++.dg/gomp/pr26611-1.C (internal compiler error) FAIL: g++.dg/gomp/pr26611-1.C (test for excess errors) FAIL: g++.dg/gomp/pr26611-2.C (internal compiler error) FAIL: g++.dg/gomp/pr26611-2.C (test for excess errors) FAIL: g++.dg/gomp/pr26823-1.C (internal compiler error) FAIL: g++.dg/gomp/pr26823-1.C (test for excess errors) FAIL: g++.dg/gomp/pr26823-2.C (internal compiler error) FAIL: g++.dg/gomp/pr26823-2.C (test for excess errors) FAIL: g++.dg/gomp/pr26913.C (internal compiler error) FAIL: g++.dg/gomp/pr26913.C (test for excess errors) FAIL: g++.dg/gomp/pr27310.C (internal compiler error) FAIL: g++.dg/gomp/pr27310.C (test for excess errors) FAIL: g++.dg/gomp/pr27325.C (internal compiler error) FAIL: g++.dg/gomp/pr27325.C (test for excess errors) FAIL: g++.dg/gomp/pr27337-1.C (internal compiler error) FAIL: g++.dg/gomp/pr27337-1.C (test for excess errors) FAIL: g++.dg/gomp/pr27337-2.C (internal compiler error) FAIL: g++.dg/gomp/pr27337-2.C (test for excess errors) FAIL: g++.dg/gomp/pr29965-1.C (internal compiler error) FAIL: g++.dg/gomp/pr29965-1.C (test for excess errors) FAIL: g++.dg/gomp/pr29965-10.C (internal compiler error) FAIL: g++.dg/gomp/pr29965-10.C (test for excess errors) FAIL: g++.dg/gomp/pr29965-2.C (internal compiler error) FAIL: g++.dg/gomp/pr29965-2.C (test for excess errors) FAIL: g++.dg/gomp/pr29965-4.C (internal compiler error) FAIL: g++.dg/gomp/pr29965-4.C (test for excess errors) FAIL: g++.dg/gomp/pr29965-5.C (internal compiler error) FAIL: g++.dg/gomp/pr29965-5.C (test for excess errors) FAIL: g++.dg/gomp/pr29965-6.C (internal compiler error) FAIL: g++.dg/gomp/pr29965-6.C (test for excess errors) FAIL: g++.dg/gomp/pr29965-7.C (internal compiler error) FAIL: g++.dg/gomp/pr29965-7.C (test for excess errors) FAIL: g++.dg/gomp/pr29965-8.C (internal compiler error) FAIL: g++.dg/gomp/pr29965-8.C (test for excess errors) FAIL: g++.dg/gomp/pr30558.C (internal compiler error) FAIL: g++.dg/gomp/pr30558.C (test for excess errors) FAIL: g++.dg/gomp/pr30696.C (internal compiler error) FAIL: g++.dg/gomp/pr30696.C (test for excess errors) FAIL: g++.dg/gomp/pr31598.C (internal compiler error) FAIL: g++.dg/gomp/pr31598.C (test for excess errors) FAIL: g++.dg/gomp/pr31769.C (internal compiler error) FAIL: g++.dg/gomp/pr31769.C (test for excess errors) FAIL: g++.dg/gomp/pr32177.C (internal compiler error) FAIL: g++.dg/gomp/pr32177.C (test for excess errors) FAIL: g++.dg/gomp/pr3.C (internal compiler error) FAIL: g++.dg/gomp/pr3.C (test for excess errors) FAIL: g++.dg/gomp/pr33372-2.C (internal compiler error) FAIL: g++.dg/gomp/pr33372-2.C (test for excess errors) FAIL: g++.dg/gomp/pr34608.C (internal compiler error) FAIL: g++.dg/gomp/pr34608.C (test for excess errors) FAIL: g++.dg/gomp/pr34694.C (internal compiler error) FAIL: g++.dg/gomp/pr34694.C (test for warnings, line 12) FAIL: g++.dg/gomp/pr34694.C (test for warnings, line 13) FAIL: g++.dg/gomp/pr34694.C (test for excess errors) FAIL: g++.dg/gomp/pr35028.C (internal compiler error) FAIL: g++.dg/gom
[Bug middle-end/45926] [4.6 Regression] Revision 165057 breaks GOMP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45926 Dave Korn changed: What|Removed |Added CC||davek at gcc dot gnu.org --- Comment #2 from Dave Korn 2010-10-07 15:29:22 UTC --- *** Bug 45935 has been marked as a duplicate of this bug. ***
[Bug middle-end/45935] [4.6 Regression] Many g++.dg/gomp failures with ICE in expand_omp_taskreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45935 Dave Korn changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Dave Korn 2010-10-07 15:29:22 UTC --- Found it. Already fixed on head. *** This bug has been marked as a duplicate of bug 45926 ***
[Bug testsuite/45851] FAIL: gcc.dg/lto/20090210 link test with WHOPR owing to bad -pthread option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45851 Dave Korn changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #6 from Dave Korn 2010-10-12 12:09:53 UTC --- Verified at http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00997.html
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #36 from Dave Korn 2010-10-14 15:37:34 UTC --- Hi everyone, sorry I've been busy working on LTO stuff for a bit but I haven't forgotten this. Before this discussion gets too heated, could Vadim and/or Cesar please add some of the object files we've been discussing as attachments to this bug report, so that we can all take a close look at why gcc's files are so much bigger? Thanks. I think depending what we uncover this might be an enhancement request rather than a bug, but we'll see.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #41 from Dave Korn 2010-10-14 15:50:53 UTC --- (In reply to comment #40) > (In reply to comment #36) > > could Vadim and/or Cesar please add > > some of the object files we've been discussing as attachments to this bug > > report, so that we can all take a close look at why gcc's files are so much > > bigger? > > I attached 4.4 and 4.5 versions and can also add 3.4 one as well as MSVC9 > build > of the same file, please let me know if this could be useful. > > Thanks! Yes please, I'm particularly interested in comparing the gcc files with the MSVC ones. (I'm going to be AFK for a few hours now and will look through them this evening.)
[Bug target/45325] [4.6 Regression] target attribute doesn't work with -march=i586
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325 --- Comment #12 from Dave Korn 2010-10-17 14:24:06 UTC --- This also breaks lto-bootstrap on i686-pc-cygwin: /gnu/gcc/gcc/libcpp/lex.c: In function ‘search_line_sse2’: /gnu/gcc/gcc/libcpp/lex.c:370:15: internal compiler error: in convert_move, at expr.c:326 In the call to convert_move, we have: to = (reg/v:V16QI 62 [ repl_nl ]) from = (mem/u/c:BLK (reg/f:SI 97) [0 MEM[(const v16qi *)&repl_chars]+0 S16 A128])
[Bug tree-optimization/44776] FAIL: gcc.dg/matrix/transpose-3.c execution, -fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44776 Dave Korn changed: What|Removed |Added CC||davek at gcc dot gnu.org --- Comment #10 from Dave Korn 2010-10-18 17:06:11 UTC --- Also fails on i686-pc-cygwin since at least r.161958 (still fails at r.165450) FAIL: gcc.dg/matrix/transpose-3.c execution,-fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix-reorg -O3 -fwhole-program In this case, it turns out to be a double free: $ /gnu/gcc/obj-lto/gcc/xgcc -B/gnu/gcc/obj-lto/gcc/ /gnu/gcc/gcc/gcc/testsuite/ gcc.dg/matrix/transpose-3.c -fprofile-use -fipa-matrix-reorg -fdump-ipa-matrix- reorg -O3 -fwhole-program -o ./transpose-3.x02 /gnu/gcc/gcc/gcc/testsuite/gcc.dg/matrix/transpose-3.c: In function 'mem_init': /gnu/gcc/gcc/gcc/testsuite/gcc.dg/matrix/transpose-3.c:96:1: note: file /gnu/gcc /obj-lto/gcc/testsuite/transpose-3.gcda not found, execution counts estimated $ gdb ./transpose-3.x02 GNU gdb 6.8.0.20080328-cvs (cygwin-special) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) b main Breakpoint 1 at 0x401176 (gdb) r Starting program: /gnu/gcc/obj-lto/gcc/testsuite/transpose-3.x02 [New thread 2236.0x184] [New thread 2236.0xc6c] Breakpoint 1, 0x00401176 in main () (gdb) b free Breakpoint 2 at 0x610725e0: file /gnu/winsup/src.clean/winsup/cygwin/malloc_wrap per.cc, line 41. (gdb) c Continuing. acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to d im2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 acc to dim2 [0][0][0]=0 [0][0][1]=12 [1][0][0]=4 [1][0][1]=16 [2][0][0]=8 [2][0][1]=20 [0][1][0]=1 [0][1][1]=13 [1][1][0]=5 [1][1][1]=17 [2][1][0]=9 [2][1][1]=21 [0][2][0]=2 [0][2][1]=14 [1][2][0]=6 [1][2][1]=18 [2][2][0]=10 [2][2][1]=22 [0][3][0]=3 [0][3][1]=15 [1][3][0]=7 [1][3][1]=19 [2][3][0]=11 [2][3][1]=23 Breakpoint 2, free (p=0x45a080) at /gnu/winsup/src.clean/winsup/cygwin/malloc_wrapper.cc:41 41 free (void *p) Current language: auto; currently c++ (gdb) c Continuing. Breakpoint 2, free (p=0x45a080) at /gnu/winsup/src.clean/winsup/cygwin/malloc_wrapper.cc:41 41 free (void *p) (gdb) c Continuing. Program received signal SIGABRT, Aborted. 0x77f88f13 in ?? () (gdb)
[Bug target/46195] r165965 regresses i386 darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46195 Dave Korn changed: What|Removed |Added CC||davek at gcc dot gnu.org --- Comment #25 from Dave Korn 2010-11-02 05:30:01 UTC --- Hi HJ, I'm getting a ton of failures caused by this same warning message at r166110 on i686-pc-cygwin: FAIL: gcc.dg/tree-ssa/forwprop-5.c (test for excess errors) FAIL: gcc.dg/tree-ssa/fre-vce-1.c (test for excess errors) FAIL: gcc.dg/tree-ssa/sra-4.c (test for excess errors) FAIL: gcc.dg/tree-ssa/vector-1.c (test for excess errors) FAIL: gcc.dg/tree-ssa/vector-2.c (test for excess errors) FAIL: gcc.c-torture/execute/va-arg-25.c compilation, -O0 FAIL: gcc.c-torture/execute/va-arg-25.c compilation, -O1 FAIL: gcc.c-torture/execute/va-arg-25.c compilation, -O2 FAIL: gcc.c-torture/execute/va-arg-25.c compilation, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/va-arg-25.c compilation, -O3 -g FAIL: gcc.c-torture/execute/va-arg-25.c compilation, -Os FAIL: gcc.c-torture/execute/va-arg-25.c compilation, -O2 -flto FAIL: gcc.c-torture/execute/va-arg-25.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/vector-1.c compilation, -O0 FAIL: gcc.c-torture/execute/vector-1.c compilation, -O1 FAIL: gcc.c-torture/execute/vector-1.c compilation, -O2 FAIL: gcc.c-torture/execute/vector-1.c compilation, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/vector-1.c compilation, -O3 -g FAIL: gcc.c-torture/execute/vector-1.c compilation, -Os FAIL: gcc.c-torture/execute/vector-1.c compilation, -O2 -flto FAIL: gcc.c-torture/execute/vector-1.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/execute/vector-2.c compilation, -O0 FAIL: gcc.c-torture/execute/vector-2.c compilation, -O1 FAIL: gcc.c-torture/execute/vector-2.c compilation, -O2 FAIL: gcc.c-torture/execute/vector-2.c compilation, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/vector-2.c compilation, -O3 -g FAIL: gcc.c-torture/execute/vector-2.c compilation, -Os FAIL: gcc.c-torture/execute/vector-2.c compilation, -O2 -flto FAIL: gcc.c-torture/execute/vector-2.c compilation, -O2 -fwhopr FAIL: gcc.c-torture/compile/pr34856.c (test for excess errors) FAIL: gcc.c-torture/compile/pr34856.c (test for excess errors) FAIL: gcc.c-torture/compile/pr34856.c (test for excess errors) FAIL: gcc.c-torture/compile/pr34856.c (test for excess errors) FAIL: gcc.c-torture/compile/pr34856.c (test for excess errors) FAIL: gcc.c-torture/compile/pr34856.c (test for excess errors) FAIL: gcc.c-torture/compile/pr34856.c (test for excess errors) FAIL: gcc.c-torture/compile/pr34856.c (test for excess errors) FAIL: gcc.c-torture/compile/pr34856.c (test for excess errors) FAIL: gcc.c-torture/compile/pr34856.c (test for excess errors) FAIL: gcc.c-torture/compile/pr39928-1.c (test for excess errors) FAIL: gcc.c-torture/compile/pr39928-1.c (test for excess errors) FAIL: gcc.c-torture/compile/pr39928-1.c (test for excess errors) FAIL: gcc.c-torture/compile/pr39928-1.c (test for excess errors) FAIL: gcc.c-torture/compile/pr39928-1.c (test for excess errors) FAIL: gcc.c-torture/compile/pr39928-1.c (test for excess errors) FAIL: gcc.c-torture/compile/pr39928-1.c (test for excess errors) FAIL: gcc.c-torture/compile/pr39928-1.c (test for excess errors) FAIL: gcc.c-torture/compile/vector-1.c (test for excess errors) FAIL: gcc.c-torture/compile/vector-1.c (test for excess errors) FAIL: gcc.c-torture/compile/vector-1.c (test for excess errors) FAIL: gcc.c-torture/compile/vector-1.c (test for excess errors) FAIL: gcc.c-torture/compile/vector-1.c (test for excess errors) FAIL: gcc.c-torture/compile/vector-1.c (test for excess errors) FAIL: gcc.c-torture/compile/vector-1.c (test for excess errors) FAIL: gcc.c-torture/compile/vector-1.c (test for excess errors) FAIL: gcc.c-torture/compile/vector-2.c (test for excess errors) FAIL: gcc.c-torture/compile/vector-2.c (test for excess errors) FAIL: gcc.c-torture/compile/vector-2.c (test for excess errors) FAIL: gcc.c-torture/compile/vector-2.c (test for excess errors) FAIL: gcc.c-torture/compile/vector-2.c (test for excess errors) FAIL: gcc.c-torture/compile/vector-2.c (test for excess errors) FAIL: gcc.c-torture/compile/vector-2.c (test for excess errors) FAIL: gcc.c-torture/compile/vector-2.c (test for excess errors) FAIL: gcc.dg/pr32912-1.c (test for excess errors) FAIL: gcc.target/i386/vect-args.c (test for excess errors) FAIL: gcc.target/i386/vect-args.c (test for excess errors) FAIL: gcc.target/i386/vect-args.c (test for excess errors) FAIL: gcc.target/i386/vect-args.c (test for excess errors) FAIL: gcc.target/i386/vect-args.c (test for excess errors) FAIL: gcc.target/i386/vect-args.c (test for excess errors) FAIL: gcc.target/i386/vect-args.c (test for excess errors) FAIL: gcc.target/i386/vect-args.c (test for excess errors) Should I reopen this bug or file a new one?
[Bug lto/46273] [4.6 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46273 Dave Korn changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.02 22:49:51 CC||davek at gcc dot gnu.org AssignedTo|unassigned at gcc dot |davek at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Dave Korn 2010-11-02 22:49:51 UTC --- I have a full fix for this. I'll un-revert the removal as part of it since it then will truly no longer be needed.
[Bug lto/46273] [4.6 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46273 Dave Korn changed: What|Removed |Added Keywords||build, patch URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-11/msg00229.htm ||l --- Comment #5 from Dave Korn 2010-11-03 00:08:13 UTC --- Patch posted at http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00229.html, tests running.
[Bug lto/46273] [4.6 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46273 Dave Korn changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p |atches/2010-11/msg00229.htm |atches/2010-11/msg00233.htm |l |l --- Comment #6 from Dave Korn 2010-11-03 01:02:20 UTC --- respun patch.
[Bug lto/46273] [4.6 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46273 --- Comment #7 from Dave Korn 2010-11-03 09:14:36 UTC --- Author: davek Date: Wed Nov 3 09:14:32 2010 New Revision: 166233 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166233 Log: ChangeLog: 2010-11-03 Ian Lance Taylor Dave Korn PR lto/46273 * configure.ac: Remove libelf tests. Build lto-plugin on ELF always and on other supported platforms whenever LTO is enabled. * configure: Rebuild. gcc/ChangeLog: 2010-11-03 Ian Lance Taylor PR lto/46273 * gcc/config.gcc: Don't set lto_binary_reader. * doc/install.texi (Prerequisites): Remove libelf paragraphs. (Configuration): Mention --disable-lto. Remove --with-libelf paragraph. lto-plugin/ChangeLog: 2010-11-03 Dave Korn PR lto/46273 * lto-plugin.h: Delete. * lto-plugin-elf.c: Likewise. * lto-plugin-coff.c: Likewise. * configure.ac: Don't use libelf, don't source config.gcc. (LIBELFLIBS): Delete. (LIBELFINC): Delete. (LTO_FORMAT): Delete. (SYM_STYLE): Add AC_DEFINE var, set based on $target. (config.h): Add AC_CONFIG_HEADERS directive. * Makefile.am (LIBELFLIBS): Delete. (LIBELFINC): Delete. (LTO_FORMAT): Delete. (DEFS): Import. (AM_CPPFLAGS): Use it. Don't use LIBELFINC. (liblto_plugin_la_SOURCES): Don't use LTO_FORMAT, don't include any object-format-specific source file in the link. (liblto_plugin_la_LIBADD): Don't use LIBELFLIBS. * config.h.in: Generate. * configure: Regenerate. * Makefile.in: Likewise. * lto-plugin.c (O_BINARY): Definition moved here from lto-plugin.h. (LTO_SEGMENT_NAME): New definition. (LTO_SECTION_PREFIX): Definition moved here from lto-plugin.h. (LTO_SECTION_PREFIX_LEN): New definition. (struct sym_aux): Struct definition moved here from lto-plugin.h. (struct plugin_symtab): Likewise. (struct plugin_objfile): Likewise. (struct plugin_objfile): New struct def. (enum symbol_style): New enum type. (add_symbols): Make static. (claimed_files): Likewise. (num_claimed_files): Likewise. (sym_style): New global. (check): Make static. (parse_table_entry): Likewise. Respect sym_style when extracting symbol from symtab entry. (translate): Make static. (resolve_conflicts): Likewise. (process_symtab): New function, per-section callback version of old object-format-specific handling from deleted lto-plugin-elf.c. (claim_file_handler): Convert ELF-specific version from deleted lto-plugin-elf.c to simple_object interface and move here. (process_options): Allow new '-sym-style=' option. (onload): Don't call deleted onload_format_checks hook. Added: trunk/lto-plugin/config.h.in Removed: trunk/lto-plugin/lto-plugin-coff.c trunk/lto-plugin/lto-plugin-elf.c trunk/lto-plugin/lto-plugin.h Modified: trunk/ChangeLog trunk/configure trunk/configure.ac trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/doc/install.texi trunk/lto-plugin/ChangeLog trunk/lto-plugin/Makefile.am trunk/lto-plugin/Makefile.in trunk/lto-plugin/configure trunk/lto-plugin/configure.ac trunk/lto-plugin/lto-plugin.c
[Bug lto/46273] [4.6 Regression] Failed to bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46273 Dave Korn changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Dave Korn 2010-11-03 09:18:28 UTC --- Fix committed revision 166233, as mentioned above.
[Bug lto/46291] [4.6 Regression] Failed to bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46291 --- Comment #1 from Dave Korn 2010-11-03 17:12:51 UTC --- I am investigating.
[Bug lto/46291] [4.6 Regression] Failed to bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46291
Dave Korn changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2010.11.03 20:49:18
AssignedTo|unassigned at gcc dot |davek at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #2 from Dave Korn 2010-11-03 20:49:18
UTC ---
I have found the problem. There is an ambiguity in the plugin interface spec.
http://gcc.gnu.org/wiki/whopr/driver says
" Input Files
[ ... ]
struct ld_plugin_input_file
{
const char *name;
int fd;
[ ... ]
};
[ ... ]
fd: An open file descriptor for the input file. The current position in the
file is undefined (i.e., the plug-in must call lseek before reading). If the
plug-in
^^
claims the file, it will then own the file descriptor and has the
responsibility
^
for closing it. If the plug-in does not claim the file, it must leave it open,
but
^^^
it is not required to maintain the current position in the file. "
However it also says:
" Plugin Interfaces
[ ... ]
4.
[ ... ]
Whether the file is claimed or not, the linker maintains responsibility for
^^^
opening and closing the file as necessary."
^^
Oops. Guess which way LD does it? Guess which way GOLD does it?
Ian? Which way should this really be?
While we decide, I have a patch that will fix lto-bootstrap by detecting which
linker is calling onload and deciding whether or not to close the fd on that
basis.
[Bug lto/46291] [4.6 Regression] Failed to bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46291 --- Comment #3 from Dave Korn 2010-11-03 20:51:02 UTC --- Created attachment 22267 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22267 only close fd if we were called by gnu ld About to put this through a test cycle.
[Bug lto/46291] [4.6 Regression] Failed to bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46291 --- Comment #5 from Dave Korn 2010-11-03 21:35:11 UTC --- Thanks Cary. I shall prepare a different patch that simply deletes the lines that close the fd, and shall fix LD to match.
[Bug lto/46291] [4.6 Regression] Failed to bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46291 Dave Korn changed: What|Removed |Added Attachment #22267|0 |1 is obsolete|| --- Comment #6 from Dave Korn 2010-11-03 21:42:26 UTC --- Created attachment 22269 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22269 never close the fd
[Bug lto/46291] [4.6 Regression] Failed to bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46291 Dave Korn changed: What|Removed |Added Keywords||build, lto, patch URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-11/msg00362.htm ||l --- Comment #7 from Dave Korn 2010-11-03 21:43:48 UTC --- posted. bootstrap running.
[Bug lto/46291] [4.6 Regression] Failed to bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46291 --- Comment #8 from Dave Korn 2010-11-03 23:13:55 UTC --- Author: davek Date: Wed Nov 3 23:13:51 2010 New Revision: 166285 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166285 Log: PR lto/46291 * lto-plugin.c (claim_file_handler): Don't close file descriptor. Modified: trunk/lto-plugin/ChangeLog trunk/lto-plugin/lto-plugin.c
[Bug lto/46291] [4.6 Regression] Failed to bootstrap-lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46291 Dave Korn changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Dave Korn 2010-11-03 23:15:19 UTC --- works now.
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 Dave Korn changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.05 17:44:25 AssignedTo|unassigned at gcc dot |davek at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Dave Korn 2010-11-05 17:44:25 UTC --- investigating, thanks for the report
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319
--- Comment #3 from Dave Korn 2010-11-05 22:59:04
UTC ---
When I tried running these tests in a pre-existing build tree,
plugin_default_version_check failed because the datestamps don't match up:
(gdb) p gcc_version[0]
$5 = {basever = 0x1029fe8 "4.6.0", datestamp = 0x1029fee "20101103",
devphase = 0x1029ff7 "experimental", revision = 0x1143f30 "",
configuration_arguments = 0xd2d2c0 "/n/10/davek/gcc/gcc/configure
--prefix=/n/
10/davek/gcc --with-mpfr=/opt/cfarm/mpfr-2.4.1 --with-gmp=/opt/cfarm/gmp-4.2.4
-
-with-mpc=/opt/cfarm/mpc-0.8 --with-libelf=/n/10/davek/usr --enable-bootstrap
".
..}
(gdb) p plugin_version[0]
$6 = {basever = 0x77567d29 "4.6.0",
datestamp = 0x77567d2f "20101105",
devphase = 0x77567d38 "experimental", revision = 0x77567e28 "",
configuration_arguments = 0x77566720 "/n/10/davek/gcc/gcc/configure
--pref
ix=/n/10/davek/gcc --with-mpfr=/opt/cfarm/mpfr-2.4.1
--with-gmp=/opt/cfarm/gmp-4
.2.4 --with-mpc=/opt/cfarm/mpc-0.8 --with-libelf=/n/10/davek/usr
--enable-bootst
rap "...}
(gdb)
This will happen if $objdir/gcc/plugin-version.h or $objdir/gcc/configargs.h
has been regenerated for any reason in between building the compiler and
running the test. Can you tell if this may have happened in your case?
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 --- Comment #7 from Dave Korn 2010-11-05 23:33:29 UTC --- (In reply to comment #4) > Everything seems wrong. Yes, you aren't exaggerating! I am continuing to try and figure out what's going wrong.
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 --- Comment #8 from Dave Korn 2010-11-08 04:52:12 UTC --- The generated source file selfassign.so.ltrans0.s (and hence also the object file selfassign.so.ltrans0.ltrans.o) file which gets created when lto-plugin invokes lto1 on the original input selfassign.o file has no contents. This appears to be because plugin_init in selfassign.c isn't marked with __attribute__((externally_visible)), and the resolution file marks it as PREVAILING_DEF_IRONLY. WPA then concludes that everything can be made static, nothing is referenced, and discards the lot. The consequence of this is that the object file that the pluging then adds back into the link has no contents, so it doesn't override the symbol definitions supplied from the IR when it first claimed the input selfassign.o file. It works with GOLD because GOLD thinks the plugin's external symbols are PREVAILING_DEF, not PREVAILING_DEF_IRONLY. This is the resolution file that the lto-plugin writes based on what LD tells it at all_symbols_read time: 1 selfassign.o 27 5072 e2eb6ce9 PREVAILING_DEF_IRONLY plugin_init 5105 e2eb6ce9 UNDEF tree_check_failed 5114 e2eb6ce9 UNDEF tree_class_check_failed 5148 e2eb6ce9 UNDEF fancy_abort 5155 e2eb6ce9 UNDEF gimple_check_failed 5165 e2eb6ce9 UNDEF gimple_assign_single_p 5169 e2eb6ce9 UNDEF tree_contains_struct_check_failed 5253 e2eb6ce9 UNDEF build4_stat 5262 e2eb6ce9 UNDEF tree_operand_check_failed 5271 e2eb6ce9 UNDEF fold_build2_stat_loc 5279 e2eb6ce9 UNDEF build3_stat 5287 e2eb6ce9 UNDEF warning_at 5302 e2eb6ce9 UNDEF operand_equal_p 5308 e2eb6ce9 UNDEF maybe_get_identifier 5312 e2eb6ce9 UNDEF integer_zerop 5314 e2eb6ce9 UNDEF register_callback 5324 e2eb6ce9 UNDEF warning 5351 e2eb6ce9 UNDEF plugin_default_version_check 5494 e2eb6ce9 PREVAILING_DEF_IRONLY check_operator_eq 5536 e2eb6ce9 PREVAILING_DEF_IRONLY plugin_is_GPL_compatible 5433 e2eb6ce9 UNDEF tree_code_type 5442 e2eb6ce9 UNDEF tree_code_length 5452 e2eb6ce9 UNDEF gss_for_code_ 5457 e2eb6ce9 UNDEF gimple_ops_offset_ 5471 e2eb6ce9 UNDEF tree_contains_struct 5486 e2eb6ce9 UNDEF input_location 5502 e2eb6ce9 UNDEF cfun ... and here is the one generated when the plugin is loaded into GOLD: 1 selfassign.o 27 5072 e2eb6ce9 PREVAILING_DEF plugin_init 5105 e2eb6ce9 UNDEF tree_check_failed 5114 e2eb6ce9 UNDEF tree_class_check_failed 5148 e2eb6ce9 UNDEF fancy_abort 5155 e2eb6ce9 UNDEF gimple_check_failed 5165 e2eb6ce9 UNDEF gimple_assign_single_p 5169 e2eb6ce9 UNDEF tree_contains_struct_check_failed 5253 e2eb6ce9 UNDEF build4_stat 5262 e2eb6ce9 UNDEF tree_operand_check_failed 5271 e2eb6ce9 UNDEF fold_build2_stat_loc 5279 e2eb6ce9 UNDEF build3_stat 5287 e2eb6ce9 UNDEF warning_at 5302 e2eb6ce9 UNDEF operand_equal_p 5308 e2eb6ce9 UNDEF maybe_get_identifier 5312 e2eb6ce9 UNDEF integer_zerop 5314 e2eb6ce9 UNDEF register_callback 5324 e2eb6ce9 UNDEF warning 5351 e2eb6ce9 UNDEF plugin_default_version_check 5494 e2eb6ce9 PREVAILING_DEF check_operator_eq 5536 e2eb6ce9 PREVAILING_DEF plugin_is_GPL_compatible 5433 e2eb6ce9 UNDEF tree_code_type 5442 e2eb6ce9 UNDEF tree_code_length 5452 e2eb6ce9 UNDEF gss_for_code_ 5457 e2eb6ce9 UNDEF gimple_ops_offset_ 5471 e2eb6ce9 UNDEF tree_contains_struct 5486 e2eb6ce9 UNDEF input_location 5502 e2eb6ce9 UNDEF cfun
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 --- Comment #9 from Dave Korn 2010-11-08 06:27:25 UTC --- (In reply to comment #8) > This appears to be because plugin_init in selfassign.c isn't marked with > __attribute__((externally_visible)), and the resolution file marks it as > PREVAILING_DEF_IRONLY. > It works with GOLD because GOLD thinks the plugin's external symbols are > PREVAILING_DEF, not PREVAILING_DEF_IRONLY. Thanks to Ian T, I now have an understanding of why GOLD does this: it is because if the ELF symbol visibility is STV_DEFAULT or STV_PROTECTED, GOLD assumes it may be externally referenced, perhaps dynamically at runtime, so doesn't resolve it _IRONLY. I'll need to adjust GNU LD to match this behaviour. (Can't work around it just by tagging __attribute__((externally_visible)) onto the definition of plugin_init in selfassign.c, because cc1 has been lto-bootstrapped, and all the symbols that the plugin wants to reference have been made static for the same reason - they are seen as IRONLY - so the plugin can't resolve them and dlopen'ing it fails.)
[Bug lto/46319] LTO plugin test failures with --with-build-config=bootstrap-lto --with-plugin-ld=ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46319 Dave Korn changed: What|Removed |Added Keywords||patch URL||http://sourceware.org/ml/bi ||nutils/2010-11/msg00170.htm ||l --- Comment #10 from Dave Korn 2010-11-09 19:32:13 UTC --- Binutils with the posted patch passes LTO-bootstrap using LD as the linker plugin and resolves the failing tests.
[Bug target/28627] [cygwin/mingw32] Missing dllimport diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28627 --- Comment #3 from Dave Korn 2010-11-09 19:50:53 UTC --- (In reply to comment #2) > As we want to keep here errors instead of warnings and the cgraph pass is > modeled that way that the diagnostic of second error isn't possible, I decided > to adjust testcase as fix. I close this bug. Thankyou. I agree that we'll just have to live with the missing error for now.
[Bug bootstrap/46397] lto-plugin.c does not build on Solaris 10/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46397 Dave Korn changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.09 20:21:04 Ever Confirmed|0 |1
[Bug bootstrap/46362] [4.6 regression] lto-plugin.c doesn't compile on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46362 Dave Korn changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.09 20:21:15 CC||davek at gcc dot gnu.org AssignedTo|unassigned at gcc dot |davek at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug bootstrap/46397] lto-plugin.c does not build on Solaris 10/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46397 --- Comment #4 from Dave Korn 2010-11-09 21:00:57 UTC --- Created attachment 22355 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22355 first spin of trial patch How about if we make building the plugin conditional on having c99 available? I'm testing this at the moment on cygwin, and will test it later on linux; Sean, could you give it a try on SPARC and check that it successfully disables building the plugin? (Don't forget to regenerate the two configure files, I omitted that diff from the patch. If you'd prefer, I could send a version with the full diff; just ask if so.)
[Bug bootstrap/46362] [4.6 regression] lto-plugin.c doesn't compile on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46362 --- Comment #4 from Dave Korn 2010-11-09 21:00:47 UTC --- Created attachment 22354 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22354 proposed patch ISTM the main issue (common to this and Bug 46397) is C99, so this patch adds a test for its availability at top-level that disables lto-plugin if C99 can't be used (but doesn't make the compiler actually use C99 mode in general), and makes the lto-plugin itself use C99 mode to compile. It also adds stdbool support as shown in the autoconf man page. Rainer, could you give it a whirl?
[Bug bootstrap/46397] lto-plugin.c does not build on Solaris 10/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46397 --- Comment #5 from Dave Korn 2010-11-09 21:03:50 UTC --- > (Don't forget to regenerate the two configure files, And run autoheader in lto-plugin, I should have added there.
[Bug bootstrap/46362] [4.6 regression] lto-plugin.c doesn't compile on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46362 --- Comment #5 from Dave Korn 2010-11-09 21:04:29 UTC --- BTW note that this needs a run of autoheader in the lto-plugin dir, as well as autoconf there and at top-level.
[Bug bootstrap/46397] lto-plugin.c does not build on Solaris 10/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46397 --- Comment #7 from Dave Korn 2010-11-09 21:21:07 UTC --- (In reply to comment #6) > > How about if we make building the plugin conditional on having c99 > > available? > > That wouldn't be consistent with us currently requiring only a C90 compiler to > build GCC. Can't the code be rewritten in C90 instead? I would expect so, but haven't audited the code. Of course, we *have* a c99 compiler available after stage 1; is there a way to disable lto-plugin just during stage1/non-bootstrap builds?
[Bug bootstrap/46397] lto-plugin.c does not build on Solaris 10/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46397 --- Comment #9 from Dave Korn 2010-11-09 21:35:09 UTC --- (In reply to comment #6) > > How about if we make building the plugin conditional on having c99 > > available? > > That wouldn't be consistent with us currently requiring only a C90 compiler to > build GCC. Can't the code be rewritten in C90 instead? The prerequisites page does say: " ISO C90 compiler Necessary to bootstrap GCC, although versions of GCC prior to 3.4 also allow bootstrapping with a traditional (K&R) C compiler. To build all languages in a cross-compiler or other configuration where 3-stage bootstrap is not performed, you need to start with an existing GCC binary (version 2.95 or later) because source code for language frontends other than C might use GCC extensions. " We could just say that lto-plugin comes under the same rule as the non-C FEs. However I'll look at porting it. I guess we can break up the 64-bit hex printf into two 32-bit ones.
[Bug bootstrap/46362] [4.6 regression] lto-plugin.c doesn't compile on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46362 --- Comment #7 from Dave Korn 2010-11-09 21:54:31 UTC --- (In reply to comment #6) > The LTO plugin is a fairly small piece of code; how hard would it be to > eliminate any C99 dependencies? Just looking at that now in response to Eric's comments on the other related bug 46397.
[Bug bootstrap/46362] [4.6 regression] lto-plugin.c doesn't compile on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46362 Dave Korn changed: What|Removed |Added Attachment #22354|0 |1 is obsolete|| --- Comment #8 from Dave Korn 2010-11-09 22:03:27 UTC --- Created attachment 22358 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22358 remove c90 usage from lto plugin How about this? Compiles OK on i686-pc-cygwin with -std=c89 added to the cflags.
[Bug bootstrap/46397] lto-plugin.c does not build on Solaris 10/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46397 Dave Korn changed: What|Removed |Added Attachment #22355|0 |1 is obsolete|| --- Comment #10 from Dave Korn 2010-11-09 22:03:25 UTC --- Created attachment 22357 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22357 remove c90 usage from lto plugin Tested this by rebuilding lto-plugin.lo with -std=c89 in the cflags.
