[Bug bootstrap/38862] Bootstrap failure on HEAD with static linking vs. graphite
--- Comment #2 from davek at gcc dot gnu dot org 2009-01-17 21:06 --- Subject: Bug 38862 Author: davek Date: Sat Jan 17 21:06:17 2009 New Revision: 143472 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143472 Log: PR bootstrap/38862 * Makefile.in (BACKENDLIBS): Reorder to match dependencies. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38862
[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update
--- Comment #12 from davek at gcc dot gnu dot org 2009-01-21 19:20 --- Subject: Bug 37660 Author: davek Date: Wed Jan 21 19:20:08 2009 New Revision: 143552 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143552 Log: PR bootstrap/37660 * config/i386/cygwin.h (SHARED_LIBGCC_SPEC): New helper macro. (LIBGCC_SPEC): Don't define. (REAL_LIBGCC_SPEC): Define instead, using SHARED_LIBGCC_SPEC. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/cygwin.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
[Bug target/38904] Shared libgcc DLL violates Cygwin platform conventions.
--- Comment #3 from davek at gcc dot gnu dot org 2009-01-31 18:52 --- Subject: Bug 38904 Author: davek Date: Sat Jan 31 18:52:00 2009 New Revision: 143829 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143829 Log: PR target/38904 * mkmap-flat.awk (END): Use pe_dll command-line arg to pass LIBRARY name in, instead of hard-coding it. * config.gcc (i[34567]86-*-pe | i[34567]86-*-cygwin*): Add an extra target make frag to tmake_files according to EH model. (i[34567]86-*-mingw* | x86_64-*-mingw*): Likewise. * config/i386/t-dw2-eh, config/i386/t-sjlj-eh: Add new target frags that define makefile variable EH_MODEL appropriately. * config/i386/cygming.h (DWARF2_UNWIND_INFO): Add comment. * config/i386/cygwin.h (LIBGCC_EH_EXTN): Define to nothing or to "-sjlj" according to type of EH configured. (LIBGCC_SONAME): Concatenate it to shared library base name. * config/i386/mingw32.h (LIBGCC_EH_EXTN): Define to "_dw2" or to "_sjlj" according to type of EH configured. (LIBGCC_SONAME): Concatenate it to shared library base name. * config/i386/t-cygming (SHLIB_SONAME): Use EH_MODEL. (SHLIB_LINK): Add missing semicolon to if-else construct. (SHLIB_MKMAP_OPTS): Pass library name to mkmap-flat.awk as string value of "pe_dll" command-line option. * config/i386/t-cygwin (SHLIB_EH_EXTENSION): New helper. (SHLIB_SONAME): Use it when overriding t-cygming default. (SHLIB_IMPLIB): Override t-cygming default. (SHLIB_MKMAP_OPTS): Pass library name to mkmap-flat.awk as string value of "pe_dll" command-line option. Added: trunk/gcc/config/i386/t-dw2-eh trunk/gcc/config/i386/t-sjlj-eh Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/i386/cygming.h trunk/gcc/config/i386/cygwin.h trunk/gcc/config/i386/mingw32.h trunk/gcc/config/i386/t-cygming trunk/gcc/config/i386/t-cygwin trunk/gcc/mkmap-flat.awk -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38904
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #60 from davek at gcc dot gnu dot org 2009-05-28 10:48 --- Subject: Bug 37216 Author: davek Date: Thu May 28 10:48:35 2009 New Revision: 147950 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147950 Log: gcc/ChangeLog: 2009-05-28 Dave Korn PR target/37216 * configure.ac (HAVE_GAS_ALIGNED_COMM): Add autoconf test and macro definition for support of three-operand format aligned .comm directive in assembler on cygwin/pe/mingw target OS. * configure: Regenerate. * config.in: Regenerate. * config/i386/winnt.c (i386_pe_asm_output_aligned_decl_common): Use aligned form of .comm directive if -mpe-aligned-commons is in effect. * config/i386/cygming.opt (-mpe-aligned-commons): Add new option. * doc/invoke.texi (-mpe-aligned-commons): Document new target option. * doc/tm.texi (ASM_OUTPUT_COMMON): Document zero size commons. gcc/testsuite/ChangeLog: 2009-05-28 Dave Korn Uros Bizjak Danny Smith PR target/37216 * lib/target-supports.exp (check_effective_target_pe_aligned_commons): New function. * gcc.target/i386/pr37216.c: New test source file. * gcc.dg/compat/struct-layout-1_generate.c (dg_options[]): No longer use -fno-common for testing Cygwin and MinGW targets. Added: trunk/gcc/testsuite/gcc.target/i386/pr37216.c Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/config/i386/cygming.opt trunk/gcc/config/i386/winnt.c trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/doc/invoke.texi trunk/gcc/doc/tm.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug libgcj/31662] Can't boostrap current gcc trunk with libjava
--- Comment #3 from davek at gcc dot gnu dot org 2009-07-20 01:25 --- Long since fixed. -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31662
[Bug libffi/40807] [4.5 Regression] : libffi.call/return_sc.c
--- Comment #2 from davek at gcc dot gnu dot org 2009-07-20 01:27 --- Taking assignment. -- davek at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-20 01:27:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40807
[Bug libffi/40807] [4.5 Regression] : libffi.call/return_sc.c
--- Comment #3 from davek at gcc dot gnu dot org 2009-07-20 14:11 --- Created an attachment (id=18229) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18229&action=view) proposed fix This patch fixes all the significant FAILs currently extant in the libffi testsuite. === libffi Summary === # of expected passes1642 # of unexpected failures2 # of expected failures 10 The remaining two FAILs I see: FAIL: libffi.call/cls_align_pointer.c (test for excess errors) FAIL: libffi.call/huge_struct.c (test for excess errors) ... are format string warnings of less importance. I have to go AFK for a bit now so I won't get to submit this until tomorrow sometime. Just in case I get hit by a meteorite, here it is for the record. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40807
[Bug libffi/40807] [4.5 Regression] : libffi.call/return_sc.c
--- Comment #4 from davek at gcc dot gnu dot org 2009-07-20 14:31 --- Created an attachment (id=18230) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18230&action=view) Updated patch Now with a trivial tweak to fix a missing-prototype warning. -- davek at gcc dot gnu dot org changed: What|Removed |Added Attachment #18229|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40807
[Bug libffi/40807] [4.5 Regression] : libffi.call/return_sc.c
--- Comment #5 from davek at gcc dot gnu dot org 2009-07-20 14:43 --- Created an attachment (id=18231) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18231&action=view) final spin Turns out that '#' makes a bad choice of comment introducer if the next word is "if" and you're running your .S file through the C preprocessor! -- davek at gcc dot gnu dot org changed: What|Removed |Added Attachment #18230|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40807
[Bug libffi/40807] [4.5 Regression] : libffi.call/return_sc.c
--- Comment #6 from davek at gcc dot gnu dot org 2009-07-24 10:12 --- Subject: Bug 40807 Author: davek Date: Fri Jul 24 10:12:16 2009 New Revision: 150042 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150042 Log: PR libffi/40807 * src/x86/ffi.c (ffi_prep_cif_machdep): Also use sign/zero-extending return types for X86_WIN32. * src/x86/win32.S (_ffi_call_SYSV): Handle omitted return types. (_ffi_call_STDCALL, _ffi_closure_SYSV, _ffi_closure_raw_SYSV, _ffi_closure_STDCALL): Likewise. * src/closures.c (is_selinux_enabled): Define to const 0 for Cygwin. (dlmmap, dlmunmap): Also use these functions on Cygwin. Modified: trunk/libffi/ChangeLog trunk/libffi/src/closures.c trunk/libffi/src/x86/ffi.c trunk/libffi/src/x86/win32.S -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40807
[Bug libffi/40807] [4.5 Regression] : libffi.call/return_sc.c
--- Comment #7 from davek at gcc dot gnu dot org 2009-07-24 10:22 --- Fixed at r.150042. -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40807
[Bug ada/40857] New: Ada broken on newlib-based platforms.
There is a problem with the 32/64-bit file i/o compatibility macros defined in
adaint.h: they clash with some of newlib's definitions.
cc1: warnings being treated as errors
In file included from /gnu/gcc/gcc-patched/gcc/ada/cstreams.c:47:0:
/gnu/gcc/gcc-patched/gcc/ada/adaint.h:58:0: error: "FOPEN" redefined
/usr/include/sys/_default_fcntl.h:95:0: note: this is the location of the
previo
us definition
make[3]: *** [ada/cstreams.o] Error 1
make[3]: Leaving directory `/gnu/gcc/obj-patched/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/gnu/gcc/obj-patched'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/gnu/gcc/obj-patched'
make: *** [all] Error 2
More info in follow-on comments.
--
Summary: Ada broken on newlib-based platforms.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davek at gcc dot gnu dot org
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40857
[Bug ada/40857] Ada broken on newlib-based platforms.
--- Comment #1 from davek at gcc dot gnu dot org 2009-07-25 15:09 --- This is how adaint.h uses the FOPEN, etc. macros to conceal the 32/64 file i/o selection: #if defined (__GLIBC__) || defined (sun) || defined (__sgi) #define FOPEN fopen64 #define STAT stat64 #define FSTAT fstat64 #define LSTAT lstat64 #define STRUCT_STAT struct stat64 #else #define FOPEN fopen #define STAT stat #define FSTAT fstat #define LSTAT lstat #define STRUCT_STAT struct stat #endif In newlib, sys/_default_fcntl.h defines FOPEN as a synonym for the _FOPEN fcntl flag, when !_POSIX_SOURCE: /* * The rest of the flags, used only for opens */ #define FOPEN _FOPEN I haven't yet decided between the two immediately obvious solutions: #1. Prefix _GNAT_ (or similar) to all the #defines in adaint.h and their uses in the ada code. #2. Simply #undef FOPEN before redefining it for our own use. #1 is slightly more work but I guess a bit more robust. Will ask advice from ADA maintainers. BTW my sandbox is on rev 149338 still, but the same #defines are still present on HEAD so I don't suppose it's been fixed yet. -- davek at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-25 15:09:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40857
[Bug bootstrap/40578] FOPEN double defined used in ada/adaint.h:58
--- Comment #6 from davek at gcc dot gnu dot org 2009-07-25 16:06 --- *** Bug 40857 has been marked as a duplicate of this bug. *** -- davek at gcc dot gnu dot org changed: What|Removed |Added CC||davek at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578
[Bug ada/40857] Ada broken on newlib-based platforms.
--- Comment #2 from davek at gcc dot gnu dot org 2009-07-25 16:06 --- *** This bug has been marked as a duplicate of 40578 *** -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40857
[Bug bootstrap/40578] FOPEN double defined used in ada/adaint.h:58
-- davek at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-25 16:07:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578
[Bug bootstrap/40578] FOPEN double defined used in ada/adaint.h:58
--- Comment #7 from davek at gcc dot gnu dot org 2009-07-25 16:14 --- Created an attachment (id=18253) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18253&action=view) Rename macros with GNAT_ prefix Now testing this (respun) version of the fix I originally suggested to bug 40857 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578
[Bug ada/864] --program-suffix is ignored (for ada)
--- Comment #13 from davek at gcc dot gnu dot org 2009-07-26 14:26 --- Broken again on HEAD :-( Configured with --program-suffix=-4, bootstrapped, and installed into a new $prefix that I then placed at the front of $PATH. None of the newly built gnat* executables had the --program-suffix appended. When trying to run the testsuite, host_gnatmake invokes plain unadorned 'gnatmake', which finds the newly-installed one in $prefix. That attempts to invoke plain unadorned 'gcc' unfortunately, which is the distro compiler installed in /usr/bin, and not the newly installed $prefix/bin/gcc-4, resulting in the following error: > + host_gnatmake -gnatws macrosub.adb > > GNATMAKE 4.5.0 20090707 (experimental) > Copyright (C) 1995-2009, Free Software Foundation, Inc. > "macrosub.ali" being checked ... > -> "macrosub.ali" missing. > gcc -c -gnatV -gnatws macrosub.adb > gnat1: invalid switch: -gnatea > End of compilation I tried hacking host_gnatmake and host_gnatchop to pass --GCC=gcc-4, but that only got me a little way further: > + host_gnatmake -gnatws macrosub.adb > > GNATMAKE 4.5.0 20090707 (experimental) > Copyright (C) 1995-2009, Free Software Foundation, Inc. > "macrosub.ali" being checked ... > -> "macrosub.ali" missing. > gcc-4 -c -gnatws macrosub.adb > "defs.ali" being checked ... > -> "defs.ali" missing. > gcc-4 -c -gnatws defs.ads > "getsubs.ali" being checked ... > -> "getsubs.ali" missing. > gcc-4 -c -gnatws getsubs.adb > "parsemac.ali" being checked ... > -> "parsemac.ali" missing. > gcc-4 -c -gnatws parsemac.adb > "text_io.ali" is a read-only library > End of compilation > gnatbind -x macrosub.ali > gnatlink macrosub.ali > b~macrosub.o:b~macrosub.adb:(.eh_frame+0x11): undefined reference to > `___gnat_eh > _personality' > collect2: ld returned 1 exit status > gnatlink: error when calling /usr/bin/gcc.exe > gnatmake: *** link failed. ... the problem being that yet again the unsuffixed system compiler has been invoked, and it's using the system runtime libs rather than the ones that go with the newly-built compiler in $prefix (and which happen to be ABI incompatible because they use ZCX instead of SJLJ). Should gnatmake have passed down the --GCC= option to gnatbind and gnatlink? -- davek at gcc dot gnu dot org changed: What|Removed |Added CC|dave dot korn dot cygwin at |davek at gcc dot gnu dot org |gmail dot com | Status|RESOLVED|REOPENED Resolution|FIXED | Version|2.95.2 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
[Bug bootstrap/40578] FOPEN double defined used in ada/adaint.h:58
--- Comment #8 from davek at gcc dot gnu dot org 2009-07-26 15:09 --- Subject: Bug 40578 Author: davek Date: Sun Jul 26 15:09:10 2009 New Revision: 150098 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150098 Log: PR bootstrap/40578 * adaint.h (FOPEN, STAT, FSTAT, LSTAT, STRUCT_STAT): Rename from these (GNAT_FOPEN, GNAT_STAT, GNAT_FSTAT, GNAT_LSTAT, GNAT_STRUCT_STAT): ... to these. (__gnat_stat): Adjust reference to STAT in prototype. * adaint.c (__gnat_try_lock, __gnat_fopen, __gnat_file_length, __gnat_named_file_length, __gnat_file_time_name, __gnat_file_time_fd, __gnat_get_libraries_from_registry, __gnat_stat, __gnat_file_exists, __gnat_is_regular_file, __gnat_is_directory, __gnat_is_readable_file, __gnat_is_writable_file, __gnat_is_executable_file, __gnat_set_writable, __gnat_set_executable, __gnat_set_non_writable, __gnat_set_readable, __gnat_set_non_readable, __gnat_is_symbolic_link, __gnat_copy_attribs): Adjust all references to the above. * cstreams.c (__gnat_is_regular_file_fd): Likewise. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/adaint.c trunk/gcc/ada/adaint.h trunk/gcc/ada/cstreams.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578
[Bug bootstrap/40578] FOPEN double defined used in ada/adaint.h:58
--- Comment #9 from davek at gcc dot gnu dot org 2009-07-26 15:13 --- All done now. -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578
[Bug ada/864] --program-suffix is ignored (for ada)
--- Comment #17 from davek at gcc dot gnu dot org 2009-07-26 20:39 --- (In reply to comment #15) > Right, my change fixed gnatmake so that it would call the proper gcc (based on > the > previous comments on this PR), but Makefiles have never supported > --program-suffix, so that's not even a regression. Uh, you both focussed on the line where I mentioned in passing that the gnat executables don't get suffixed, and missed the actual bug report: it does *not* call the proper GCC. Regardless of whether gnatmake itself gets a suffix or not, it should have invoked "gcc-4", not "gcc", shouldn't it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
[Bug ada/864] --program-suffix is ignored (for ada)
--- Comment #19 from davek at gcc dot gnu dot org 2009-07-26 20:57 --- (In reply to comment #18) > No, the support that was implemented is that the suffix of gnatmake > is the one that gcc gets suffixed with. Ah ok, I see. Then it's working as designed. Sorry for the noise in your inbox.Judging from the way your patch only changes the names at install time, I expect that if I manually rename the files after they've been installed, they'll also notice their new suffixes and it should all work ok. Bug reclosed. -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=864
[Bug bootstrap/38903] Bootstrap failure on Cygwin vs. libiberty.
--- Comment #4 from davek at gcc dot gnu dot org 2009-07-29 09:23 --- Reopening against 4.3.4 RC 20090727. -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|VERIFIED|UNCONFIRMED Resolution|FIXED | Version|4.4.0 |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38903
[Bug bootstrap/38903] Bootstrap failure on Cygwin vs. libiberty.
-- davek at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-29 09:27:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38903
[Bug bootstrap/38903] Bootstrap failure on Cygwin vs. libiberty.
--- Comment #5 from davek at gcc dot gnu dot org 2009-07-29 11:45 --- Subject: Bug 38903 Author: davek Date: Wed Jul 29 11:45:30 2009 New Revision: 150209 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150209 Log: PR bootstrap/38903: Backport fix from HEAD. * configure.ac (funcs, vars, checkfuncs): Don't munge on Cygwin, as it no longer shares libiberty object files. * configure: Regenerated. Modified: branches/gcc-4_3-branch/libiberty/ChangeLog branches/gcc-4_3-branch/libiberty/configure branches/gcc-4_3-branch/libiberty/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38903
[Bug bootstrap/38903] Bootstrap failure on Cygwin vs. libiberty.
--- Comment #6 from davek at gcc dot gnu dot org 2009-07-29 12:08 --- Fixed on gcc-4_3-branch. Not present on gcc-4_4-branch, fix was applied to HEAD before branching. -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38903
[Bug ada/40984] New: Build failure in oscons stage not detected.
/gcc-tools/i686-pc-cygwin/sys-include " "CFLAGS=-g -O2 -W -Wall > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes" gnatlib-shared \ > && touch stamp-libada > make[3]: Entering directory `/gnu/gcc/obj-patched-gnat5/gcc/ada' > make \ > GNATLIBFLAGS="-W -Wall -gnatpg " \ >GNATLIBCFLAGS="-g -O2 " \ >MULTISUBDIR="" \ >THREAD_KIND="native" \ >TARGET_LIBGCC2_CFLAGS="" \ > gnatlib-shared-win32 The build carries on regardless until some time later, when the malformed/partial s-oscons.ads is finally referenced, while compiling g-socket.ads in $objdir/gcc/ada/rts: > /gnu/gcc/obj-patched-gnat5/./gcc/xgcc -B/gnu/gcc/obj-patched-gnat5/./gcc/ > -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ > -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem > /opt/gcc-tools/i686-pc-cygwin/sys-include-c -g -O2-W -Wall -gnatpg > g-soccon.ads -o g-soccon.o > g-socket.ads:432:46: "SIZEOF_tv_sec" not declared in "OS_Constants" > g-socket.ads:434:53: expected type "Standard.Duration" > g-socket.ads:434:53: found type universal integer > g-socket.ads:1134:58: "SIZEOF_fd_set" not declared in "OS_Constants" > s-oscons.ads:48:01: (style) multiple blank lines > s-oscons.ads:53:01: (style) multiple blank lines > s-oscons.ads:58:01: (style) multiple blank lines > s-oscons.ads:63:01: (style) multiple blank lines > s-oscons.ads:68:01: (style) multiple blank lines > s-oscons.ads:75:01: (style) multiple blank lines > s-oscons.ads:80:01: (style) multiple blank lines > s-oscons.ads:85:01: (style) multiple blank lines > s-oscons.ads:90:01: (style) multiple blank lines > s-oscons.ads:95:01: (style) multiple blank lines > s-oscons.ads:100:01: (style) multiple blank lines > s-oscons.ads:111:01: (style) multiple blank lines > s-oscons.ads:132:01: (style) multiple blank lines > make[6]: *** [g-soccon.o] Error 1 > make[6]: Leaving directory `/gnu/gcc/obj-patched-gnat5/gcc/ada/rts' > make[5]: *** [gnatlib] Error 2 > make[5]: Leaving directory `/gnu/gcc/obj-patched-gnat5/gcc/ada' > make[4]: *** [gnatlib-shared-win32] Error 2 > make[4]: Leaving directory `/gnu/gcc/obj-patched-gnat5/gcc/ada' > make[3]: *** [gnatlib-shared] Error 2 > make[3]: Leaving directory `/gnu/gcc/obj-patched-gnat5/gcc/ada' > make[2]: *** [gnatlib-shared] Error 2 > make[2]: Leaving directory `/gnu/gcc/obj-patched-gnat5/i686-pc-cygwin/libada' > make[1]: *** [all-target-libada] Error 2 > make[1]: Leaving directory `/gnu/gcc/obj-patched-gnat5' > make: *** [all] Error 2 At a first glance, I think this is happening because 'oscons' is a .PHONY target in libada/Makefile.in, and there is no stamp or other sentinel to make sure the sub-make succeeded. The sub-make doesn't pass an error back because the error occurs in the middle of a long shell pipeline at the end of which is a command "$(CP) s-oscons.ads s-oscons.h ../../" that succeeds because xoscons still generates a fragmentary s-oscons.ads despite there being an error. Either xoscons should delete its output in case of an error, or the Makefile rule: $(ADA_GEN_SUBDIR)/s-oscons.ads : $(ADA_GEN_SUBDIR)/s-oscons-tmplt.c $(ADA_GEN_SUBDIR)/gsocket.h $(ADA_GEN_SUBDIR)/xoscons.adb $(ADA_GEN_SUBDIR)/xutil.ads $(ADA_GEN_SUBDIR)/xutil.adb -$(MKDIR) $(ADA_GEN_SUBDIR)/bldtools/oscons $(RM) $(addprefix $(ADA_GEN_SUBDIR)/bldtools/oscons/,$(notdir $^)) $(CP) $^ $(ADA_GEN_SUBDIR)/bldtools/oscons (cd $(ADA_GEN_SUBDIR)/bldtools/oscons ; gnatmake -q xoscons ; \ $(RM) s-oscons-tmplt.i s-oscons-tmplt.s ; \ $(OSCONS_CPP) ; \ $(OSCONS_EXTRACT) ; \ ./xoscons ; \ $(RM) ../../s-oscons.ads ; \ $(CP) s-oscons.ads s-oscons.h ../../) should be changed something along the lines (untested): $(ADA_GEN_SUBDIR)/s-oscons.ads : $(ADA_GEN_SUBDIR)/s-oscons-tmplt.c $(ADA_GEN_SUBDIR)/gsocket.h $(ADA_GEN_SUBDIR)/xoscons.adb $(ADA_GEN_SUBDIR)/xutil.ads $(ADA_GEN_SUBDIR)/xutil.adb -$(MKDIR) $(ADA_GEN_SUBDIR)/bldtools/oscons $(RM) $(addprefix $(ADA_GEN_SUBDIR)/bldtools/oscons/,$(notdir $^)) $(CP) $^ $(ADA_GEN_SUBDIR)/bldtools/oscons (cd $(ADA_GEN_SUBDIR)/bldtools/oscons ; gnatmake -q xoscons ; \ $(RM) s-oscons-tmplt.i s-oscons-tmplt.s ; \ $(OSCONS_CPP) ; \ $(OSCONS_EXTRACT) ; \ ./xoscons || $(RM) s-oscons.ads ; \ $(RM) ../../s-oscons.ads ; \ $(CP) s-oscons.ads s-oscons.h ../../) ... which would hopefully let the copy (and as a result the entire sub-make) fail. -- Summary: Build failure in oscons stage not detected. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: davek at gcc dot gnu dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40984
[Bug c++/41020] New: Can't declare an extern "C" friend.
Attempting to declare a previously-declared extern "C" function as a friend
within a class definition fails with an error that the friend declaration
ambiguates the original extern "C" declaration. It appears that the friend
declaration is taken as an overload with "C++" linkage, since G++ then
complains that the class members are private within the context of the extern
"C" function definition.
$ cat friend.cxx
extern "C"
{
int fork (void);
};
class frok
{
int this_errno;
friend int fork (void);
};
extern "C" int
fork (void)
{
frok grouped;
return grouped.this_errno;
}
$ g++-4 -c friend.cxx -o friend.o
friend.cxx:10:24: error: new declaration 'int fork()'
friend.cxx:4:7: error: ambiguates old declaration 'int fork()'
friend.cxx: In function 'int fork()':
friend.cxx:9:7: error: 'int frok::this_errno' is private
friend.cxx:17:18: error: within this context
$
According to, for example, "C++ in a nutshell"
(http://books.google.co.uk/books?id=91JTA9B_m44C&pg=PA170&lpg=PA170&dq=friend+%22storage+class%22&source=bl&ots=HrN4X1Y5wu&sig=N9rnB8r_YnxbH2hiWGqtbAWbWyk&hl=en&ei=oDt_SqmvGJKNjAe9k93wAQ&sa=X&oi=book_result&ct=result&resnum=5#v=onepage&q=friend%20%22storage%20class%22&f=false),
a function in a friend declaration should "retain its original linkage" when it
has already been declared. That is referring to the case of applying a storage
class specifier (static) to the prior declaration that isn't syntactically
valid within a friend declaration, but it seems like it should apply here too;
the linkage should still be retained, even though I'm not changing the
storage-class specifier.
There may be some reason why this isn't valid C++, but I think it's probably
a weakness in the parsing of friend declarations.
$ g++-4 -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: /gnu/gcc/gcc-patched/configure --prefix=/opt/gcc-tools -v
--wit
h-gmp=/usr --with-mpfr=/usr --enable-bootstrap
--enable-version-specific-runtime
-libs --enable-static --enable-shared --enable-shared-libgcc
--disable-__cxa_ate
xit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions
--disabl
e-symvers --disable-libjava --disable-interpreter --program-suffix=-4
--disable-
libgomp --enable-libssp --enable-libada --enable-threads=posix --with-arch=i686
--with-tune=generic CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4
--with-ecj-jar=/usr/share/java/ecj.jar LD=/opt/gcc-tools/bin/ld.exe
LD_FOR_TARGE
T=/opt/gcc-tools/bin/ld.exe AS=/opt/gcc-tools/bin/as.exe
AS_FOR_TARGET=/opt/gcc-
tools/bin/as.exe --disable-win32-registry --disable-libgcj-debug
--enable-langua
ges=c,c++,ada
Thread model: posix
gcc version 4.5.0 20090730 (experimental) (GCC)
--
Summary: Can't declare an extern "C" friend.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davek at gcc dot gnu dot org
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug c++/41020] Can't declare an extern "C" friend.
--- Comment #1 from davek at gcc dot gnu dot org 2009-08-09 21:31 --- (In reply to comment #0) > $ g++-4 -v Yuck, that got horribly wrapped. Here it is again, hopefully formatted a little better this time: Using built-in specs. Target: i686-pc-cygwin Configured with: /gnu/gcc/gcc-patched/configure --prefix=/opt/gcc-tools -v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap --enable-version-specific-runtime-libs --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --disable-symvers --disable-libjava --disable-interpreter --program-suffix=-4 --disable-libgomp --enable-libssp --enable-libada --enable-threads=posix --with-arch=i686 --with-tune=generic CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 --with-ecj-jar=/usr/share/java/ecj.jar LD=/opt/gcc-tools/bin/ld.exe LD_FOR_TARGET=/opt/gcc-tools/bin/ld.exe AS=/opt/gcc-tools/bin/as.exe AS_FOR_TARGET=/opt/gcc-tools/bin/as.exe --disable-win32-registry --disable-libgcj-debug --enable-languages=c,c++,ada Thread model: posix gcc version 4.5.0 20090730 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug middle-end/31844] Incorrect source locations and number of warnings for unsupported visibility attribute
--- Comment #2 from davek at gcc dot gnu dot org 2009-08-09 22:03 --- Still present, although the location has slipped slightly for the warnings on the function declarations with no body. $ g++ -S vis.cpp -o vis.asm vis.cpp: In function 'int foo(int)': vis.cpp:11: warning: visibility attribute not supported in this configuration; i gnored vis.cpp: At global scope: vis.cpp:30: warning: visibility attribute not supported in this configuration; i gnored vis.cpp:30: warning: visibility attribute not supported in this configuration; i gnored Confirming, but lowering the severity and priority. -- davek at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |trivial Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P5 Last reconfirmed|-00-00 00:00:00 |2009-08-09 22:03:51 date|| Version|4.2.0 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31844
[Bug c++/41020] [4.5 Regression] Can't declare an extern "C" friend.
--- Comment #3 from davek at gcc dot gnu dot org 2009-08-10 16:17 --- (In reply to comment #2) > Apart from the semi-colon after the extern "C" block the code is valid and > this > is a recent regression on trunk. I am fairly sure that a semi-colon after a block statement like that is unnecessary, but not actually invalid. It certainly makes no difference to the testcase whether it is present or absent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug c++/41020] [4.5 Regression] Can't declare an extern "C" friend.
--- Comment #5 from davek at gcc dot gnu dot org 2009-08-10 17:16 ---
(In reply to comment #4)
> It's irrelevant to this bug and is just me being more pedantic than -pedantic,
> however ... even with -pedantic GCC has always accepted stray semi-colons at
> namespace scope, but it's not valid.
>
> At function scope a lone ';' is a valid expression-statement, but
> expression-statements are not allowed at namespace scope, only declarations
> are, and ';' is not a valid declaration.
Well you learn something new every day! Never realised that was a gnu
extension, but it sure is, comeau online choked on my testcase:
"ComeauTest.c", line 5: error: extra ";" ignored,
In C: A function definition does not end with a semicolon
In C++: A non-member function definition, extern "C" block,
or namespace does not end with a semicolon
};
^
Anyway. Consider the testcase amended. :-)
$ cat friend.cxx
extern "C"
{
int fork (void);
}
class frok
{
int this_errno;
friend int fork (void);
};
extern "C" int
fork (void)
{
frok grouped;
return grouped.this_errno;
}
$ g++-4 -c friend.cxx -o friend.o
friend.cxx:10:24: error: new declaration 'int fork()'
friend.cxx:4:7: error: ambiguates old declaration 'int fork()'
friend.cxx: In function 'int fork()':
friend.cxx:9:7: error: 'int frok::this_errno' is private
friend.cxx:17:18: error: within this context
$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug target/40125] libgcc_s DLL installed in wrong directory in cross toolchain
-- davek at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-12 22:14:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40125
[Bug target/40125] libgcc_s DLL installed in wrong directory in cross toolchain
--- Comment #1 from davek at gcc dot gnu dot org 2009-08-12 22:57 --- Even the target-specific i686-mingw32/bin directory contains host applications, i.e. the non-$target-prefixed versions of the binutils. So since these DLLs are never going to be used on the host, we could put them in $target/lib. That might end up altering the link order a bit, since ld supports linking directly against dlls but $prefix/bin isn't usually in the link path; however as long as the compiler's private directory $prefix/lib/gcc/$target/$version is first in the list, the dll's related import lib will always be found first. The other place to install them would be in GCC's private dir. I'm not sure yet which might be preferable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40125
[Bug preprocessor/14331] please add option to suppress warning message "no newline at end of file"
--- Comment #14 from davek at gcc dot gnu dot org 2007-04-10 15:11 --- Patch posted for review at http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00457.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
[Bug preprocessor/14331] please add option to suppress warning message "no newline at end of file"
--- Comment #16 from davek at gcc dot gnu dot org 2007-04-17 18:47 --- Oh, BTW, congratulations Tom on being appointed a libcpp maintainer! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331
[Bug libgcj/31662] New: Can't boostrap current gcc trunk with libjava
Originally reported at http://gcc.gnu.org/ml/gcc/2007-04/msg00539.html,
bootstrap fails with a redefinition error for the macro _EXFUN.
In file included from ../../../gcc/libjava/classpath/native/fdlibm/fdlibm.h:29,
from ../../../gcc/libjava/java/lang/natVMDouble.cc:27:
../../../gcc/libjava/classpath/native/fdlibm/mprec.h:297:1: error:
"_EXFUN" redefined
In file included from /usr/include/stdlib.h:10,
from ../../../gcc/libjava/java/lang/natVMDouble.cc:14:
/usr/include/_ansi.h:36:1: error: this is the location of the previous
definition
make[3]: *** [java/lang/natVMDouble.lo] Error 1
The problem is that cygwin (and presumably other newlib-based targets) supply
the _ansi.h compatibility header from newlib's include dir as a system header.
This defines _EXFUN and a number of other K'n'R-vs-C89 compatibility macros.
When mprec.h was imported (from newlib, possibly indirectly via the classpath
project) it was necessary to supply equivalents to these macros that would
allow it to build on a non-newlib system. This decision makes sense because
removing the macros and ANSI-fying the source would make future imports/merges
very tricky. However, it leads to the redefinition problem on newlib targets
mentioned above.
I am testing a patch that wraps the compatibility definitions in mprec.h in
#ifndef. This is preferable to #undef'ing them, as it defers to the system's
own definitions (in cygwin's case, this include the __cdecl declarator).
--
Summary: Can't boostrap current gcc trunk with libjava
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davek at gcc dot gnu dot org
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31662
[Bug libgcj/31662] Can't boostrap current gcc trunk with libjava
--- Comment #2 from davek at gcc dot gnu dot org 2007-04-25 01:23 --- It determines the calling convention used, and is therefore surely the territory of the system headers/libs. Do take a look at the upstream source: http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/include/_ansi.h?rev=1.4&content-type=text/x-cvsweb-markup&cvsroot=src after all, it comes from the same place mprec comes from. Someone snipped the #if __CYGWIN__ clause somewhere down the line. Would you be happier with a patch that just imported that block of definitions verbatim from newlib? I don't think it's likely to change often and need resyncing! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31662
[Bug bootstrap/40578] FOPEN double defined used in ada/adaint.h:58
--- Comment #11 from davek at gcc dot gnu dot org 2009-08-18 13:36 --- (In reply to comment #10) > Does the fix mean that GNAT does not support large files on any platform? > No need to worry, that was reason why I mentioned it would be necessary to change the 64-bit definition as well, back in comment #5, and that's what I did in the final patch. Large file support in GNAT is entirely unchanged. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40578
[Bug bootstrap/38892] gcc 4.4.0 20090104 - natVMVirtualMachine.cc:903: error: request for member 'frame_type' in ...
--- Comment #10 from davek at gcc dot gnu dot org 2009-08-21 02:20 --- *** Bug 30570 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38892
[Bug libgcj/30570] Word "DEBUG" used as a variable in VMAccessController.java breaks build
--- Comment #9 from davek at gcc dot gnu dot org 2009-08-21 02:20 --- *** This bug has been marked as a duplicate of 38892 *** -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30570
[Bug bootstrap/38892] gcc 4.4.0 20090104 - natVMVirtualMachine.cc:903: error: request for member 'frame_type' in ...
--- Comment #11 from davek at gcc dot gnu dot org 2009-08-21 02:23 --- This has been fixed now since these two revisions were applied: http://gcc.gnu.org/viewcvs?view=revision&revision=146627 http://gcc.gnu.org/viewcvs?view=revision&revision=146869 These days libjava builds fine with --enable-libgcj-debug. -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38892
[Bug boehm-gc/34232] bootstrap fails when libgcj enabled due to undefined reference in libgcjgc (boehm-gc)
--- Comment #1 from davek at gcc dot gnu dot org 2009-08-21 02:26 --- Was fixed in http://gcc.gnu.org/viewcvs?view=revision&revision=147641 -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34232
[Bug debug/41357] libgomp build fail
--- Comment #3 from davek at gcc dot gnu dot org 2009-09-15 12:47 --- This bug is also present on i686-pc-cygwin at r.151703, so given Jie's diagnosis in comment 2, let's switch the component from 'target' to 'debug'. libtool: link: /gnu/gcc/obj.libstdc.enabled/./gcc/xgcc -B/gnu/gcc/obj.libstdc.enabled/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-include-shared .libs/alloc.o .libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o .libs/iter.o .libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o .libs/parallel.o .libs/sections.o .libs/single.o .libs/task.o .libs/team.o .libs/work.o .libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o .libs/ptrlock.o .libs/time.o .libs/fortran.o .libs/affinity.o-pthread -Wl,-O1 -o .libs/cyggomp-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgomp.dll.a xgcc: unrecognized option '-pthread' Creating library file: .libs/libgomp.dll.a.libs/iter.o:iter.c:(.debug_info+0xc29): undefined reference to `_gomp_tls_data' .libs/iter.o:iter.c:(.debug_info+0xcd1): undefined reference to `_gomp_tls_data' .libs/iter.o:iter.c:(.debug_info+0xdc8): undefined reference to `_gomp_tls_data' .libs/iter.o:iter.c:(.debug_info+0xe92): undefined reference to `_gomp_tls_data' .libs/iter_ull.o:iter_ull.c:(.debug_info+0xc55): undefined reference to `_gomp_tls_data' .libs/iter_ull.o:iter_ull.c:(.debug_info+0xd12): more undefined references to `_gomp_tls_data' follow collect2: ld returned 1 exit status One slight difference is that I don't get the complaint from ld about "fde encoding ... prevents .eh_frame_hdr table being created" or the (presumably consequent) "Nonrepresentable section on output" error. -- davek at gcc dot gnu dot org changed: What|Removed |Added ---------------------------- CC||davek at gcc dot gnu dot org Status|UNCONFIRMED |NEW Component|target |debug Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-15 12:47:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #4 from davek at gcc dot gnu dot org 2009-09-15 12:52 --- (In reply to comment #2) > I think it's the same issue for PR41357. > *This* is PR41357; you must mean PR41308. Yes, I think so, I'll mark it as a dup of this one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #5 from davek at gcc dot gnu dot org 2009-09-15 12:52 --- *** Bug 41308 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug bootstrap/41308] build of libgomp fails with undefined reference to gomp_tls_data
--- Comment #1 from davek at gcc dot gnu dot org 2009-09-15 12:52 --- *** This bug has been marked as a duplicate of 41357 *** -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41308
[Bug debug/41357] libgomp build fail
--- Comment #6 from davek at gcc dot gnu dot org 2009-09-15 13:29 --- (In reply to comment #1) > The cause is that DW_TAG_variable references gomp_tls_data instead of > ___emutls_v.gomp_tls_data. > Here's an example: <1>: Abbrev Number: 49 (DW_TAG_variable) DW_AT_name: (indirect string, offset: 0x4a): gomp_tls_data DW_AT_decl_file : 8 DW_AT_decl_line : 361 DW_AT_type: <0x96e> DW_AT_external: 1 DW_AT_declaration : 1 This points to the declaration of gomp_tls_data on line 361 of libgomp.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #7 from davek at gcc dot gnu dot org 2009-09-15 13:40 --- This looks a little tricky. Knowledge of the "__emutls_v." prefix is entirely private to varasm.c. The actual prefixed object itself escapes publicly with that name, but only varasm.c knows that subsequent references to that variable need to be prefixed also, and this is not refelected anywhere in the DECL_NAME or DECL_ASSEMBLER_NAME. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #8 from davek at gcc dot gnu dot org 2009-09-15 14:07 --- (In reply to comment #6) > (In reply to comment #1) > > The cause is that DW_TAG_variable references gomp_tls_data instead of > > ___emutls_v.gomp_tls_data. > > > > Here's an example: No, that's not it, that's not it at all, sorry. Here's the relevant part of the debug info from iter.s in the libgomp build dir, with a bit of surrounding context: .byte 0x1 .ascii "gomp_iter_dynamic_next_locked\0" .byte 0x1 .byte 0x90 .byte 0x1 .long 0x7c3 .long LFB24 .long LFE24 .secrel32 LLST13 .long 0xc77 .uleb128 0x1d .secrel32 LASF4 .byte 0x1 .byte 0x90 .long 0xbc2 .secrel32 LLST14 .uleb128 0x1e .ascii "pend\0" .byte 0x1 .byte 0x90 .long 0xbc2 .secrel32 LLST15 .uleb128 0x24 .ascii "thr\0" .byte 0x1 .byte 0x92 v .long 0xa79 .long _gomp_tls_data ^ .uleb128 0x25 .ascii "ws\0" .byte 0x1 .byte 0x93 .long 0x4e7 .byte 0x1 .byte 0x52 .uleb128 0x26 .secrel32 LASF5 .byte 0x1 .byte 0x94 .long 0xe0 .byte 0x1 .byte 0x51 .uleb128 0x20 .ascii "end\0" Here's what objdump -W has to say about that: <1>: Abbrev Number: 28 (DW_TAG_subprogram) DW_AT_external: 1 DW_AT_name: gomp_iter_dynamic_next_locked DW_AT_decl_file : 1 DW_AT_decl_line : 144 DW_AT_prototyped : 1 DW_AT_type: <0x7c3> DW_AT_low_pc : 0x250 DW_AT_high_pc : 0x2a7 DW_AT_frame_base : 0x1bc (location list) DW_AT_sibling : <0xc77> <2>: Abbrev Number: 29 (DW_TAG_formal_parameter) DW_AT_name: (indirect string, offset: 0x20): pstart DW_AT_decl_file : 1 DW_AT_decl_line : 144 DW_AT_type: <0xbc2> DW_AT_location: 0x200 (location list) <2>: Abbrev Number: 30 (DW_TAG_formal_parameter) DW_AT_name: pend DW_AT_decl_file : 1 DW_AT_decl_line : 144 DW_AT_type: <0xbc2> DW_AT_location: 0x214 (location list) <2>: Abbrev Number: 36 (DW_TAG_variable) DW_AT_name: thr DW_AT_decl_file : 1 DW_AT_decl_line : 146 vvv DW_AT_type: <0xa79> DW_AT_const_value : 0x0 ^^^ (n.b. unrelocated value) <2>: Abbrev Number: 37 (DW_TAG_variable) DW_AT_name: ws DW_AT_decl_file : 1 DW_AT_decl_line : 147 DW_AT_type: <0x4e7> DW_AT_location: 1 byte block: 52(DW_OP_reg2) <2>: Abbrev Number: 38 (DW_TAG_variable) DW_AT_name: (indirect string, offset: 0x44): start DW_AT_decl_file : 1 DW_AT_decl_line : 148 DW_AT_type: <0xe0> DW_AT_location: 1 byte block: 51(DW_OP_reg1) <2>: Abbrev Number: 32 (DW_TAG_variable) DW_AT_name: end DW_AT_decl_file : 1 DW_AT_decl_line : 148 DW_AT_type: <0xe0> DW_AT_location: 0x228 (location list) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #10 from davek at gcc dot gnu dot org 2009-09-15 14:24 --- (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #6) > > > (In reply to comment #1) > > > > The cause is that DW_TAG_variable references gomp_tls_data instead of > > > > ___emutls_v.gomp_tls_data. > > > > > > > > > > Here's an example: > > > > No, that's not it, that's not it at all, sorry. Here's the relevant part > > of > > the debug info from iter.s in the libgomp build dir, with a bit of > > surrounding > > context: > > > > .ascii "thr\0" > > .byte 0x1 > > .byte 0x92 > >v > > .long 0xa79 > > .long _gomp_tls_data > >^ > Yeah, this is what I found. When var-tracking generates debug_insn, it should > use ___emutls_v.gomp_tls_data as normal insn is expanded. > I'm just debugging add_location_or_const_value_attribute() which is where the value gets added. Not sure how to export knowledge of tls prefix from varasm.c yet though. We could punt on trying to attach a const value to the DIE altogether, although that seems a shame since it's potentially knowable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #11 from davek at gcc dot gnu dot org 2009-09-15 14:53 ---
The bogus const info is added in at the end of this call chain, when generating
the var die:
#0 0x004d0679 in add_const_value_attribute (die=0x7fcbd660, rtl=0x7fd20270)
at /gnu/gcc/gcc/gcc/tree.h:182
#1 0x004d25ec in add_location_or_const_value_attribute (die=0x7fcbd660,
decl=0x7fe19e40, attr=DW_AT_location) at /gnu/gcc/gcc/gcc/tree.h:182
#2 0x004da1f2 in gen_variable_die (decl=0x7fe19e40, origin=0x0,
context_die=0x7fcbbe50) at /gnu/gcc/gcc/gcc/tree.h:182
#3 0x004deda3 in gen_decl_die (decl=0x7fe19e40, origin=0x0,
context_die=0x7fcbbe50) at /gnu/gcc/gcc/gcc/tree.h:182
#4 0x004dd3ed in process_scope_var (stmt=0x7fcb2060, decl=0x7fe19e40,
origin=0x0, context_die=0x7fcbbe50) at /gnu/gcc/gcc/gcc/tree.h:182
#5 0x004dd470 in decls_for_scope (stmt=0x7fcb2060, context_die=0x7fcbbe50,
depth=0) at /gnu/gcc/gcc/gcc/tree.h:182
#6 0x004d91d8 in gen_subprogram_die (decl=0x7fdfb500, context_die=0x7fe03678)
at /gnu/gcc/gcc/gcc/tree.h:182
#7 0x004dea1c in gen_decl_die (decl=0x7fdfb500, origin=0x0,
context_die=0x7fe03678) at /gnu/gcc/gcc/gcc/tree.h:182
#8 0x004dfb56 in dwarf2out_decl (decl=0x7fdfb500)
at /gnu/gcc/gcc/gcc/tree.h:182
#9 0x00834dbf in rest_of_handle_final () at /gnu/gcc/gcc/gcc/final.c:3131
In the above call stack, the rtx that is passed to add_const_value_attribute()
looks like this:
(gdb) call debug_rtx (rtl)
(symbol_ref:SI ("gomp_tls_data") [flags 0x42] )
There is code in add_const_value_attribute() to avoid this problem already:
12789 /* Attach a DW_AT_const_value attribute for a variable or a parameter
which
12790 does not have a "location" either in memory or in a register. These
12791 things can arise in GNU C when a constant is passed as an actual
parameter
12792 to an inlined function. They can also arise in C++ where declared
12793 constants do not necessarily get memory "homes". */
12794
12795 static void
12796 add_const_value_attribute (dw_die_ref die, rtx rtl)
12797 {
12798switch (GET_CODE (rtl))
12799 {
[ ... ]
12911 case SYMBOL_REF:
12912if (GET_CODE (rtl) == SYMBOL_REF
12913&& SYMBOL_REF_TLS_MODEL (rtl) != TLS_MODEL_NONE)
12914 break;
12915 case LABEL_REF:
12916add_AT_addr (die, DW_AT_const_value, rtl);
12917VEC_safe_push (rtx, gc, used_rtx_array, rtl);
12918break;
and indeed, it works by simply punting if the symbol ref in question points to
a TLS item, but the flags are wrong in the rtx that is passed in:
(symbol_ref:SI ("gomp_tls_data") [flags 0x42] )
This apparently has SYMBOL_REF_TLS_MODEL (rtl) == TLS_MODEL_NONE, so we never
bail out the escape hatch and end up calling add_AT_addr() to create the
DW_AT_const_value that needs relocating against the undefined symbol.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #12 from davek at gcc dot gnu dot org 2009-09-15 16:16 ---
(In reply to comment #11)
> The bogus const info is added in at the end of this call chain, when
> generating
> the var die:
>
> #0 0x004d0679 in add_const_value_attribute (die=0x7fcbd660, rtl=0x7fd20270)
> at /gnu/gcc/gcc/gcc/tree.h:182
> and indeed, it works by simply punting if the symbol ref in question points to
> a TLS item, but the flags are wrong in the rtx that is passed in:
>
> (symbol_ref:SI ("gomp_tls_data") [flags 0x42] gomp_tls_data>)
>
> This apparently has SYMBOL_REF_TLS_MODEL (rtl) == TLS_MODEL_NONE, so we never
> bail out the escape hatch and end up calling add_AT_addr() to create the
> DW_AT_const_value that needs relocating against the undefined symbol.
It's this part of add_location_or_const_value_attribute() that is adding the
bad const value:
/* If we have tried to generate the location otherwise, and it
didn't work out (we wouldn't be here if we did), and we have a one entry
location list, try generating a location from that. */
if (loc_list && loc_list->first)
{
enum var_init_status status;
node = loc_list->first;
status = NOTE_VAR_LOCATION_STATUS (node->var_loc_note);
rtl = NOTE_VAR_LOCATION (node->var_loc_note);
if (GET_CODE (rtl) == VAR_LOCATION
&& GET_CODE (XEXP (rtl, 1)) != PARALLEL)
rtl = XEXP (XEXP (rtl, 1), 0);
if (CONSTANT_P (rtl) || GET_CODE (rtl) == CONST_STRING)
{
add_const_value_attribute (die, rtl);
^^^
return;
}
(gdb) print (var_loc_list *)0x7fd36d30
$1 = (struct var_loc_list_def *) 0x7fd36d30
(gdb) print $1[0]
$2 = {first = 0x7fd36d20, last = 0x7fd36d20, decl_id = 3277}
(gdb) print $1[0].first
$3 = (struct var_loc_node *) 0x7fd36d20
(gdb) print $1[0].first[0]
$4 = {var_loc_note = 0x7fcdd000, label = 0x7ff27298 "*LVL49",
section_label = 0xd8e60a "*Ltext0", next = 0x0}
(gdb) print $1[0].first[0].var_loc_note
$5 = (rtx) 0x7fcdd000
(gdb) call debug_rtx($1[0].first[0].var_loc_note)
(note 85 4 66 (var_location thr (expr_list:REG_DEP_TRUE (symbol_ref:SI
("gomp_tl
s_data") [flags 0x42] )
(const_int 0 [0x0]))) NOTE_INSN_VAR_LOCATION)
So, the NOTE_VAR_LOCATION stored in the location list's first entry's
var_loc_note field points to this definition that already has incorrect
(non-TLS) flags in the rtl. If we look at the var_decl it's based on:
(gdb) call debug_tree(0x7fe190c0)
unit size
align 32 symtab 2145789512 alias set 7 canonical type 0x7fe7df90
fields
unsigned SI file /gnu/gcc/gcc/libgomp/libgomp.h line 327 col 10
size
unit size
align 32 offset_align 128
offset
bit offset context chain > context
pointer_to_this chain >
addressable used public external tls-local-exec BLK file
/gnu/gcc/gcc/libgom
p/libgomp.h line 361 col 36 size unit size
align 32
(mem/s/c:BLK (symbol_ref:SI ("gomp_tls_data") [flags 0x42] ) [7 gomp_tls_data+0 S52 A32]) chain >
(gdb)
I notice that the tls-local-exec flag is set but there's no TLS mode in the
RTL, again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #14 from davek at gcc dot gnu dot org 2009-09-15 17:08 --- Created an attachment (id=18586) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18586&action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #15 from davek at gcc dot gnu dot org 2009-09-15 17:16 --- (In reply to comment #14) > Created an attachment (id=18586) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18586&action=view) [edit] > reduced testcase > Ok, this is really interesting. The generated debug info only contains the ".long gomp_tls_data" if there are *two* functions that both begin with struct gomp_thread *thr = gomp_thread (); Also, if you change the line to read struct gomp_thread *thr = gomp_thread () + 1; it also doesn't happen. When I read through iter.c.207r.vartrack, I see lots of references to cselib. Is VTA inappropriately CSEing the two value/location expressions together? And perhaps losing track of the TLS status in the process? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #17 from davek at gcc dot gnu dot org 2009-09-15 17:25 --- (In reply to comment #16) > Please read what I wrote. I did, but I'm a few steps behind, and haven't figured out whether to blame encode_section_info() for being naive, or to look at where the SYM_REF gets created as part of vta location note handling and think that it ought to be doing something more subtle there. > vartrack uses cselib as a value numbering implementation, not for anything > else. It's interesting that the debug code only tries to emit a const value for the DIEs in the case where there are two references to the same value number. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #18 from davek at gcc dot gnu dot org 2009-09-15 17:36 --- Created an attachment (id=18587) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18587&action=view) patch based on jakub's suggestion this fixes the testcase, so I may as well take it for a full bootstrap cycle. -- davek at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #22 from davek at gcc dot gnu dot org 2009-09-15 17:57 --- Created an attachment (id=18588) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18588&action=view) slightly reworked patch slightly reworked per hj's suggestion -- davek at gcc dot gnu dot org changed: What|Removed |Added Attachment #18587|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #21 from davek at gcc dot gnu dot org 2009-09-15 17:51 ---
(In reply to comment #19)
> Index: varasm.c
> ===
> --- varasm.c(revision 151703)
> +++ varasm.c(working copy)
> @@ -6420,6 +6420,8 @@ default_encode_section_info (tree decl, rtx rtl, i
>if (targetm.have_tls && TREE_CODE (decl) == VAR_DECL
>&& DECL_THREAD_LOCAL_P (decl))
> flags |= DECL_TLS_MODEL (decl) << SYMBOL_FLAG_TLS_SHIFT;
> + else if (TREE_CODE (decl) == VAR_DECL && DECL_THREAD_LOCAL_P (decl))
> + flags |= TLS_MODEL_EMULATED << SYMBOL_FLAG_TLS_SHIFT;
>else if (targetm.in_small_data_p (decl))
> flags |= SYMBOL_FLAG_SMALL;
>/* ??? Why is DECL_EXTERNAL ever set for non-PUBLIC names? Without
>
> Can't you do
>
> if (TREE_CODE (decl) == VAR_DECL && DECL_THREAD_LOCAL_P (decl))
> {
> if (targetm.have_tls)
> else
> }
Yes, or I can do this:
Index: varasm.c
===
--- varasm.c(revision 151703)
+++ varasm.c(working copy)
@@ -6417,9 +6417,9 @@ default_encode_section_info (tree decl, rtx rtl, i
flags |= SYMBOL_FLAG_FUNCTION;
if (targetm.binds_local_p (decl))
flags |= SYMBOL_FLAG_LOCAL;
- if (targetm.have_tls && TREE_CODE (decl) == VAR_DECL
- && DECL_THREAD_LOCAL_P (decl))
-flags |= DECL_TLS_MODEL (decl) << SYMBOL_FLAG_TLS_SHIFT;
+ if (TREE_CODE (decl) == VAR_DECL && DECL_THREAD_LOCAL_P (decl))
+flags |= (targetm.have_tls ? DECL_TLS_MODEL (decl) : TLS_MODEL_EMULATED)
+ << SYMBOL_FLAG_TLS_SHIFT;
else if (targetm.in_small_data_p (decl))
flags |= SYMBOL_FLAG_SMALL;
/* ??? Why is DECL_EXTERNAL ever set for non-PUBLIC names? Without
I'll test this variant.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #23 from davek at gcc dot gnu dot org 2009-09-16 10:19 --- Created an attachment (id=18595) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18595&action=view) simplified fix After discussion on the -patches list, it seemed sensible to try preserving the precise value of the tls model that gets selected by the emulation, even if it is a bit surprising, so this reworked patch simply removes the targetm.have_tls test altogether. Now running bootstrap-and-test cycle. -- davek at gcc dot gnu dot org changed: What|Removed |Added Attachment #18588|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #25 from davek at gcc dot gnu dot org 2009-09-16 10:51 --- (In reply to comment #24) > As the __emul* decls are using TLS_MODEL_EMULATED, this patch might make even > their SYMBOL_REFs start using that TLS model. But, unlike the user vars, > these > occur normally in the instruction stream, so I wonder if this patch won't > break > things. Perhaps we shouldn't set SYMBOL_REF_TLS_MODEL if DECL_TLS_MODEL is > TLS_MODEL_EMULATED, otherwise it risks that e.g. backends reject it as invalid > constant. Yes, I see what you mean. There are a lot of references to every other kind of TLS_MODEL_xxx value in the backend files, but no mentions of TLS_MODEL_EMULATED. And just to pick one example: xtensa_legitimize_tls_address() will gcc_unreachable() if it sees that value. So I'll give it one more try, adding a check that the decl's model isn't _EMULATED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug debug/41357] libgomp build fail
--- Comment #26 from davek at gcc dot gnu dot org 2009-09-16 10:54 --- Created an attachment (id=18596) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18596&action=view) YA respin don't copy tls model into rtl flags for TLS_MODEL_EMULATED, only other values. -- davek at gcc dot gnu dot org changed: What|Removed |Added Attachment #18595|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug middle-end/41357] libgomp build fail
--- Comment #27 from davek at gcc dot gnu dot org 2009-09-16 21:10 --- This is not really specific to debug info after all, and since tls doesn't have its own category, I think middle-end is the best description of this bug. Just about to post test results from final respin, only check-target-libffi left to go. -- davek at gcc dot gnu dot org changed: What|Removed |Added Component|debug |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug middle-end/41357] libgomp build fail
--- Comment #28 from davek at gcc dot gnu dot org 2009-09-16 21:29 --- Subject: Bug 41357 Author: davek Date: Wed Sep 16 21:29:17 2009 New Revision: 151773 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151773 Log: PR middle-end/41357 * varasm.c (default_encode_section_info): Copy TLS model into sym_ref flags regardless of backend support for TLS, for all model types except TLS_MODEL_EMULATED. Modified: branches/cygwin-improvements/gcc/ChangeLog.cygwin-improvements branches/cygwin-improvements/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug bootstrap/41404] New: expr.c undefined reference while linking jc1
Bootstrap fails with: > java/expr.o:expr.c:(.debug_loc+0x7d61): undefined reference to `LASF74' Configured tr...@151860 with: /gnu/gcc/gcc-unpatched/configure '--prefix=/opt/gcc-tools' '-v' '--with-gmp=/usr' '--with-mpfr=/usr' '--enable-bootstrap' '--enable-version-specific-runtime-libs' '--enable-static' '--enable-shared' '--enable-shared-libgcc' '--disable-__cxa_atexit' '--with-gnu-ld' '--with-gnu-as' '--with-dwarf2' '--disable-sjlj-exceptions' '--disable-symvers' '--enable-libjava' '--enable-interpreter' '--program-suffix=-4' '--enable-libgomp' '--enable-libssp' '--disable-libada' '--enable-threads=posix' '--with-arch=i686' '--with-tune=generic' 'CC=gcc-4' 'CXX=g++-4' 'CC_FOR_TARGET=gcc-4' 'CXX_FOR_TARGET=g++-4' '--with-ecj-jar=/usr/share/java/ecj.jar' 'LD=/opt/gcc-tools/bin/ld.exe' 'LD_FOR_TARGET=/opt/gcc-tools/bin/ld.exe' 'AS=/opt/gcc-tools/bin/as.exe' 'AS_FOR_TARGET=/opt/gcc-tools/bin/as.exe' '--disable-win32-registry' '--disable-libgcj-debug' '--enable-languages=c,c++,java,objc,obj-c++' 2>&1 | tee conf.log -- Summary: expr.c undefined reference while linking jc1 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: davek at gcc dot gnu dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug debug/41340] [4.5 Regression] G++ produces different code with and without -g option
--- Comment #2 from davek at gcc dot gnu dot org 2009-09-19 09:20 --- Unsurprisingly, adding -g0 to the build line results in an expr.o without the undefined reference. /gnu/gcc/obj.no.pr41357/./prev-gcc/xgcc -B/gnu/gcc/obj.no.pr41357/./prev-gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-include-c -g -O2 -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 -I ../gcc -Ijava -I/gnu/gcc/gcc-unpatched/gcc -I/gnu/gcc/gcc-unpatched/gcc/java -I/gnu/gcc/gcc-unpatched/gcc/../include -I/gnu/gcc/gcc-unpatched/gcc/../libcpp/include -I/usr/include -I/usr/include -I/gnu/gcc/gcc-unpatched/gcc/../libdecnumber -I/gnu/gcc/gcc-unpatched/gcc/../libdecnumber/dpd -I../libdecnumber /gnu/gcc/gcc-unpatched/gcc/java/expr.c -o java/expr.o --save-temps -g0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41340
[Bug debug/41340] [4.5 Regression] G++ produces different code with and without -g option
--- Comment #3 from davek at gcc dot gnu dot org 2009-09-19 09:21 --- (In reply to comment #2) > Unsurprisingly, Oops, sorry, wrong PR! I was on the wrong browser tab. Apologies. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41340
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #1 from davek at gcc dot gnu dot org 2009-09-19 09:21 --- Unsurprisingly, adding -g0 to the build line results in an expr.o without the undefined reference. /gnu/gcc/obj.no.pr41357/./prev-gcc/xgcc -B/gnu/gcc/obj.no.pr41357/./prev-gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-include-c -g -O2 -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 -I ../gcc -Ijava -I/gnu/gcc/gcc-unpatched/gcc -I/gnu/gcc/gcc-unpatched/gcc/java -I/gnu/gcc/gcc-unpatched/gcc/../include -I/gnu/gcc/gcc-unpatched/gcc/../libcpp/include -I/usr/include -I/usr/include -I/gnu/gcc/gcc-unpatched/gcc/../libdecnumber -I/gnu/gcc/gcc-unpatched/gcc/../libdecnumber/dpd -I../libdecnumber /gnu/gcc/gcc-unpatched/gcc/java/expr.c -o java/expr.o --save-temps -g0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #2 from davek at gcc dot gnu dot org 2009-09-19 09:33 ---
This is where the subsequently-undefined reference is being generated:
Will ignore next 72 crossings of breakpoint 1. Continuing.
Hardware watchpoint 1: {} 14169456
Old value = 73
New value = 74
0x004c5fe2 in mem_loc_descriptor ()
(gdb) bt
#0 0x004c5fe2 in mem_loc_descriptor ()
#1 0x004c6926 in loc_descriptor ()
#2 0x004c9e43 in add_location_or_const_value_attribute.clone.13 ()
#3 0x004caa5b in gen_variable_die ()
#4 0x004d250d in gen_decl_die ()
#5 0x004d726e in decls_for_scope ()
#6 0x004d3d05 in gen_subprogram_die ()
#7 0x004d27c0 in gen_decl_die ()
#8 0x0082586f in rest_of_handle_final ()
#9 0x00604685 in execute_one_pass ()
#10 0x006048ec in execute_pass_list ()
#11 0x006048ff in execute_pass_list ()
#12 0x006048ff in execute_pass_list ()
#13 0x007fbe60 in tree_rest_of_compilation ()
#14 0x0060774d in cgraph_expand_function ()
#15 0x00609861 in cgraph_finalize_compilation_unit ()
#16 0x0041f9db in c_write_global_declarations ()
#17 0x0063267c in toplev_main ()
#18 0x00496820 in main ()
(gdb)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #4 from davek at gcc dot gnu dot org 2009-09-19 09:44 ---
Fortunately it even happens when using the stage1 compiler, which has usable
debug info:
(gdb) c 73
Will ignore next 72 crossings of breakpoint 1. Continuing.
Hardware watchpoint 1: dw2_string_counter
Old value = 73
New value = 74
gen_label_for_indirect_string (node=0x7ee82980)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:6849
6849 node->label = xstrdup (label);
(gdb) bt
#0 gen_label_for_indirect_string (node=0x7ee82980)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:6849
#1 0x007b00f3 in get_debug_string_label (str=0x7f15d578 "goto")
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:6862
#2 0x007b9d00 in mem_loc_descriptor (rtl=0x7f23f420, mode=VOIDmode,
initialized=VAR_INIT_STATUS_INITIALIZED)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:11610
#3 0x007ba7ba in loc_descriptor (rtl=0x7f23f420, mode=SImode,
initialized=VAR_INIT_STATUS_INITIALIZED)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:11968
#4 0x007ba0a5 in loc_descriptor (rtl=0x7ebdd810, mode=SImode,
initialized=VAR_INIT_STATUS_INITIALIZED)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:11742
#5 0x007bfd60 in add_location_or_const_value_attribute (die=0x7ef9fb58,
decl=0x7f004bc0, attr=DW_AT_location)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:13769
#6 0x007c7ea8 in gen_variable_die (decl=0x7f004bc0, origin=0x0,
context_die=0x7ef9c940) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:16129
#7 0x007ccb2b in gen_decl_die (decl=0x7f004bc0, origin=0x0,
context_die=0x7ef9c940) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:17388
#8 0x007cb12d in process_scope_var (stmt=0x7f01a020, decl=0x7f004bc0,
origin=0x0, context_die=0x7ef9c940)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:16990
#9 0x007cb1b0 in decls_for_scope (stmt=0x7f01a020, context_die=0x7ef9c940,
depth=0) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:17012
#10 0x007c6df5 in gen_subprogram_die (decl=0x7f6af500, context_die=0x7fcb3f00)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:15853
#11 0x007cc80f in gen_decl_die (decl=0x7f6af500, origin=0x0,
context_die=0x7fcb3f00) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:17323
#12 0x007cd881 in dwarf2out_decl (decl=0x7f6af500)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:17694
#13 0x013c68a5 in rest_of_handle_final ()
at /gnu/gcc/gcc-unpatched/gcc/final.c:4284
#14 0x00b9de10 in execute_one_pass (pass=0x24668e0)
at /gnu/gcc/gcc-unpatched/gcc/passes.c:1295
#15 0x00b9dfb0 in execute_pass_list (pass=0x24668e0)
at /gnu/gcc/gcc-unpatched/gcc/passes.c:1344
#16 0x00b9dfcc in execute_pass_list (pass=0x2464680)
at /gnu/gcc/gcc-unpatched/gcc/passes.c:1345
#17 0x00b9dfcc in execute_pass_list (pass=0x2464640)
at /gnu/gcc/gcc-unpatched/gcc/passes.c:1345
#18 0x012dfc0a in tree_rest_of_compilation (fndecl=0x7f6af500)
at /gnu/gcc/gcc-unpatched/gcc/tree-optimize.c:389
#19 0x00bbfccc in cgraph_expand_function (node=0x7f108b00)
at /gnu/gcc/gcc-unpatched/gcc/cgraphunit.c:1158
#20 0x00bbfe89 in cgraph_expand_all_functions ()
at /gnu/gcc/gcc-unpatched/gcc/cgraphunit.c:1217
#21 0x00bc0452 in cgraph_optimize ()
at /gnu/gcc/gcc-unpatched/gcc/cgraphunit.c:1440
#22 0x00bbf9a9 in cgraph_finalize_compilation_unit ()
at /gnu/gcc/gcc-unpatched/gcc/cgraphunit.c:1087
#23 0x00479c29 in c_write_global_declarations ()
at /gnu/gcc/gcc-unpatched/gcc/c-decl.c:9361
#24 0x00db0ca4 in compile_file () at /gnu/gcc/gcc-unpatched/gcc/toplev.c:1050
#25 0x00db2cbe in do_compile () at /gnu/gcc/gcc-unpatched/gcc/toplev.c:2382
#26 0x00db2d8c in toplev_main (argc=32, argv=0x8079df0)
at /gnu/gcc/gcc-unpatched/gcc/toplev.c:2424
#27 0x006281ed in main (argc=32, argv=0x8079df0)
at /gnu/gcc/gcc-unpatched/gcc/main.c:35
(gdb)
(gdb) print node[0]
$1 = {str = 0x7f23fe18 "goto", refcount = 1, form = 0, label = 0x0}
(gdb)
(gdb) up
#1 0x007b00f3 in get_debug_string_label (str=0x7f15d578 "goto")
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:6862
6862 gen_label_for_indirect_string (node);
(gdb) up
#2 0x007b9d00 in mem_loc_descriptor (rtl=0x7f23f420, mode=VOIDmode,
initialized=VAR_INIT_STATUS_INITIALIZED)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:11610
11610 rtl = get_debug_string_label (XSTR (rtl, 0));
(gdb) call debug_rtx (rtl)
(const_string:SI ("goto"))
(gdb)
That's a touch odd.
ad...@ubik /gnu/gcc/gcc/gcc
$ grep -w goto java/expr.c
goto fail;
ad...@ubik /gnu/gcc/gcc/gcc
$
"goto fail" indeed. Why would a keyword end up as a debug info string?
(preprocessed source on the way)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #5 from davek at gcc dot gnu dot org 2009-09-19 09:49 --- Created an attachment (id=18606) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18606&action=view) unreduced preprocessed source. compile this with: /gnu/gcc/obj.no.pr41357/./stage1-gcc/cc1.exe -fpreprocessed expr.i -quiet -dumpbase expr.c -mtune=generic -march=i686 -auxbase-strip java/expr.o -g -O2 -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 -version -fno-common -o expr.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #6 from davek at gcc dot gnu dot org 2009-09-19 09:56 --- heh, it's my old friend add_location_or_const_value_attribute() from pr41357 (gdb) up #5 0x007bfd60 in add_location_or_const_value_attribute (die=0x7ef9fb58, decl=0x7f004bc0, attr=DW_AT_location) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:13769 13769 descr = loc_by_reference (loc_descriptor (varloc, DECL_MODE(decl), (gdb) print decl $2 = (tree) 0x7f004bc0 (gdb) call debug_tree (decl) unit size align 8 symtab 2144046360 alias set -1 canonical type 0x7fc634f0 precision 8 min max pointer_to_this > sizes-gimplified asm_written public unsigned SI size unit size align 32 symtab 2144046304 alias set -1 canonical type 0x7fc63560 pointer_to_this > unsigned SI file /gnu/gcc/gcc-unpatched/gcc/java/expr.c line 3304 col 15 size unit size align 32 context chain > (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #7 from davek at gcc dot gnu dot org 2009-09-19 10:44 --- Was off-by-one on the rtx, it's actually "ret" not "goto". The refcount of the indirect_string_node goes to zero here, in prune_unused_types_walk_attribs(): (gdb) c Continuing. Hardware watchpoint 5: ((struct indirect_string_node *) 2123651344)->refcount Old value = 2 New value = 0 prune_unused_types_walk_attribs (die=0x7eec09d8) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:18314 18314 for (ix = 0; VEC_iterate (dw_attr_node, die->die_attr, ix, a); ix++) (gdb) bt #0 prune_unused_types_walk_attribs (die=0x7eec09d8) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:18314 #1 0x007cf108 in prune_unused_types_walk (die=0x7eec09d8) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:18472 #2 0x007cf135 in prune_unused_types_walk (die=0x7eec0690) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:18478 #3 0x007cf135 in prune_unused_types_walk (die=0x7fcb3f00) at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:18478 #4 0x007cf38c in prune_unused_types () at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:18579 #5 0x007cfc45 in dwarf2out_finish ( filename=0x80b5288 "/gnu/gcc/gcc-unpatched/gcc/java/expr.c") at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:18758 #6 0x00db0d32 in compile_file () at /gnu/gcc/gcc-unpatched/gcc/toplev.c:1080 #7 0x00db2cbe in do_compile () at /gnu/gcc/gcc-unpatched/gcc/toplev.c:2382 #8 0x00db2d8c in toplev_main (argc=30, argv=0x8079df0) at /gnu/gcc/gcc-unpatched/gcc/toplev.c:2424 #9 0x006281ed in main (argc=30, argv=0x8079df0) at /gnu/gcc/gcc-unpatched/gcc/main.c:35 (gdb) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #9 from davek at gcc dot gnu dot org 2009-09-19 10:56 ---
(In reply to comment #8)
> The "ret" string is shared between some attribute and a value from
> CONST_STRING.
Sorry, as I just figured out I was off by one on that:
(gdb) fin
Run till exit from #0 gen_label_for_indirect_string (node=0x7e945910)
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:6849
get_debug_string_label (str=0x7f15e0b8 "ret")
at /gnu/gcc/gcc-unpatched/gcc/dwarf2out.c:6864
6864 return gen_rtx_SYMBOL_REF (Pmode, node->label);
(gdb) print ((struct indirect_string_node *) 0x7e945910)[0]
$5 = {str = 0x7ff2f498 "ret", refcount = 2, form = 0,
label = 0x8284dc0 "*LASF74"}
(gdb)
> But prune_unused_types_walk_attribs resets the count to 0:
> /* Set the string's refcount to 0 so that prune_unused_types_mark
> accounts properly for it. */
> if (AT_class (a) == dw_val_class_str)
> a->dw_attr_val.v.val_str->refcount = 0;
> and while attributes are walked, location lists are not and thus nothing
> notices it is still used. I'll have to read the prune_unused_types stuff
> carefully to understand how this can be fixed, ideally if we could just
> decrement refcount in prune_unused_types_walk_attribs, as long as we are sure
> it is walked for all attributes, it could fix this. Alternatively we'd have
> to
> walk all location lists as well, looking for labels for strings.
But we're looking at the same suspect here anyway :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #11 from davek at gcc dot gnu dot org 2009-09-19 11:17 --- (In reply to comment #10) > Actually, I think it is wrong how mem_loc_descriptor handles CONST_STRING, I'm > afraid we can't do anything for it, unless we can find such string in the > rodata section of the compilation unit. So rather than write code to index and search all the strings emitted during compilation, I'm giving this a try: Index: dwarf2out.c === --- dwarf2out.c (revision 151860) +++ dwarf2out.c (working copy) @@ -11598,8 +11598,8 @@ mem_loc_descriptor (rtx rtl, enum machine_mode mod break; case CONST_STRING: - rtl = get_debug_string_label (XSTR (rtl, 0)); - goto symref; + /* These can't easily be tracked, see PR41404. */ + break; default: #ifdef ENABLE_CHECKING As might be expected, there is no longer an undefined reference to any debuginfo string in the generated source after this. Shall I take it for a full bootstrap and test? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #12 from davek at gcc dot gnu dot org 2009-09-19 11:34 --- (In reply to comment #10) > we can't do anything for it, unless we can find such string in the > rodata section of the compilation unit. > .LASF74 is a label in .debug_str section, which isn't > allocated, so I wonder what will the debugger do with that anyway. I don't actually understand this (yet), as I don't know why the debugger would need the debug info to be loaded into the inferior's memory; it's not like the .debug_loc section gets allocated either. However I'm perfectly able to go ahead and test a patch without fully understanding that :) if you think just giving up on tracking string values is the way to go. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #14 from davek at gcc dot gnu dot org 2009-09-19 12:32 --- (In reply to comment #13) Thanks for taking the time to explain that. I think the implication of what you're saying is that we can in fact handle strings and just giving up on them is too severe, but we need to decide somewhere a bit further up the call stack whether to use the string itself or the address-of the string as the value in the location table, based on the type of the var_decl; is that about right? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #15 from davek at gcc dot gnu dot org 2009-09-19 13:13 ---
(In reply to comment #14)
> (In reply to comment #13)
>
> Thanks for taking the time to explain that.
>
> I think the implication of what you're saying is that we can in fact handle
> strings and just giving up on them is too severe, but we need to decide
> somewhere a bit further up the call stack whether to use the string itself or
> the address-of the string as the value in the location table, based on the
> type
> of the var_decl; is that about right?
Hmm, maybe not; maybe we should be generating the location notes differently
in the first place.
(gdb) print varloc
$3 = (rtx) 0x7ebdd9b0
(gdb) call debug_rtx(varloc)
(var_location opname (expr_list:REG_DEP_TRUE (const_string:SI ("ret"))
(const_int 0 [0x0])))
(gdb)
If that note held the address of the "ret" string constant we'd be ok. But
I'm not sure if we can get that when we need it, the label we'd need to sym_ref
probably doesn't exist until we actually emit the string pool.
So maybe punting on strings is the best we can do after all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #17 from davek at gcc dot gnu dot org 2009-09-19 16:25 --- (In reply to comment #16) > Patch I sent to improve tree_loc code also has code to lookup constants > in constant pool. For strings in particular this has pretty good chance > of success. I see you wrote: " There was latent bug in that code causing undefined references to constant pool values that was optimized out. This is fixed now. " That sounds like this bug! I'll test your patches against my tree, thanks for the help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #18 from davek at gcc dot gnu dot org 2009-09-19 17:59 --- (In reply to comment #17) > (In reply to comment #16) > > > Patch I sent to improve tree_loc code also has code to lookup constants > > in constant pool. For strings in particular this has pretty good chance > > of success. > > I see you wrote: > > " There was latent bug in that code causing undefined references to constant > pool values that was optimized out. This is fixed now. " > > That sounds like this bug! I'll test your patches against my tree, thanks > for the help. :-( There must be one more latent bug in the code; after applying both the patches you sent today and rebuilding dwarf2out.o and cc1.exe, no difference in the generated source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #20 from davek at gcc dot gnu dot org 2009-09-19 21:20 --- (In reply to comment #19) > Subject: Re: expr.c undefined reference while linking jc1 > > > :-( There must be one more latent bug in the code; after applying both the > > patches you sent today and rebuilding dwarf2out.o and cc1.exe, no > > difference in > > the generated source. > > You would need to add code handling RTL CONST_STRING same way as tree > STRING_CST is handled. If Jakub thinks it makes sense, I can add that. > and indeed, I am quite sure there are number of latent problems in that > :(( What's your timescale for this if you were to do it? If it's likely to take a few days, should we maybe commit something roughly like the patch from comment 11 as a band-aid to get trunk building again and have you remove it again as part of the subsequent patch to handle strings? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug libgomp/41418] New: Can't build libgomp without --enable-languages=fortran
[ ref: http://gcc.gnu.org/ml/gcc/2009-08/msg00085.html ]
> libtool: link: /opt/gcc-tools/i686-pc-cygwin/bin/ar rc .libs/libgomp.lib
> alloc.
> o barrier.o critical.o env.o error.o iter.o iter_ull.o loop.o loop_ull.o
> ordered
> .o parallel.o sections.o single.o task.o team.o work.o lock.o mutex.o proc.o
> sem
> .o bar.o ptrlock.o time.o fortran.o affinity.o
> /opt/gcc-tools/i686-pc-cygwin/bin/ar: .libs/libgomp.lib: File format not
> recogni
> zed
> make[4]: *** [libgomp.la] Error 1
>
> $ file i686-pc-cygwin/libgomp/.libs/libgomp.lib
> i686-pc-cygwin/libgomp/.libs/libgomp.lib: symbolic link to `libgomp-1.dll'
There's one immediately obvious difference in the generated makefiles between
a bad and a good build:
> -#nodist_finclude_HEADERS = omp_lib.h omp_lib.f90 omp_lib.mod
> omp_lib_kinds.mod
> +nodist_finclude_HEADERS = omp_lib.h omp_lib.f90 omp_lib.mod omp_lib_kinds.mod
The good file has the nodist_finclude_HEADERS defined (makes sense), this
adds extra dependencies in the build, and because these files are generated by
running config.status I wonder if there's some kind of either parallel build
missing dependency problem or just a consequence of invoking config.status at a
different time during the build sequence.
In connection with that, I found an interesting difference when comparing two
config.log files (both from successful builds, as it happens):
@@ -1498,3 +1500,21 @@ toolexeclibdir='$(toolexecdir)/$(gcc_ver
#define HAVE_SYNC_BUILTINS 1
configure: exit 0
+
+## -- ##
+## Running config.status. ##
+## -- ##
+
+This file was extended by GNU OpenMP Runtime Library config.status 1.0, which
w
as
+generated by GNU Autoconf 2.64. Invocation command line was
+
+ CONFIG_FILES=
+ CONFIG_HEADERS =
+ CONFIG_LINKS=
+ CONFIG_COMMANDS =
+ $ ./config.status Makefile depfiles
+
+on ubik
+
+config.status:1233: creating Makefile
+config.status:1446: executing depfiles commands
This also makes me think that there's some uncertainty in exactly how and
where config.status is getting run.
--
Summary: Can't build libgomp without --enable-languages=fortran
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davek at gcc dot gnu dot org
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
[Bug libgomp/41418] Can't build libgomp without --enable-languages=fortran
--- Comment #1 from davek at gcc dot gnu dot org 2009-09-20 14:57 --- Created an attachment (id=18616) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18616&action=view) diffs in generated libtool files This looks like it might be informative. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
[Bug libgomp/41418] Can't build libgomp without --enable-languages=fortran
--- Comment #2 from davek at gcc dot gnu dot org 2009-09-20 14:59 --- Perhaps the two single most salient points from that diff: # Is the compiler the GNU compiler? -with_gcc=no +with_gcc=yes # Whether we are building with GNU ld or not. -with_gnu_ld="no" +with_gnu_ld="yes" Did not having fortran in the mix maybe cause some basic tests of the build tools/environment to be omitted? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
[Bug libgomp/41418] Can't build libgomp without --enable-languages=fortran
--- Comment #4 from davek at gcc dot gnu dot org 2009-09-21 07:53 --- (In reply to comment #3) > First off, do you happen to know whether this is a regression? 'fraid not, I never thought to try this before. > Then, please show more of the build output of the failing build: > everything starting from toplevel target 'configure-target-libgomp'. > You can recreate that with: > rm -rf i686-pc-cygwin/libgomp > make configure-target-libgomp all-target-libgomp Yep, will have to, I only have "make -j" output around right now. > The issue is probably some of the configure tests done in libgomp > coming from Libtool and using the Fortran compiler rather than the C > compiler. I'll get you good-vs-bad logs of configuring and rebuilding target-libgomp and get back to you later today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
[Bug libgomp/41418] Can't build libgomp without --enable-languages=fortran
--- Comment #5 from davek at gcc dot gnu dot org 2009-09-21 17:44 --- Created an attachment (id=18624) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18624&action=view) good rebuild log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
[Bug libgomp/41418] Can't build libgomp without --enable-languages=fortran
--- Comment #6 from davek at gcc dot gnu dot org 2009-09-21 17:44 --- Created an attachment (id=18625) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18625&action=view) bad rebuild log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
[Bug libgomp/41418] Can't build libgomp without --enable-languages=fortran
--- Comment #8 from davek at gcc dot gnu dot org 2009-09-21 17:57 --- Created an attachment (id=18626) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18626&action=view) good config log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
[Bug libgomp/41418] Can't build libgomp without --enable-languages=fortran
--- Comment #9 from davek at gcc dot gnu dot org 2009-09-21 17:57 --- Created an attachment (id=18627) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18627&action=view) bad config log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
[Bug bootstrap/41404] expr.c undefined reference while linking jc1
--- Comment #23 from davek at gcc dot gnu dot org 2009-09-22 01:17 --- Subject: Bug 41404 Author: davek Date: Tue Sep 22 01:17:24 2009 New Revision: 151958 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151958 Log: PR bootstrap/41404 * dwarf2out.c (mem_loc_descriptor): Punt on CONST_STRING until we can handle it correctly. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41404
[Bug middle-end/41357] libgomp build fail
--- Comment #29 from davek at gcc dot gnu dot org 2009-09-22 01:34 --- Subject: Bug 41357 Author: davek Date: Tue Sep 22 01:33:53 2009 New Revision: 151959 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151959 Log: PR middle-end/41357 * varasm.c (default_encode_section_info): Copy TLS model into sym_ref flags regardless of backend support for TLS, for all model types except TLS_MODEL_EMULATED. Modified: trunk/gcc/ChangeLog trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug libgomp/41418] Can't build libgomp without --enable-languages=fortran
--- Comment #11 from davek at gcc dot gnu dot org 2009-09-22 11:54 --- I'll try and get to testing it today, but it'll be late tonight before I can start, I've got to spend the day doing some binutils stuff. Will be back in touch when I know something, thanks for the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41418
[Bug middle-end/41357] libgomp build fail
--- Comment #31 from davek at gcc dot gnu dot org 2009-09-28 05:48 --- (In reply to comment #30) > I still get > > /bin/sh ./libtool --tag CC --mode=link > /usr/local/src/trunk/objdir/./gcc/xgcc > -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/ > -B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem > /usr/local/gnu/i686-pc-cygwin/include -isystem > /usr/local/gnu/i686-pc-cygwin/sys-include-Wall -Werror -Wc,-pthread -g > -O2 > -Wl,-O1 -o libgomp.la -version-info 1:0:0 -no-undefined -bindir > "/usr/local/gnu/bin" -rpath /usr/local/gnu/lib/gcc/i686-pc-cygwin/4.5.0 > alloc.lo barrier.lo critical.lo env.lo error.lo iter.lo iter_ull.lo loop.lo > loop_ull.lo ordered.lo parallel.lo sections.lo single.lo task.lo team.lo > work.lo lock.lo mutex.lo proc.lo sem.lo bar.lo ptrlock.lo time.lo fortran.lo > affinity.lo > libtool: link: rm -fr .libs/libgomp.dll.a > libtool: link: /usr/local/src/trunk/objdir/./gcc/xgcc > -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/ > -B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem > /usr/local/gnu/i686-pc-cygwin/include -isystem > /usr/local/gnu/i686-pc-cygwin/sys-include-shared .libs/alloc.o > .libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o .libs/iter.o > .libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o > .libs/parallel.o > .libs/sections.o .libs/single.o .libs/task.o .libs/team.o .libs/work.o > .libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o > .libs/ptrlock.o > .libs/time.o .libs/fortran.o .libs/affinity.o-pthread -Wl,-O1 -o > .libs/cyggomp-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib > -Xlinker > .libs/libgomp.dll.a > xgcc: unrecognized option '-pthread' > Creating library file: > .libs/libgomp.dll.a.libs/team.o:team.c:(.debug_info+0x1084): undefined > reference to `_gomp_tls_data' > collect2: ld returned 1 exit status > > make[4]: *** [libgomp.la] Error 1 Yeah, confirmed at r.152230; this bug is not yet fixed. Note that it's a different .o file from those mentioned in the original error. Haven't yet debugged it to see how it's going wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug target/41512] New: dllexport broken on cygwin
These new FAILs have been appearing on trunk since some time between 20090820
and 20090903:
FAIL: g++.dg/ext/dllexport-MI1.C scan-assembler -export:_ZNK2D12vfEv
FAIL: g++.dg/ext/dllexport-MI1.C scan-assembler -export:_ZNK2D22vfEv
FAIL: g++.dg/ext/dllexport-MI1.C scan-assembler -export:_ZNK3MI12vfEv
FAIL: g++.dg/ext/dllexport-MI1.C scan-assembler -export:_ZTV2D1,data
FAIL: g++.dg/ext/dllexport-MI1.C scan-assembler -export:_ZN2D2C2ERKS_
FAIL: g++.dg/ext/dllexport1.C scan-assembler -export:_ZN3Bar10inline_barEi
(Refs: http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg02276.html
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00356.html )
They seem to represent serious breakage of dllexport with cygwin as the latest
testrun with my libstdc-as-dll patch is showing even more fails on top of
these, but didn't fail before they appeared, and a quick investigation shows
that the executables generated during the testsuite fail to import anything
from the libstdc DLL!
This could be either a target or a C++ problem since they both co-operate to
manage the dllexport attribute. I couldn't find any changes in that area of
the backend in the relevant date range, so I've marked it C++ for now. I'll
attach preprocessed source for the testcase shortly.
--
Summary: dllexport broken on cygwin
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davek at gcc dot gnu dot org
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41512
[Bug middle-end/41485] [4.5 Regressions] ld: (Warning) Unsatisfied symbol "gomp_tls_data"
--- Comment #2 from davek at gcc dot gnu dot org 2009-09-30 03:28 --- Hi John, What kind of TLS do you have on your platform? Also, does reverting the patch help you any, or do you just end up with the failures that were showing in bug 41357? That PR is still open because the fix didn't keep it fixed for very long, although it repaired bootstrap on the trunk revision I tested it against it wasn't long before it stopped working again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41485
[Bug target/41512] dllexport broken on cygwin
--- Comment #1 from davek at gcc dot gnu dot org 2009-09-30 03:32 --- Created an attachment (id=18669) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18669&action=view) testcase source compiled by gcc HEAD -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41512
[Bug target/41512] dllexport broken on cygwin
--- Comment #2 from davek at gcc dot gnu dot org 2009-09-30 03:33 --- Created an attachment (id=18670) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18670&action=view) same testcase compiled with gcc 4.3.4 Note the differences in the "-export: " directives in the .drectve section at the end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41512
[Bug c++/41512] dllexport broken on cygwin
--- Comment #3 from davek at gcc dot gnu dot org 2009-09-30 03:40 --- Switching to c++ as I suggested initially, there were changes to the handling of vague linkage and global declarations within the same period, and as I mentioned nothing that seemed relevant in the backend. -- davek at gcc dot gnu dot org changed: What|Removed |Added Component|target |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41512
[Bug middle-end/41485] [4.5 Regressions] ld: (Warning) Unsatisfied symbol "gomp_tls_data"
--- Comment #3 from davek at gcc dot gnu dot org 2009-09-30 13:50 --- Comment 32 in bug 41357 says that that bug has now gone away again as of r.152325; I haven't had time to verify that myself yet but perhaps that one will work for you also? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41485
[Bug middle-end/41485] [4.5 Regressions] ld: (Warning) Unsatisfied symbol "gomp_tls_data"
--- Comment #5 from davek at gcc dot gnu dot org 2009-09-30 14:10 --- (In reply to comment #4) > It uses GCC's emulated TLS support (don't support HP's TLS implementation). > There were no libgomp failures prior to the change: > http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02555.html Right, thank you. > While I know that the change introduced the failures, I haven't tried > reverting the change with the current head. > > The same failures do not occur on the 32-bit hppa2.0w-hp-hpux11.11 target. > It also uses GCC's emulated TLS support. I would guess that this has > something to do with hppa64-hp-hpux11.11 using dwarf debug support and > hppa2.0w-hp-hpux11.11 using stabs. Hmm, that suggests a horrible workaround where we only copy the flags into the rtl in the case of dwarf debug info: Index: gcc/varasm.c === --- gcc/varasm.c(revision 152317) +++ gcc/varasm.c(working copy) @@ -6416,6 +6416,7 @@ default_encode_section_info (tree decl, rtx rtl, i if (targetm.binds_local_p (decl)) flags |= SYMBOL_FLAG_LOCAL; if (TREE_CODE (decl) == VAR_DECL && DECL_THREAD_LOCAL_P (decl) + && (write_symbols == DWARF2_DEBUG || write_symbols == VMS_AND_DWARF2_DEBUG) && DECL_TLS_MODEL (decl) != TLS_MODEL_EMULATED) flags |= DECL_TLS_MODEL (decl) << SYMBOL_FLAG_TLS_SHIFT; else if (targetm.in_small_data_p (decl)) Would anyone like to give that a try and see if it does the job? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41485
