[Bug bootstrap/45134] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: internal compiler error: in delete_corresponding_reg_eq_notes, at dce.c:495
--- Comment #2 from dje at gcc dot gnu dot org 2010-07-29 18:33 --- *** Bug 45135 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
[Bug rtl-optimization/45135] DCE ICE on PPC
--- Comment #1 from dje at gcc dot gnu dot org 2010-07-29 18:33 --- *** This bug has been marked as a duplicate of 45134 *** -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45135
[Bug bootstrap/45134] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: internal compiler error: in delete_corresponding_reg_eq_notes, at dce.c:495
--- Comment #1 from dje at gcc dot gnu dot org 2010-07-29 18:32 --- This fails on powerpc-ibm-aix as well: /farm/dje/src/src/gcc/cfg.c: In function 'scale_bbs_frequencies_gcov_type': /farm/dje/src/src/gcc/cfg.c:1109:1: internal compiler error: in delete_corresponding_reg_eq_notes, at dce.c:495 -- dje at gcc dot gnu dot org changed: What|Removed |Added CC| |dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc-apple-darwin9 |*-*-* GCC host triplet|powerpc-apple-darwin9 |*-*-* GCC target triplet|powerpc-apple-darwin9 |powerpc-*-* Keywords||build, ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2010-07-29 18:32:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45134
[Bug rtl-optimization/45135] New: DCE ICE on PPC
The DCE patch for PR rtl-optimization/42575 appears to have introduced a bootstrap failure on PowerPC targets: /farm/dje/src/src/gcc/cfg.c: In function 'scale_bbs_frequencies_gcov_type': /farm/dje/src/src/gcc/cfg.c:1109:1: internal compiler error: in delete_corresponding_reg_eq_notes, at dce.c:495 -- Summary: DCE ICE on PPC Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, build Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dje at gcc dot gnu dot org GCC build triplet: *-*-* GCC host triplet: *-*-* GCC target triplet: powerpc-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45135
[Bug testsuite/42855] FAIL: gcc.dg/tree-ssa/pr42585.c scan-tree-dump-times optimized *
--- Comment #6 from dje at gcc dot gnu dot org 2010-07-21 23:52 --- I think the thread about the patch became confused. First, Janis essentially approved the testsuite patch. Second, Martin commented that the failure probably was due to MOVE_RATIO not defined. The statement caused some misunderstanding. MOVE_RATIO does not need to be defined and the failure is not caused by a missing definition. The default value of MOVE_RATIO (used by PPC and ARM) cause the heuristic to disable the optimization being tested. If the optimization is not expected to occur on some platforms, then the testcase should be disabled as implemented by the patch or the testcase explicitly should set some gcc param that ensures the optimization will occur on all targets. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-07-21 23:52:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42855
[Bug target/43892] PowerPC suboptimal "add with carry" optimization
--- Comment #16 from dje at gcc dot gnu dot org 2010-05-27 01:37 --- >> You have no patience, now do you? > Sure I do. It is just that its been almost a month and from the > description it sounded like an easy fix: > "config/rs6000/rs6000.md would need to add a addcc expander" No you do not have any patience; in fact, your comments are rather obnoxious, such as: "its been almost a month". If you do not know what you are talking about, stop talking. No, it is not an easy fix. The high-level concept and description is simple, the implementation is extremely complex and tedious. >> even though it sounded that the >> initial fix was easy(addcc expander) > >> The fix will be a few thousand lines of patch. Literally. > Oops, just to add a cc expander? Yes. Again, if you do not know the complexity of what you are requesting, get more information instead of acting annoyed that people are not jumping to solve your problem. It is not "just adding" a cc expander. Do you even know what that means or what it involves? For the expander to be effective, the PowerPC port of GCC needs to be taught to track the carry bit, which it currently does not. *ALL* patterns that produce instructions affecting the carry bit must be updated. One cannot add the pattern in isolation. If you do not understand the implications of your request, then *ask* why it is more complicated than you assumed. There is no "simple" fix. The only fix is the ultimate fix: completely propagating the carry bit throughout the PowerPC port. You apparently have not read the documentation to understand the -mcpu= option or the --with-cpu= configure option. You are making a lot of incorrect assumption and assertions, apparently without making any effort to gain some knowledge before you start writing. That really does not encourage anyone to help you, especially when it requires a lot of work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
[Bug regression/43892] PowerPC suboptimal "add with carry" optimization
--- Comment #10 from dje at gcc dot gnu dot org 2010-05-21 00:28 --- > On my mpc8321 it is a big difference(don't have numbers handy). Why would > such a simply insn be a problem performance wise? > I know the kernel still uses the carry insn's for calculating the > Internet checksum. mpc8321 is a relatively simplistic pipeline. Processors like POWER4, 5, 6, 7 may not have the same characteristics. Even with carry bit register renaming, it is an extra input/output to a dedicated resource, an extra register port. XLC currently avoids carry completely for POWER5 and POWER6: .add32carry: add r5,r3,r4 cmpl0,0,r5,r4 addir3,r5,1 bclrBO_IF,CR0_LT ori r3,r5,0x blr One cannot assume that fewer UISA instructions equates with fewer microarchitecture operations and faster performance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #21 from dje at gcc dot gnu dot org 2010-05-20 17:52 --- I tested the patch from comment #14 on top of the DECL_PRESERVE_P patch from PR 44132, which was necessary to get back to a sane level of C++ and libgomp failures on AIX. The DECL_DLLIMPORT_P and DECL_ATTRIBUTES patch did not have any further affect on AIX testsuite results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug regression/43892] PowerPC suboptimal "add with carry" optimization
--- Comment #8 from dje at gcc dot gnu dot org 2010-05-20 14:25 --- Has anyone tested if generating an instruction sequence that uses the carry bit actually improves performance on modern POWER processors? It reduces the number of instructions, which is good when optimizing for size, but that may not necessarily translate to performance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets
--- Comment #19 from dje at gcc dot gnu dot org 2010-05-19 15:40 --- What is the relationship between this bug and PR 44132? Richi and Honza seem to prefer the DECL_PRESERVE_P hack. We will see if Iain's lowering works. I don't think both the decl attribute merging patch and DECL_PRESERVE_P patch are needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
[Bug target/44163] [4.6 Regression] Multiple failures in the objc and libgomp test suites
-- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-18 14:59:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44163
[Bug target/33637] [4.3/4.4/4.5/4.6 Regression] "checking for nm: test: too many arguments" causes "Undefined symbol: __gxx_personality_v0"
--- Comment #10 from dje at gcc dot gnu dot org 2010-05-04 11:41 --- Binutils now fully supports AIX. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P4 |P1 Last reconfirmed|-00-00 00:00:00 |2010-05-04 11:41:11 date|| Target Milestone|4.3.5 |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33637
[Bug bootstrap/43936] [4.6 regression] Revision 158896 fails to bootstrap
--- Comment #4 from dje at gcc dot gnu dot org 2010-04-29 13:29 --- On rs6000, the miscompare seems to start at revision 158633 and a SEGV configuring libgcc at rev 158639. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43936
[Bug bootstrap/43936] [4.6 regression] Revision 158896 fails to bootstrap
--- Comment #3 from dje at gcc dot gnu dot org 2010-04-29 13:25 --- rs6000 also is experiencing stage 2/3 comparison failures on both Linux and AIX. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43936
[Bug rtl-optimization/43892] PowerPC suboptimal "add with carry" optimization
-- dje at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
[Bug rtl-optimization/43892] PowerPC suboptimal "add with carry" optimization
--- Comment #3 from dje at gcc dot gnu dot org 2010-04-26 13:52 --- As Jakub mentioned, i386.md implements the addcc named pattern and rs6000.md does not provide that named pattern yet. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|i686-pc-linux-gnu |powerpc-*-* Last reconfirmed|-00-00 00:00:00 |2010-04-26 13:52:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43892
[Bug bootstrap/43391] [4.5 Regression] make_decl_rtl failure for C++ on AIX and HPUX
-- dje at gcc dot gnu dot org changed: What|Removed |Added Summary|make_decl_rtl failure for |[4.5 Regression] |C++ on AIX and HPUX |make_decl_rtl failure for ||C++ on AIX and HPUX Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43391
[Bug bootstrap/43391] New: make_decl_rtl failure for C++ on AIX and HPUX
The patch for GCC PR c/43288 causes C++ bootstrap failure on AIX and HPUX: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00468.html http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00487.html internal compiler error: in make_decl_rtl, at varasm.c:1447 This affects libstdc++ -- Summary: make_decl_rtl failure for C++ on AIX and HPUX Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dje at gcc dot gnu dot org GCC build triplet: *-*-* GCC host triplet: *-*-* GCC target triplet: powerpc-ibm-aix, hppa-*-hpux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43391
[Bug target/42746] AIX ABI defaults to unsigned bitfields
--- Comment #1 from dje at gcc dot gnu dot org 2010-01-14 16:02 --- GCC does provide -funsigned-bitfields but defaults to -fsigned-bitfields. GCC advocates consistency and does not believe this should be an ABI decision because it does not affect object layout. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42746
[Bug target/42746] New: AIX ABI defaults to unsigned bitfields
AIX ABI by default maps all bitfields to unsigned type regardless of their type declaration. GCC does not provide any mechanism to control this behavior. XLC controls this behavior with -qbitfield option. -- Summary: AIX ABI defaults to unsigned bitfields Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dje at gcc dot gnu dot org GCC build triplet: powerpc-ibm-aix GCC host triplet: powerpc-ibm-aix GCC target triplet: powerpc-ibm-aix http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42746
[Bug tree-optimization/42286] October 23rd change to tree-ssa-pre.c breaks calculix on powerpc with -ffast-math
--- Comment #5 from dje at gcc dot gnu dot org 2010-01-05 15:47 --- sqrt(-0) = -0 and 0 is a discontinuity for atan2 Either sqrt should return +0 or atan2 should force +0 if games with signed zeros are allowed. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-05 15:47:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42286
[Bug libstdc++/42349] ifstream vs -pthread on AIX
--- Comment #2 from dje at gcc dot gnu dot org 2009-12-10 14:10 --- > Since there is only one libstdc++ for both with and without threads weird > things will happen. When building GCC on AIX, pthreads is one of the multilib libraries. There is a separate libstdc++ for pthread, so the statement and analysis seem wrong. Are you building GCC with multilibs disabled? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42349
[Bug tree-optimization/41035] AIX cexp builtin underflow
--- Comment #4 from dje at gcc dot gnu dot org 2009-12-09 16:36 --- I think the problem is bad design of MPFR, not a bug in MPC. GCC uses mpfr_clear_flags(), mpfr_overflow_p() and mpfr_underflow_p() for results of computations in both MPFR and MPC, which uses MPFR. These rely on the MPFR global variable __gmpfr_flags. If libmpfr is a static library and libmpc is a shared library, libmpc and GCC will have their own, private copies of __gmpfr_flags. If both libraries are static or both libraries are shared, only one copy of the variable should exist. There sometimes are reasons to have both shared and static libraries and the current interaction creates a hidden dependency between the libraries. I think it would be a much better design to associate the flag with the variable containing the computational result than some global state. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41035
[Bug tree-optimization/41035] AIX cexp builtin underflow
--- Comment #2 from dje at gcc dot gnu dot org 2009-12-09 00:03 --- libmpfr must be a shared object because libmpc relies on hidden, global state in libmpfr. If libmpfr is linked statically with libmpc and with GCC, each receives different instances of the global variables. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41035
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #18 from dje at gcc dot gnu dot org 2009-12-03 19:09 --- Subject: Bug 42243 Author: dje Date: Thu Dec 3 19:09:29 2009 New Revision: 154956 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154956 Log: PR libffi/42243 * src/powerpc/ffi_darwin.c (ffi_prep_args): Remove extra parentheses. Modified: trunk/libffi/ChangeLog trunk/libffi/src/powerpc/ffi_darwin.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #16 from dje at gcc dot gnu dot org 2009-12-03 17:42 --- I found a system and backported the libffi changes. For some reason, Darwin is calculating the stack location of FP arguments wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #15 from dje at gcc dot gnu dot org 2009-12-03 16:32 --- One would not expect __ppc64__ to be defined for -m32. Thanks for the confirmation. I do not have access to a darwin system. Do either of you have enough PPC assembly knowledge to step through libffi/testsuite/libffi.call/return_fl1.c in a debugger? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #13 from dje at gcc dot gnu dot org 2009-12-03 15:20 --- One would assume ... I do not see any differences that should cause the 11 FPR return value tests to fail on Darwin but not AIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #10 from dje at gcc dot gnu dot org 2009-12-03 13:56 --- The only unique change was in ffitarget.h: #elif defined (POWERPC_DARWIN) && defined (__ppc64__) /* Darwin */ #define POWERPC64 Does Darwin define __ppc64__ in 32 bit mode on 64 bit systems? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug libffi/42243] [4.5 Regression] powerpc-apple-darwin9 libffi failures
--- Comment #9 from dje at gcc dot gnu dot org 2009-12-03 13:46 --- Bootstrap is fixed, but mysterious libffi failures remain. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Component|bootstrap |libffi Resolution|FIXED | Summary|[4.5 Regression] powerpc- |[4.5 Regression] powerpc- |apple-darwin9 bootstrap |apple-darwin9 libffi |broken at ffi_darwin.c |failures http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug bootstrap/42243] [4.5 Regression] powerpc-apple-darwin9 bootstrap broken at ffi_darwin.c
--- Comment #6 from dje at gcc dot gnu dot org 2009-12-03 01:44 --- Darwin and AIX share most of the C code and the assembly files are nearly identical for 32 bit support, except for the format of calls. The results on AIX now are clean. I cannot see any reason for the difference between the AIX results and the Apple regression tester results. The regression tester results look identical to the results you posted with your long double fix and without my additional patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug libffi/35484] libffi doesn't support AIX 64bit
--- Comment #8 from dje at gcc dot gnu dot org 2009-12-03 01:33 --- The support in GCC trunk now is feature complete and operational. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35484
[Bug bootstrap/42243] [4.5 Regression] powerpc-apple-darwin9 bootstrap broken at ffi_darwin.c
--- Comment #4 from dje at gcc dot gnu dot org 2009-12-02 12:36 --- I believe the bootstrap failure should be fixed. Please let me know about the testsuite results. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug bootstrap/42243] [4.5 Regression] powerpc-apple-darwin9 bootstrap broken at ffi_darwin.c
--- Comment #3 from dje at gcc dot gnu dot org 2009-12-02 12:35 --- Yes -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P1 |P3 Last reconfirmed|-00-00 00:00:00 |2009-12-02 12:35:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42243
[Bug libffi/35484] libffi doesn't support AIX 64bit
--- Comment #7 from dje at gcc dot gnu dot org 2009-12-01 16:52 --- The changes are not available in any version and the changes are not complete. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35484
[Bug libffi/35484] libffi doesn't support AIX 64bit
--- Comment #5 from dje at gcc dot gnu dot org 2009-11-30 23:34 --- Subject: Bug 35484 Author: dje Date: Mon Nov 30 23:34:33 2009 New Revision: 154855 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154855 Log: 2009-11-30 David Edelsohn PR target/35484 * src/powerpc/ffitarget.h (POWERPC64): Define for PPC64 Linux and AIX64. * src/powerpc/aix.S: Implement AIX64 version. * src/powerpc/aix_closure.S: Implement AIX64 version. (ffi_closure_ASM): Use extsb, lha and displament addresses. * src/powerpc/ffi_darwin.c (ffi_prep_args): Implement AIX64 support. (ffi_prep_cif_machdep): Same. (ffi_call): Same. (ffi_closure_helper_DARWIN): Same. Modified: trunk/libffi/ChangeLog trunk/libffi/src/powerpc/aix.S trunk/libffi/src/powerpc/aix_closure.S trunk/libffi/src/powerpc/ffi_darwin.c trunk/libffi/src/powerpc/ffitarget.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35484
[Bug bootstrap/40343] AIX PPC64 libgcc bootstrap miscompare
--- Comment #4 from dje at gcc dot gnu dot org 2009-11-15 23:04 --- It's fixed. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40343
[Bug tree-optimization/41647] New: Early Loop Unrolling control
GCC currently does not provide independent control over early loop unrolling. The early inner loop unrolling complicates Polyhedral analysis. An individual option that Graphite could access would be helpful. -- Summary: Early Loop Unrolling control Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dje at gcc dot gnu dot org GCC build triplet: *-*-* GCC host triplet: *-*-* GCC target triplet: *-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41647
[Bug middle-end/41611] guard variable is emitted even when the guarded symbol isn't
--- Comment #3 from dje at gcc dot gnu dot org 2009-10-06 23:28 --- Yep -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||mark at codesourcery dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-06 23:28:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41611
[Bug ada/41321] Ada runtime not initializing fpu (finit)
--- Comment #2 from dje at gcc dot gnu dot org 2009-09-09 17:57 --- Fixed on mainline. Patch needs to be backported. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.4.0 4.4.1 Known to work||4.5.0 Last reconfirmed|-00-00 00:00:00 |2009-09-09 17:57:31 date|| Target Milestone|--- |4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41321
[Bug target/40677] flag -mmultiple is ignored
--- Comment #8 from dje at gcc dot gnu dot org 2009-09-09 16:59 --- Kumar, If you want this fixed then you or Edmar or someone at Freescale should fix the patch referenced in comment #6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40677
[Bug libfortran/41169] [4.5 regression] libgfortran fails to build on Solaris 10+: '_Imaginary_I' undeclared
--- Comment #2 from dje at gcc dot gnu dot org 2009-08-25 21:32 --- Just follow the style that Steve Ellcey and I used for HPUX and AIX. You basically should be able to take either of our stanzas in inclhack.def and substitute the regex in the "select" line that matches Solaris (and another for Irix). Choose an appropriate "hackname", set "mach" line for Solaris, and use the original text from the header file in test_text. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-25 21:32:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41169
[Bug testsuite/40671] [4.5 Regression] internal compiler error: in extract_insn, at recog.c:2089 on powerpc
--- Comment #4 from dje at gcc dot gnu dot org 2009-08-17 20:21 --- confirmed. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc-apple-darwin9 |powerpc-*-* GCC host triplet|powerpc-apple-darwin9 |powerpc-*-* GCC target triplet|powerpc-apple-darwin9 |powerpc-*-* Last reconfirmed|-00-00 00:00:00 |2009-08-17 20:21:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40671
[Bug tree-optimization/41035] AIX cexp builtin underflow
--- Comment #1 from dje at gcc dot gnu dot org 2009-08-12 17:35 --- This started failing after I started compiling with MPC library. Is this an MPC bug or interaction bug? -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-08-12 17:35:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41035
[Bug tree-optimization/41035] New: AIX cexp builtin underflow
gcc.dg/tortore/builtin-math-5.c /* Check for overflow/underflow. */ TESTIT (cexp, 1e20); TESTIT (cexp, -1e20); produces foof (__builtin_cexpf (__complex__ (1.0002004087734272e+20, 0.0))); foo (__builtin_cexp (__complex__ (1.0e+20, 0.0))); fool (__builtin_cexpl (__complex__ (1.0e+20, 0.0))); foof (__complex__ (0.0, 0.0)); foo (__complex__ (0.0, 0.0)); fool (__complex__ (0.0, 0.0)); underflow for -1e20 test. -- Summary: AIX cexp builtin underflow Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dje at gcc dot gnu dot org GCC build triplet: power-ibm-aix GCC host triplet: powerpc-ibm-aix GCC target triplet: power-ibm-aix http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41035
[Bug target/40677] flag -mmultiple is ignored
--- Comment #6 from dje at gcc dot gnu dot org 2009-07-15 12:50 --- The fix for this actually is more involved. Nathan had a patch last October which exposed similar bootstrap problems. He posted a revised patch http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01103.html -- dje at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg01103.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40677
[Bug target/40677] flag -mmultiple is ignored
--- Comment #5 from dje at gcc dot gnu dot org 2009-07-15 12:38 --- The patch seems reasonable, but it exposes a latent bug in Nathan's mmultiple patch that was not tested because of this bug. This patch should have been tested and posted to the GCC mailinglist referencing this PR. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC| |dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-15 12:38:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40677
[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c
--- Comment #13 from dje at gcc dot gnu dot org 2009-06-30 18:16 --- The failure appears to need a compiler built in 32 bit mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c
--- Comment #12 from dje at gcc dot gnu dot org 2009-06-30 17:01 --- I tried bootstrapping with that patch and it did not solve the bootstrap failure in simplify_subreg. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c
--- Comment #9 from dje at gcc dot gnu dot org 2009-06-30 15:07 --- The traceback leads to the store flag change. (gdb) print op $3 = (rtx) 0x30153558 (gdb) pr (reg:SI 234) (gdb) print innermode $4 = DImode (gdb) print outermode $5 = SImode #0 fancy_abort (file=0x10e8a5b8 "/farm/dje/src/src/gcc/simplify-rtx.c", line=4966, function=0x10e8a7b8 "simplify_subreg") at /farm/dje/src/src/gcc/diagnostic.c:730 #1 0x105d4920 in simplify_subreg (outermode=SImode, op=0x30153558, innermode=DImode, byte=0) at /farm/dje/src/src/gcc/simplify-rtx.c:4965 #2 0x105d6204 in simplify_gen_subreg (outermode=SImode, op=0x30153558, innermode=DImode, byte=0) at /farm/dje/src/src/gcc/simplify-rtx.c:5273 #3 0x1012a0ac in operand_subword (op=0x30153558, offset=0, validate_address=1, mode=DImode) at /farm/dje/src/src/gcc/emit-rtl.c:1394 #4 0x1012a130 in operand_subword_force (op=0x30153558, offset=0, mode=DImode) at /farm/dje/src/src/gcc/emit-rtl.c:1407 #5 0x107abb8c in expand_binop (mode=DImode, binoptab=0x20055a60, op0=0x30153558, op1=0x3000c460, target=0x3015f498, unsignedp=1, methods=OPTAB_WIDEN) at /farm/dje/src/src/gcc/optabs.c:1738 #6 0x105b8318 in emit_store_flag (target=0x3015f498, code=NE, op0=0x30153528, op1=0x3000c450, mode=SImode, unsignedp=1, normalizep=1) at /farm/dje/src/src/gcc/expmed.c:5583 #7 0x105b7144 in emit_store_flag_1 (target=0x3015f498, code=NE, op0=0x301534e0, op1=0x3000c450, mode=DImode, unsignedp=1, normalizep=1) at /farm/dje/src/src/gcc/expmed.c:5310 #8 0x105b75e4 in emit_store_flag (target=0x3015f498, code=NE, op0=0x301534e0, op1=0x3000c450, mode=DImode, unsignedp=1, normalizep=1) at /farm/dje/src/src/gcc/expmed.c:5424 #9 0x105b8944 in emit_store_flag_force (target=0x3015f498, code=NE, op0=0x301534e0, op1=0x3000c450, mode=DImode, unsignedp=1, normalizep=1) at /farm/dje/src/src/gcc/expmed.c:5733 #10 0x103e4a08 in do_store_flag (exp=0x30165780, target=0x3015f498, mode=DImode) at /farm/dje/src/src/gcc/expr.c:9877 #11 0x103ddc58 in expand_expr_real_1 (exp=0x30165780, target=0x3015f498, tmode=DImode, modifier=EXPAND_NORMAL, alt_rtl=0x2ff20348) at /farm/dje/src/src/gcc/expr.c:9109 #12 0x103cc03c in expand_expr_real (exp=0x30165780, target=0x3015f498, tmode=DImode, modifier=EXPAND_NORMAL, alt_rtl=0x2ff20348) at /farm/dje/src/src/gcc/expr.c:7177 #13 0x103bb8f8 in store_expr (exp=0x30165780, target=0x3015f498, call_param_p=0, nontemporal=5) at /farm/dje/src/src/gcc/expr.c:4644 #14 0x103ba000 in expand_assignment (to=0x30158118, from=0x30165780, nontemporal=1240688) at /farm/dje/src/src/gcc/expr.c:4428 #15 0x103df0e0 in expand_expr_real_1 (exp=0x30165820, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /farm/dje/src/src/gcc/expr.c:9256 #16 0x103cc03c in expand_expr_real (exp=0x30165820, target=0x3000c450, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at /farm/dje/src/src/gcc/expr.c:7177 #17 0x108f14e0 in expand_expr (exp=0x30165820, target=0x3000c450, mode=VOIDmode, modifier=EXPAND_NORMAL) at /farm/dje/src/src/gcc/expr.h:542 #18 0x108f30d4 in expand_expr_stmt (exp=0x30165820) at /farm/dje/src/src/gcc/stmt.c:1353 #19 0x108e9a50 in expand_gimple_basic_block (bb=0x3000e558) at /farm/dje/src/src/gcc/cfgexpand.c:2146 #20 0x108ec75c in gimple_expand_cfg () at /farm/dje/src/src/gcc/cfgexpand.c:2586 #21 0x10663db0 in execute_one_pass (pass=0x20094c18) at /farm/dje/src/src/gcc/passes.c:1289 #22 0x106641e8 in execute_pass_list (pass=0x20094c18) at /farm/dje/src/src/gcc/passes.c:1338 #23 0x10918560 in tree_rest_of_compilation (fndecl=0x3008e180) at /farm/dje/src/src/gcc/tree-optimize.c:394 #24 0x108b7b70 in cgraph_expand_function (node=0x30126200) at /farm/dje/src/src/gcc/cgraphunit.c:1097 #25 0x108b7e30 in cgraph_expand_all_functions () at /farm/dje/src/src/gcc/cgraphunit.c:1156 #26 0x108b86d8 in cgraph_optimize () at /farm/dje/src/src/gcc/cgraphunit.c:1379 #27 0x1003851c in c_write_global_declarations () at /farm/dje/src/src/gcc/c-decl.c:9410 #28 0x10002b80 in compile_file () at /farm/dje/src/src/gcc/toplev.c:1037 #29 0x10006060 in do_compile () at /farm/dje/src/src/gcc/toplev.c:2346 #30 0x10006198 in toplev_main (argc=5, argv=0x2ff22444) at /farm/dje/src/src/gcc/toplev.c:2391 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
[Bug bootstrap/40597] Powerpc bootstrap is broken due to changes in expmed.c
--- Comment #8 from dje at gcc dot gnu dot org 2009-06-30 14:50 --- Now I see failures when building libgcc: ../../.././gcc/dp-bit.c: In function '__pack_d': ../../.././gcc/dp-bit.c:268:39: internal compiler error: in simplify_subreg, at simplify-rtx.c:4966 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
[Bug middle-end/39254] [4.4/4.5 Regression] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #14 from dje at gcc dot gnu dot org 2009-06-15 23:06 --- This patch also fixes the gcc.c-torture/compile/pr34688.c failures. RTL-PRE finds RTL with deep LABEL_REFs. When it creates a move, the emit_use and the REG_NOTE on the move itself share RTL. I suspect we need to apply the patch and deal with the fall-out separately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug bootstrap/40343] AIX PPC64 libgcc bootstrap miscompare
--- Comment #1 from dje at gcc dot gnu dot org 2009-06-04 19:27 --- confirmed. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2009-06-04 19:27:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40343
[Bug bootstrap/40343] New: AIX PPC64 libgcc bootstrap miscompare
GCC bootstrap on AIX 5.3 miscompares all ppc64/libgcc files. This appears to be caused by Jakub's rs6000 CFI patch. -- Summary: AIX PPC64 libgcc bootstrap miscompare Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dje at gcc dot gnu dot org GCC build triplet: powerpc-ibm-aix5.3.0.0 GCC host triplet: powerpc-ibm-aix5.3.0.0 GCC target triplet: powerpc-ibm-aix5.3.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40343
[Bug bootstrap/40338] [4.5 Regression] bootstrap comparision fails on 32 bit PA when comparing libgcc objects
--- Comment #7 from dje at gcc dot gnu dot org 2009-06-04 19:25 --- Okay, I think these are separate bugs. The HP-PA error may be due to Alexandre's change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40338
[Bug bootstrap/40338] [4.5 Regression] bootstrap comparision fails on 32 bit PA when comparing libgcc objects
--- Comment #6 from dje at gcc dot gnu dot org 2009-06-04 17:17 --- Alexandre committed the change in revision 148080 and I successfully bootstrapped AIX yesterday with revision 148105. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40338
[Bug bootstrap/40338] [4.5 Regression] bootstrap comparision fails on 32 bit PA when comparing libgcc objects
--- Comment #5 from dje at gcc dot gnu dot org 2009-06-04 17:11 --- Jakub mentioned that Alexandre patch added comparison of libgcc, which may not have been compared before. But I successfully bootstrapped with Alexandre's patch the previous day. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40338
[Bug bootstrap/40338] bootstrap comparision fails on 32 bit PA when comparing libgcc objects
--- Comment #2 from dje at gcc dot gnu dot org 2009-06-04 16:18 --- AIX started miscomparing in libgcc as well. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2009-06-04 16:18:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40338
[Bug debug/40012] [4.5 Regression] Revision 146817 generated bad debug info for local variables
--- Comment #5 from dje at gcc dot gnu dot org 2009-06-02 12:51 --- cfgexpand.c:expand_used_vars() expands and instantiates virtual-stack-vars for INSNs when it walks the partion map: for (i = 0; i < SA.map->num_partitions; i++) { tree var = partition_to_var (SA.map, i); gcc_assert (is_gimple_reg (var)); if (TREE_CODE (SSA_NAME_VAR (var)) == VAR_DECL) expand_one_var (var, true, true); It then instantiates the same virtual-stack-vars in debug DECLs when it calls expand_used_vars_for_block (outer_block, true), which calls /* Expand all variables at this level. */ for (t = BLOCK_VARS (block); t ; t = TREE_CHAIN (t)) if (TREE_USED (t)) expand_one_var (t, toplevel, true); The INSN var is an SSA_NAME and expand_one_stack_var_at() uses the alignment in the DECL; the BLOCK var is not an SSA_NAME and the alignment is computed as the STACK_BOUNDARY. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug debug/40012] [4.5 Regression] Revision 146817 generated bad debug info for local variables
--- Comment #4 from dje at gcc dot gnu dot org 2009-06-01 21:49 --- Local variable debugging is broken for AIX stabs as well. On AIX, the DECL and the insn contain different offsets from virtual-stack-vars for the same variable: (mem/c/i:SI (plus:SI (reg/f:SI 115 virtual-stack-vars) (const_int 8 [0x8])) [0 a+0 S4 A128]) versus (insn 11 10 12 3 ad.c:11 (set (reg:SI 123) (mem/c/i:SI (reg/f:SI 115 virtual-stack-vars) [0 a+0 S4 A32])) -1 (nil)) -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug other/40024] trunk/gcc-4.3/gcc: * emutls.c (emutls_destroy): Don' t fall out of the array bound.
--- Comment #1 from dje at gcc dot gnu dot org 2009-05-21 12:40 --- Confirmed -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org GCC target triplet|i586-pc-mingw32 |i586-pc-mingw32,powerpc-ibm- ||aix Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40024
[Bug bootstrap/39929] [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-apple-darwin9 and powerpc-ibm-aix
--- Comment #3 from dje at gcc dot gnu dot org 2009-04-27 14:19 --- This probably is related to the promoted parameter problem that has appeared on other architectures as well. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||matz at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929
[Bug bootstrap/39929] [4.5 Regression] Bootstrapping fails at stage 1 on powerpc-apple-darwin9 and powerpc-ibm-aix
--- Comment #2 from dje at gcc dot gnu dot org 2009-04-27 13:54 --- This also fails on AIX. On AIX, the error appears as a failure while compiling libobjc/linking.m. A function in cgraphunit.c is being mis-compiled, possibly build_cdtor(). This causes cgraph_build_static_cdtor() to be called with an invalid priority of "-1", instead of 65535. The priority should not be negative. This negative priority value generates an invalid global file function name: _GLOBAL__I_-1_0___objc_linking A function name should not contain a minus sign, which is a syntax error. Recompiling cgarphunit.c without optimization fixes the miscompilation. An incorrect priority is calculated from decl_fini_priority_lookup(), but recompiling tree.c does not change the failure. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC| |dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc-apple-darwin9 |powerpc-apple- ||darwin9,powerpc-ibm-aix GCC host triplet|powerpc-apple-darwin9 |powerpc-apple- ||darwin9,powerpc-ibm-aix GCC target triplet|powerpc-apple-darwin9 |powerpc-apple- ||darwin9,powerpc-ibm-aix Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2009-04-27 13:54:23 date|| Summary|[4.5 Regression]|[4.5 Regression] |Bootstrapping fails at stage|Bootstrapping fails at stage |1 on powerpc-apple-darwin9 |1 on powerpc-apple-darwin9 ||and powerpc-ibm-aix http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929
[Bug libstdc++/39629] [4.5 Regression] Revision 145483 may have caused many failures
--- Comment #5 from dje at gcc dot gnu dot org 2009-04-03 19:48 --- I see similar failures on AIX. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-03 19:48:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39629
[Bug target/38731] Local strings on the stack not aligned
--- Comment #2 from dje at gcc dot gnu dot org 2009-01-05 19:54 --- For example, the following, when declared locally: typedef char Str_30 [31]; Str_30 Str_1_Par_Ref; Str_30 Str_2_Par_Ref; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38731
[Bug target/38731] New: Local strings on the stack not aligned
String variables allocated on the stack on not aligned. -- Summary: Local strings on the stack not aligned Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dje at gcc dot gnu dot org GCC build triplet: powerpc*-*-* GCC host triplet: powerpc*-*-* GCC target triplet: powerpc*-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38731
[Bug tree-optimization/38258] [4.4 regression] IV-opts creating poor code for loop exit test
--- Comment #1 from dje at gcc dot gnu dot org 2008-11-24 21:57 --- Yep. confirmed. -- dje 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-11-24 21:57:44 date|| Summary|IV-opts creating poor code |[4.4 regression] IV-opts |for loop exit test |creating poor code for loop ||exit test http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38258
[Bug target/26397] Program crashes when rethrowing exception
--- Comment #12 from dje at gcc dot gnu dot org 2008-11-06 15:34 --- Subject: Bug 26397 Author: dje Date: Thu Nov 6 15:32:40 2008 New Revision: 141646 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141646 Log: PR target/26397 * config/rs6000/aix.h (LIBSTDCXX_STATIC): Define. cp/ * g++spec.c (LIBSTDCXX_STATIC): New. (lang_spec_driver): Use LIBSTDCXX_STATIC when not shared_libgcc. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/aix.h trunk/gcc/cp/ChangeLog trunk/gcc/cp/g++spec.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26397
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #38 from dje at gcc dot gnu dot org 2008-11-05 15:45 --- I think the AIX testsuite problem is a problem with the testsuite harness. If I compile a trivial Java program with gcj, it works. If I manually compile programs from libjava.lang testsuite, they work. If I manually run the testsuite executables built by the testsuite, they work. But the testsuite reports that execution fails. Where is libjava_load defined? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #29 from dje at gcc dot gnu dot org 2008-11-04 18:33 --- > So I take it that the libgcj linkage failure is fixed, but some other > unrelated > bug now occurs? Sounds like this one needs to be closed. No. "linkage failure" does not mean a link-edit failure. It always has been a runtime failure: "libgcj failure: gcj linkage error." That error now is gone, but we may only have stepped to the next error on these platforms. We can decide if it should continue in this bug or a new bug should be opened. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #19 from dje at gcc dot gnu dot org 2008-11-03 17:35 --- Characterizing this as "testsuite failures" trivializes the problem. libgcj builds but does not work properly on the platforms. This PR should be categorized as P2, not P4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug rtl-optimization/32283] [4.3/4.4 regression] Missed induction variable optimization
--- Comment #18 from dje at gcc dot gnu dot org 2008-10-30 14:49 --- GCC no longer generates branch on count instructions on PowerPC. -- dje at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|arm-none-eabi |arm-none-eabi,powerpc-linux Priority|P3 |P1 Summary|Missed induction variable |[4.3/4.4 regression] Missed |optimization|induction variable ||optimization Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug target/37878] [4.4 regression] PPC64 ldu command generated with invalid offset
--- Comment #13 from dje at gcc dot gnu dot org 2008-10-29 23:33 --- Subject: Bug 37878 Author: dje Date: Wed Oct 29 23:33:02 2008 New Revision: 141450 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141450 Log: PR target/37878 * config/rs6000/predicates.md (word_offset_memref_operand): Restructure code and look inside auto-inc/dec addresses. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/predicates.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37878
[Bug target/37878] [4.4 regression] PPC64 ldu command generated with invalid offset
--- Comment #12 from dje at gcc dot gnu dot org 2008-10-28 23:13 --- Created an attachment (id=16577) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16577&action=view) another refinement Jakub suggested a further refinement to hoist a common sub-expression. -- dje at gcc dot gnu dot org changed: What|Removed |Added Attachment #16576|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37878
[Bug target/37878] [4.4 regression] PPC64 ldu command generated with invalid offset
--- Comment #11 from dje at gcc dot gnu dot org 2008-10-28 22:35 --- Created an attachment (id=16576) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16576&action=view) disallow illegal displacement wrapped in PRE_MODIFY or PRE_INC/DEC I think this patch accomplishes the effect but easier to follow with the address form localized in one place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37878
[Bug java/35485] libjava is disabled by default
--- Comment #4 from dje at gcc dot gnu dot org 2008-10-24 02:45 --- Subject: Bug 35485 Author: dje Date: Fri Oct 24 02:44:26 2008 New Revision: 141335 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141335 Log: PR target/35485 * configure.ac: AIX threads are Posix threads. Set signal handler to aix-signal.h * configure: Regenerate. * classpath/native/fdlibm/fdlibm.h: Undef hz. * include/aix-signal.h: New file. * sysdep/powerpc/locks.h: Avoid GNU Assembler syntax. Added: trunk/libjava/include/aix-signal.h Modified: trunk/libjava/ChangeLog trunk/libjava/classpath/native/fdlibm/fdlibm.h trunk/libjava/configure trunk/libjava/configure.ac trunk/libjava/sysdep/powerpc/locks.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35485
[Bug java/35485] libjava is disabled by default
--- Comment #3 from dje at gcc dot gnu dot org 2008-10-21 17:35 --- Subject: Bug 35485 Author: dje Date: Tue Oct 21 17:33:53 2008 New Revision: 141269 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141269 Log: PR target/35485 * tree.c (get_file_function_name): Copy first_global_object_name. Centralize call to clean_symbol_name. Modified: trunk/gcc/ChangeLog trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35485
[Bug target/37878] [4.4 regression] PPC64 ldu command generated with invalid offset
--- Comment #7 from dje at gcc dot gnu dot org 2008-10-21 15:14 --- Also, note the problem is a DFmode value in a GPR. FPRs can handle the non-word-aligned offset. Forcing all DFmode to be 64 bit aligned is not an option because that is known to impose a severe performance penalty. For non-update form, we have handled this in rs6000_legitimize_reload_address. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37878
[Bug target/37878] [4.4 regression] PPC64 ldu command generated with invalid offset
--- Comment #5 from dje at gcc dot gnu dot org 2008-10-21 14:53 --- The test in rs6000_legitimate_offset_address_p is for something completely different. This should be tested in rs6000_legitimate_address: if (GET_CODE (x) == PRE_MODIFY && mode != TImode && mode != TFmode && mode != TDmode && ((TARGET_HARD_FLOAT && TARGET_FPRS && TARGET_DOUBLE_FLOAT) || TARGET_POWERPC64 || ((mode != DFmode && mode != DDmode) || TARGET_E500_DOUBLE)) && (TARGET_POWERPC64 || mode != DImode) && !ALTIVEC_VECTOR_MODE (mode) && !SPE_VECTOR_MODE (mode) /* Restrict addressing for DI because of our SUBREG hackery. */ && !(TARGET_E500_DOUBLE && (mode == DFmode || mode == DDmode || mode == DImode)) && TARGET_UPDATE && legitimate_indirect_address_p (XEXP (x, 0), reg_ok_strict) && (rs6000_legitimate_offset_address_p (mode, XEXP (x, 1), reg_ok_strict) || legitimate_indexed_address_p (XEXP (x, 1), reg_ok_strict)) && rtx_equal_p (XEXP (XEXP (x, 1), 0), XEXP (x, 0))) return 1; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37878
[Bug java/37068] [4.4 Regression] libgcj linkage failure: Incorrect library ABI version detected
--- Comment #3 from dje at gcc dot gnu dot org 2008-10-16 20:12 --- I see the same failure on AIX that just restored Java support. On AIX, _Jv_CheckABI is invoked with version argument of 0 instead of 404000 GCC version constant. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-16 20:12:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37068
[Bug c++/35483] GCC on AIX doesn't support dollar in symbols name.
--- Comment #10 from dje at gcc dot gnu dot org 2008-10-16 11:58 --- Subject: Bug 35483 Author: dje Date: Thu Oct 16 11:57:26 2008 New Revision: 141170 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141170 Log: gcc/ PR target/35483 * Makefile.in (coverage.o): Depend on $(TM_P_H). * coverage.c: Include tm_p.h. * config/rs6000/x-aix (jc1): Override LDFLAGS. * config/rs6000/xcoff.h (ASM_GENERATE_INTERNAL_LABEL): Strip dollar signs from PREFIX. * config/rs6000/rs6000.c (output_toc): Use RS6000_OUTPUT_BASENAME instead of manual strip_name_encoding. java/ PR target/35483 * Make-lang.in (class.o): Depend on $(TM_P_H). (expr.o): Same. * class.c: Include tm_p.h. * expr.c: Include tm_p.h. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/x-aix trunk/gcc/config/rs6000/xcoff.h trunk/gcc/coverage.c trunk/gcc/java/ChangeLog trunk/gcc/java/Make-lang.in trunk/gcc/java/class.c trunk/gcc/java/expr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35483
[Bug c++/35483] GCC on AIX doesn't support dollar in symbols name.
--- Comment #9 from dje at gcc dot gnu dot org 2008-10-15 16:55 --- Patch committed. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35483
[Bug target/26397] Program crashes when rethrowing exception
--- Comment #11 from dje at gcc dot gnu dot org 2008-10-15 15:34 --- You can try manually linking the program with libsupc++.a as well: http://codesynthesis.com/~boris/blog/2006/12/10/statically-linking-on-aix/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26397
[Bug target/26397] Program crashes when rethrowing exception
--- Comment #9 from dje at gcc dot gnu dot org 2008-10-15 12:29 --- Proper G++ exception handling requires shared libraries. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26397
[Bug c++/35483] GCC on AIX doesn't support dollar in symbols name.
--- Comment #8 from dje at gcc dot gnu dot org 2008-10-15 12:25 --- Subject: Bug 35483 Author: dje Date: Wed Oct 15 12:23:55 2008 New Revision: 141134 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141134 Log: PR target/35483 Based on patches by Laurent Vivier. * xcoffout.h (DBX_FINISH_STABS): Translate dollar sign to underscore. * config/rs6000/rs6000-protos.h (rs6000_xcoff_strip_dollar): Declare. * config/rs6000/xcoff.h (ASM_DECLARE_FUNCTION_NAME): Translate dollar sign to underscore. (ASM_OUTPUT_EXTERNAL): Same. (ASM_OUTPUT_LABELREF): New. * config/rs6000/rs6000.c (rs6000_xcoff_strip_dollar): New. * config/rs6000/aix51.h (TARGET_USE_JCR_SECTION): Define. * config/rs6000/aix52.h (TARGET_USE_JCR_SECTION): Define. * config/rs6000/aix53.h (TARGET_USE_JCR_SECTION): Define. * config/rs6000/aix61.h (TARGET_USE_JCR_SECTION): Define. Modified: trunk/gcc/config/rs6000/aix51.h trunk/gcc/config/rs6000/aix52.h trunk/gcc/config/rs6000/aix53.h trunk/gcc/config/rs6000/aix61.h trunk/gcc/config/rs6000/rs6000-protos.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/xcoff.h trunk/gcc/xcoffout.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35483
[Bug c++/35483] GCC on AIX doesn't support dollar in symbols name.
--- Comment #7 from dje at gcc dot gnu dot org 2008-10-14 17:06 --- Created an attachment (id=16493) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16493&action=view) patch to convert dollar signs to underscores New patch. This patch intercepts the dollar signs at a lower level and correctly handles garbage collection allocations of strings. -- dje at gcc dot gnu dot org changed: What|Removed |Added Attachment #15273|0 |1 is obsolete|| Attachment #15298|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35483
[Bug bootstrap/37733] GCC Bootstrap fails in Stage 2 AIX 5.2
--- Comment #4 from dje at gcc dot gnu dot org 2008-10-12 22:42 --- This probably is the data segment overflow that occurred on mainline with the additional dfa descriptions. For some reason AIX 5.2 is hitting it sooner and on GCC itself. You probably need to add -Wl,-bmaxdata:0x2000 to LDFLAGS. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37733
[Bug c++/35483] GCC on AIX doesn't support dollar in symbols name.
--- Comment #6 from dje at gcc dot gnu dot org 2008-10-02 21:30 --- + strip = (char *)ggc_alloc_string (name, len); + + for (len = 0; name[len]; len++) +if (name[len] == '$') + strip[len] = '_'; +else + strip[len] = name[len]; + strip[len] = 0; + + return strip; It is not safe to edit a ggc_alloc_string-allocated string in place. This should be + strip = (char *)alloca (name, len); ... + return ggc_alloc_string (strip, len); Also, using fixed-size 256 byte buffers is not safe because they can overflow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35483
[Bug c++/35483] GCC on AIX doesn't support dollar in symbols name.
--- Comment #5 from dje at gcc dot gnu dot org 2008-10-02 20:47 --- This patch causes G++ to crash building some applications on AIX. Apparently a version of G++ including this patch is being distributed and users are reporting problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35483
[Bug middle-end/19988] [4.2/4.3/4.4 Regression] pessimizes fp multiply-add/subtract combo
-- dje at gcc dot gnu dot org changed: What|Removed |Added CC||bergner at gcc dot gnu dot ||org Severity|minor |major Priority|P4 |P3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19988
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #30 from dje at gcc dot gnu dot org 2008-09-22 15:17 --- Subject: Bug 33642 Author: dje Date: Mon Sep 22 15:15:56 2008 New Revision: 140551 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140551 Log: PR rtl-optimization/33642 * gcc.c-torture/compile/pr11832.c: Extend XFAIL to powerpc*-*-*. * gcc.c-torture/compile/pr33009.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/pr11832.c trunk/gcc/testsuite/gcc.c-torture/compile/pr33009.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #35 from dje at gcc dot gnu dot org 2008-09-17 12:22 --- User reports successful resolution. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #33 from dje at gcc dot gnu dot org 2008-09-16 20:00 --- I have not tried MPFR as a shared library. One thing to be careful about with shared libraries on AIX is libpath. libtool configured for gmp and mpfr decides to hardcode the path and finds all of the GCC build directory paths. I manually edit the configured libtool to cleanup libpath. libgmp.a and libmpfr.a only need /usr/lib:/lib because they do not depend on shared libgcc.a. libgmpxx.a depends on the directories where libstdc++.a and libgcc_s.a are installed. cc1, cc1plus, etc. generally end up with sane libpaths, but libstdc++ (again built by libtool) includes a lot of junk directories. These latter dependencies would not affect the ICEs when building OpenFOAM, but you might want to be aware for the application itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #31 from dje at gcc dot gnu dot org 2008-09-16 18:34 --- No, I do not use any patches from IBM. The patches seem to be focussed on packaging and layout, but I would recommend using the standard FSF GCC 4.3.2 release plus the pt.c patch that now is upstream in the FSF GCC sources. We cannot help you with a compiler that diverges from the FSF tree. Again, I am not sure which versions of GMP and MPFR you are using. I would recommend that you configure and build those packages with --disable-shared and ABI=32. You also can try running cc1plus inside GDB and compiling the files to see where the ICE occurs. Right now we cannot reproduce the failures and are flying blind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #29 from dje at gcc dot gnu dot org 2008-09-16 17:40 --- I bootstrap GCC using GCC 4.1. I assume you use GCC 4.2 distributed by IBM. I do not understand your comment in the initial report about "forward porting of the 4.2.0 patches." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #28 from dje at gcc dot gnu dot org 2008-09-16 15:52 --- The AIX systems to which I have access also are AIX 5.3.0.0 TL 07. My GCC configure command only specifies the languages and where to find GMP and MRPF. I had been using gmp-4.1.4 static archive library, but recently upgraded to gmp-4.2.3 dynamic library. I am using mpfr-2.3.1 static archive library. I build GCC as a 32 bit application, which is the default. I assume that you are compiling the OpenFOAM as 32 bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #19 from dje at gcc dot gnu dot org 2008-09-14 22:42 --- First, you reported seven ICEs. You attached files for makeChemkinReactions.ii. That file failed before Honza's patch and does not appear to fail after his patch. I cannot reproduce the failure using my version of GCC 4.3.1. Saying that the patch does not fix "the" problem is not accurate. You said that the makeChemkinReactions.ii still was present in GCC 4.3.2, but you report an ICE for chemkinReader.ii. Please stop shifting the goalpost. You have not commented on makeChemkinReactions.ii. No one said that the seven ICEs were do to a single problem. I suspect the makeChemkinReactions.ii ICE *is* fixed. If you attach chemkinReader.ii, we can try to investigate it as well. These likely all are due to garbage collection issues, but not a single bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #17 from dje at gcc dot gnu dot org 2008-09-14 19:52 --- Because the problem is due to garbage collection, it is non-deterministic, depending on what data GCC generates. I was able to reproduce the problem in a recent development version of GCC, prior to Honza's patch, but not in my installed version of GCC 4.3.1, which is why I asked you to confirm that the patch fixes the problem for you. GCC 4.3.2 fixes numerous bugs over GCC 4.3.1, although not necessarily ICEs that affect you. I would recommend using a patched version of GCC 4.3.2 over a patched version of GCC 4.3.1, but that is your decision. -- dje at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #15 from dje at gcc dot gnu dot org 2008-09-14 15:35 --- Honza, I think that your recent pt.c:tsubst_decl() fix coincidentally may have fixed this as well. Tracing the ggc_alloc_stat() calls, struct function only appears to be allocated once, but likely is copied when it should not be. Jørn, Could you try rebuilding GCC 4.3.1 with Honza's patch and report if it fixes your failures? http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00999.html #0 ggc_alloc_stat (size=84) at /farm/dje/src/src/gcc/ggc-page.c:1251 #1 0x100059ac in ggc_alloc_cleared_stat (size=84) at /farm/dje/src/src/gcc/ggc-common.c:132 #2 0x10072b10 in allocate_struct_function (fndecl=0x30119c00, abstract_p=1 '\001') at /farm/dje/src/src/gcc/function.c:3944 #3 0x10562c28 in start_preparsed_function (decl1=0x30119c00, attrs=0x20029648, flags=0) at /farm/dje/src/src/gcc/cp/decl.c:11544 #4 0x10581d78 in start_function (declspecs=0x2006e360, declarator=0x10, attrs=0x0) at /farm/dje/src/src/gcc/cp/decl.c:11727 #5 0x107340e0 in cp_parser_init_declarator (parser=0x304ef230, decl_specifiers=0x2ff21f20, checks=0x0, function_definition_allowed_p=1 '\001', member_p=0 '\0', declares_class_or_enum=806084960, function_definition_p=0x2ff21f18 "\001") at /farm/dje/src/src/gcc/cp/parser.c:17371 #6 0x10735bec in cp_parser_single_declaration (parser=0x304ef230, checks=0x0, member_p=0 '\0', explicit_specialization_p=0 '\0', friend_p=0x2ff21fd8 "") at /farm/dje/src/src/gcc/cp/parser.c:17717 #7 0x10735ed4 in cp_parser_template_declaration_after_export ( parser=0x304ef230, member_p=0 '\0') at /farm/dje/src/src/gcc/cp/parser.c:17570 #8 0x1073d484 in cp_parser_declaration (parser=0x304ef230) at /farm/dje/src/src/gcc/cp/parser.c:7885 #9 0x1073da88 in cp_parser_declaration_seq_opt (parser=0x304ef230) at /farm/dje/src/src/gcc/cp/parser.c:7816 #10 0x1073e7d0 in cp_parser_namespace_definition (parser=0x304ef230) at /farm/dje/src/src/gcc/cp/parser.c:12029 #11 0x1073d390 in cp_parser_declaration (parser=0x304ef230) at /farm/dje/src/src/gcc/cp/parser.c:7917 #12 0x1073da88 in cp_parser_declaration_seq_opt (parser=0x304ef230) at /farm/dje/src/src/gcc/cp/parser.c:7816 #13 0x1073e370 in c_parse_file () at /farm/dje/src/src/gcc/cp/parser.c:3031 #14 0x107abf98 in c_common_parse_file (set_yydebug=806760888) at /farm/dje/src/src/gcc/c-opts.c:1239 #15 0x10003800 in toplev_main (argc=537008760, argv=0x109696c0) at /farm/dje/src/src/gcc/toplev.c:968 #16 0x13a0 in main (argc=806760888, argv=0x10) at /farm/dje/src/src/gcc/main.c:35 #17 0x1214 in __start () (gdb) print fndecl $6 = 0x30119c00 (gdb) pt > SI size unit size align 32 symtab 0 alias set -1 canonical type 301211a0 method basetype arg-types chain chain >>> throws > nothrow public static external in_system_header no-static-chain SI file /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/include/c++/bits/basic_string.tcc line 420 col 42 align 32 context initial arguments readonly unsigned type_0 type_6 SI size unit size align 32 symtab 0 alias set -1 canonical type 301206e8> readonly unsigned SI file /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/include/c++/bits/basic_string.tcc line 420 col 42 size unit size align 32 chain unsigned SI file /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/include/c++/bits/basic_string.tcc line 420 col 30 size unit size align 32>> result ignored VOID file /opt/freeware/lib/gcc/powerpc-ibm-aix5.3.0.0/4.3.1/include/c++/bits/basic_string.tcc line 420 col 42 align 8> template-info 3017b320 chain > -- dje at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||09/msg00999.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057
[Bug c++/37057] 7 Internal Compiler Errors when compiling OpenFOAM-1.5
--- Comment #11 from dje at gcc dot gnu dot org 2008-09-14 02:04 --- Honza, I may not be analyzing this correctly, but it looks like cgraph_remove_unreachable_nodes() may be removing something that is not dead. Is cgraph handling constructors and destructors on non-ELF systems correctly? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37057