[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 davek at gcc dot gnu.org 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 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] function_decl 0x7fdf9c00 bar))
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 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 davek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX --- Comment #3 from Dave Korn davek at gcc dot gnu.org 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 cygwin/process.h, not process.h 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 other/39933] make clean fails in libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39933 Dave Korn davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org changed: What|Removed |Added CC||ich at az2000 dot de --- Comment #4 from Dave Korn davek at gcc dot gnu.org 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 davek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||davek at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Dave Korn davek at gcc dot gnu.org 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 davek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||davek at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Dave Korn davek at gcc dot gnu.org 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 davek at gcc dot gnu.org changed: What|Removed |Added CC||phantall at gmail dot com --- Comment #5 from Dave Korn davek at gcc dot gnu.org 2011-12-08 12:10:35 UTC --- *** Bug 45994 has been marked as a duplicate of this bug. ***
[Bug bootstrap/38388] parallel install failures in install-{libiberty,gnatlib}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38388 Dave Korn davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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 prefix=/gnu/usr exeext=.exeext.should.not.be.used 'CC=the.host.compiler.should.not.be.needed' GCC_FOR_TARGET=/gnu/gcc/obj3/./gcc/xgcc -B/gnu/gcc/obj3/./gcc/ -B/gnu/usr/i686-pc-cygwin/bin/ -B/gnu/usr/i686-pc-cygwin/lib/ -isystem /gnu/usr/i686-pc-cygwin/include -isystem /gnu/usr/i686-pc-cygwin/sys-include CFLAGS=-g -O2 install-gnatlib make[3]: Entering directory `/gnu/gcc/obj3/gcc/ada' mkdir -p /gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adalib mkdir -p /gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude rm -rf /gnu/gcc
[Bug ada/864] --program-suffix is ignored (for ada)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #20 from Dave Korn davek at gcc dot gnu.org 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 -- target-gnatmake and Nam is gcc, the returned value will be a pointer -- to target-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 davek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||davek at gcc dot gnu.org Resolution||DUPLICATE --- Comment #3 from Dave Korn davek at gcc dot gnu.org 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 davek at gcc dot gnu.org changed: What|Removed |Added CC||mark at grondar dot org --- Comment #21 from Dave Korn davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 2011-12-07 00:46:18 UTC --- we may as well resume the discussion here there, not here, sorry for any confusion.
[Bug libstdc++/51135] [4.7 Regression] SIGSEGV during exception cleanup on win32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51135 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added CC||davek at gcc dot gnu.org --- Comment #2 from Dave Korn davek at gcc dot gnu.org 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 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 davek at gcc dot gnu.org 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 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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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 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 davek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Dave Korn davek at gcc dot gnu.org 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 davek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #8 from Dave Korn davek at gcc dot gnu.org 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 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 davek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||davek at gcc dot gnu.org Resolution||INVALID --- Comment #4 from Dave Korn davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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 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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||davek at gcc dot gnu.org Resolution||DUPLICATE --- Comment #12 from Dave Korn davek at gcc dot gnu.org 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: .stringzFinside_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/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 davek at gcc dot gnu.org changed: What|Removed |Added CC||davek at gcc dot gnu.org --- Comment #22 from Dave Korn davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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 .stringzabs .stringz .stringz .stringz .stringz .stringz .stringz
[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 davek at gcc dot gnu.org 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/46652] undefined reference to '__udivdi3' with -flto -fuse-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46652 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added CC||davek at gcc dot gnu.org --- Comment #7 from Dave Korn davek at gcc dot gnu.org 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 c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #52 from Dave Korn davek at gcc dot gnu.org 2011-01-26 01:50:14 UTC --- Committed rev.169268. http://gcc.gnu.org/viewcvs?view=revisionrevision=169268 (Then added the missing PR refs to the changelogss in the next rev: http://gcc.gnu.org/viewcvs?view=revisionrevision=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 davek at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||FIXED
Target Milestone|--- |4.6.0
--- Comment #8 from Dave Korn davek at gcc dot gnu.org 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=gccview=revrev=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 davek at gcc dot gnu.org 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=gccview=revrev=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 davek at gcc dot gnu.org 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
[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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 2011-01-26 04:50:09 UTC --- HJ, you offered to take a look at what's causing this problem. Any ideas?
[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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 2011-01-21 04:17:24 UTC --- Patch submitted.
[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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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=gccview=revrev=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 davek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Dave Korn davek at gcc dot gnu.org 2011-01-10 00:53:45 UTC --- Done.
[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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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=revisionrevision=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 davek at gcc dot gnu.org 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=revisionrevision=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 davek at gcc dot gnu.org 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 davek at gcc dot gnu.org 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++/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 21 --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 davek at gcc dot gnu.org changed: What|Removed |Added CC||davek at gcc dot gnu.org --- Comment #4 from Dave Korn davek at gcc dot gnu.org 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 davek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.07 21:05:02 Ever Confirmed|0 |1 --- Comment #1 from Dave Korn davek at gcc dot gnu.org 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 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 davek at gcc dot gnu.org 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=gccview=revrev=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 davek at gcc dot gnu.org 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=gccview=revrev=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 davek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Dave Korn davek at gcc dot gnu.org 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 davek at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #28 from Dave Korn davek at gcc dot gnu.org 2010-12-19 11:18:37 UTC --- Problems (PR46674) with this fix now resolved.
[Bug testsuite/46938] FAIL: gcc.dg/pr43157.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46938 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-12/msg00917.htm ||l Keywords||patch Last reconfirmed||2010.12.15 09:29:22 AssignedTo|unassigned at gcc dot |davek at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Dave Korn davek at gcc dot gnu.org 2010-12-15 09:29:22 UTC --- Patch got approved while I was out of town for a couple of days, will commit it shortly.
[Bug testsuite/46938] FAIL: gcc.dg/pr43157.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46938 --- Comment #2 from Dave Korn davek at gcc dot gnu.org 2010-12-15 09:51:30 UTC --- Author: davek Date: Wed Dec 15 09:51:26 2010 New Revision: 167848 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167848 Log: PR testsuite/46938 * gcc.dg/pr43157.c: Add dg-require-linker-plugin directive. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr43157.c
[Bug testsuite/46938] FAIL: gcc.dg/pr43157.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46938 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Dave Korn davek at gcc dot gnu.org 2010-12-15 09:53:13 UTC --- Should be fixed now.
[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 davek at gcc dot gnu.org changed: What|Removed |Added Target|powerpc-linux, i?86-linux, |powerpc-linux, i?86-linux, |alpha-linux |alpha-linux, i?86-pc-cygwin Status|RESOLVED|REOPENED CC||davek at gcc dot gnu.org Depends on||46674 Resolution|FIXED | AssignedTo|rguenth at gcc dot gnu.org |davek at gcc dot gnu.org --- Comment #26 from Dave Korn davek at gcc dot gnu.org 2010-12-15 16:28:12 UTC --- (In reply to comment #25) *** Bug 46674 has been marked as a duplicate of this bug. *** Actually, it's a genuine bug in the patch; it ends up comparing C identifiers to actual assembler names, which works fine when there's no USER_LABEL_PREFIX and when none of the nodes in question have __asm(..) names, but runs into problems if/when there is/they do. See attachment 22765 for the patch to resolve all this by always using assembler names. Bootstraps and testruns are under way.
[Bug middle-end/46674] [4.6 Regression] Weak alias is mistakenly optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674 --- Comment #11 from Dave Korn davek at gcc dot gnu.org 2010-12-15 16:17:54 UTC --- Created attachment 22765 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22765 Lower all C identifiers to actual assembler symbols for comparison. This should resolve the problem by ensuring that aliases and decls are lowered to the canonical assembler form before doing any comparisons or testing if they are used.
[Bug tree-optimization/29710] gnat ICEs on -fprefetch-loop-arrays -O1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29710
Dave Korn davek at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed|2006-11-10 19:32:46 |2010-12-11 19:32:46
CC||davek at gcc dot gnu.org
Version|4.2.0 |4.6.0
Known to fail||4.6.0
--- Comment #6 from Dave Korn davek at gcc dot gnu.org 2010-12-11 10:17:11
UTC ---
I've run into what appears to be the same problem with 4.6.0 HEAD in java:
http://gcc.gnu.org/ml/gcc/2010-12/msg00308.html
http://gcc.gnu.org/ml/gcc/2010-12/msg00315.html
FAIL: newarray_overflow -O3 compilation from source
FAIL: newarray_overflow -O3 -findirect-dispatch compilation from source
The problem showed up as a crash during gimple stmt verification. Turning on
tree dumps moved the crash earlier, to a point where it was trying to dump a
call to builtin_prefetch during the 118t.aprefetch pass. The GIMPLE context in
that file, after working around the dump problem, shows:
;; Function newarray_overflow.int_check()
(_ZN17newarray_overflow9int_checkEJvv)
[ . . . ]
bb 13:
D.1283_116 = MEM[(int *)#ref#2#2_6].data[#slot#3#12.29_44]{lb: 0 sz: 4};
D.1284_85 = D.1283_116 + 1275068416;
newarray_overflow.int_check.__builtin_prefetch (D.1284_85, 0, );
#slot#2#0_53 = MEM[(int *)#ref#2#2_6].data[#slot#3#12.29_44]{lb: 0 sz: 4};
goto bb 15;
Judging by the way all the RTL dump files (and the generated assembler
source) leave off immediately before this function, it's some kind of invalid
GIMPLE problem. The verification failure occurred here:
(gdb) bt
#0 walk_gimple_op (stmt=0x7fe106e0,
callback_op=0x4a0ef0 verify_expr.265801, wi=0x326c554)
at /gnu/gcc/gcc/gcc/gimple.c:1342
#1 0x0054a0fd in verify_stmts () at /gnu/gcc/gcc/gcc/tree-cfg.c:4156
#2 0x0054a94a in verify_ssa (check_modified_stmt=1 '\001')
at /gnu/gcc/gcc/gcc/tree-ssa.c:878
#3 0x008cc671 in execute_function_todo.56548 (data=0x1)
at /gnu/gcc/gcc/gcc/passes.c:1237
#4 0x00776449 in do_per_function (
callback=0x8cc530 execute_function_todo.56548, data=0x1)
at /gnu/gcc/gcc/gcc/passes.c:1084
#5 0x00540e90 in execute_todo (flags=1) at /gnu/gcc/gcc/gcc/passes.c:1268
#6 0x00541140 in execute_one_pass (pass=0xaf1320)
at /gnu/gcc/gcc/gcc/passes.c:1576
... verifying a gimple call statement:
(gdb) p stmt[0].gimple_call
$8 = {membase = {opbase = {gsbase = {code = TS_IDENTIFIER, no_warning = 0,
visited = 0, nontemporal_move = 0, plf = 0, modified = 0,
has_volatile_ops = 0, pad = 0, subcode = 0, uid = 0, location = 0,
num_ops = 6, bb = 0x7fda3210, block = 0x0}, def_ops = 0x0,
use_ops = 0x7fed6f30}, vdef = 0x0, vuse = 0x0}, call_used = {
anything = 1, nonlocal = 0, escaped = 0, ipa_escaped = 0, null = 0,
vars_contains_global = 0, vars_contains_restrict = 0, vars = 0x0},
call_clobbered = {anything = 0, nonlocal = 0, escaped = 0, ipa_escaped = 0,
null = 0, vars_contains_global = 0, vars_contains_restrict = 0,
vars = 0x0}, op = {0x0}}
By forcing the num_ops down to 5, I managed to defer the crash until
expand_builtin_prefetch:
Program received signal SIGSEGV, Segmentation fault.
expand_builtin_prefetch (exp=value optimized out)
at /gnu/gcc/gcc/gcc/builtins.c:1131
1131 if (TREE_CODE (arg2) != INTEGER_CST)
So that made me suspect the third argument to the call was invalid, and
breakpointing on gimple_build_call showed the problem:
(gdb) bt
#0 gimple_build_call (fn=0x7ff8f580, nargs=3) at /gnu/gcc/gcc/gcc/gimple.c:261
#1 0x008c310d in tree_ssa_loop_prefetch () at
/gnu/gcc/gcc/gcc/tree-ssa-loop-pr
efetch.c:1121
(gdb) x/8xw $esp
0x326c5fc: 0x008c310d 0x7ff8f580 0x0003 0x7feb8280
0x326c60c: 0x7fef03d8 0x 0x 0x0008
fn and nargs can be seen in the middle of the first row there, and the next
three words should be the arguments to the gimple call, but you can see the
third one is null. That comes from this line in issue_prefetch_ref() in
tree-ssa-loop-prefetch.c:
prefetch = gimple_build_call (built_in_decls[BUILT_IN_PREFETCH],
3, addr, write_p, local);
and the variable local is set like so:
local = nontemporal ? integer_zero_node : integer_three_node;
Sure enough, on investigating the integer_xxx_nodes,
TI_INTEGER_ZERO, // = 13
TI_INTEGER_ONE, // = 14
TI_INTEGER_THREE, // = 15
TI_INTEGER_MINUS_ONE, // = 16
(gdb) p global_trees[13]
$20 = (union tree_node *) 0x7fef03d8
(gdb) p global_trees[14]
$21 = (union tree_node *) 0x7fef03f0
(gdb) p global_trees[15]
$22 = (union tree_node *) 0x0
(gdb) p global_trees[16]
$23 = (union tree_node *) 0x7fef0438
... it appears that integer_three_node has not been initialised. Looks to me
like that might be something
[Bug tree-optimization/29710] gnat ICEs on -fprefetch-loop-arrays -O1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29710 --- Comment #7 from Dave Korn davek at gcc dot gnu.org 2010-12-11 10:46:22 UTC --- (In reply to comment #6) Although I haven't verified that this is the same as the original problem report, it really looks like it, modulo various changes to the compiler's internals since 4.2; in particular, (In reply to comment #4) (gdb) p current_stmt_group $6 = (struct stmt_group *) 0x0 ... that looks like that null third argument causing problems to me. Ah, but there was no integer_three_node back then and builtin_expect only used to take two args at the time. So it can't be the same thing after all.
[Bug c++/45201] ICE: stack overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45201 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added CC||davek at gcc dot gnu.org --- Comment #10 from Dave Korn davek at gcc dot gnu.org 2010-12-11 16:08:37 UTC --- Should be fixed for 4.6.0: compiler stack size was increased to 12MB by: http://gcc.gnu.org/viewcvs?view=revisionrevision=167400
[Bug middle-end/46674] [4.6 Regression] Weak alias is mistakenly optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46674 --- Comment #10 from Dave Korn davek at gcc dot gnu.org 2010-12-10 14:29:03 UTC --- Author: davek Date: Fri Dec 10 14:28:58 2010 New Revision: 167688 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167688 Log: gcc/ChangeLog: PR middle-end/46674 PR lto/43157 * target.def (mangle_assembler_name): New target asm_out hook. * targhooks.c (default_mangle_assembler_name): Add default hook implementation. * targhooks.h (default_mangle_assembler_name): Add prototype. * lto-symtab.c (lto_symtab_register_decl): Use new hook when processing DECL_ASSEMBLER_NAMEs for lto symtabs. (lto_symtab_get_resolution): Likewise. (lto_cgraph_replace_node): Likewise. (lto_symtab_prevailing_decl): Likewise. * lto-streamer-out.c (write_symbol): Likewise. * doc/tm.texi.in (TARGET_MANGLE_ASSEMBLER_NAME): Add @hook directive. * doc/tm.texi: Regenerate. * config/i386/cygming.h (TARGET_MANGLE_ASSEMBLER_NAME): Define to point at i386_pe_mangle_assembler_name. * config/i386/winnt.c (i386_pe_mangle_assembler_name): New function. * config/i386/i386-protos.h (i386_pe_mangle_assembler_name): Add prototype. lto-plugin/ChangeLog: PR middle-end/46674 PR lto/43157 * configure.ac (SYM_STYLE): Don't AC_DEFINE. * lto-plugin.c (sym_style): Don't use it; default to ss_none. * configure: Regenerate. * config.h.in: Likewise. gcc/testsuite/ChangeLog: PR middle-end/46674 PR lto/43157 * gcc.dg/pr43157.c: New file. Added: trunk/gcc/testsuite/gcc.dg/pr43157.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cygming.h trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/winnt.c trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/lto-streamer-out.c trunk/gcc/lto-symtab.c trunk/gcc/target.def trunk/gcc/targhooks.c trunk/gcc/targhooks.h trunk/gcc/testsuite/ChangeLog trunk/lto-plugin/ChangeLog trunk/lto-plugin/config.h.in trunk/lto-plugin/configure trunk/lto-plugin/configure.ac trunk/lto-plugin/lto-plugin.c
[Bug lto/43157] Segmentation fault in aggregate_value_p, asm aliases do not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43157 --- Comment #8 from Dave Korn davek at gcc dot gnu.org 2010-12-10 14:29:03 UTC --- Author: davek Date: Fri Dec 10 14:28:58 2010 New Revision: 167688 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167688 Log: gcc/ChangeLog: PR middle-end/46674 PR lto/43157 * target.def (mangle_assembler_name): New target asm_out hook. * targhooks.c (default_mangle_assembler_name): Add default hook implementation. * targhooks.h (default_mangle_assembler_name): Add prototype. * lto-symtab.c (lto_symtab_register_decl): Use new hook when processing DECL_ASSEMBLER_NAMEs for lto symtabs. (lto_symtab_get_resolution): Likewise. (lto_cgraph_replace_node): Likewise. (lto_symtab_prevailing_decl): Likewise. * lto-streamer-out.c (write_symbol): Likewise. * doc/tm.texi.in (TARGET_MANGLE_ASSEMBLER_NAME): Add @hook directive. * doc/tm.texi: Regenerate. * config/i386/cygming.h (TARGET_MANGLE_ASSEMBLER_NAME): Define to point at i386_pe_mangle_assembler_name. * config/i386/winnt.c (i386_pe_mangle_assembler_name): New function. * config/i386/i386-protos.h (i386_pe_mangle_assembler_name): Add prototype. lto-plugin/ChangeLog: PR middle-end/46674 PR lto/43157 * configure.ac (SYM_STYLE): Don't AC_DEFINE. * lto-plugin.c (sym_style): Don't use it; default to ss_none. * configure: Regenerate. * config.h.in: Likewise. gcc/testsuite/ChangeLog: PR middle-end/46674 PR lto/43157 * gcc.dg/pr43157.c: New file. Added: trunk/gcc/testsuite/gcc.dg/pr43157.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cygming.h trunk/gcc/config/i386/i386-protos.h trunk/gcc/config/i386/winnt.c trunk/gcc/doc/tm.texi trunk/gcc/doc/tm.texi.in trunk/gcc/lto-streamer-out.c trunk/gcc/lto-symtab.c trunk/gcc/target.def trunk/gcc/targhooks.c trunk/gcc/targhooks.h trunk/gcc/testsuite/ChangeLog trunk/lto-plugin/ChangeLog trunk/lto-plugin/config.h.in trunk/lto-plugin/configure trunk/lto-plugin/configure.ac trunk/lto-plugin/lto-plugin.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 davek at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|ASSIGNED AssignedTo|unassigned at gcc dot |davek at gcc dot gnu.org |gnu.org |
[Bug debug/46123] [4.5/4.6 Regression] ICE: in output_aranges, at dwarf2out.c:11531 with -feliminate-dwarf2-dups -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46123 --- Comment #13 from Dave Korn davek at gcc dot gnu.org 2010-12-11 04:34:07 UTC --- Didn't crop up in my latest testrun (based on r.167484 / 20101206), so whatever it was seems to have gone away.
[Bug c/46859] Attribute depends on location
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46859
Dave Korn davek at gcc dot gnu.org changed:
What|Removed |Added
CC||davek at gcc dot gnu.org
--- Comment #2 from Dave Korn davek at gcc dot gnu.org 2010-12-09 20:31:25
UTC ---
I note that if you re-write foo2 like this:
int
__attribute__((aligned(4096)))
*
foo2a ()
{
return 0;
}
it gets aligned properly. I think something must be going wrong when the
parser starts to build a derived pointer type based on the underlying scalar
type, but that's just a first guess.
[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 davek at gcc dot gnu.org changed:
What|Removed |Added
CC||davek at gcc dot gnu.org
--- Comment #7 from Dave Korn davek at gcc dot gnu.org 2010-12-10 06:57:54
UTC ---
I can't reproduce any segfault, but this slightly-modified version of the
testcase fails on i686-pc-cygwin, which is a target where __USER_LABEL_PREFIX
is an underscore:
ad...@ubik /gnu/gcc/obj-lto/gcc
$ cat pr43157.c
/* { dg-do link } */
/* { dg-require-effective-target lto } */
/* { dg-options -O1 -flto -fuse-linker-plugin } */
#define LABEL3(pfx, x) # pfx x
#define LABEL2(pfx, x) LABEL3(pfx, x)
#define LABEL(x) LABEL2(__USER_LABEL_PREFIX__, x)
unsigned int factorial_ (unsigned int) __asm__ (LABEL (factorial));
unsigned int factorial (unsigned int i)
{
return i 1 ? i * factorial_ (i - 1) : 1;
}
int main (void)
{
return factorial (5);
}
ad...@ubik /gnu/gcc/obj-lto/gcc
$ ./xgcc.exe -B. -O1 -flto -fuse-linker-plugin pr43157.c -o pr43157.exe
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccroMaGc.ltrans0.ltrans.o:ccroMaGc.ltrans
0.o:(.text.startup+0x16): undefined reference to `_factorial'
collect2: ld returned 1 exit status
Looking at the lto symtab in the generated .o file:
ad...@ubik /gnu/gcc/obj-lto/gcc
$ nm --plugin /gnu/gcc/obj-asm-mangle/gcc/cyglto_plugin-0.dll pr43157.o
U _factorial
T factorial
T main
... you can see it's gotten confused about c-level vs. asm-level symbols, this
reflects in the generated resolution file:
ad...@ubik /gnu/gcc/obj-lto/gcc
$ ./xgcc.exe -B. -O1 -flto -fuse-linker-plugin pr43157.c -o pr43157.exe --save-
temps
[Leaving LTRANS /win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccU0cpRH.args]
[Leaving LTRANS pr43157.exe.ltrans.out]
[Leaving LTRANS /win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccGUCoPM.args]
[Leaving LTRANS pr43157.exe.ltrans0.o]
pr43157.exe.ltrans0.ltrans.o:pr43157.exe.ltrans0.o:(.text.startup+0x16):
undefin
ed reference to `_factorial'
collect2: ld returned 1 exit status
ad...@ubik /gnu/gcc/obj-lto/gcc
$ cat pr43157.res
1
pr43157.o 3
75 d804d237 PREVAILING_DEF_IRONLY _factorial
84 d804d237 PREVAILING_DEF _main
87 d804d237 UNDEF __factorial
With my patch for asm name mangling in lto symtabs, it works fine. The
generated lto symtab contains asm-level symbols only:
ad...@ubik /gnu/gcc/obj-asm-mangle/gcc
$ ./xgcc.exe -B. -O1 -flto -fuse-linker-plugin -c pr43157.c -o pr43157.o
ad...@ubik /gnu/gcc/obj-asm-mangle/gcc
$ nm --plugin /gnu/gcc/obj-asm-mangle/gcc/cyglto_plugin-0.dll pr43157.o
T _factorial
T _main
ad...@ubik /gnu/gcc/obj-asm-mangle/gcc
$ ./xgcc.exe -B. -O1 -flto -fuse-linker-plugin pr43157.c -o pr43157.exe --save-
temps
[Leaving LTRANS /win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccBfa3cb.args]
[Leaving LTRANS pr43157.exe.ltrans.out]
[Leaving LTRANS /win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccmkGBnN.args]
[Leaving LTRANS pr43157.exe.ltrans0.o]
ad...@ubik /gnu/gcc/obj-asm-mangle/gcc
$ cat pr43157.res
1
pr43157.o 2
75 f3900364 PREVAILING_DEF_IRONLY _factorial
84 f3900364 PREVAILING_DEF _main
ad...@ubik /gnu/gcc/obj-asm-mangle/gcc
... and so the resolution file comes out correct.
[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 davek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2010.12.08 14:10:43
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 #6 from Dave Korn davek at gcc dot gnu.org 2010-12-08 14:10:43
UTC ---
I stumbled into the underlying cause of this bug while working on
dllimport/dllexport attributes. It turns out that the TARGET_INSERT_ATTRIBUTES
hook is broken in C++, because of a bit of premature optimisation in the
routine gcc/cp/decl2.c#cplus_decl_attributes(). This is a C++-specific wrapper
round the core compiler's gcc/attribs.c#decl_attributes() which takes care of
deferred attribute handling for templates:
/* Like decl_attributes, but handle C++ complexity. */
void
cplus_decl_attributes (tree *decl, tree attributes, int flags)
{
if (*decl == NULL_TREE || *decl == void_type_node
|| *decl == error_mark_node
|| attributes == NULL_TREE)
return;
if (processing_template_decl)
{
if (check_for_bare_parameter_packs (attributes))
return;
save_template_attributes (attributes, decl);
if (attributes == NULL_TREE)
return;
}
if (TREE_CODE (*decl) == TEMPLATE_DECL)
decl = DECL_TEMPLATE_RESULT (*decl);
decl_attributes (decl, attributes, flags);
if (TREE_CODE (*decl) == TYPE_DECL)
SET_IDENTIFIER_TYPE_VALUE (DECL_NAME (*decl), TREE_TYPE (*decl));
}
The early exits when attributes == NULL_TREE are (I suppose) intended to save
the time taken calling decl_attributes when there aren't any attributes to be
added to the newly-created decl, but it has the side-effect of bypassing the
call that decl_attributes makes to TARGET_INSERT_ATTRIBUTES. The consequence
is that the default/target/pragma-derived attributes don't get inserted onto
any decls in C++ - except for decls that have some explicit attributes
specified!
I'm going to be testing this fix as part of a larger patch over the next
couple of days, perhaps others would like to give it a try on their platforms:
Index: gcc/cp/decl2.c
===
--- gcc/cp/decl2.c(revision 167484)
+++ gcc/cp/decl2.c(working copy)
@@ -1269,8 +1269,7 @@ void
cplus_decl_attributes (tree *decl, tree attributes, int flags)
{
if (*decl == NULL_TREE || *decl == void_type_node
- || *decl == error_mark_node
- || attributes == NULL_TREE)
+ || *decl == error_mark_node)
return;
if (processing_template_decl)
@@ -1279,13 +1278,13 @@ cplus_decl_attributes (tree *decl, tree attributes
return;
save_template_attributes (attributes, decl);
- if (attributes == NULL_TREE)
-return;
}
if (TREE_CODE (*decl) == TEMPLATE_DECL)
decl = DECL_TEMPLATE_RESULT (*decl);
+ /* Even if ATTRIBUTES is null, we must call this in order to
+ give the TARGET_INSERT_ATTRIBUTES hook a chance to run. */
decl_attributes (decl, attributes, flags);
if (TREE_CODE (*decl) == TYPE_DECL)
[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 --- Comment #7 from Dave Korn davek at gcc dot gnu.org 2010-12-08 14:19:40 UTC --- (In reply to comment #6) I stumbled into the underlying cause of this bug Should clarify: I'm referring to the broken-ness referred to in comments 1 and 4. My patch probably won't make any difference to the original testcase, because it's to do with declarations, not preprocessor macros.
[Bug c++/40269] ICE during processing class attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40269 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||davek at gcc dot gnu.org Resolution||WORKSFORME --- Comment #1 from Dave Korn davek at gcc dot gnu.org 2010-12-07 23:26:26 UTC --- Couldn't reproduce this on the released 4.5.0 nor on 4.6.0 current trunk, so I assume this was a transient thing that got fixed. Please re-open if you see it again anytime.
[Bug target/45754] Driver core dump when duplicating -Wall command line option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45754 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||davek at gcc dot gnu.org Resolution||FIXED --- Comment #3 from Dave Korn davek at gcc dot gnu.org 2010-12-08 05:57:07 UTC --- (In reply to comment #2) Subject: Re: Driver core dump when duplicating -Wall command line option Unless this can be reproduced with trunk I'd guess it was fixed by: 2010-06-09 Dave Korn dave.korn.cyg...@gmail.com * opts-common.c (prune_options): Ensure replacement argv array is correctly terminated by a NULL entry. Yes, I confirmed that the bug is fixed on head. Martin, it is also fixed in the cygwin gcc-4.5.0-1 test release. BTW, use 'g++', not 'gcc', when compiling C++, or you will run into link errors vs. libstdc!
[Bug middle-end/46671] [4.6 Regression] ICE in default_no_named_section, at varasm .c:5994
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46671 --- Comment #9 from Dave Korn davek at gcc dot gnu.org 2010-12-06 17:27:06 UTC --- (In reply to comment #8) sdbout.c is broken then. Quite likely, but I don't understand what it thinks it's trying to do yet well enough to be sure how. If it doesn't care in which code section it emits the stuff, it should at least not switch_to_section (text_section) if in_section != NULL (in_section-flags SECTION_CODE) != 0. I'll take a look at that possibility, thanks. I'm going to have to read up on the coff debug spec to see what it says about the matter. And in any case, it should remember in_section from the beginning of the function into say saved_section automatic var and if it was non-NULL, do switch_to_section (saved_section) at the end of the function. In fact I don't think that would help, GAS does not accept switching section in the middle of an open CFI directive block (though this is probably an implementation limitation rather than a deliberate design choice; cfi is tracked on a per-frag basis, switching to a new section and back leads to starting a new frag which doesn't have any pointer to the previously-begun cfi block.)
[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED See Also||http://www.sourceware.org/b ||ugzilla/show_bug.cgi?id=122 ||48 Resolution||FIXED --- Comment #40 from Dave Korn davek at gcc dot gnu.org 2010-12-06 17:54:12 UTC --- The implicit -static problem is fixed at the gcc end, and the remaining aspects of this problem will be resolved by HJ's patch to binutils (see 'See also' URL).
[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 davek at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED CC||davek at gcc dot gnu.org Resolution|FIXED | --- Comment #9 from Dave Korn davek at gcc dot gnu.org 2010-12-07 04:31:08 UTC --- Not fixed on platforms where USER_LABEL_PREFIX is non-empty. On i686-pc-cygwin: FAIL: gcc.dg/pr46674.c scan-assembler wobbly Stripping the star isn't enough, because behind that star it's a fully-qualified assembler name, i.e. prefixed if prefixes are in use. The alias names are C level symbols. We can't just compare them; this is the same as the lto symtab problem. We should be able to fix this fully using the mangle_assembler_name hook I'm testing a patch for (http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00403.html).
[Bug target/40125] libgcc_s DLL installed in wrong directory in cross toolchain
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40125 --- Comment #6 from Dave Korn davek at gcc dot gnu.org 2010-12-06 00:50:11 UTC --- Author: davek Date: Mon Dec 6 00:50:04 2010 New Revision: 167480 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167480 Log: config/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * lthostflags.m4: New file. (ACX_LT_HOST_FLAGS): Define. libgfortran/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * configure.ac: Invoke ACX_LT_HOST_FLAGS. * Makefile.am (LTLDFLAGS): Use lt_host_flags. * aclocal.m4: Regenerate. * configure: Regenerate. * Makefile.in: Regenerate. libgomp/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * configure.ac: Invoke ACX_LT_HOST_FLAGS. * Makefile.am (libgomp_la_LDFLAGS): Use lt_host_flags. * aclocal.m4: Regenerate. * configure: Regenerate. * Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. libjava/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * configure.ac: Invoke ACX_LT_HOST_FLAGS. * configure.host (libgcj_sublib_ltflags): Use lt_host_flags. * aclocal.m4: Regenerate. * configure: Regenerate. * Makefile.in: Regenerate. * gcj/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. libobjc/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * configure.ac (extra_ldflags_libobjc): Invoke ACX_LT_HOST_FLAGS. * Makefile.in (lt_host_flags): Import AC_SUBST'd value. * aclocal.m4: Regenerate. * configure: Regenerate. libquadmath/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * configure.ac: Invoke ACX_LT_HOST_FLAGS. * Makefile.am (libquadmath_la_LDFLAGS): Use lt_host_flags. * aclocal.m4: Regenerate. * configure: Regenerate. * Makefile.in: Regenerate. libssp/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * configure.ac: Invoke ACX_LT_HOST_FLAGS. * Makefile.am (libssp_la_LDFLAGS): Use lt_host_flags. * aclocal.m4: Regenerate. * configure: Regenerate. * Makefile.in: Regenerate. libstdc++-v3/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * configure.ac: Invoke ACX_LT_HOST_FLAGS. * configure.host (OPT_LDFLAGS): Use lt_host_flags for cygming. * aclocal.m4: Regenerate. * configure: Regenerate. * Makefile.in: Regenerate. * doc/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * libsupc++/Makefile.in: Regenerate. * po/Makefile.in: Regenerate. * python/Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. lto-plugin/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * configure.ac: Invoke ACX_LT_HOST_FLAGS. * Makefile.am (liblto_plugin_la_LDFLAGS): Use lt_host_flags but override -bindir setting. * aclocal.m4: Regenerate. * configure: Regenerate. * Makefile.in: Regenerate. Added: trunk/config/lthostflags.m4 Modified: trunk/config/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/aclocal.m4 trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgomp/ChangeLog trunk/libgomp/Makefile.am trunk/libgomp/Makefile.in trunk/libgomp/aclocal.m4 trunk/libgomp/configure trunk/libgomp/configure.ac trunk/libgomp/testsuite/Makefile.in trunk/libjava/ChangeLog trunk/libjava/Makefile.in trunk/libjava/aclocal.m4 trunk/libjava/configure trunk/libjava/configure.ac trunk/libjava/configure.host trunk/libjava/gcj/Makefile.in trunk/libjava/include/Makefile.in trunk/libjava/testsuite/Makefile.in trunk/libobjc/ChangeLog trunk/libobjc/Makefile.in trunk/libobjc/aclocal.m4 trunk/libobjc/configure trunk/libobjc/configure.ac trunk/libquadmath/ChangeLog trunk/libquadmath/Makefile.am trunk/libquadmath/Makefile.in trunk/libquadmath/aclocal.m4 trunk/libquadmath/configure trunk/libquadmath/configure.ac trunk/libssp/ChangeLog trunk/libssp/Makefile.am trunk/libssp/Makefile.in trunk/libssp/aclocal.m4 trunk/libssp/configure trunk/libssp/configure.ac trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/Makefile.in trunk/libstdc++-v3/aclocal.m4 trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/configure.host trunk/libstdc++-v3/doc/Makefile.in trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/libsupc++/Makefile.in trunk
[Bug lto/46695] [4.6 regression] failure to build X from darwin to cris-elf with lto enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46695 --- Comment #7 from Dave Korn davek at gcc dot gnu.org 2010-12-06 00:50:11 UTC --- Author: davek Date: Mon Dec 6 00:50:04 2010 New Revision: 167480 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167480 Log: config/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * lthostflags.m4: New file. (ACX_LT_HOST_FLAGS): Define. libgfortran/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * configure.ac: Invoke ACX_LT_HOST_FLAGS. * Makefile.am (LTLDFLAGS): Use lt_host_flags. * aclocal.m4: Regenerate. * configure: Regenerate. * Makefile.in: Regenerate. libgomp/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * configure.ac: Invoke ACX_LT_HOST_FLAGS. * Makefile.am (libgomp_la_LDFLAGS): Use lt_host_flags. * aclocal.m4: Regenerate. * configure: Regenerate. * Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. libjava/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * configure.ac: Invoke ACX_LT_HOST_FLAGS. * configure.host (libgcj_sublib_ltflags): Use lt_host_flags. * aclocal.m4: Regenerate. * configure: Regenerate. * Makefile.in: Regenerate. * gcj/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. libobjc/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * configure.ac (extra_ldflags_libobjc): Invoke ACX_LT_HOST_FLAGS. * Makefile.in (lt_host_flags): Import AC_SUBST'd value. * aclocal.m4: Regenerate. * configure: Regenerate. libquadmath/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * configure.ac: Invoke ACX_LT_HOST_FLAGS. * Makefile.am (libquadmath_la_LDFLAGS): Use lt_host_flags. * aclocal.m4: Regenerate. * configure: Regenerate. * Makefile.in: Regenerate. libssp/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * configure.ac: Invoke ACX_LT_HOST_FLAGS. * Makefile.am (libssp_la_LDFLAGS): Use lt_host_flags. * aclocal.m4: Regenerate. * configure: Regenerate. * Makefile.in: Regenerate. libstdc++-v3/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * configure.ac: Invoke ACX_LT_HOST_FLAGS. * configure.host (OPT_LDFLAGS): Use lt_host_flags for cygming. * aclocal.m4: Regenerate. * configure: Regenerate. * Makefile.in: Regenerate. * doc/Makefile.in: Regenerate. * include/Makefile.in: Regenerate. * libsupc++/Makefile.in: Regenerate. * po/Makefile.in: Regenerate. * python/Makefile.in: Regenerate. * src/Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. lto-plugin/ChangeLog: 2010-12-06 Dave Korn dave.korn.cyg...@gmail.com PR target/40125 PR lto/46695 * configure.ac: Invoke ACX_LT_HOST_FLAGS. * Makefile.am (liblto_plugin_la_LDFLAGS): Use lt_host_flags but override -bindir setting. * aclocal.m4: Regenerate. * configure: Regenerate. * Makefile.in: Regenerate. Added: trunk/config/lthostflags.m4 Modified: trunk/config/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/aclocal.m4 trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgomp/ChangeLog trunk/libgomp/Makefile.am trunk/libgomp/Makefile.in trunk/libgomp/aclocal.m4 trunk/libgomp/configure trunk/libgomp/configure.ac trunk/libgomp/testsuite/Makefile.in trunk/libjava/ChangeLog trunk/libjava/Makefile.in trunk/libjava/aclocal.m4 trunk/libjava/configure trunk/libjava/configure.ac trunk/libjava/configure.host trunk/libjava/gcj/Makefile.in trunk/libjava/include/Makefile.in trunk/libjava/testsuite/Makefile.in trunk/libobjc/ChangeLog trunk/libobjc/Makefile.in trunk/libobjc/aclocal.m4 trunk/libobjc/configure trunk/libobjc/configure.ac trunk/libquadmath/ChangeLog trunk/libquadmath/Makefile.am trunk/libquadmath/Makefile.in trunk/libquadmath/aclocal.m4 trunk/libquadmath/configure trunk/libquadmath/configure.ac trunk/libssp/ChangeLog trunk/libssp/Makefile.am trunk/libssp/Makefile.in trunk/libssp/aclocal.m4 trunk/libssp/configure trunk/libssp/configure.ac trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/Makefile.in trunk/libstdc++-v3/aclocal.m4 trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/configure.host trunk/libstdc++-v3/doc/Makefile.in trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/libsupc++/Makefile.in trunk
[Bug lto/46695] [4.6 regression] failure to build X from darwin to cris-elf with lto enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46695 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Dave Korn davek at gcc dot gnu.org 2010-12-06 00:53:15 UTC --- Haven't verified but should be fixed now that you don't have -no-undefined getting added any more. Please reopen if any problem persists.
[Bug target/40125] libgcc_s DLL installed in wrong directory in cross toolchain
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40125 --- Comment #7 from Dave Korn davek at gcc dot gnu.org 2010-12-06 00:54:23 UTC --- That still leaves libffi and libgcc_s to fix; I'll get to them shortly.
[Bug lto/46695] [4.6 regression] failure to build X from darwin to cris-elf with lto enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46695 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Component|other |lto --- Comment #6 from Dave Korn davek at gcc dot gnu.org 2010-12-04 00:29:15 UTC --- Problems with the plugin are filed under the LTO category, so adjusting. This bug should be resolved by the patch I've posted for Bug 40125.
[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 davek at gcc dot gnu.org changed: What|Removed |Added Attachment #22549|0 |1 is obsolete|| Keywords||patch URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-12/msg00132.htm ||l --- Comment #5 from Dave Korn davek at gcc dot gnu.org 2010-11-28 05:40:58 UTC --- Created attachment 22552 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22552 revised patch last one had a couple of quoting glitches in it. fixed in this spin. don't forget to regenerate everything. aclocal requires the args -I ../config -I . -I .. in every directory except libjava where it requires -I . -I .. -I ../config -I libltdl. autoconf required in each of the top-level subdirs touched, automake in all but libobjc.
[Bug middle-end/46671] [4.6 Regression] ICE in default_no_named_section, at varasm .c:5994
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46671
Dave Korn davek at gcc dot gnu.org changed:
What|Removed |Added
CC||davek at gcc dot gnu.org
--- Comment #7 from Dave Korn davek at gcc dot gnu.org 2010-12-04 05:36:36
UTC ---
I think this may also have caused
FAIL: g++.dg/debug/debug9.C (test for excess errors)
on i686-pc-cygwin. I get all sorts of assembler complaints:
/gnu/gcc/obj-pr40125/gcc/testsuite/g++/../../g++
-B/gnu/gcc/obj-pr40125/gcc/testsuite/g++/../../ -nostdinc++
-I/gnu/gcc/obj-pr40125/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin
-I/gnu/gcc/obj-pr40125/i686-pc-cygwin/libstdc++-v3/include
-I/gnu/gcc/gcc-patched/libstdc++-v3/libsupc++
-I/gnu/gcc/gcc-patched/libstdc++-v3/include/backward
-I/gnu/gcc/gcc-patched/libstdc++-v3/testsuite/util -fmessage-length=0 -gcoff3
-O2 -c -o debug9.o /gnu/gcc/gcc-patched/gcc/testsuite/g++.dg/debug/debug9.C
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s: Assembler messages:
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:61: Error: CFI instruction
used without previous .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:62: Error: CFI instruction
used without previous .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:63: Error: CFI instruction
used without previous .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:65: Error: CFI instruction
used without previous .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:67: Error: CFI instruction
used without previous .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:69: Error: CFI instruction
used without previous .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:71: Error: CFI instruction
used without previous .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:75: Error: CFI instruction
used without previous .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:135: Error: .cfi_endproc
without corresponding .cfi_startproc
/win/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccaVQnkC.s:178: Error: open CFI at the
end of file; missing .cfi_endproc directive
compiler exited with status 1
... and these are caused because we're hopping around between .text and
.text.startup, and we do so:
.filedebug9.C
.text
.def_s;.scl10;.type010;.size1;.endef
.def.eos;.val1;.scl102;.tag_s;.size1;
.endef
.def_s;.scl13;.tag_s;.size1;.type010;
.endef
.def___main;.scl2;.type32;.endef
.section.text.startup,x
.p2align 4,,15
.text
.def_main;.val_main;.scl2;.type044;.endef
.globl_main
_main:
.def.bf;.val.;.scl101;.line23;.endef
.section.text.startup,x
LFB1:
.cfi_startproc
.cfi_personality 0,___gxx_personality_v0
.cfi_lsda 0,LLSDA1
leal4(%esp), %ecx
.cfi_def_cfa 1, 0
andl$-16, %esp
pushl-4(%ecx)
pushl%ebp
movl%esp, %ebp
.cfi_escape 0x10,0x5,0x2,0x75,0
pushl%esi
pushl%ebx
pushl%ecx
.cfi_escape 0xf,0x3,0x75,0x74,0x6
.cfi_escape 0x10,0x3,0x2,0x75,0x78
.cfi_escape 0x10,0x6,0x2,0x75,0x7c
subl$44, %esp
.ln1
call___main
.def.bb;.val.;.scl100;.line1;.endef
.def.bb;.val.;.scl100;.line1;.endef
.text
... here, right in the middle of an open CFI. GAS can't handle this even if we
were to switch back to the original section anyway, but in this case it's even
worse:
.def_c;.val-26;.scl1;.tag_s;.size1;
.type010;.endef
leal-26(%ebp), %ebx
leal-25(%ebp), %esi
... as we end up carrying on code generation in a different section. Urk!
This test is compiled with -gcoff in effect, and the problematic switch back
to the .text section is generated in sdbout.c#sdbout_one_type(), right here at
the start:
static void
sdbout_one_type (tree type)
{
if (current_function_decl != NULL_TREE
DECL_SECTION_NAME (current_function_decl) != NULL_TREE)
; /* Don't change section amid function. */
else
switch_to_section (text_section);
For some reason this doesn't realise that we may be in a section other than
the .text section any more. current_function_decl points to main() at the time
of the problem, but DECL_SECTION_NAME is indeed null.
Honza, any ideas how to teach it about the new sections?
[Bug debug/46123] [4.5/4.6 Regression] ICE: in output_aranges, at dwarf2out.c:11531 with -feliminate-dwarf2-dups -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46123
Dave Korn davek at gcc dot gnu.org changed:
What|Removed |Added
CC||davek at gcc dot gnu.org
--- Comment #9 from Dave Korn davek at gcc dot gnu.org 2010-12-04 06:26:55
UTC ---
The testcase is failing for me on i686-pc-cygwin:
spawn /gnu/gcc/obj-pr40125/gcc/testsuite/g++/../../g++
-B/gnu/gcc/obj-pr40125/gcc/testsuite/g++/../../
/gnu/gcc/gcc-patched/gcc/testsuite/g++.dg/debug/pr46123.C -nostdinc++
-I/gnu/gcc/obj-pr40125/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin
-I/gnu/gcc/obj-pr40125/i686-pc-cygwin/libstdc++-v3/include
-I/gnu/gcc/gcc-patched/libstdc++-v3/libsupc++
-I/gnu/gcc/gcc-patched/libstdc++-v3/include/backward
-I/gnu/gcc/gcc-patched/libstdc++-v3/testsuite/util -fmessage-length=0 -gdwarf-2
-g -feliminate-dwarf2-dups -S -o pr46123.s
/gnu/gcc/gcc-patched/gcc/testsuite/g++.dg/debug/pr46123.C:47:1: internal
compiler error: in output_aranges, at dwarf2out.c:11678
It happens here,
(gdb) bt
#0 0x007c7c70 in fancy_abort (
file=0xe22afc /gnu/gcc/gcc-patched/gcc/dwarf2out.c, line=11678,
function=0xe284b4 output_aranges)
at /gnu/gcc/gcc-patched/gcc/diagnostic.c:101
#1 0x0066b9c1 in dwarf2out_finish (
filename=0x59bccaa
/gnu/gcc/gcc-patched/gcc/testsuite/g++.dg/debug/pr46123.
C) at /gnu/gcc/gcc-patched/gcc/dwarf2out.c:1109
... in dwarf2out.c, where output_aranges() has been inlined into
dwarf2out_finish:
/* It is necessary not to output these entries if the sections were
not used; if the sections were not used, the length will be 0 and
the address may end up as 0 if the section is discarded by ld
--gc-sections, leaving an invalid (0, 0) entry that can be
confused with the terminator. */
if (text_section_used)
{
dw2_asm_output_addr (DWARF2_ADDR_SIZE, text_section_label, Address);
dw2_asm_output_delta (DWARF2_ADDR_SIZE, text_end_label,
text_section_label, Length);
}
if (cold_text_section_used)
{
dw2_asm_output_addr (DWARF2_ADDR_SIZE, cold_text_section_label,
Address);
dw2_asm_output_delta (DWARF2_ADDR_SIZE, cold_end_label,
cold_text_section_label, Length);
}
for (i = 0; i arange_table_in_use; i++)
{
dw_die_ref die = arange_table[i];
/* We shouldn't see aranges for DIEs outside of the main CU. */
gcc_assert (die-die_mark);
This assertion triggers on the second address range in the table:
(gdb) p arange_table[0][0]
$2 = {die_id = {die_symbol = 0x0, die_type_node = 0x0},
die_attr = 0x7ff01400, die_parent = 0x7feb1980, die_child = 0x7feb1b00,
die_sib = 0x7feb19e0, die_definition = 0x0, die_offset = 98,
die_abbrev = 4, die_mark = 0, die_perennial_p = 0, decl_id = 1705,
die_tag = DW_TAG_subprogram}
(gdb) p arange_table[1][0]
$3 = {die_id = {die_symbol = 0x0, die_type_node = 0x0},
die_attr = 0x7ff816c0, die_parent = 0x7feb0360, die_child = 0x7feb1e00,
die_sib = 0x7feb2340, die_definition = 0x0, die_offset = 78,
die_abbrev = 9, die_mark = 1, die_perennial_p = 0, decl_id = 1697,
die_tag = DW_TAG_subprogram}
(gdb) p arange_table[2]
$4 = (dw_die_ref) 0x0
(gdb)
Any ideas what this could mean?
[Bug debug/46123] [4.5/4.6 Regression] ICE: in output_aranges, at dwarf2out.c:11531 with -feliminate-dwarf2-dups -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46123 --- Comment #10 from Dave Korn davek at gcc dot gnu.org 2010-12-04 06:28:04 UTC --- Created attachment 22625 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22625 generated assembler This is the assembler output that has been generated up to the point when it ICEs.
[Bug debug/46123] [4.5/4.6 Regression] ICE: in output_aranges, at dwarf2out.c:11531 with -feliminate-dwarf2-dups -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46123 --- Comment #11 from Dave Korn davek at gcc dot gnu.org 2010-12-04 06:28:48 UTC --- Created attachment 22626 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22626 preprocessed source
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #14 from Dave Korn davek at gcc dot gnu.org 2010-12-02 08:52:20 UTC --- (In reply to comment #13) Yeh, precisely. The ironly file is a placeholder into which we put the symbols found in the lto symtab so that they can take part in the link and their resolutions be determined. We have no way of conveying any symbol type The error comes out after the lto1 invocation, so why the ironly section is still around? I would expect it to be discarded at that time and replaced by whatever compiler returns to you. It's the symbol from the ironly section that remains, and it gets discarded and replaced by the the symbol from the real object file by the linker multiple_definition callback hook when _bfd_generic_link_add_one_symbol is called to add the symbol from the real object file into the link hash table. Unfortunately, the elf linker has some additional checking that it does before calling that routine which preemptively complains about the multiple definition before the linker hook has a chance to replace the original ironly symbol by the new one.
[Bug driver/46760] LTO doesn't work with FDO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Depends on||42690 AssignedTo|davek at gcc dot gnu.org|unassigned at gcc dot ||gnu.org --- Comment #7 from Dave Korn davek at gcc dot gnu.org 2010-12-02 09:08:42 UTC --- (In reply to comment #6) Hi, at one point I tried profiledbootstrap and problem is that we can not merge multiple LTO files that has been profiled different amount of times. This happens during our build because lto1 and cc1 share libbackend. We probably need to add code rescaling corresponding events... Honza Rather than open a second bug for this part of the problem, let's leave this PR to handle it; the first part of the problem that HJ originally reported can be considered a part of bug 42690, which I'm in the course of testing the attached patch as part of. So, de-assigning myself from this PR. Possibly we should consider this a build system bug and the makefile should be responsible for swapping sets of gcda files in and out? Otherwise the component should be changed to lto.
[Bug other/46695] [4.6 regression] failure to build X from darwin to cris-elf with lto enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46695 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.12.01 12:17:35 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 #3 from Dave Korn davek at gcc dot gnu.org 2010-12-01 12:17:35 UTC --- (In reply to comment #2) not I, the addition of -no-undefined was from the Dave K. who needs it to get a .dll to build - without that change, everything is hunky-dory with libtool defaults. Based on our off-list discussion, I thought that it actually required an explicit -undefined dynamic_lookup? (Dave also has a patch that makes the addition conditional on the *win* target). Yep, that will resolve this problem. Just need to agree the fine details with Ralf.
[Bug other/46695] [4.6 regression] failure to build X from darwin to cris-elf with lto enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46695 --- Comment #4 from Dave Korn davek at gcc dot gnu.org 2010-12-01 12:31:28 UTC --- (In reply to comment #3) (In reply to comment #2) not I, the addition of -no-undefined was from the Dave K. who needs it to get a .dll to build - without that change, everything is hunky-dory with libtool defaults. Based on our off-list discussion, I thought that it actually required an explicit -undefined dynamic_lookup? Ah, hang on, I re-read our earlier emails and think I misunderstood. My understanding now is that that is what you get by default, so simply /not/ passing -no-undefined on Darwin is all that is required. That is how I will respin the patch.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added CC||davek at gcc dot gnu.org --- Comment #12 from Dave Korn davek at gcc dot gnu.org 2010-12-02 01:03:43 UTC --- (In reply to comment #11) OK, working around the previous issues we fail with: /abuild/jh/trunk-install/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/bin/ld: gTLSIsMainThread: TLS reference in /tmp/cczRYvg1.ltrans0.ltrans.o mismatches non-TLS definition in nsThreadManager.o.ironly section .text Dave, is this a GNU LD bug? It seems to me that most likely that nsThreadManager.o.ironly section is the one got from lto plugin and we don't put TLS annotations there because we have no way to do so? Yeh, precisely. The ironly file is a placeholder into which we put the symbols found in the lto symtab so that they can take part in the link and their resolutions be determined. We have no way of conveying any symbol type info. We'll need to handle this in the multiple-def linker hook in LD's plugin code, by getting it to copy type info from the newly-added symbols to the ironly ones. Oh, hang on, that won't work. elflink.c calls _bfd_elf_merge_symbol /before/ _bfd_generic_link_add_one_symbol, which is where the multiple-def hook gets called back from. So it'll error on the mismatch before we get a chance to do anything about it. That's awkward. Need to scratch my head over that for a bit.
[Bug driver/46760] LTO doesn't work with FDO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.12.02 04:57:41 AssignedTo|unassigned at gcc dot |davek at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Dave Korn davek at gcc dot gnu.org 2010-12-02 04:57:41 UTC --- Created attachment 22600 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22600 extend pass-throughs I'm testing this, which adds pass-thoughs for gcov and the endfiles (see also Bug 42690).
[Bug driver/46760] LTO doesn't work with FDO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760 --- Comment #4 from Dave Korn davek at gcc dot gnu.org 2010-12-02 07:14:34 UTC --- With my patch we no longer get the undefined symbols building lto-wrapper, but instead later on we hit this problem: -- [ . . . ] /home/davek/gcc/obj-gold/./prev-gcc/xgcc -B/home/davek/gcc/obj-gold/./prev-gcc/ -B/n/10/davek/gcc/x86_64-unknown-linux-gnu/bin/ -B/n/10/davek/gcc/x86_64-unknown-linux-gnu/bin/ -B/n/10/davek/gcc/x86_64-unknown-linux-gnu/lib/ -isystem /n/10/davek/gcc/x86_64-unknown-linux-gnu/include -isystem /n/10/davek/gcc/x86_64-unknown-linux-gnu/sys-include -g -O2 -flto=jobserver -fuse-linker-plugin -frandom-seed=1 -fprofile-use -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genchecksum \ build/genchecksum.o .././libiberty/libiberty.a lto1: sorry, unimplemented: combining units with different profiles is not supported lto1: internal compiler error: in lto_file_decl_data_get_fn_decl, at lto-streamer.h:1075 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /home/davek/gcc/obj-gold/./prev-gcc/xgcc returned 1 exit status gold: fatal error: lto-wrapper failed collect2: ld returned 1 exit status make[3]: *** [build/genchecksum] Error 1 make[3]: *** Waiting for unfinished jobs rm gfdl.pod cpp.pod gfortran.pod gcov.pod fsf-funding.pod gcc.pod make[3]: Leaving directory `/home/davek/gcc/obj-gold/gcc' make[2]: *** [all-stagefeedback-gcc] Error 2 make[2]: Leaving directory `/home/davek/gcc/obj-gold' make[1]: *** [stagefeedback-bubble] Error 2 make[1]: Leaving directory `/home/davek/gcc/obj-gold' make: *** [profiledbootstrap] Error 2 -- As far as I can see though, everything relevant was compiled with -fprofile-use in effect: -- Configuring stage feedback in ./libiberty [ . . . ] /home/davek/gcc/obj-gold/./prev-gcc/xgcc -B/home/davek/gcc/obj-gold/./prev-gcc/ -B/n/10/davek/gcc/x86_64-unknown-linux-gnu/bin/ -B/n/10/davek/gcc/x86_64-unknown-linux-gnu/bin/ -B/n/10/davek/gcc/x86_64-unknown-linux-gnu/lib/ -isystem /n/10/davek/gcc/x86_64-unknown-linux-gnu/include -isystem /n/10/davek/gcc/x86_64-unknown-linux-gnu/sys-include-c -DHAVE_CONFIG_H -g -O2 -flto=jobserver -fuse-linker-plugin -frandom-seed=1 -fprofile-use -I. -I/n/10/davek/gcc/gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic /n/10/davek/gcc/gcc/libiberty/md5.c -o md5.o [ . . . ] /home/davek/gcc/obj-gold/./prev-gcc/xgcc -B/home/davek/gcc/obj-gold/./prev-gcc/ -B/n/10/davek/gcc/x86_64-unknown-linux-gnu/bin/ -B/n/10/davek/gcc/x86_64-unknown-linux-gnu/bin/ -B/n/10/davek/gcc/x86_64-unknown-linux-gnu/lib/ -isystem /n/10/davek/gcc/x86_64-unknown-linux-gnu/include -isystem /n/10/davek/gcc/x86_64-unknown-linux-gnu/sys-include-c -DHAVE_CONFIG_H -g -O2 -flto=jobserver -fuse-linker-plugin -frandom-seed=1 -fprofile-use -I. -I/n/10/davek/gcc/gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic /n/10/davek/gcc/gcc/libiberty/fopen_unlocked.c -o fopen_unlocked.o [ . . . ] /home/davek/gcc/obj-gold/./prev-gcc/xgcc -B/home/davek/gcc/obj-gold/./prev-gcc/ -B/n/10/davek/gcc/x86_64-unknown-linux-gnu/bin/ -B/n/10/davek/gcc/x86_64-unknown-linux-gnu/bin/ -B/n/10/davek/gcc/x86_64-unknown-linux-gnu/lib/ -isystem /n/10/davek/gcc/x86_64-unknown-linux-gnu/include -isystem /n/10/davek/gcc/x86_64-unknown-linux-gnu/sys-include-c -DHAVE_CONFIG_H -g -O2 -flto=jobserver -fuse-linker-plugin -frandom-seed=1 -fprofile-use -I. -I/n/10/davek/gcc/gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic /n/10/davek/gcc/gcc/libiberty/xstrerror.c -o xstrerror.o [ . . . ] /home/davek/gcc/obj-gold/./prev-gcc/xgcc -B/home/davek/gcc/obj-gold/./prev-gcc/ -B/n/10/davek/gcc/x86_64-unknown-linux-gnu/bin/ -B/n/10/davek/gcc/x86_64-unknown-linux-gnu/bin/ -B/n/10/davek/gcc/x86_64-unknown-linux-gnu/lib/ -isystem /n/10/davek/gcc/x86_64-unknown-linux-gnu/include -isystem /n/10/davek/gcc/x86_64-unknown-linux-gnu/sys-include-c -g -O2 -flto=jobserver -fuse-linker-plugin -frandom-seed=1 -fprofile-use -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/n/10/davek/gcc/gcc/gcc -I/n/10/davek/gcc/gcc/gcc/build
[Bug driver/46760] LTO doesn't work with FDO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760
--- Comment #5 from Dave Korn davek at gcc dot gnu.org 2010-12-02 07:47:13
UTC ---
(In reply to comment #4)
-DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genchecksum \
build/genchecksum.o .././libiberty/libiberty.a
lto1: sorry, unimplemented: combining units with different profiles is not
supported
lto1: internal compiler error: in lto_file_decl_data_get_fn_decl, at
lto-streamer.h:1075
This sorry comes from input_profile_summary() in lto-cgraph.c, in fact:
static struct gcov_ctr_summary lto_gcov_summary;
/* Input profile_info from IB. */
static void
input_profile_summary (struct lto_input_block *ib)
{
unsigned int runs = lto_input_uleb128 (ib);
if (runs)
{
if (!profile_info)
{
profile_info = lto_gcov_summary;
lto_gcov_summary.runs = runs;
lto_gcov_summary.sum_all = lto_input_sleb128 (ib);
lto_gcov_summary.run_max = lto_input_sleb128 (ib);
lto_gcov_summary.sum_max = lto_input_sleb128 (ib);
}
/* We can support this by scaling all counts to nearest common multiple
of all different runs, but it is perhaps not worth the effort. */
else if (profile_info-runs != runs
|| profile_info-sum_all != lto_input_sleb128 (ib)
|| profile_info-run_max != lto_input_sleb128 (ib)
|| profile_info-sum_max != lto_input_sleb128 (ib))
sorry (combining units with different profiles is not supported);
/* We allow some units to have profile and other to not have one. This
will
just make unprofiled units to be size optimized that is sane. */
}
}
This is the start of the cgraph data from build/genchecksum.o:
(gdb) c
Continuing.
Breakpoint 5, lto_create_simple_input_block (file_data=0x77267000,
section_type=LTO_section_cgraph, datar=0x7fffd858, len=0x7fffd860)
at /n/10/davek/gcc/gcc/gcc/lto-section-in.c:294
294 {
$17 = {current_decl_state = 0x77275000,
global_decl_state = 0x77275000, cgraph_node_encoder = 0x0,
varpool_node_encoder = 0x0, function_decl_states = 0x7735dcb0,
file_name = 0x1bde940 build/genchecksum.o, section_hash_table = 0x1bfa560,
renaming_hash_table = 0x1bfb4a0, next = 0x0, id = 3807079657,
resolutions = 0x1bfab30}
(gdb) fin
Run till exit from #0 lto_create_simple_input_block (
file_data=0x77267000, section_type=LTO_section_cgraph,
datar=0x7fffd858, len=0x7fffd860)
at /n/10/davek/gcc/gcc/gcc/lto-section-in.c:294
input_cgraph () at /n/10/davek/gcc/gcc/gcc/lto-cgraph.c:1475
1475 if (!ib)
Value returned is $18 = (struct lto_input_block *) 0x1bfa250
(gdb) p $18[0]
$19 = {data = 0x1bfa020 \004\201?\225\r??\237\003?\233\f\002\177, p = 0,
len = 551}
(gdb) x/551xb $18-data
0x1bfa020: 0x040x810xf10x950x0d0xc00xdc0x9f
0x1bfa028: 0x030xda0xb90x9b0x0c0x020x7f0x00
0x1bfa030: 0x000x000x060x070x050x0f0x7f0x7f
0x1bfa038: 0xbc0xa00x0a0x000x000x020x7f0x01
0x1bfa040: 0xbd0x010xc80x200xe40x000x060xe2
and here is how it gets read into lto_gcov_summary first time
input_profile_summary is called:
(gdb) p 'lto_gcov_summary.170684.49820'
$27 = (data variable, no debug info *) 0x1777280
(gdb) p (struct gcov_ctr_summary *)'lto_gcov_summary.170684.49820'
$28 = (struct gcov_ctr_summary *) 0x1777280
(gdb) p $28[0]
$29 = {num = 0, runs = 4, sum_all = 27621505, run_max = 6811200,
sum_max = 25615578}
(gdb) p/x $28[0]
$30 = {num = 0x0, runs = 0x4, sum_all = 0x1a57881, run_max = 0x67ee40,
sum_max = 0x186dcda}
(gdb)
But here's the start of the ../libiberty/md5.o cgraph section data:
(gdb) c
Continuing.
Breakpoint 5, lto_create_simple_input_block (file_data=0x772670b0,
section_type=LTO_section_cgraph, datar=0x7fffd858, len=0x7fffd860)
at /n/10/davek/gcc/gcc/gcc/lto-section-in.c:294
294 {
$22 = {current_decl_state = 0x77275870,
global_decl_state = 0x77275870, cgraph_node_encoder = 0x0,
varpool_node_encoder = 0x0, function_decl_states = 0x7735dd20,
file_name = 0x1bfb480 ../libiberty/md5.o, section_hash_table = 0x1bfcdd0,
renaming_hash_table = 0x1bfae30, next = 0x0, id = 3807079657,
resolutions = 0x1bfb770}
(gdb) fin
Run till exit from #0 lto_create_simple_input_block (
file_data=0x772670b0, section_type=LTO_section_cgraph,
datar=0x7fffd858, len=0x7fffd860)
at /n/10/davek/gcc/gcc/gcc/lto-section-in.c:294
input_cgraph () at /n/10/davek/gcc/gcc/gcc/lto-cgraph.c:1475
1475 if (!ib)
Value returned is $23 = (struct lto_input_block *) 0x1bfbb50
(gdb) p $23[0]
$24 = {
data = 0x1bfc0e0 ?\016??\212?\212\002\220?\204\017??\204?\002\002\177,
p = 0, len = 352}
(gdb) x/352xb $23-data
0x1bfc0e0: 0xc00x0e0xaf0xbc0x8a0xed0x8a0x02
0x1bfc0e8: 0x900xcf0x840x0f0xa30xa10x84
[Bug middle-end/46709] [4.6 regression] internal compiler error: process_function_and_variable_attributes gcc/cgraphunit.c:847
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46709 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Dave Korn davek at gcc dot gnu.org 2010-11-30 16:56:37 UTC --- Committed revision 167302. http://gcc.gnu.org/viewcvs?root=gccview=revrev=167302 (Changelog fixed in r.167303)
[Bug target/42904] Attribute dllexport should imply externally_visible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42904 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-11/msg02190.htm ||l Depends on||46709 Resolution||FIXED AssignedTo|davek at gcc dot gnu.org|ktietz at gcc dot gnu.org --- Comment #5 from Dave Korn davek at gcc dot gnu.org 2010-11-30 17:31:32 UTC --- Yes, Kai's patch (see URL) works for -fwhole-program as well as LTO :)
[Bug target/42904] Attribute dllexport should imply externally_visible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42904 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug middle-end/46709] [4.6 regression] internal compiler error: process_function_and_variable_attributes gcc/cgraphunit.c:847
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46709 Dave Korn davek at gcc dot gnu.org changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2010-11/msg02837.htm ||l Last reconfirmed||2010.11.29 21:02:17 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 #2 from Dave Korn davek at gcc dot gnu.org 2010-11-29 21:02:17 UTC --- Patch posted.
