[Bug driver/35300] References to original ${prefix} paths in relocated toolchain and /lib and /usr/lib search paths appear in cross toolchain.
--- Comment #7 from kkylheku at gmail dot com 2008-02-23 08:03 --- Both my patches apply even if Carlos' patches are removed. The crti.o problem remains. What's happening is that xgcc actually searches for the crti.o module, and then passes the full path to crti.o down to collect2 if it finds it. It looks like in the case when crti.o is not found, it simply passes the unprefixed name crti.o down to collect2, which bounces the arguments down to the linker and so it fails there. I made the compiler too smart :) so that even the intermediate stage xgcc restricts its search paths to its own installation. It thinks that its own temporary installation contains the sysroot, when in fact it should be ``breaking the rules'' and using the absolute path to the sysroot. I think that I'm hacking in the right direction here; there just has to be logic to have no path translation during staging. I have an idea, which I think is the cleanest solution for me. During the building of a shared gcc, quite simply, you have to fake out a miniature sysroot within gcc's own build directory. This is done by copyinig some files from the real sysroot (like crti.o, and some others) into the location where xgcc will expect them. This way there are no hacks in gcc itself to have a different search strategy during staging. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
[Bug driver/35300] References to original ${prefix} paths in relocated toolchain and /lib and /usr/lib search paths appear in cross toolchain.
--- Comment #8 from kkylheku at gmail dot com 2008-02-23 08:54 --- I ended up doing the symlink trick because quite a bit of the sysroot material is needed to build everything, like libstdc++. It worked like a charm. And so now I have a compiler with search paths only in its own tree. Check this out: $ toolchain2/mips64-linux/bin/mips64-linux-gcc -print-search-dirs install: /data/work/main-trunk/ZeugmaLinux/toolchain/mips64-linux/lib/gcc/mips64-linux/4.1.1/ programs: =/toolchain2/mips64-linux/bin/../libexec/gcc/mips64-linux/4.1.1/:/toolchain2/mips64-linux/bin/../libexec/gcc/:/toolchain2/mips64-linux/bin/../libexec/gcc/mips64-linux/4.1.1/:/toolchain2/mips64-linux/bin/../libexec/gcc/mips64-linux/4.1.1/:/toolchain2/mips64-linux/bin/../libexec/gcc/mips64-linux/:/toolchain2/mips64-linux/bin/../lib/gcc/mips64-linux/4.1.1/:/toolchain2/mips64-linux/bin/../lib/gcc/mips64-linux/:/toolchain2/mips64-linux/bin/../lib/gcc/mips64-linux/4.1.1/../../../../mips64-linux/bin/mips64-linux/4.1.1/:/toolchain2/mips64-linux/bin/../lib/gcc/mips64-linux/4.1.1/../../../../mips64-linux/bin/:/toolchain2/mips64-linux/bin/../lib/gcc/mips64-linux/4.1.1/../../../../mips64-linux/bin/mips64-linux/4.1.1/:/toolchain2/mips64-linux/bin/../lib/gcc/mips64-linux/4.1.1/../../../../mips64-linux/bin/ libraries: =/toolchain2/mips64-linux/bin/../lib/gcc/mips64-linux/4.1.1/:/toolchain2/mips64-linux/bin/../lib/gcc/:/toolchain2/mips64-linux/bin/../lib/gcc/mips64-linux/4.1.1/:/toolchain2/mips64-linux/bin/../lib/gcc/mips64-linux/4.1.1/../../../../mips64-linux/lib/mips64-linux/4.1.1/:/toolchain2/mips64-linux/bin/../lib/gcc/mips64-linux/4.1.1/../../../../mips64-linux/lib/:/toolchain2/mips64-linux/bin/../lib/gcc/mips64-linux/4.1.1/../../../../mips64-linux/lib/mips64-linux/4.1.1/:/toolchain2/mips64-linux/bin/../lib/gcc/mips64-linux/4.1.1/../../../../mips64-linux/lib/:/toolchain2/mips64-linux/bin/../mips64-linux/root/lib/mips64-linux/4.1.1/:/toolchain2/mips64-linux/bin/../mips64-linux/root/lib/:/toolchain2/mips64-linux/bin/../mips64-linux/root/usr/lib/mips64-linux/4.1.1/:/toolchain2/mips64-linux/bin/../mips64-linux/root/usr/lib/ The install: line reveals where I built the compiler: in the directory /data/work/main-trunk/... All other paths nicely begin with /toolchain2 where I copied the whole toolchain. (Actually I cheated; /toolchain2 it's a loopback NFS mount that points under /data/work, but that's beside the point). Before building GCC, I created a symlink: $GCC_BUILD_DIR/mips64-linux/root The mips64-linux/root is my relative path to the sysroot within a toolchain. So I just made this relative path work relative to the build directory, as a symlink to the real sysroot. Presto; xgcc nicely accepted this, and everything built. libgcc_s.so, libstdc++. What to do to close this bug? Someone should investigate the behavior of current gcc maybe. If you build a cross toolchain and relocate it, what is the output of -print-search-dirs? Are all the paths under the toolchain, or do some point back to the original build or install directory? Does a cross-compiling toolchain refer to build machine material in /usr/lib/gcc or /usr/libexec/gcc? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
[Bug target/33281] gfortran crt2.o not found under Vista
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2008-02-23 10:44 --- (In reply to comment #11) As a MinGW administrator, I am dismayed that you consider this __USE_MINGW_ACCESS kludge as a solution to this bug; I would like this particularly nasty kludge to go away, from the MinGW code base, as soon as is practicably possible. You're welcome to contribute and provide a patch that implements your idea of what would we the Right Thing To Do, as long as it doesn't break support of existing MinGW versions. Post your patch to the gcc-patches mailing-list and it will be reviewed. Thanks for helping, FX -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33281
[Bug other/35151] mingw64 is an invalid name
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-02-23 11:07 --- (In reply to comment #0) although it should be removed from any place. It's not used in any other place. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-23 11:07:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35151
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||02/msg01007.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2008-02-21 14:12:02 |2008-02-23 11:08:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug other/35151] mingw64 is an invalid name
--- Comment #2 from nightstrike at gmail dot com 2008-02-23 11:12 ---
Here's an even better way to do it:
Index: configure.ac
===
--- configure.ac(revision 132554)
+++ configure.ac(working copy)
@@ -1010,10 +1010,7 @@ case ${host} in
*-cygwin*)
host_makefile_frag=config/mh-cygwin
;;
- *-mingw32*)
-host_makefile_frag=config/mh-mingw
-;;
- *-mingw64*)
+ *-mingw*)
host_makefile_frag=config/mh-mingw
;;
*-interix*)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35151
[Bug preprocessor/35301] Function macro nesting depth appears to be uncomfortably limited.
--- Comment #2 from _deepfire at feelingofgreen dot ru 2008-02-23 11:56 --- I think this is correct CPP behavior. it only evaluates one level of _ . Interesting, reading the CPP manual[1] gives me an impression that there is at least intent to support nested expansions: You might wonder, #8220;Why mention the prescan, if it makes no difference? And why not skip it and make the preprocessor faster?#8221; The answer is that the prescan does make a difference in three special cases: * Nested calls to a macro. We say that nested calls to a macro occur when a macro's argument contains a call to that very macro. For example, if f is a macro that expects one argument, f (f (1)) is a nested pair of calls to f. The desired expansion is made by expanding f (1) and substituting that into the definition of f. The prescan causes the expected result to happen. Without the prescan, f (1) itself would be substituted as an argument, and the inner use of f would appear during the main scan as an indirect self-reference and would not be expanded. But in my case the nesting is not immediately observable, and therefore requires further body expansion to detect and apply that strategy. I wonder what will be the final call of GCC people on that -- will this use pattern be considered legit-enough to deserve support, or not. 1. http://gcc.gnu.org/onlinedocs/cpp/Argument-Prescan.html#Argument-Prescan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35301
[Bug c++/35311] New: ICE at postreload.c:392 while building webkit on s390
Also reported as http://bugs.debian.org/466613
An ICE appeared twice while trying to build webkit on s390. The first file
fails to build with -O2 but is OK with -O1, for the second file it is just the
opposite.
$ gcc -v
Using built-in specs.
Target: s390-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--disable-libmudflap --with-long-double-128 --enable-checking=release
--build=s390-linux-gnu --host=s390-linux-gnu --target=s390-linux-gnu
Thread model: posix
gcc version 4.2.3 (Debian 4.2.3-1)
$ g++ -c -O2 regexp_object.ii
../../../JavaScriptCore/kjs/regexp_object.cpp: In member function
âKJS::JSObject* KJS::RegExpObjectImp::arrayOfMatches(KJS::ExecState*)
constâ:
../../../JavaScriptCore/kjs/regexp_object.cpp:333: error: insn does not satisfy
its constraints:
(insn 532 533 160 16 (set (reg:SI 2 %r2)
(const_int -1146241297 [0xbbadbeef])) 56 {*movsi_esa} (nil)
(nil))
../../../JavaScriptCore/kjs/regexp_object.cpp:333: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:392
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.2/README.Bugs.
$ g++ -c -O1 regexp_object.ii
= OK
$ g++ -c -O1 debugger.ii
../../../JavaScriptCore/wtf/HashTable.h: In member function âvoid
WTF::HashTableKey, Value, Extractor, HashFunctions, Traits,
KeyTraits::rehash(int) [with Key = int, Value = std::pairint,
KJS::ProtectedPtrKJS::JSValue , Extractor =
WTF::PairFirstExtractorstd::pairint, KJS::ProtectedPtrKJS::JSValue ,
HashFunctions = WTF::IntHashint, Traits =
WTF::PairHashTraitsWTF::HashTraitsint,
WTF::HashTraitsKJS::ProtectedPtrKJS::JSValue , KeyTraits =
WTF::HashTraitsint]â:
../../../JavaScriptCore/wtf/HashTable.h:856: error: insn does not satisfy its
constraints:
(insn 796 797 58 7 (set (reg:SI 2 %r2)
(const_int -1146241297 [0xbbadbeef])) 56 {*movsi_esa} (nil)
(nil))
../../../JavaScriptCore/wtf/HashTable.h:856: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:392
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.2/README.Bugs.
$ g++ -c -O2 debugger.ii
== OK
--
Summary: ICE at postreload.c:392 while building webkit on s390
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joss at debian dot org
GCC build triplet: s390-linux-gnu
GCC host triplet: s390-linux-gnu
GCC target triplet: s390-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35311
[Bug c++/35311] ICE at postreload.c:392 while building webkit on s390
--- Comment #1 from joss at debian dot org 2008-02-23 12:52 --- Created an attachment (id=15212) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15212action=view) First test case (fails with -O2) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35311
[Bug c++/35311] ICE at postreload.c:392 while building webkit on s390
--- Comment #2 from joss at debian dot org 2008-02-23 12:52 --- Created an attachment (id=15213) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15213action=view) Second test case (fails with -O1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35311
[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-02-23 12:57 --- Hi, as I added to the gcc-patches thread, I think GCC is valid to optimize stack alignment on the reduced testcase and it is precisely what is supposed to be done by the code Michael disabled. ABI is not strict about the alignment (or call convention) requirement for local calls, just for external calls. It would be good to know the testcase where the misalignment leads to ICE: it seems that elsewhere we forget to maintain cfun-preferred_stack_boundary when we are expanding the vector code needing the alignment for real. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
[Bug preprocessor/35301] Function macro nesting depth appears to be uncomfortably limited.
--- Comment #3 from joseph at codesourcery dot com 2008-02-23 13:47 --- Subject: Re: Function macro nesting depth appears to be uncomfortably limited. I think GCC aims to implement the version of the rescanning rules described in X3J11/86-196, as posted in Dave Prosser's message included in bug 1565. (This specifies some details the C standard leaves underspecified.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35301
[Bug preprocessor/35312] New: Invalid syntax in PP expressions not diagnosed in strict mode
The following expression violates the syntax but is not diagnosed and rejected with -pedantic-errors, for C90 or C99: extern int x; #if #foo #endif -- Summary: Invalid syntax in PP expressions not diagnosed in strict mode Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: neil at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35312
[Bug preprocessor/35313] New: Valid pp-expression rejected in C99 mode
The following obeys the syntax, semantics and constraints of C99, but is rejected with -pedantic-errors extern int x; #if 0 ? 2,3 : 2 #endif -- Summary: Valid pp-expression rejected in C99 mode Product: gcc Version: 4.1.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: neil at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35313
[Bug preprocessor/35301] Function macro nesting depth appears to be uncomfortably limited.
--- Comment #4 from neil at gcc dot gnu dot org 2008-02-23 14:03 --- To be honest this isn't even a disputed case from what I can see. I doubt you can find a serious C implementation (i.e. tcc etc. doesn't count) that will do what you expect. -- neil at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35301
[Bug other/31569] Install's web page has 0.n when it should be either 4.n or 5.n
--- Comment #3 from rwild at gcc dot gnu dot org 2008-02-23 14:04 --- Subject: Bug 31569 Author: rwild Date: Sat Feb 23 14:04:12 2008 New Revision: 132570 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132570 Log: gcc/: PR documentation/31569 * doc/install.texi2html: Use makeinfo --no-number-sections. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi2html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31569
[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code
--- Comment #11 from matz at gcc dot gnu dot org 2008-02-23 14:08 --- FWIW, Torbjorn: I agree with Honza that it would be very good to see the original testcase that segfaults on darwin. The testcases here are all of the type where it's questionable if the behaviour is really wrong. There were indeed also other reports for darwin where the runtime loaders use of aligned instructions caused problems, but the cause for these problems was different than what I was patching. In particular how could the non-ABI-compliant alignment in 'foo' in these testcase ever lead to a problem in darwins runtime loader? We need to see the real testcase, not something testing something different to give a definitive answer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
[Bug ada/34289] gnatmake -s doesn't work
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2008-02-23 14:28 --- http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00198.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34289
[Bug target/34256] mmx and movd/movq on x86_64
--- Comment #5 from uros at gcc dot gnu dot org 2008-02-23 15:24 --- Subject: Bug 34256 Author: uros Date: Sat Feb 23 15:24:02 2008 New Revision: 132572 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132572 Log: PR target/22076 PR target/34256 * config/i386/mmx.md (*movmode_internal_rex64): Use !y to prevent reload from using MMX registers. (*movmode_internal): Ditto. (*movv2sf_internal_rex64): Ditto. (*movv2sf_internal): Ditto. testsuite/ChangeLog: PR target/22076 PR target/34256 * gcc.target/i386/pr22076.c: New test. * gcc.target/i386/pr34256.c: New test. * gcc.target/i386/vecinit-5.c: New test. * gcc.target/i386/vecinit-6.c: New test. * gcc.target/i386/vecinit-[1-4].c: Check that no MMX register is used. * g++.dg/compat/struct-layout-1.h: Do not include mmintrin.h and xmmintrin.h, define __m64 and __m128 directly. * g++.dg/compat/struct-layout-1_generate.c: Add -mno-mmx for x86. Added: trunk/gcc/testsuite/gcc.target/i386/pr22076.c trunk/gcc/testsuite/gcc.target/i386/pr34256.c trunk/gcc/testsuite/gcc.target/i386/vecinit-5.c trunk/gcc/testsuite/gcc.target/i386/vecinit-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/mmx.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/compat/struct-layout-1.h trunk/gcc/testsuite/g++.dg/compat/struct-layout-1_generate.c trunk/gcc/testsuite/gcc.target/i386/vecinit-1.c trunk/gcc/testsuite/gcc.target/i386/vecinit-2.c trunk/gcc/testsuite/gcc.target/i386/vecinit-3.c trunk/gcc/testsuite/gcc.target/i386/vecinit-4.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34256
[Bug target/22076] Strange code for MMX register moves
--- Comment #9 from uros at gcc dot gnu dot org 2008-02-23 15:24 --- Subject: Bug 22076 Author: uros Date: Sat Feb 23 15:24:02 2008 New Revision: 132572 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132572 Log: PR target/22076 PR target/34256 * config/i386/mmx.md (*movmode_internal_rex64): Use !y to prevent reload from using MMX registers. (*movmode_internal): Ditto. (*movv2sf_internal_rex64): Ditto. (*movv2sf_internal): Ditto. testsuite/ChangeLog: PR target/22076 PR target/34256 * gcc.target/i386/pr22076.c: New test. * gcc.target/i386/pr34256.c: New test. * gcc.target/i386/vecinit-5.c: New test. * gcc.target/i386/vecinit-6.c: New test. * gcc.target/i386/vecinit-[1-4].c: Check that no MMX register is used. * g++.dg/compat/struct-layout-1.h: Do not include mmintrin.h and xmmintrin.h, define __m64 and __m128 directly. * g++.dg/compat/struct-layout-1_generate.c: Add -mno-mmx for x86. Added: trunk/gcc/testsuite/gcc.target/i386/pr22076.c trunk/gcc/testsuite/gcc.target/i386/pr34256.c trunk/gcc/testsuite/gcc.target/i386/vecinit-5.c trunk/gcc/testsuite/gcc.target/i386/vecinit-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/mmx.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/compat/struct-layout-1.h trunk/gcc/testsuite/g++.dg/compat/struct-layout-1_generate.c trunk/gcc/testsuite/gcc.target/i386/vecinit-1.c trunk/gcc/testsuite/gcc.target/i386/vecinit-2.c trunk/gcc/testsuite/gcc.target/i386/vecinit-3.c trunk/gcc/testsuite/gcc.target/i386/vecinit-4.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22076
[Bug target/22076] Strange code for MMX register moves
--- Comment #10 from ubizjak at gmail dot com 2008-02-23 15:33 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||02/msg01026.html Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22076
[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code
--- Comment #12 from matz at gcc dot gnu dot org 2008-02-23 16:15 --- In fact I'm now convinced of the opposite, the testcases here don't show any problem. The non-alignment of RSP at function entry in these cases is not a bug. See the discussions at http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01027.html http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01028.html So we really need a different testcase or this PR is INVALID. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|matz at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
[Bug c++/35275] Operator for embedded class of templetized class isn't found
--- Comment #1 from s__nakayama at infoseek dot jp 2008-02-23 16:20 --- This is a duplicate of #13399. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35275
[Bug middle-end/30610] huge memory consumption with -O3
--- Comment #5 from kcwu at csie dot org 2008-02-23 16:21 --- this issue is resolved in gcc 4.3 20080221 snapshot. $ time gcc43 -O3 -c f5.c -Wall user0m0.418s And the memory usage is less than 10 MB. -- kcwu at csie dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30610
[Bug libfortran/35063] Clean up use of destroy_unit_mutex()
--- Comment #38 from jvdelisle at gcc dot gnu dot org 2008-02-23 16:40 --- Janne, do you want to bring your patch from comment #35 up to date and submit for approval to the lists? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
[Bug fortran/25829] [F2003] Asynchronous IO support
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-02-23 16:48 --- Status: local experimental trunk Front-end has most if not all keywords compiling. DECIMAL= is working all the way through to runtime. WAIT compiles and executes a stub in the runtime with a new st_parameter_wait structure to pass parameters from the front end to the library. The stub is _gfortran_st_wait. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
[Bug pch/35027] too short to be a PCH file warning should be conditional on -Winvalid-PCH
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-23 17:08 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35027
[Bug pch/35027] too short to be a PCH file warning should be conditional on -Winvalid-PCH
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-23 17:08 --- Subject: Bug 35027 Author: pinskia Date: Sat Feb 23 17:08:12 2008 New Revision: 132574 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132574 Log: 2008-02-23 Andrew Pinski [EMAIL PROTECTED] PR pch/35027 * c-pch.c (c_common_valid_pch): Make the too short to be a PCH file warning condtional on -Winvalid-PCH. Modified: trunk/gcc/ChangeLog trunk/gcc/c-pch.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35027
[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code
--- Comment #13 from tege-gcc at swox dot com 2008-02-23 17:09 --- Created an attachment (id=15214) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15214action=view) This is a minimized version of the original faling code. I understand the reasoning about local calls. The problem here is with what *looks* like a local call, the calls to __gmp_mt_recalc_buffer from __gmp_randget_mt. But in a shared library, the Darwin linker will replace these calls with calls to dyld_stub___gmp_mt_recalc_buffer, and that's where the crash happens. One may argue that it is utterly silly to use runtime linker calls when the function is at a known offset in the same object, and that this is an Apple tools bug. I have not read any ABI document for Darwin, so I will rest my case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
[Bug preprocessor/35312] Invalid syntax in PP expressions not diagnosed in strict mode
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 17:16 --- I think this is a dup of bug 22168. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35312
[Bug target/35311] ICE at postreload.c:392 while building webkit on s390
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|major |normal Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35311
[Bug c++/35275] Operator for embedded class of templetized class isn't found
--- Comment #2 from pcarlini at suse dot de 2008-02-23 17:00 --- *** This bug has been marked as a duplicate of 13399 *** -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35275
[Bug c++/13399] G++ 3.3 fails to match the templatized, overloaded operator for subtypes defined in the class template
--- Comment #3 from pcarlini at suse dot de 2008-02-23 17:00 --- *** Bug 35275 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added CC||yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13399
[Bug middle-end/35314] New: [4.2/4.3/4.4 regression] ICE with __builtin_setjmp and -fmudflap
The following valid testcase triggers an ICE since GCC 4.2.0 when compiled
with -fmudflap:
#includesetjmp.h
jmp_buf buf;
void foo(volatile char* p)
{
if (__builtin_setjmp(buf))
*p;
}
bug.c: In function 'foo':
bug.c:6: error: control flow in the middle of basic block 11
bug.c:6: error: control flow in the middle of basic block 11
bug.c:6: internal compiler error: verify_flow_info failed
Please submit a full bug report, [etc.]
--
Summary: [4.2/4.3/4.4 regression] ICE with __builtin_setjmp and -
fmudflap
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35314
[Bug middle-end/35314] [4.2/4.3/4.4 regression] ICE with __builtin_setjmp and -fmudflap
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35314
[Bug driver/35300] References to original ${prefix} paths in relocated toolchain and /lib and /usr/lib search paths appear in cross toolchain.
--- Comment #9 from drow at gcc dot gnu dot org 2008-02-23 17:43 ---
Subject: Re: References to original ${prefix} paths in
relocated toolchain and /lib and /usr/lib search paths appear in
cross toolchain.
On Sat, Feb 23, 2008 at 08:03:34AM -, kkylheku at gmail dot com wrote:
I made the compiler too smart :) so that even the intermediate stage xgcc
restricts its search paths to its own installation. It thinks that its own
temporary installation contains the sysroot, when in fact it should be
``breaking the rules'' and using the absolute path to the sysroot.
I think that I'm hacking in the right direction here; there just has to be
logic to have no path translation during staging.
It sounds to me like you are reinventing --with-build-sysroot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
[Bug c++/35315] New: [4.4 regression] ICE with attribute transparent_union
The following valid code snippet triggers an ICE on mainline:
=
typedef union { int i; } U __attribute__((transparent_union));
static void foo(U) {}
static void foo(int) {}
void bar()
{
foo(0);
}
=
bug.cc: In function 'void bar()':
bug.cc:8: internal compiler error: same canonical type node for different types
anonymous union and U
Please submit a full bug report, [etc.]
--
Summary: [4.4 regression] ICE with attribute transparent_union
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35315
[Bug c++/35315] [4.4 regression] ICE with attribute transparent_union
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35315
[Bug driver/35300] References to original ${prefix} paths in relocated toolchain and /lib and /usr/lib search paths appear in cross toolchain.
--- Comment #10 from drow at gcc dot gnu dot org 2008-02-23 17:45 ---
Subject: Re: References to original ${prefix} paths in
relocated toolchain and /lib and /usr/lib search paths appear in
cross toolchain.
On Sat, Feb 23, 2008 at 08:54:56AM -, kkylheku at gmail dot com wrote:
What to do to close this bug? Someone should investigate the behavior of
current gcc maybe. If you build a cross toolchain and relocate it, what is the
output of -print-search-dirs? Are all the paths under the toolchain, or do
some
point back to the original build or install directory? Does a cross-compiling
toolchain refer to build machine material in /usr/lib/gcc or /usr/libexec/gcc?
I understand that you have to work with 4.1, but the first step is
still to look at HEAD and see what other people have already fixed.
For instance:
/* If not cross-compiling, search well-known system locations. */
if (*cross_compile == '0')
{
#ifndef OS2
add_prefix (exec_prefixes, standard_exec_prefix_1, BINUTILS,
PREFIX_PRIORITY_LAST, 2, 0);
add_prefix (exec_prefixes, standard_exec_prefix_2, BINUTILS,
PREFIX_PRIORITY_LAST, 2, 0);
#endif
add_prefix (startfile_prefixes, standard_exec_prefix_2, BINUTILS,
PREFIX_PRIORITY_LAST, 1, 0);
}
So no, a cross toolchain will not refer to /usr.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35300
[Bug rtl-optimization/33512] Simple bitwise simplification missed
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-23 17:59 --- Subject: Bug 33512 Author: pinskia Date: Sat Feb 23 17:58:48 2008 New Revision: 132575 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132575 Log: 2008-02-23 Andrew Pinski [EMAIL PROTECTED] PR rtl-opt/33512 * simplify-rtx.c (simplify_binary_operation_1): Add simplification of (and X (ior (not X) Y) and (and (ior (not X) Y) X). 2008-02-23 Andrew Pinski [EMAIL PROTECTED] PR rtl-opt/33512 * gcc.dg/and-1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/and-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33512
[Bug c++/35317] New: [4.1/4.2/4.3/4.4 regression] ICE with operator delete[] and ellipsis
The following valid code snippet triggers an ICE since GCC 3.1:
struct A
{
void operator delete[] (void*, ...);
};
bug.cc:2: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.1/4.2/4.3/4.4 regression] ICE with operator delete[]
and ellipsis
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35317
[Bug c++/35317] [4.1/4.2/4.3/4.4 regression] ICE with operator delete[] and ellipsis
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35317
[Bug tree-optimization/33512] Simple bitwise simplification missed
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-02-23 18:02 --- The RTL level has been fixed. The tree level needs fixing still but I am not working on that. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO|33702 | nThis|| AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org URL|http://gcc.gnu.org/ml/gcc- | |patches/2008- | |02/msg01008.html| Status|ASSIGNED|NEW Component|rtl-optimization|tree-optimization Keywords|patch |TREE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33512
[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code
--- Comment #14 from hubicka at gcc dot gnu dot org 2008-02-23 18:05 --- I see. It is quite pity that Darwin's dynamic linker insist on the alignment. I guess it would be worthwhile to try to tell GCC to optimize those calls as local: calling overhead of recursive functions is quite expensive. I will look into this. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
[Bug inline-asm/35318] New: [4.3/4.4 regression] ICE with inline asm in reload
The following valid code snippet triggers an ICE on mainline and 4.3 branch
when compiled with -O:
void foo()
{
double x = 4, y;
__asm__ volatile ( : =r,r (x), =r,r (y) : %0,0 (x), m,r (8));
}
bug.c: In function 'void foo()':
bug.c:5: error: Failure trying to reload:
(nil)
bug.c:5: internal compiler error: in gen_reload, at reload1.c:8043
Please submit a full bug report, [etc.]
--
Summary: [4.3/4.4 regression] ICE with inline asm in reload
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35318
[Bug inline-asm/35318] [4.3/4.4 regression] ICE with inline asm in reload
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35318
[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code
--- Comment #15 from hubicka at gcc dot gnu dot org 2008-02-23 18:10 --- Still, can I ask how does the PLT entry of Darwin look like? It seems a bit weird that recursive call that should not trigger lazy binding will get into code relying on the alignment. Or are some kind of aliases in place? I guess if the function has aliases we will need to disable the optimization since it can be called by one name but recurse to different overwritten name or so. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
[Bug target/35318] [4.3/4.4 regression] ICE with inline asm in reload
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 18:12 --- this works on: Target: i386-apple-darwin8.11.1 Configured with: /Users/apinski/src/local/gcc/configure --prefix=/Users/apinski/local-gcc --disable-multilib Thread model: posix gcc version 4.4.0 20080223 (experimental) [trunk revision 132567] (GCC) -- Pinski -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|inline-asm |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35318
[Bug c++/35319] New: [4.3/4.4 regression] ICE throwing fixed-point types
The following valid code snippet triggers an ICE on mainline and 4.3 branch
when compiled with -O:
===
void foo()
{
throw 0r;
}
===
bug.cc: In function 'void foo()':
bug.cc:3: internal compiler error: in write_type, at cp/mangle.c:1695
Please submit a full bug report, [etc.]
The code was invalid before GCC 4.3.0 and was simply rejected.
--
Summary: [4.3/4.4 regression] ICE throwing fixed-point types
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35319
[Bug c++/35319] [4.3/4.4 regression] ICE throwing fixed-point types
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35319
[Bug c++/35319] [4.3/4.4 regression] ICE throwing fixed-point types
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-02-23 18:17 --- The code also ICEs without -O. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35319
[Bug c++/35316] [4.2/4.3/4.4 regression] ICE with typeof/decltype and bit-fields
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35316
[Bug c++/35316] New: [4.2/4.3/4.4 regression] ICE with typeof/decltype and bit-fields
The following valid code snippet triggers an ICE since GCC 4.2.0:
==
templateint struct A
{
int i : 2;
void foo()
{
typeof(i) j;
}
};
==
bug.cc: In member function 'void Aanonymous ::foo()':
bug.cc:7: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
Also happens with __decltype instead of typeof (on mainline and 4.3 branch).
--
Summary: [4.2/4.3/4.4 regression] ICE with typeof/decltype and
bit-fields
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35316
[Bug c++/35320] [4.1/4.2/4.3/4.4 regression] ICE with invalid friend declaration
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35320
[Bug target/35271] Stack not aligned at mod 16 byte boundary in x86_64 code
--- Comment #16 from tege-gcc at swox dot com 2008-02-23 18:27 --- I don't know how a PLT entry looks like. They use the object format macho, of which I know nothing. Note that the new testcase does not have any recursive calls. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
[Bug c++/35321] New: [4.1/4.2/4.3/4.4 regression] ICE with invalid use of __builtin_offsetof
The following invalid code snippet triggers an ICE since GCC 4.0.0:
=
struct A
{
A operator[] (int);
};
struct B
{
A a;
};
void foo()
{
__builtin_offsetof(B, a[0]);
}
=
bug.cc: In function 'void foo()':
bug.cc:13: internal compiler error: in fold_offsetof_1, at c-common.c:6850
Please submit a full bug report, [etc.]
Before, the code was rejected as __builtin_offsetof was not yet supported.
The problem is related to PR28573.
--
Summary: [4.1/4.2/4.3/4.4 regression] ICE with invalid use of
__builtin_offsetof
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
BugsThisDependsOn: 28573
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35321
[Bug c++/35321] [4.1/4.2/4.3/4.4 regression] ICE with invalid use of __builtin_offsetof
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35321
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #48 from fxcoudert at gcc dot gnu dot org 2008-02-23 18:42
---
Subject: Bug 25477
Author: fxcoudert
Date: Sat Feb 23 18:42:04 2008
New Revision: 132576
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132576
Log:
PR target/25477
* config/darwin-protos.h: Add darwin_patch_builtins prototype.
* config/darwin-ppc-ldouble-patch.def: New file.
* config/rs6000/darwin.h (SUBTARGET_INIT_BUILTINS): New macro.
* config/rs6000/rs6000.c (rs6000_init_builtins): Call
SUBTARGET_INIT_BUILTINS if defined.
* config/darwin.c (darwin_patch_builtin,
darwin_patch_builtins): New functions.
* trans-expr.c (gfc_conv_power_op): Use BUILT_IN_CPOW{F,,L}.
* f95-lang.c (gfc_init_builtin_functions): Define BUILT_IN_CPOW{F,,L}.
* trans.h (gfor_fndecl_math_cpow, gfor_fndecl_math_cpowf,
gfor_fndecl_math_cpowl10, gfor_fndecl_math_cpowl16): Remove.
* trans-decl.c: Likewise.
* gfortran.dg/large_real_kind_2.F90: Split testing of ERF and
ERFC into gfortran.dg/large_real_kind_3.F90.
* gfortran.dg/large_real_kind_3.F90: New test.
Added:
trunk/gcc/config/darwin-ppc-ldouble-patch.def
trunk/gcc/testsuite/gfortran.dg/large_real_kind_3.F90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/darwin-protos.h
trunk/gcc/config/darwin.c
trunk/gcc/config/rs6000/darwin.h
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/f95-lang.c
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/large_real_kind_2.F90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug c/35322] New: [4.2/4.3/4.4 regression] ICE with incomplete macro
The following invalid code snippet triggers an ICE since GCC 4.2.0: = _Pragma(GCC dependency) = bug.c:1: internal compiler error: Segmentation fault Please submit a full bug report, [etc.] A correct error message is issued in the following version: = #pragma GCC dependency = nobug.c:1:23: error: #pragma dependency expects FILENAME or FILENAME -- Summary: [4.2/4.3/4.4 regression] ICE with incomplete macro Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, monitored Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35322
[Bug c/35322] [4.2/4.3/4.4 regression] ICE with incomplete macro
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35322
[Bug libfortran/35063] Clean up use of destroy_unit_mutex()
--- Comment #39 from jb at gcc dot gnu dot org 2008-02-23 18:46 --- (In reply to comment #38) Janne, do you want to bring your patch from comment #35 up to date and submit for approval to the lists? Sure, I hope to get it done withing a few days; assigning to myself. -- jb at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jvdelisle at gcc dot gnu dot|jb at gcc dot gnu dot org |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35063
[Bug c++/35323] New: [4.3/4.4 regression] ICE calling functions with fixed-point type parameter
The following invalid code snippet triggers an ICE on mainline and 4.3 branch:
=
void foo(int);
void bar()
{
foo(1r);
}
=
bug.cc: In function 'void bar()':
bug.cc:5: internal compiler error: in arg_assoc_type, at cp/name-lookup.c:4630
Please submit a full bug report, [etc.]
Before, the code was rejected because fixed-point types weren't supported.
--
Summary: [4.3/4.4 regression] ICE calling functions with fixed-
point type parameter
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35323
[Bug c++/35323] [4.3/4.4 regression] ICE calling functions with fixed-point type parameter
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35323
[Bug preprocessor/35322] [4.2/4.3/4.4 regression] ICE with incomplete macro
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-23 18:51 --- The preprocessor is the one that is crashing and the preprocessor in the case of the #pragma is the one that errors out. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c |preprocessor Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-23 18:51:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35322
[Bug c++/35320] New: [4.1/4.2/4.3/4.4 regression] ICE with invalid friend declaration
The following invalid code snippet triggers an ICE since GCC 3.1:
==
typedef void (func_type)();
struct A
{
friend func_type f : 2;
};
==
bug.cc:5: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
Before, the code was wrongly accepted.
--
Summary: [4.1/4.2/4.3/4.4 regression] ICE with invalid friend
declaration
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35320
[Bug c++/35324] New: [4.1/4.2/4.3/4.4 regression] Invalid argument to sizeof not rejected in template
The following invalid code snippet is accepted since GCC 3.4.0:
=
templateint struct A {};
templatetypename struct B : Asizeof(0=0) {};
=
Before the code was correctly rejected, although the error message
couldn't be printed:
bug.cc:3: sorry, unimplemented: `modop_expr' not supported by dump_expr
bug.cc:3: sorry, unimplemented: `modop_expr' not supported by dump_expr
--
Summary: [4.1/4.2/4.3/4.4 regression] Invalid argument to sizeof
not rejected in template
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: accepts-invalid, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35324
[Bug c++/35324] [4.1/4.2/4.3/4.4 regression] Invalid argument to sizeof not rejected in template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35324
[Bug target/25477] builtin functions should use $LDBL128 suffix on darwin when appropriate
--- Comment #49 from fxcoudert at gcc dot gnu dot org 2008-02-23 19:00 --- To fix this completely, a little bit more work is required to check what should be done for nanl(), which is not handled by current patch. (I don't have time to look into it.) For more information, see http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01035.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Known to fail|4.2.0 4.3.0 4.4.0 |4.2.0 4.3.0 Known to work||4.4.0 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25477
[Bug c++/35325] New: [4.3/4.4 regression] ICE with fixed-point types in template parameter
The following invalid code snippet triggers an ICE on mainline and 4.3 branch:
templateint struct A {};
templatetypename struct B : Asizeof(0=0r) {};
templatetypename struct C : Asizeof(0=0r) {};
bug.cc:5: internal compiler error: in cp_tree_equal, at cp/tree.c:1932
Please submit a full bug report, [etc.]
The bug is related to PR35324.
--
Summary: [4.3/4.4 regression] ICE with fixed-point types in
template parameter
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
BugsThisDependsOn: 35324
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35325
[Bug c++/35325] [4.3/4.4 regression] ICE with fixed-point types in template parameter
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35325
[Bug c++/35326] New: [4.2/4.3/4.4 regression] ICE with stray digraph token
The following invalid code snippet triggers an ICE since GCC 4.2.0: %:%:; bug.cc:1: error: stray '%:%:' in program bug.cc:1: internal compiler error: vector VEC(fs_p,base) index domain error, in restore_input_file_stack at toplev.c:1021 Please submit a full bug report, [etc.] The C frontend doesn't have this problem. Also the version without digraphs is rejected correctly: ##; bug.cc:1: error: stray '##' in program -- Summary: [4.2/4.3/4.4 regression] ICE with stray digraph token Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35326
[Bug c++/35327] New: [4.3/4.4 regression] ICE with invalid constructor
The following invalid code snippet triggers an ICE on mainline and 4.3 branch:
struct A
{
A(int)();
};
templateint void foo(bool b, A a) { b ? a : 0; }
bug.cc:3: error: 'A' declared as function returning a function
bug.cc: In function 'void foo(bool, A)':
bug.cc:6: internal compiler error: in build_target_expr, at cp/tree.c:267
Please submit a full bug report, [etc.]
--
Summary: [4.3/4.4 regression] ICE with invalid constructor
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35327
[Bug c++/35327] [4.3/4.4 regression] ICE with invalid constructor
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35327
[Bug c++/35328] New: ICE with firstprivate variable with invalid destructor
The following invalid code snippet triggers an ICE since GCC 4.2.0 when
compiled with -fopenmp:
struct A
{
~A()();
};
void foo()
{
A a;
#pragma omp parallel firstprivate(a)
;
}
bug.cc:3: error: 'A' declared as function returning a function
bug.cc: In function 'void foo()':
bug.cc:9: internal compiler error: in get_callee_fndecl, at tree.c:6597
Please submit a full bug report, [etc.]
--
Summary: ICE with firstprivate variable with invalid destructor
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored, openmp
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35328
[Bug c++/35329] New: [4.2/4.3/4.4 regression] ICE with invalid template class after #pragma interface
The following invalid code snippet triggers an ICE since GCC 4.2.0:
#pragma implementation
#pragma interface
templatevoid struct A
{
A() {}
};
bug.cc:4: error: 'void' is not a valid type for a template constant parameter
bug.cc: In constructor 'Adeclaration error ::A()':
bug.cc:6: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.2/4.3/4.4 regression] ICE with invalid template class
after #pragma interface
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35329
[Bug c/35330] New: [4.1/4.2/4.3/4.4 regression] ICE with invalid pragma weak
The following invalid code snippet triggers an ICE since GCC 3.1.1: #pragma weak int = foo built-in:0: error: weak declaration of 'int' must be public bug.c:1: internal compiler error: in make_decl_rtl, at varasm.c:1267 Please submit a full bug report, [etc.] Also happens with the C++ frontend. -- Summary: [4.1/4.2/4.3/4.4 regression] ICE with invalid pragma weak Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35330
[Bug c++/35326] [4.2/4.3/4.4 regression] ICE with stray digraph token
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35326
[Bug c/35330] [4.1/4.2/4.3/4.4 regression] ICE with invalid pragma weak
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35330
[Bug c++/35331] New: [4.3/4.4 regression] ICE with invalid specialization of variadic template
The following invalid code snippet triggers an ICE on mainline and 4.3 branch:
templatetypename... struct A;
templatetypename...T struct AT*
{
friend void foo();
};
bug.cc:3: error: parameter packs not expanded with `...':
bug.cc:3: note: 'T'
bug.cc:4: error: parameter packs not expanded with `...':
bug.cc:4: note: 'T'
bug.cc:5: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have error_mark in
maybe_add_class_template_decl_list, at cp/class.c:2540
Please submit a full bug report, [etc.]
--
Summary: [4.3/4.4 regression] ICE with invalid specialization of
variadic template
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35331
[Bug c++/35331] [4.3/4.4 regression] ICE with invalid specialization of variadic template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35331
[Bug c++/35332] New: [4.1/4.2/4.3/4.4 regression] Broken diagnostics for builtins
Broken diagnostics are issued for the following invalid code snippet since
GCC 3.0:
void foo(double x)
{
__builtin_isgreater(x, 0.0)();
__builtin_isless(x, 0.0)();
__builtin_isunordered(x, 0.0)();
}
bug.cc: In function 'void foo(double)':
bug.cc:3: error: '!#'unle_expr' not supported by dump_expr#expression error'
cannot be used as a function
bug.cc:4: error: '!#'unge_expr' not supported by dump_expr#expression error'
cannot be used as a function
bug.cc:5: error: '#'unordered_expr' not supported by dump_expr#expression
error' cannot be used as a function
--
Summary: [4.1/4.2/4.3/4.4 regression] Broken diagnostics for
builtins
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35332
[Bug c++/35332] [4.1/4.2/4.3/4.4 regression] Broken diagnostics for builtins
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35332
[Bug c++/35333] New: [4.1/4.2/4.3/4.4 regression] Broken diagnostic for complex builtin
A broken diagnostic is issued for the following invalid code snippet since
GCC 4.0.0:
void foo(__complex__ double x)
{
__builtin_conj(x)();
}
bug.cc: In function 'void foo(double __complex__)':
bug.cc:3: error: '#'conj_expr' not supported by dump_expr#expression error'
cannot be used as a function
--
Summary: [4.1/4.2/4.3/4.4 regression] Broken diagnostic for
complex builtin
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35333
[Bug c++/35333] [4.1/4.2/4.3/4.4 regression] Broken diagnostic for complex builtin
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35333
[Bug c++/35334] New: [4.1/4.2/4.3/4.4 regression] Broken diagnostic for complex cast
A broken diagnostic is issued for the following invalid code snippet since
at least GCC 2.95.3:
void foo(__complex__ unsigned int i)
{
((__complex__ int)i)();
}
bug.cc: In function 'void foo(unsigned int __complex__)':
bug.cc:3: error: '#'complex_expr' not supported by dump_expr#expression
error' cannot be used as a function
--
Summary: [4.1/4.2/4.3/4.4 regression] Broken diagnostic for
complex cast
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35334
[Bug c++/35335] New: [4.1/4.2/4.3/4.4 regression] Broken diagnostic: 'expr_stmt' not supported by dump_expr
A broken diagnostic is issued for the following invalid code snippet since
GCC 4.0.0:
struct A {};
void foo()
{
A a;
a = ({ { 1; } });
}
bug.cc: In function 'void foo()':
bug.cc:6: error: no match for 'operator=' in 'a = #'expr_stmt' not supported by
dump_expr#expression error'
bug.cc:1: note: candidates are: A A::operator=(const A)
--
Summary: [4.1/4.2/4.3/4.4 regression] Broken diagnostic:
'expr_stmt' not supported by dump_expr
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35335
[Bug c++/35335] [4.1/4.2/4.3/4.4 regression] Broken diagnostic: 'expr_stmt' not supported by dump_expr
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35335
[Bug c++/35336] New: Broken diagnostic: 'bit_field_ref' not supported by dump_expr
A broken diagnostic is issued for the following invalid code snippet since
at least GCC 2.95.3:
struct A
{
int i : 2;
};
void foo(bool b)
{
A a;
(a.i || b)();
}
bug.cc: In function 'void foo(bool)':
bug.cc:9: error: '(((#'bit_field_ref' not supported by dump_expr#expression
error 3u) != 0u) || b)' cannot be used as a function
--
Summary: Broken diagnostic: 'bit_field_ref' not supported by
dump_expr
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35336
[Bug c++/35329] [4.2/4.3/4.4 regression] ICE with invalid template class after #pragma interface
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35329
[Bug middle-end/35306] Missing expression simplication for conditional OR
--- Comment #1 from segher at kernel dot crashing dot org 2008-02-23 19:51
---
(In reply to comment #0)
The following rule is not handled by GCC
(a x) || (a y) === a (x | y)
Perhaps that is because those two expressions aren't equivalent?
But, confirmed, assuming you meant to say that
int bla(int a, int x, int y)
{
return (a x) || (a y);
}
isn't transformed to the equivalent of
int blabla(int a, int x, int y)
{
return !!(a (x | y));
}
This _is_ handled for constant x, y though.
Segher
--
segher at kernel dot crashing dot org changed:
What|Removed |Added
CC||segher at kernel dot
||crashing dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35306
[Bug c++/35338] New: [4.3/4.4 regression] Broken diagnostics for fixed-point types
Broken diagnostics are issued for the following invalid code snippet on mainline and 4.3 branch: int i = 1r; bool b = !1r; bug.cc:1: error: cannot convert '#'fixed_point_type' not supported by dump_type#type error' to 'int' in initialization bug.cc:2: error: could not convert '#'fixed_cst' not supported by dump_expr#expression error' to 'bool' bug.cc:2: error: in argument to unary ! -- Summary: [4.3/4.4 regression] Broken diagnostics for fixed-point types Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: diagnostic, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35338
[Bug c++/35338] [4.3/4.4 regression] Broken diagnostics for fixed-point types
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35338
[Bug middle-end/35307] Missing Simplication for div op
--- Comment #1 from segher at kernel dot crashing dot org 2008-02-23 19:57 --- Not equivalent in the presence of overflow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35307
[Bug middle-end/35307] Missing Simplication for div op
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-02-23 20:00 --- (In reply to comment #1) Not equivalent in the presence of overflow. You mean defined overflow :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35307
[Bug libfortran/24685] real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90)
--- Comment #30 from fxcoudert at gcc dot gnu dot org 2008-02-23 20:10
---
On powerpc-apple-darwin9.2, gfortran.dg/large_real_kind_form_io_2.f90 fails for
that reason:
$ cat a.f90
real(kind=16) :: a,b
character(len=180) :: tmp
b = 8.98846567431157953864652595394501287669662887245e307_16
write (tmp, *) b
read (tmp, *) a
write(*,(G70.55E4)) b
write(*,(G70.55E4)) a
write(*,(G70.55E4)) a-b
if (a /= b) print *, #
end
$ ./bin/gfortran a.f90 ./a.out
0.898846567431157953864652595394512366810E+0308
0.898846567431157953864652595394512366810E+0308
0.110791393256022264271830208461724263440E+0277
#
But, as the following C testcase shows, that's not a gfortran problem, but
rather a libc issue on darwin:
$ cat a.c
#include stdio.h
#include string.h
int main(void) {
long double x, y = 8.98846567431157953864652595394501287669662887245e307L;
char buf[79];
memset (buf, ' ', sizeof(buf));
sprintf (buf, %60.70Lg, y);
puts (buf);
sscanf (buf, %Lg, x);
memset (buf, ' ', sizeof(buf));
sprintf (buf, %60.70Lg, x);
puts (buf);
printf (%60.70Lg\n, x-y);
return 0;
}
$ gcc a.c ./a.out
8.988465674311579538646525953945123668089884894711532863671504057886634e+307
8.988465674311579538646525953945123668089884894711532863671504057886634e+307
1.107913932560222642718302084617242634394213707491304322373697056856707e+276
I have reported that issue to Apple as radar #5761818, we'll see if it is
fixed, but I doubt it (no new PowerPC sold by Apple, and generally little
interest in long double). I have thus XFAILed
gfortran.dg/large_real_kind_form_io_2.f90 on powerpc*-apple-darwin*.
As comment #27 says, this doesn't fail on sparc-solaris, I'm closing this as
INVALID. Please reopen if you have a testcase on another target where the issue
is not due to a faulty libc.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug libfortran/24685] real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90)
--- Comment #31 from fxcoudert at gcc dot gnu dot org 2008-02-23 20:11 --- Subject: Bug 24685 Author: fxcoudert Date: Sat Feb 23 20:10:29 2008 New Revision: 132577 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=132577 Log: PR libfortran/24685 * gfortran.dg/large_real_kind_form_io_2.f90: XFAIL on powerpc*-apple-darwin*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/large_real_kind_form_io_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
Problem with c++ exception handling within shared objects
Hi All,
I have a very subtly problem when linking a shared object that includes the
gcc-runtime to support c++ exceptions, type info, ...
The problem is that the following crashes:
try {
throw cCoreException();
}
// catch(const cUnUsedObjectThatWillNeverBeThrown e)
//{
// (*mcu.mpDebug) Caught! cMy\n;
// (*mcu.mpDebug) e.what() \n;
//}
catch(const cCoreException a)
{
// so far so good //
const char* p = a.what(); // - results in a crash
}
The crash does occur when using:
gcc-4.1, binutils-2.16.1 (compiled for ARM, sjlj-exceptions)
gcc-4.2.1, binutils-2.18 (compiled for ARM, sjlj-exceptions)
The crash not coccurs when using:
gcc-3.4.1, binutils-2.15 (compiled for ARM, sjlj-exceptions)
If I uncommend the lines above the same code works as expected on all tested
compilers.
When linking using the -symbolic switch the code also works.
When I catch a non-reference of cCoreException like:
catch(cCoreException a) // - no const reference
{
// so far so good //
const char* p = a.what();
}
all works perfectly.
For two weeks I try to track down the problem and I have collected all
information in a document:
http://www.obico.de/problem/gcc-runtime.pdf
(It's too much stuff for the mailing list.)
Some background information - What I try to do
I'm working on an exokernel for ARM written c++ in form of a shared object.
I use the default linux linker scripts that produce ELF shared objects without
any changes.
My bootloader loads and relocates the shared object, calls all global
constructors and jumps into the kernel-init function
that executes the code above.
The c++ runtime support is compiled together with the kernel sources.
I'm not using the libgcc_eh.a and libsupc++.a provided by the toolchain
because I think the code is not position independend. - Am I right ???
The libgcc.so and libsupc++.so are also not a solution because this would
require to load and relocate these libraries by my bootloader.
My questions are:
Why does the -symbolic link switch enable the code to work ?
As far I understood the -symbolic switch prevents the .plt section in
the resulting ELF library. Does this influence the c++ exception handling ???
Is there another piece of code required to get the c++ runtime working ?
Please note that I use sjlj exceptions. As far as I know calling global
constructors is enough. - A I right ???
I hope anyone can give me a hint...
Best Regards,
Peer Georgi.
[Bug middle-end/34572] program that built with 4.1.2 fails with 4.2.2
--- Comment #7 from galtgendo at o2 dot pl 2008-02-23 20:17 --- Well, shortly after I reported this bug hardware got upgraded (it was Christmas). Now it's 512MB and gcc 4.2.3. It still fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34572
[Bug c++/35337] New: Broken diagnostic for firstprivate clause
A broken diagnostic is issued for the following invalid code snippet since
GCC 4.2.0:
struct A {};
void foo()
{
#pragma omp parallel firstprivate(A)
;
}
bug.cc: In function 'void foo()':
bug.cc:5: error: '#'type_decl' not supported by dump_expr#expression error'
is not a variable in clause 'firstprivate'
This is related to PR31748 and PR35244.
--
Summary: Broken diagnostic for firstprivate clause
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored, openmp
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
BugsThisDependsOn: 31748,35244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35337
[Bug fortran/35299] scope of variables in statement function do not acquire rank from host
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-02-23 20:22 --- Confirmed. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2008-02-23 20:22:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35299
