[Bug testsuite/43959] [4.6 Regression] FAIL: gcc.dg/torture/builtin-cproj-1.c -O1 (test for excess errors)
--- Comment #7 from ghazi at gcc dot gnu dot org 2010-09-07 23:43 --- (In reply to comment #6) Subject: Bug 43959 Author: danglin Date: Tue Sep 7 23:23:30 2010 New Revision: 163979 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163979 Log: PR testsuite/43959 * gcc.dg/torture/builtin-cproj-1.c: Require c99 runtime. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/builtin-cproj-1.c This change isn't necessary or correct, the test should (and does) fold away all references to cproj on non-c99 platforms. The bug on hppa at -O1 will still occur on hppa-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43959
[Bug testsuite/43959] [4.6 Regression] FAIL: gcc.dg/torture/builtin-cproj-1.c -O1 (test for excess errors)
--- Comment #3 from ghazi at gcc dot gnu dot org 2010-09-02 15:24 ---
Please check whether
+/* { dg-add-options c99_runtime } */
+/* { dg-require-effective-target c99_runtime } */
You're right that these foldings should succeed anyway, the c99_runtime should
not be necessary. If requiring a c99 effective target eliminates the error,
it's only because the test doesn't run anymore.
The subject indicates the test fails at -O1, but I assume not -O0 or -O2. This
leads me to guess that the failing line(s) are in the #ifdef __OPTIMIZE__
section. These bits rely on some generic optimizations to fully fold away the
relevant code, which may not be happening here at -O1.
I don't have access to a test infrastructure ATM. So if David could please
narrow down which line is failing to fold, it would help. Each test line here
calls link_error(__LINE__) so if you add -fdump-tree-* you should be able to
see which one(s) aren't folding, and hopefully why.
I suspect it's something more than the c99 complex stuff.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43959
[Bug testsuite/29404] make check fails to compile library testcases
--- Comment #10 from ghazi at gcc dot gnu dot org 2010-03-30 17:11 --- Still happens on 4.5 trunk. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-01-17 03:03:45 |2010-03-30 17:11:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29404
[Bug rtl-optimization/30957] Misscompare with variable expansion optimization
--- Comment #19 from ghazi at gcc dot gnu dot org 2010-03-30 17:16 --- gcc.dg/pr30957-1.c still XFAILs on x86_64-unknown-linux-gnu -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-11-22 18:01:42 |2010-03-30 17:16:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
[Bug libmudflap/32276] [4.3/4.4/4.5 Regression]: libmudflap.c++/pass41-frag.cxx
--- Comment #14 from ghazi at gcc dot gnu dot org 2010-03-30 17:17 --- Reconfirm -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-12-20 16:12:51 |2010-03-30 17:17:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32276
[Bug c/39959] [4.5 Regression] IMA is broken, gcc.dg/pr34668-1.c, gcc.dg/pr34668-2.c ICE
--- Comment #20 from ghazi at gcc dot gnu dot org 2010-03-30 17:22 --- Still have gcc.dg/pr34668-1.c failing on mainline (with checking enabled). -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-11-16 16:38:01 |2010-03-30 17:22:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39959
[Bug middle-end/36143] [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C
--- Comment #16 from ghazi at gcc dot gnu dot org 2010-03-30 17:25 --- PASSes on 4.5 trunk, but still XFAILs on 4.4 branch. Since it's a 4.4 regression, should the patch be backported to 4.4 ? -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.4 Last reconfirmed|2008-05-25 18:13:41 |2010-03-30 17:25:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36143
[Bug target/39254] [4.4 Regression] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #25 from ghazi at gcc dot gnu dot org 2010-03-27 18:56 --- Subject: Bug 39254 Author: ghazi Date: Sat Mar 27 18:56:08 2010 New Revision: 157780 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157780 Log: Backport: 2009-06-16 Jorn Rennecke joern.renne...@arc.com Janis Johnson janis...@us.ibm.com PR target/39254 * config/rs6000/rs6000.c (rs6000_emit_move): Don't emit a USE for the symbol ref of a constant that is the source of a move - nor for any other not-obvious-label-ref constants. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug target/39254] [4.4 Regression] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #26 from ghazi at gcc dot gnu dot org 2010-03-27 19:03 --- Completed full bootstrap and testsuite on powerpc-unknown-linux-gnu with extra -fpic/-fPIC passes. The only difference was that the testcase va-arg-trap-1.c was fixed. Installed on 4.4 branch. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.4.4 | Known to work|4.5.0 |4.4.4 4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug testsuite/43495] gcc.c-torture/execute/20000603-1.c fails with -fpic/-fPIC
--- Comment #4 from ghazi at gcc dot gnu dot org 2010-03-24 18:11 --- OK, I'll modify the testcase to ensure function f() gets inlined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43495
[Bug c/43494] New: gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
When running the testsuite on ia64-unknown-linux-gnu with extra passes containing -fpic/-fPIC I get the following additional error on the 4.4 branch: FAIL: gcc.c-torture/execute/vector-2.c execution, -O2 FAIL: gcc.c-torture/execute/vector-2.c execution, -Os on 4.5 trunk I get: FAIL: gcc.c-torture/execute/vector-2.c execution, -O2 -- Summary: gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug c/43494] gcc.c-torture/execute/vector-2.c fails with -fpic/-fPIC
--- Comment #1 from ghazi at gcc dot gnu dot org 2010-03-23 17:36 --- 4.4.4 ia64 results with error: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01631.html 4.5.0 ia64 results with error: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01997.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.4 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43494
[Bug c/43495] New: [4.5 regression] gcc.c-torture/execute/20000603-1.c fails with -fpic/-fPIC
When running the testsuite on ia64-unknown-linux-gnu with extra passes containing -fpic/-fPIC I get the following additional error on the 4.5 trunk: FAIL: gcc.c-torture/execute/2603-1.c execution, -O2 FAIL: gcc.c-torture/execute/2603-1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/2603-1.c execution, -O3 -g FAIL: gcc.c-torture/execute/2603-1.c execution, -Os This is a regressions from previous releases. Testsuite results showing the extra error: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01997.html -- Summary: [4.5 regression] gcc.c-torture/execute/2603-1.c fails with -fpic/-fPIC Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43495
[Bug c/43496] New: gcc.target/powerpc/gcse-1.c fails on powerpc-unknown-linux-gnu with -fpic/-fPIC
When running the testsuite on powerpc-unknown-linux-gnu with extra passes containing -fpic/-fPIC I get the following additional error: FAIL: gcc.target/powerpc/gcse-1.c scan-assembler-times @ha 1 The error happens on the 4.3/4.4 branches and 4.5 trunk: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01996.html http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01913.html http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01630.html The pattern @ha appears zero times in the pic assembler output. I don't speak ppc, so is this expected or is it a GCC bug? -- Summary: gcc.target/powerpc/gcse-1.c fails on powerpc-unknown- linux-gnu with -fpic/-fPIC Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43496
[Bug pch/43497] New: gcc.dg/pch/static-1.c and gcc.dg/pch/static-2.c fail on powerpc-unknown-linux-gnu with -fPIC
When running the testsuite on powerpc-unknown-linux-gnu with extra passes containing -fPIC I get the following additional error on the 4.3 branch: FAIL: gcc.dg/pch/static-1.c -O0 -g assembly comparison FAIL: gcc.dg/pch/static-1.c -O0 assembly comparison FAIL: gcc.dg/pch/static-2.c -O0 -g assembly comparison FAIL: gcc.dg/pch/static-2.c -O0 assembly comparison Testsuite results: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01996.html The error does NOT occur with -fpic. Only -fPIC triggers it. Later versions (4.4 branch or 4.5 trunk) also do NOT show this error. -- Summary: gcc.dg/pch/static-1.c and gcc.dg/pch/static-2.c fail on powerpc-unknown-linux-gnu with -fPIC Product: gcc Version: 4.3.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43497
[Bug pch/43497] gcc.dg/pch/static-1.c and gcc.dg/pch/static-2.c fail on powerpc-unknown-linux-gnu with -fPIC
--- Comment #1 from ghazi at gcc dot gnu dot org 2010-03-23 18:39 --- The -O0 vs -O0 -g diffs appear to be the same except for line number changes. So here is just the -O0 -g diffs for both testcases: line #69 .LCL1: .LCL0: line #70 .long .LCTOC1-.LCF1 .long .LCTOC1-.LCF0 line #88 bcl 20,31,.LCF1 bcl 20,31,.LCF0 line #89 .LCF1: .LCF0: line #91 lwz 0,.LCL1-.LCF1(30) lwz 0,.LCL0-.LCF0(30) FAIL: gcc.dg/pch/static-1.c -O0 -g assembly comparison line #70 .LCL1: .LCL0: line #71 .long .LCTOC1-.LCF1 .long .LCTOC1-.LCF0 line #89 bcl 20,31,.LCF1 bcl 20,31,.LCF0 line #90 .LCF1: .LCF0: line #92 lwz 0,.LCL1-.LCF1(30) lwz 0,.LCL0-.LCF0(30) FAIL: gcc.dg/pch/static-2.c -O0 -g assembly comparison -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.5 Known to work||4.4.4 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43497
[Bug libgomp/43499] New: libgomp.fortran/appendix-a/a.22.7.f90 and libgomp.fortran/omp_parse3.f90 fail on powerpc-unknown-linux-gnu with -fpic
When running the testsuite on powerpc-unknown-linux-gnu with extra passes containing -fpic I get the following additional error on the 4.3 branch: Running target unix/-fpic FAIL: libgomp.fortran/appendix-a/a.22.7.f90 -Os (test for excess errors) UNRESOLVED: libgomp.fortran/appendix-a/a.22.7.f90 -Os compilation failed to produce executable FAIL: libgomp.fortran/omp_parse3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) UNRESOLVED: libgomp.fortran/omp_parse3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions compilation failed to produce executable It only triggers with -fpic, -fPIC does not trigger. The error only occurs on the 4.3 branch, later versions (4.4 branch and 4.5 trunk) do not show the error. Testsuite results showing the error: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01996.html The gcc.log file shows this message for both failures: /usr/bin/ld: BFD 2.17 Debian GNU/Linux internal error, aborting at ../../bfd/elf32-ppc.c line 6071 in ppc_elf_relocate_section /usr/bin/ld: Please report this bug. While binutils ld shouldn't crash, I think we should see if GCC is producing erroneous output too. -- Summary: libgomp.fortran/appendix-a/a.22.7.f90 and libgomp.fortran/omp_parse3.f90 fail on powerpc-unknown- linux-gnu with -fpic Product: gcc Version: 4.3.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43499
[Bug c/43495] [4.5 regression] gcc.c-torture/execute/20000603-1.c fails with -fpic/-fPIC
--- Comment #1 from ghazi at gcc dot gnu dot org 2010-03-23 19:05 --- Testcase also fails on powerpc-unknown-linux-gnu with -fpic/-fPIC: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg01630.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|ia64-unknown-linux-gnu |ia64-unknown-linux-gnu ||powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43495
[Bug middle-end/43500] New: gcc.c-torture/execute/va-arg-trap-1.c fails on powerpc-unknown-linux-gnu with -fPIC
When running the testsuite on powerpc-unknown-linux-gnu with extra passes containing -fPIC I get the following additional errors on the 4.4 branch: FAIL: gcc.c-torture/execute/va-arg-trap-1.c compilation, -O2 (internal compiler error) FAIL: gcc.c-torture/execute/va-arg-trap-1.c compilation, -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/execute/va-arg-trap-1.c compilation, -O3 -g (internal compiler error) FAIL: gcc.c-torture/execute/va-arg-trap-1.c compilation, -Os (internal compiler error) I don't have a logfile handy, but compiling the test by hand using -fPIC and any one of the above optimization levels I get this error: va-arg-trap-1.c:29: internal compiler error: in move_insn, at haifa-sched.c:1934 The problem does not happen in 4.5 trunk, so perhaps we can backport a fix if it can be identified. -- Summary: gcc.c-torture/execute/va-arg-trap-1.c fails on powerpc- unknown-linux-gnu with -fPIC Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43500
[Bug target/39254] [4.4 Regression] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #21 from ghazi at gcc dot gnu dot org 2010-03-23 19:55 --- As noted in duplicate PR43500, I am able to reproduce this error on plain powerpc-unknown-linux-gnu when adding -fPIC. I can run tests for the 4.4. branch but it will take several days to get a baseline result vs a patch one given extra -fPIC runs. If it passes I'll apply the patch to 4.4 per Richard's approval in comment#18. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.4 Known to work||4.5.0 Last reconfirmed|2009-06-17 04:20:01 |2010-03-23 19:55:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug c/43495] [4.5 regression] gcc.c-torture/execute/20000603-1.c fails with -fpic/-fPIC
--- Comment #2 from ghazi at gcc dot gnu dot org 2010-03-23 22:17 --- Testcase also fails on sparc64-unknown-linux-gnu with -fpic/-fPIC in both 32 and 64 bit modes: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg00753.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|ia64-unknown-linux-gnu |ia64-unknown-linux-gnu |powerpc-unknown-linux-gnu |powerpc-unknown-linux-gnu ||sparc64-unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43495
[Bug middle-end/20491] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042
--- Comment #36 from ghazi at gcc dot gnu dot org 2010-03-11 17:00 --- I'm seeing failures for gcc.dg/torture/asm-subreg-1.c on armv5tel-unknown-linux-gnueabi on mainline and 4.4/4.3 branches when using -fpic or -fPIC and optimizing. See: http://gcc.gnu.org/ml/gcc-testresults/2010-03/msg00638.html The error message is: asm-subreg-1.c: In function 'evas_common_convert_yuv_420p_601_rgba': asm-subreg-1.c:13:3: error: 'asm' operand requires impossible reload compiler exited with status 1 Is this a bug or skip it like hppa? -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org Last reconfirmed|2005-03-24 08:56:02 |2010-03-11 17:00:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20491
[Bug testsuite/38163] gcc.dg/tree-ssa/loop-3.c failure at -m64 on i686-apple-darwin9
--- Comment #5 from ghazi at gcc dot gnu dot org 2010-03-10 21:15 --- Subject: Bug 38163 Author: ghazi Date: Wed Mar 10 21:15:16 2010 New Revision: 157370 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157370 Log: Backport: 2008-12-12 Uros Bizjak ubiz...@gmail.com PR testsuite/38163 * gcc.dg/tree-ssa/loop-3.c: Compile only on nonpic x86 targets. Remove dg-skip-if directive. Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/tree-ssa/loop-3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38163
[Bug testsuite/42308] test-demangle, test-pexecute and test-expandargv compiled with wrong compiler
--- Comment #4 from ghazi at gcc dot gnu dot org 2010-03-01 07:15 --- Is this a dup of 29404 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42308
[Bug libstdc++/21769] per-file control over PCH inclusion
--- Comment #6 from ghazi at gcc dot gnu dot org 2010-02-23 08:12 --- Subject: Bug 21769 Author: ghazi Date: Tue Feb 23 08:12:35 2010 New Revision: 156990 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156990 Log: Backport: 2010-01-20 Janis Johnson janis...@us.ibm.com Paolo Carlini paolo.carl...@oracle.com PR libstdc++/21769 * testsuite/lib/dg-options.exp (add_options_for_no_pch): Add. * testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc: Use it. Modified: branches/gcc-4_4-branch/libstdc++-v3/ChangeLog branches/gcc-4_4-branch/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc branches/gcc-4_4-branch/libstdc++-v3/testsuite/lib/dg-options.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21769
[Bug libstdc++/21769] per-file control over PCH inclusion
--- Comment #7 from ghazi at gcc dot gnu dot org 2010-02-23 09:42 --- Subject: Bug 21769 Author: ghazi Date: Tue Feb 23 09:41:37 2010 New Revision: 156991 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156991 Log: Backport: 2010-01-20 Janis Johnson janis...@us.ibm.com Paolo Carlini paolo.carl...@oracle.com PR libstdc++/21769 * testsuite/lib/dg-options.exp (add_options_for_no_pch): Add. * testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc: Use it. Modified: branches/gcc-4_3-branch/libstdc++-v3/ChangeLog branches/gcc-4_3-branch/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc branches/gcc-4_3-branch/libstdc++-v3/testsuite/lib/dg-options.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21769
[Bug libstdc++/21769] per-file control over PCH inclusion
-- ghazi at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.4 4.4.3 Known to work||4.3.5 4.4.4 4.5.0 Target Milestone|4.5.0 |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21769
[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
--- Comment #21 from ghazi at gcc dot gnu dot org 2010-02-05 16:55 --- Sometime in Jan 2010 between revisions 155638 and 155826, this testcase stopped failing on the trunk: FAIL: http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg00507.html no FAIL: http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01034.html When I check the logfile, it now says: UNSUPPORTED: 22_locale/time_get/get_date/wchar_t/4.cc The testcase still fails on the 4.4/4.3 branches, so the issue on debian with locales still exists, but is masked on trunk because the testcase is not run. Was this intentional? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413
[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
--- Comment #23 from ghazi at gcc dot gnu dot org 2010-02-05 17:26 --- (In reply to comment #22) Kaveh, you are comparing apples to oranges: in the first case the GNU locale model is used, a complete set of locale data is installed, thus the testcase is run and it fails. In the second case, evidently one of the first two assumptions does not hold, thus the testcase is not run at all. The failure on the branches happens on the same box (CFARM gcc14). So the locale data is identical across these cases vs trunk. E.g.: 4.4: http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg00420.html 4.3: http://gcc.gnu.org/ml/gcc-testresults/2010-02/msg00421.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413
[Bug libgomp/29986] testsuite failures
--- Comment #6 from ghazi at gcc dot gnu dot org 2010-01-26 16:31 --- (In reply to comment #5) I've found that the problem doesn't occur when assembler patch 118683-03 is installed. If this issue is fixed, perhaps you could add a note to: http://gcc.gnu.org/install/specific.html#x-x-solaris2 describe the bug and mention which patch fixes it, then close this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29986
[Bug bootstrap/42424] [4.5 Regression] in-tree GMP/MPFR/MPC bootstrap fails
--- Comment #9 from ghazi at gcc dot gnu dot org 2010-01-07 21:58 --- Subject: Bug 42424 Author: ghazi Date: Thu Jan 7 21:58:23 2010 New Revision: 155712 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155712 Log: PR bootstrap/42424 * configure.ac: Include libtool m4 files. (_LT_CHECK_OBJDIR): Call it. (extra_mpc_mpfr_configure_flags, extra_mpc_gmp_configure_flags, gmplibs, ppllibs, clooglibs): Use $lt_cv_objdir. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424
[Bug bootstrap/42424] [4.5 Regression] in-tree GMP/MPFR/MPC bootstrap fails
--- Comment #7 from ghazi at gcc dot gnu dot org 2010-01-06 23:26 --- Proposed patch: http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00300.html The bug is masked on my box by an old libgmp installation. So to be sure the above patch actually fixes the problem, I'd appreciate hearing from someone who was able to reproduce the error to verify it works. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424
[Bug bootstrap/42424] [4.5 Regression] in-tree GMP/MPFR/MPC bootstrap fails
--- Comment #6 from ghazi at gcc dot gnu dot org 2010-01-03 15:31 --- (In reply to comment #3) OK, I can reproduce the issue. The problem is that mpc isn't told where to find the gmp and mpfr libraries. [...] Except that on some targets, .libs is actually called _libs. I don't know how to deal with that. Ah, I think you're on the right track. I can't yet figure out why it won't reproduce for me. There must be some libgmp in my lib path but I can't find it ATM. Anyway, I have an idea for _libs and will try to fix it. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-01-02 19:53:42 |2010-01-03 15:31:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424
[Bug bootstrap/42424] in-tree GMP/MPFR/MPC bootstrap fails
--- Comment #1 from ghazi at gcc dot gnu dot org 2010-01-02 16:24 --- I was able to do a C-only bootstrap of mainline with all three libraries in-tree on x86_64-unknown-linux-gnu. I used mpc-0.8, mpfr-2.4.2, gmp-4.3.1 and bootstrapped with gcc-4.3.2. I cannot reproduce this problem, so we need more info, e.g. 1. Is this a recent regression or has it always failed? 2. What versions of the various libraries did you use? 3. Does it fail with all versions of the libs or just some? 4. The targets listed include darwin9 and i686-linux, do they both fail for the same reason? 5. Do you have other versions of gmp/mpfr installed somewhere that conflict with the bootstrap? 6. Is there more info or investigation you can provide? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42424
[Bug libmudflap/32276] [4.3/4.4/4.5 Regression]: libmudflap.c++/pass41-frag.cxx
--- Comment #13 from ghazi at gcc dot gnu dot org 2009-12-20 16:12 --- Reconfirming on all active branches for x86_64-unknown-linux-gnu: gcc-4.5: http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg01759.html gcc-4.4: http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg01486.html gcc-4.3: http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg00752.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org Last reconfirmed|2007-07-13 00:55:55 |2009-12-20 16:12:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32276
[Bug fortran/40318] Complex division by zero in gfortran returns wrong results
--- Comment #16 from ghazi at gcc dot gnu dot org 2009-12-18 17:16 --- (In reply to comment #15) Now that MPC is required by gcc, I'll take a look at making gfortran give a consistent result when comparing its constant folding with generated code. BTW, I put in some special-case code in arith.c:gfc_arith_divide() to ensure we still got the old fortran divide behavior. You probably want to remove it if you're working on this PR. See note #3 from this patch: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01368.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
[Bug target/42074] gcc.dg/torture/builtin-math-7.c fails on darwin
--- Comment #13 from ghazi at gcc dot gnu dot org 2009-12-11 16:44 --- The Darwin issue is being tracked in PR42333. Since the LTO issue is fixed, to avoid confusion I'll close this one as a dup. *** This bug has been marked as a duplicate of 42333 *** -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42074
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #31 from ghazi at gcc dot gnu dot org 2009-12-11 16:44 --- *** Bug 42074 has been marked as a duplicate of this bug. *** -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #28 from ghazi at gcc dot gnu dot org 2009-12-09 18:55 --- (In reply to comment #26) I am still a bit confused about this bug. When we leave -lm out of the linkage of builtin-math-7.exe, where does the ___divdc3 call get resolved from? The ___divdc3 function is defined in FSF GCC's libgcc2.so, which is what you want here. That version correctly handles overflow scenarios in complex division. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug lto/42074] gcc.dg/torture/builtin-math-7.c failed
--- Comment #9 from ghazi at gcc dot gnu dot org 2009-12-08 08:08 ---
Jack, what does this program do on darwin9 and darwin10?
(The correct output is 2 0.)
int main(void)
{
volatile _Complex double val = (__DBL_MAX__ * 0.5 + __DBL_MAX__ * 0.5i);
val /= (__DBL_MAX__ * 0.25 + __DBL_MAX__ * 0.25i);
__builtin_printf (%g %g\n, __real (val), __imag (val));
if (val != 2) __builtin_abort();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42074
[Bug other/42333] New: complex division failure on darwin10 with -lm
As noted in PR42074, linking with the math library on darwin10 allows overflow
to occur during complex division. It was originally reported as a failure in
testcase gcc.dg/torture/builtin-math-7.c at all optimization levels. However
as described in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42074#c10 the error
is related to using -lm on the reduced testcase below. Without -lm it passes,
with -lm a failure occurs. As such, it isn't necessarily a bug in GCC, however
this PR will help track if there is a possible workaround.
int main(void)
{
volatile _Complex double val = (__DBL_MAX__ * 0.5 + __DBL_MAX__ * 0.5i);
val /= (__DBL_MAX__ * 0.25 + __DBL_MAX__ * 0.25i);
__builtin_printf (%g %g\n, __real (val), __imag (val));
if (val != 2) __builtin_abort();
return 0;
}
--
Summary: complex division failure on darwin10 with -lm
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
GCC target triplet: *-*-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug lto/42074] gcc.dg/torture/builtin-math-7.c fails with -flto or -fwhopr
--- Comment #11 from ghazi at gcc dot gnu dot org 2009-12-08 16:35 --- (In reply to comment #10) I had a look at the problem and found that it is due to the -lm flag used in the test suite. [...] and tgcc.dg/torture/builtin-math-7.c passes when it is compiled manually without -lm. Thanks. Clearly now these are separate bugs. I've opened PR42333 for the darwin10 issue. Let's continue the discussion about that problem in that PR. This PR will remain solely for the -flto/-fwhopr failures. I've modified the description accordingly. Someone who understands LTO needs to investigate the code from comment#8. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Summary|gcc.dg/torture/builtin-math-|gcc.dg/torture/builtin-math- |7.c failed |7.c fails with -flto or - ||fwhopr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42074
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-12-08 16:46 --- (In reply to comment #1) As such, it isn't necessarily a bug in GCC, however this PR will help track if there is a possible workaround. As far as I understand the use of the gcc compilers on darwin, I do not see when I should use -lm. So the simplest workaround could be to not use -lm in the testsuite at least for intel-darwin10. If someone tells me how to do that I can do the testing. I don't think that's the right approach, that would only mask the bug in the testsuite but leave it in userland. IMHO, the first thing we need to understand is *why* the math library is the trigger. In the assembler output from Jack in PR42074, the only function calls are to abort and __divdc3 which is a libgcc2 provided function that performs the complex division. I don't see why -lm would override either one, let alone a GCC internal one. You may be able to check via nm if libm defines it. Oh wait, try running ldd (or the darwin equivalent) on the shared math library. See if it (or any of its dependencies) link in a another darwin copy of libgcc2 from the system compiler. Maybe there's an old definition of __divdc3 in there that is overriding the one from gcc-4.5 and yields a bogus result. Also check if linking staticly solves the problem. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-12-08 20:24 --- (In reply to comment #6) Considering that builtin-math-7.c doesn't exist in gcc 4.4 branch, it is unclear what that test should do there. Jack - Focusing on builtin-math-7.c (which tests multiple things) misses the point. The bug on darwin10 is exposed by a trivial runtime complex division. See the code from the original description above. That code should work on 4.4 branch, etc and that is what Dominique is compiling with other gcc versions. Note I'm not commenting on your suggested patch revert, I don't know enough about Darwin to predict whether that will be fruitful. I just want to make sure we all understand that the reduced testcase I provided should work on all GCC versions that support complex numbers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #13 from ghazi at gcc dot gnu dot org 2009-12-08 23:58 --- (In reply to comment #12) .. seems likely that there are two things here: 1. we seem to be generating (probably) less efficient code than older versions of the compiler ... and 2. possibly the ___divdc3 in /usr/lib/libSystem is faulty? There are more than one way of generating a complex divide. One way is faster, but it's naive (lazy) and leads to errors and overflow. A second way is correct in more cases, but a little slower. FSF GCC defaults to choosing correctness over speed, unless the user asks for extra speed with a special flag. There are flags in FSF GCC for example that allow one to use the lazy complex divide algorithms, but the default is correctness. It appears that the Apple GCC has chosen to have their ___divdc3 routine follow the lazy algoritm in the name of speed. This must have been a concious choice on their part. Therefore filing a bug report against it is likely to get a response of works as intended. You can try filing a bug report at Apple, but I think a better route would be to see if we can avoid linking in the system ___divdc3 from FSF GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #14 from ghazi at gcc dot gnu dot org 2009-12-09 00:06 --- (In reply to comment #11) I think I understand why apple gcc42 does not show the problem: it does not call ___divdc3: It is possible that some versions of GCC (Apple's and/or FSF's) inline the assembly code to do the divide. That would explain why they don't call ___divdc3. Then what happens only depends on what version of the algorithm they inline, not what they link against. ... This also explain why the test compiled with -c and 4.5, but linked with 4.2 fails. So my guess about the lazy complex division seems right in libm. Could someone write a C code forcing the use of ___divdc3? I don't think it makes sense to consider user code calling ___divdc3 directly. According to the C standard, functions that begin with double underscore are reserved for the compiler and/or system libraries. That is exactly how they are being used here. The call should only be generated by the compiler itself as a service function to perform something like a complex divide. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/42333] complex division failure on darwin10 with -lm
--- Comment #17 from ghazi at gcc dot gnu dot org 2009-12-09 00:34 --- (In reply to comment #15) (In reply to comment #13) You can try filing a bug report at Apple, but I think a better route would be to see if we can avoid linking in the system ___divdc3 from FSF GCC. This may be impossible without having FSF gcc access its own ___divdc3 under a different symbol name. The functionality of libgcc has been subsumed into libSystem in darwin10 and the symbols from libgcc itself are supposed to be ignored in favor of those from libSystem... http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html I don't think we should get into a cat-and-mouse game of renaming functions that *are already FSF functions* just to avoid Apple's rewritten versions. Who's to say they won't override the new name(s) in a future release with the same broken copy(ies)? The sad thing is they changed ___divdc3 and they don't even emit it from their compiler. :-/ If you want to file a bug report at Apple using the FSF generated assembly (and C testcase for reference), please proceed. I hope they fix their ___divdc3 routine. Note there may be other complex math things they've rewritten. Someone would need to audit Apple's compiler to see what else they've changed. On what to do about builtin-math-7.c testcase, my inclination is we should just XFAIL it for darwin10 since fixing darwin's ___divdc3 won't help with distributions out in the field. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333
[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #9 from ghazi at gcc dot gnu dot org 2009-12-07 15:33 --- Subject: Bug 40302 Author: ghazi Date: Mon Dec 7 15:32:43 2009 New Revision: 155043 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155043 Log: PR other/40302 * arith.c: Remove HAVE_mpc* checks throughout. * expr.c: Likewise. * gfortran.h: Likewise. * resolve.c: Likewise. * simplify.c: Likewise. * target-memory.c: Likewise. * target-memory.h: Likewise. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/target-memory.c trunk/gcc/fortran/target-memory.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #10 from ghazi at gcc dot gnu dot org 2009-12-07 15:37 --- Subject: Bug 40302 Author: ghazi Date: Mon Dec 7 15:36:46 2009 New Revision: 155045 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155045 Log: PR other/40302 * gcc.dg/torture/builtin-math-6.c: Assume we have MPC. * gcc.dg/torture/builtin-math-7.c: Likewise. * gfortran.dg/complex_intrinsic_7.f90: Likewise. * gfortran.dg/complex_intrinsic_8.f90: Likewise. * gfortran.dg/integer_exponentiation_4.f90: Re-enable some tests. * lib/target-supports.exp (check_effective_target_mpc, check_effective_target_mpc_pow, check_effective_target_mpc_arc): Delete. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/builtin-math-6.c trunk/gcc/testsuite/gcc.dg/torture/builtin-math-7.c trunk/gcc/testsuite/gfortran.dg/complex_intrinsic_7.f90 trunk/gcc/testsuite/gfortran.dg/complex_intrinsic_8.f90 trunk/gcc/testsuite/gfortran.dg/integer_exponentiation_4.f90 trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #11 from ghazi at gcc dot gnu dot org 2009-12-07 15:43 --- Subject: Bug 40302 Author: ghazi Date: Mon Dec 7 15:42:55 2009 New Revision: 155046 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155046 Log: PR other/40302 * builtins.c: Remove HAVE_mpc* checks throughout. * fold-const.c: Likewise. * real.h: Likewise. * toplev.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/fold-const.c trunk/gcc/real.h trunk/gcc/toplev.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #12 from ghazi at gcc dot gnu dot org 2009-12-07 15:45 --- Subject: Bug 40302 Author: ghazi Date: Mon Dec 7 15:45:01 2009 New Revision: 155047 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155047 Log: PR other/40302 * configure.ac (HAVE_mpc): Don't define. * config.in, configure: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/configure trunk/gcc/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug middle-end/30447] Evaluate complex math functions at compile-time
--- Comment #13 from ghazi at gcc dot gnu dot org 2009-12-07 15:55 --- Done. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30447
[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #14 from ghazi at gcc dot gnu dot org 2009-12-08 05:24 --- Done. :-) -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug lto/42074] gcc.dg/torture/builtin-math-7.c failed
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-12-08 06:10 --- I took a quick look. First, there seems to be two separate bugs reported here. One bug, reported by HJ, appears to be lto/whopr related, and so happens on systems lto is activated. The other bug is specific to Darwin (10 only?) and happens at all optimizations levels without lto. Jack reported the Darwin errors happen on the DBL_MAX overflow check. I ran the testcase with lto and it failed in the TEST_ONE_PART_INF section. The two different errors may have the same root cause, or not in which case a separate PR should be opened for the Darwin error. The second comment I have is that all of these are runtime/execute failures. That means it's not related to MPC per se which only handles compile-time optimizations. In addition to the compile-time checks, the testcase sanity checks the runtime behavior of GCC and that's what's failing. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC|ghazi at caip dot rutgers |ghazi at gcc dot gnu dot org |dot edu | Last reconfirmed|2009-11-17 01:47:17 |2009-12-08 06:10:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42074
[Bug lto/42074] gcc.dg/torture/builtin-math-7.c failed
--- Comment #8 from ghazi at gcc dot gnu dot org 2009-12-08 07:18 ---
Here's a reduced testcase for the -flto/-fwhopr failures. If you compile it
with -O2 -flto or -O2 -fwhopr you get the wrong answers:
nan nan
nan nan
If you use just -O2, you get the correct output, i.e. it contains an inf:
-inf nan
inf nan
It seems like the erroneous case occurs with the wrong value for
flag_complex_method during code-gen. Although how/why that happens I can't
say. I think someone more familiar with LTO should look as this part.
#define VAL ((_Complex double)__builtin_inf() * 1i)
#define PRINTIT(X) do { \
__builtin_printf (%g %g\n, __real (X), __imag (X)); \
} while (0)
int main(void)
{
PRINTIT(VAL * VAL);
PRINTIT((_Complex double) 1 / (_Complex double) 0);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42074
[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #8 from ghazi at gcc dot gnu dot org 2009-12-06 16:11 --- Subject: Bug 40302 Author: ghazi Date: Sun Dec 6 16:11:06 2009 New Revision: 155023 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155023 Log: PR middle-end/30447 PR middle-end/30789 PR other/40302 * configure.ac: Require MPC. * configure: Regenerate. gcc: * doc/install.texi: Document MPC is required. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac trunk/gcc/ChangeLog trunk/gcc/doc/install.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug middle-end/30789] complex folding inexact
--- Comment #12 from ghazi at gcc dot gnu dot org 2009-12-06 16:11 --- Subject: Bug 30789 Author: ghazi Date: Sun Dec 6 16:11:06 2009 New Revision: 155023 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155023 Log: PR middle-end/30447 PR middle-end/30789 PR other/40302 * configure.ac: Require MPC. * configure: Regenerate. gcc: * doc/install.texi: Document MPC is required. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac trunk/gcc/ChangeLog trunk/gcc/doc/install.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30789
[Bug middle-end/30447] Evaluate complex math functions at compile-time
--- Comment #12 from ghazi at gcc dot gnu dot org 2009-12-06 16:11 --- Subject: Bug 30447 Author: ghazi Date: Sun Dec 6 16:11:06 2009 New Revision: 155023 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155023 Log: PR middle-end/30447 PR middle-end/30789 PR other/40302 * configure.ac: Require MPC. * configure: Regenerate. gcc: * doc/install.texi: Document MPC is required. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac trunk/gcc/ChangeLog trunk/gcc/doc/install.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30447
[Bug rtl-optimization/34999] Incorrect FDE entries with hot/cold code section splitting (partition_hot_cold_basic_blocks)
--- Comment #28 from ghazi at gcc dot gnu dot org 2009-12-01 15:14 --- Backport to 4.4? Or close this and PR41501? -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34999
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #33 from ghazi at gcc dot gnu dot org 2009-11-29 16:12 --- The flag -frtl-abstract-sequences was removed and the relevant testcases deleted. Should we resolve this PR as WONTFIX ? http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01800.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug rtl-optimization/35729] const volatile variable access incorrectly hoisted out of loop
--- Comment #14 from ghazi at gcc dot gnu dot org 2009-11-29 16:21 --- This testcase was fixed here: http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01134.html Can we close this one? -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35729
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #12 from ghazi at gcc dot gnu dot org 2009-11-29 16:34 --- Rainer, I believe this bug has been appropriatly analyzed and diagnosed. You have the affected system and can test, are you working on a fix? -- ghazi 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-11-29 16:34:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug target/3195] STL warning on Solaris with GCC 3.0
--- Comment #12 from ghazi at gcc dot gnu dot org 2009-11-30 01:58 --- I believe I fixed this issue in Sept 2006 in gcc-4.0.4, see: http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01032.html http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01163.html http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01194.html http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01225.html http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01317.html and finally this testcase: http://gcc.gnu.org/ml/gcc-patches/2006-09/msg01233.html and later refinements to it ensure pthread macros work everywhere. Results for solaris that don't contain pthread-init-*.c failures: solaris2.6: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00680.html solaris2.7: http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00420.html solaris2.9: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01482.html solaris2.10: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01551.html solaris2.11: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01835.html I recall there was some issue with solaris8 where the macro definition could get out of sync with the structure definition based on what solaris patches where installed. The macro was defined in a different header than the structure and individual solaris patches updated the two files independently, which made it hard (impossible?) to synchronize. And indeed I see a failure in solaris2.8: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00523.html Other than that, all supported versions of solaris are okay. So I think we can close this 8-year-old PR. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Severity|enhancement |trivial Status|NEW |ASSIGNED Last reconfirmed|2005-01-13 01:04:59 |2009-11-30 01:58:10 date|| Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3195
[Bug target/3195] STL warning on Solaris with GCC 3.0
--- Comment #13 from ghazi at gcc dot gnu dot org 2009-11-30 02:00 --- Fixed. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3195
[Bug objc++/42156] New: Hundreds of objc++ testsuite regressions
Sometime between mainline revision 154353: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01929.html and 154391: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01929.html I'm getting massive numbers of objc++ testsuite regressions. -- Summary: Hundreds of objc++ testsuite regressions Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: objc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
[Bug objc++/42156] Hundreds of objc++ testsuite regressions
--- Comment #1 from ghazi at gcc dot gnu dot org 2009-11-23 18:15 --- Sorry the second results for 154391 link is: http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg02040.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
[Bug tree-optimization/41501] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE - `-fprofile-use' fails with '-02'
--- Comment #4 from ghazi at gcc dot gnu dot org 2009-11-22 17:23 --- Patch on mainline needs to be backported to 4.4.x branch. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||34999 Last reconfirmed|2009-11-16 15:57:29 |2009-11-22 17:23:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41501
[Bug c++/26099] support for type traits is not available
--- Comment #29 from ghazi at gcc dot gnu dot org 2009-11-22 17:54 --- The -fpic/-fPIC failures have been fixed long ago in gcc-4.3.x. Can we close this bug? -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099
[Bug target/30652] SSE expansion is missing for isinf() and other fpclassify functions
--- Comment #12 from ghazi at gcc dot gnu dot org 2009-11-22 17:58 --- What remains to be done here? -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30652
[Bug rtl-optimization/30957] Misscompare with variable expansion optimization
--- Comment #18 from ghazi at gcc dot gnu dot org 2009-11-22 18:01 --- Still fails -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-01-17 02:56:20 |2009-11-22 18:01:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
[Bug middle-end/42111] New: Failure in gcc.dg/cleanup-13.c on older x86 boxes
I seeing failures in gcc.dg/cleanup-13.c on x86_64-unknown-linux-gnu and i686-unknown-linux-gnu with gcc-4.4.3 svn. E.g.: FAIL: gcc.dg/cleanup-13.c (test for excess errors) http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01708.html gcc.dg/cleanup-13.c: Assembler messages: gcc.dg/cleanup-13.c:305: Error: CFI instruction used without previous .cfi_startproc compiler exited with status 1 The failure only occurs on certain systems. E.g. on CFARM gcc14 it does NOT occur. However I do see it on nearly every other CFARM i686 x86_64 box (e.g. gcc03, gcc09, gcc11, gcc12, gcc13, gcc16, gcc17 all fail). It probably has to do with older software (gas?) I seem to recall this came up before and don't recall whether it was fixed somehow or not. But the error does not occur on mainline. The uname and as --version output on the box it passes is: Linux gcc14 2.6.26-2-amd64 #1 SMP Sun Jun 21 04:47:08 UTC 2009 x86_64 GNU/Linux GNU assembler (GNU Binutils for Debian) 2.18.0.20080103 And if it helps, the uname and as --version output on the failing systems is: Linux gcc03 2.6.12-10-686-smp #1 SMP Fri Nov 18 12:27:41 UTC 2005 i686 GNU/Linux GNU assembler 2.16.1 Debian GNU/Linux Linux gcc09 2.6.12-10-686-smp #1 SMP Sat Mar 11 16:41:12 UTC 2006 i686 GNU/Linux GNU assembler 2.16.1 Debian GNU/Linux Linux gcc11 2.6.18-6-vserver-amd64 #1 SMP Thu Dec 25 21:35:11 UTC 2008 x86_64 GNU/Linux GNU assembler 2.17 Debian GNU/Linux Linux gcc12 2.6.18-6-vserver-amd64 #1 SMP Thu Dec 25 21:35:11 UTC 2008 x86_64 GNU/Linux GNU assembler 2.17 Debian GNU/Linux Linux gcc13 2.6.18-6-vserver-amd64 #1 SMP Sun Feb 10 17:55:04 UTC 2008 x86_64 GNU/Linux GNU assembler 2.17 Debian GNU/Linux Linux gcc16 2.6.18-6-vserver-amd64 #1 SMP Thu Dec 25 21:35:11 UTC 2008 x86_64 GNU/Linux GNU assembler 2.17 Debian GNU/Linux Linux gcc17 2.6.18-6-vserver-amd64 #1 SMP Thu Dec 25 21:35:11 UTC 2008 x86_64 GNU/Linux GNU assembler 2.17 Debian GNU/Linux -- Summary: Failure in gcc.dg/cleanup-13.c on older x86 boxes Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu i686-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42111
[Bug tree-optimization/41501] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE - `-fprofile-use' fails with '-02'
--- Comment #3 from ghazi at gcc dot gnu dot org 2009-11-16 15:57 --- See PR34999 -- ghazi 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-11-16 15:57:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41501
[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-11-15 17:58 --- Patches submitted to do all of the above cleanups, etc. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-10-14 01:59:37 |2009-11-15 17:58:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug tree-optimization/41987] [4.5 Regression] expected class �constant�, have �binary� (rdiv_expr) in build_complex, at tree.c:1485
--- Comment #8 from ghazi at gcc dot gnu dot org 2009-11-10 16:17 --- Subject: Bug 41987 Author: ghazi Date: Tue Nov 10 16:16:57 2009 New Revision: 154065 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154065 Log: PR tree-optimization/41987 * fold-const.c (const_binop): Avoid using fold_buildN(). testsuite: * gcc.c-torture/compile/pr41987.c: New. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr41987.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41987
[Bug tree-optimization/41987] [4.5 Regression] expected class �constant�, have �binary� (rdiv_expr) in build_complex, at tree.c:1485
--- Comment #9 from ghazi at gcc dot gnu dot org 2009-11-11 02:46 --- Fixed. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41987
[Bug tree-optimization/41987] [4.5 Regression] expected class �constant�, have �binary� (rdiv_expr) in build_complex, at tree.c:1485
--- Comment #6 from ghazi at gcc dot gnu dot org 2009-11-09 17:56 ---
The bug is not latent and also it is not in GCC code related MPC. It lies in
the tree-based fallback code I wrote to handle complex division when MPC is not
used. This code will still persist even after the switch to MPC. E.g. I can
trigger it from a C testcase using _Complex int and this scenario will remain
after the cutover. I.e. the C testcase below crashes both with and without
MPC.
As for why the fortran testcase passes with MPC, I guess that it gets folded in
the fortran frontend, thus it's masked and the middle-end never sees it. I
believe I know what's wrong in fold and I'm working on a fix.
void qparm_colvar(void)
{
_Complex int ylm;
int nbond;
ylm = 0;
nbond = 0;
ylm = ylm / nbond;
}
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-11-09 17:56:11
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41987
[Bug tree-optimization/41987] [4.5 Regression] expected class �constant�, have �binary� (rdiv_expr) in build_complex, at tree.c:1485
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-11-10 05:56 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00488.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41987
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #9 from ghazi at gcc dot gnu dot org 2009-11-05 02:55 --- (In reply to comment #8) Say I have a silly question, how is gmp.h getting pulled into gcc.c in the first place? It's supposed to come in via real.h which should only get included by middle-end files linking with real.o ... So the sequence is gcc.c includes flags.h which includes real.h. That last include was introduced by this patch: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00716.html IMHO, flags.h should not include real.h if things like gcc.c will include it and not link against real.o and -lgmp etc. But I don't know which if any targets now depend on this include. I tried x86_64-linux-gnu and I was able to link xgcc and cc1. But some other target may have a problem. Perhaps Ulrich can explain why he chose to add that include so we can see if there's another way to accomplish the goal. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added CC||uweigand at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-10-22 18:13 --- (In reply to comment #6) I'm not sure we can claim there is GMP breakage at all: they could argue that anyone including gmp.h can be expected to link with -lgmp as well. I just don't know if it is correct to assume that a function defined as extern inline in a header will not be emitted in the object file. Fair enough, okay. Even so, there is breakage in GCC as well: * ansidecl.h has a broken test for C99, and incorrectly assumes Sun cc doesn't support extern inline. The define from inline to nothing causes part of the problem. * Three files in the gcc directory declared extern inline call static functions, which causes Sun Studio cc to error out (cf. the attached diff). Rainer I have no objection to these patches. However I think you said they don't actually solve the problem right? So between link xgcc with -lgmp and don't include gmp.h, I prefer the latter approach. Let's not include gmp.h in gcc.c (and anywhere else it isn't necessary.) Say I have a silly question, how is gmp.h getting pulled into gcc.c in the first place? It's supposed to come in via real.h which should only get included by middle-end files linking with real.o ... If we can't disentangle real.h from this then another approach would be to define GENERATOR_FILE (or likely some new macro name) and avoid including the problematic headers that way. Then -D this macro in the gcc.o rule in the Makefile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #5 from ghazi at gcc dot gnu dot org 2009-10-21 19:51 --- (In reply to comment #3) (Also, you don't mention what version of gmp you were using.) Right, sorry: I've tried this with the latest version, gmp 4.3.1. Okay I checked gmp source tarballs, and it looks like the SUNPRO clauses defining __GMP_EXTERN_INLINE were added specifically in gmp-4.3.1. I don't see them in gmp-4.2.4 or gmp-4.3.0. Could you please verify bootstrapping gcc with those two versions of gmp plus Sun's cc to see if they work? If it does we should offer it as a workaround for users until we figure out how we want to solve this long-term. Recommending other versions of gmp as a workaround is helpful even if we hack up a patch to GCC, because gcc-4.3 and 4.4 will not see these fixes until some months in the future when we do another release. Alternatively we may end up recommending to the gmp maintainer(s) that they fix the problem in their package since that's what's really broken IMHO. Either way, it would be helpful to know whether using other versions of gmp would help. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-10-21 01:48 --- I would prefer a solution that does not involve linking xgcc and cpp with libgmp since that links in unecessary code and/or yields a runtime penalty for loading the shared library. It's unusual that we've only just now received this report since gmp has been used since gcc-4.3 (released 1.5 years ago). So I'm curious if something more recently changed to trigger this issue. I.e. did it used to work, and some newer version of either gmp, sun cc, or solaris exposed the problem? Or did it always fail? (Also, you don't mention what version of gmp you were using.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug middle-end/30447] Evaluate complex math functions at compile-time
--- Comment #11 from ghazi at gcc dot gnu dot org 2009-10-14 06:15 --- (In reply to comment #10) except for cproj because that has a wierd non-c99 implementation in glibc. I don't see why one particular library having a bug in its implementation of cproj should prevent GCC from optimizing that function correctly for constant arguments. Had it been any other system, I would agree. But that one particular library is the C lib for the GNU system and I was reluctant to make the GNU compiler incompatible with the GNU C library. There is a bug report filed for cproj from July, but nothing appears to have been done about it. http://sourceware.org/bugzilla/show_bug.cgi?id=10401 If there is consensus that we don't care what glibc does, I can implement the cproj opt. However you may recall I have most of these MPFR/MPC transformations back out if Inf is passed in. The main rationale for cproj is to handle Inf specially. So it would require hacking the infrastructure to allow Inf to pass through. I did this for two-argument calls like mpc_div, but not one-argument calls like mpc_proj. Since it's stage3 I'd defer that till later. Another (perhaps interim) option would be to do the opt only for finite numbers. That would be a one-liner and perhaps suitable for stage3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30447
[Bug middle-end/30447] Evaluate complex math functions at compile-time
--- Comment #9 from ghazi at gcc dot gnu dot org 2009-10-14 01:57 --- Support for the arc functions is done in the mpc svn repository which will be released as mpc-0.8 at the end of October. Use of these functions has been checked into mainline. All C99 builtin complex math functions are done; well, except for cproj because that has a wierd non-c99 implementation in glibc. TODO: Wait for mpc-0.8 to be released. Update gcc's configure to look for mpc-0.8. Hard require MPC. Do remaining stuff from PR40302. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-09-20 16:21:55 |2009-10-14 01:57:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30447
[Bug other/40302] [4.5 Regression] GCC must hard-require MPC before release
--- Comment #6 from ghazi at gcc dot gnu dot org 2009-10-14 01:59 --- Remember to remove the testsuite effective-target code for mpc, mpc_pow and mpc_arc. Also remove the dg- commands in various individual tests. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-09-18 04:18:50 |2009-10-14 01:59:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40302
[Bug fortran/33197] Fortran 2008: math functions
--- Comment #32 from ghazi at gcc dot gnu dot org 2009-10-02 03:52 --- Subject: Bug 33197 Author: ghazi Date: Fri Oct 2 03:52:05 2009 New Revision: 152394 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152394 Log: PR fortran/33197 * gfortran.h (HAVE_mpc_arc): Define. * simplify.c (gfc_simplify_acos): Handle complex acos. (gfc_simplify_acosh): Likewise for acosh. (gfc_simplify_asin): Likewise for asin. (gfc_simplify_asinh): Likewise for asinh. (gfc_simplify_atan): Likewise for atan. (gfc_simplify_atanh): Likewise for atanh. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/simplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33197
[Bug middle-end/41435] GCC doesn't fold complex int division
--- Comment #4 from ghazi at gcc dot gnu dot org 2009-09-27 13:59 --- Fixed -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41435
[Bug middle-end/41435] GCC doesn't fold complex int division
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-09-24 07:08 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01685.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41435
[Bug middle-end/41435] GCC doesn't fold complex int division
--- Comment #3 from ghazi at gcc dot gnu dot org 2009-09-24 20:45 --- Subject: Bug 41435 Author: ghazi Date: Thu Sep 24 20:44:55 2009 New Revision: 152145 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152145 Log: PR middle-end/41435 * fold-const.c (const_binop): Handle complex int division. * tree-complex.c (expand_complex_div_straight, expand_complex_div_wide): Update comments. testsuite: * gcc.dg/torture/builtin-math-7.c: Test complex int division at compile-time. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/builtin-math-7.c trunk/gcc/tree-complex.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41435
[Bug middle-end/41435] GCC doesn't fold complex int division
--- Comment #1 from ghazi at gcc dot gnu dot org 2009-09-23 18:24 --- Mine, working on a patch -- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-23 18:24:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41435
[Bug middle-end/41435] New: GCC doesn't fold complex int division
For integral complex types like complex int, GCC doesn't fold division with
constant arguments. E.g. this testcase should evaluate at compile-time and
link without any errors but doesn't:
extern void link_error(void);
#define EXPR ((2 + 4i) / 2)
int main(void)
{
if (__real EXPR != 1 || __imag EXPR != 2)
link_error();
return 0;
}
--
Summary: GCC doesn't fold complex int division
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41435
[Bug middle-end/41429] New: gomp tests timeout with -fpic
Somewhere between mainline revision 151676 and 151704 I started getting several gomp failures which manifest as timeouts in the testsuite when using -fpic/-fPIC. Here are the differing testsuite results: Clean: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01244.html FAIL: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01344.html The new gomp failures with -fpic/-fPIC are: FAIL: g++.dg/gomp/pr37189.C (test for excess errors) FAIL: libgomp.c++/task-3.C -O0 (test for excess errors) FAIL: libgomp.c++/task-3.C -O1 (test for excess errors) FAIL: libgomp.c++/task-3.C -O2 (test for excess errors) FAIL: libgomp.c++/task-3.C -O3 -fomit-frame-pointer (test for excess errors) FAIL: libgomp.c++/task-3.C -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: libgomp.c++/task-3.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: libgomp.c++/task-3.C -O3 -g (test for excess errors) FAIL: libgomp.c++/task-3.C -Os (test for excess errors) FAIL: libgomp.c++/task-5.C -O0 (test for excess errors) FAIL: libgomp.c++/task-5.C -O1 (test for excess errors) FAIL: libgomp.c++/task-5.C -O2 (test for excess errors) FAIL: libgomp.c++/task-5.C -O3 -fomit-frame-pointer (test for excess errors) FAIL: libgomp.c++/task-5.C -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: libgomp.c++/task-5.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: libgomp.c++/task-5.C -O3 -g (test for excess errors) FAIL: libgomp.c++/task-5.C -Os (test for excess errors) FAIL: libgomp.c++/task-7.C -O0 (test for excess errors) FAIL: libgomp.c++/task-7.C -O1 (test for excess errors) FAIL: libgomp.c++/task-7.C -O2 (test for excess errors) FAIL: libgomp.c++/task-7.C -O3 -fomit-frame-pointer (test for excess errors) FAIL: libgomp.c++/task-7.C -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: libgomp.c++/task-7.C -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: libgomp.c++/task-7.C -O3 -g (test for excess errors) FAIL: libgomp.c++/task-7.C -Os (test for excess errors) -- Summary: gomp tests timeout with -fpic Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41429
[Bug middle-end/41429] gomp tests timeout with -fpic
--- Comment #1 from ghazi at gcc dot gnu dot org 2009-09-21 15:04 ---
To reproduce, target x86_64-unknown-linux-gnu and compile g++.dg/gomp/pr37189.C
with:
cc1plus -quiet -v pr37189.C -dumpbase pr37189.C -mtune=generic -auxbase pr37189
-version -fopenmp -fpic -o pr37189.s
// PR c++/37189
// { dg-do compile }
// { dg-options -fopenmp }
struct S
{
S () {}
S (S const ) {}
};
struct T
{
S s;
};
void
bar (T )
{
}
int
foo ()
{
T t;
#pragma omp task
bar (t);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41429
[Bug objc++/41430] New: [4.5 Regression] exception handling testsuite failures in objc++
Somewhere between mainline revisions 151661 and 151676 I started getting new testsuite failures from objc++ as shown here: Clean: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01158.html FAIL: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01244.html The new failures are: FAIL: obj-c++.dg/except-1.mm execution test FAIL: obj-c++.dg/try-catch-1.mm (internal compiler error) FAIL: obj-c++.dg/try-catch-1.mm (test for excess errors) FAIL: obj-c++.dg/try-catch-2.mm (test for excess errors) FAIL: obj-c++.dg/try-catch-4.mm (internal compiler error) FAIL: obj-c++.dg/try-catch-4.mm (test for excess errors) -- Summary: [4.5 Regression] exception handling testsuite failures in objc++ Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: EH Severity: normal Priority: P3 Component: objc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41430
[Bug middle-end/30789] complex folding inexact
--- Comment #10 from ghazi at gcc dot gnu dot org 2009-09-20 15:39 --- Subject: Bug 30789 Author: ghazi Date: Sun Sep 20 15:39:22 2009 New Revision: 151904 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151904 Log: PR middle-end/30789 * builtins.c (do_mpc_arg2): Accept DO_NONFINITE parameter. (do_mpc_ckconv): Accept FORCE_CONVERT parameter. (fold_builtin_2, do_mpc_arg1): Update accordingly. * fold-const.c (const_binop): Likewise. * real.h (do_mpc_arg2): Update prototype. testsuite: * gcc.dg/torture/builtin-math-7.c: Update for testing Annex G cases in static initializers. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/fold-const.c trunk/gcc/real.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/builtin-math-7.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30789
[Bug middle-end/30789] complex folding inexact
--- Comment #11 from ghazi at gcc dot gnu dot org 2009-09-20 16:08 --- Fixed, but depends on hard-requiring MPC. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||40302 Status|ASSIGNED|RESOLVED Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30789
[Bug middle-end/30447] Evaluate complex math functions at compile-time
--- Comment #8 from ghazi at gcc dot gnu dot org 2009-09-20 16:21 --- Current GCC mainline incorporates all the complex math functions included with mpc-0.7. All that's left are the complex arc functions which are expected in a future MPC release, possibly mpc-0.8. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||40302 OtherBugsDependingO|40302 | nThis|| Last reconfirmed|2009-04-11 15:55:05 |2009-09-20 16:21:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30447
[Bug c/21759] Implement warning for codes at the intersection of C and C++
--- Comment #10 from ghazi at gcc dot gnu dot org 2009-09-07 00:59 --- (In reply to comment #9) See this note for some details on the semantics of this warning, with respect to keywords: http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00808.html What's the status of this PR? Are there any issues remaining for completing -Wc++-compat? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21759
[Bug rtl-optimization/34999] Incorrect FDE entries with hot/cold code section splitting (partition_hot_cold_basic_blocks)
--- Comment #27 from ghazi at gcc dot gnu dot org 2009-09-07 01:04 --- (In reply to comment #25) Subject: Bug 34999 Author: jakub Date: Fri Jul 24 23:30:39 2009 New Revision: 150069 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150069 Log: PR rtl-optimization/34999 * dwarf2out.c (struct dw_fde_struct): Add dw_fde_switch_cfi and dw_fde_switched_cold_to_hot fields. (output_cfi_p): New function. (output_call_frame_info): If fde-dw_fde_switched_sections, output 2 FDEs instead of one with corrupted header. (dwarf2out_do_cfi_startproc): New function. (dwarf2out_begin_prologue): Use it. Initialize fde-dw_fde_switch_cfi and fde-dw_fde_switched_cold_to_hot. (dwarf2out_switch_text_section): Compute fde-dw_fde_switched_cold_to_hot. Switch to new text section here. If dwarf2out_do_cfi_asm, emit .cfi_endproc before it and call dwarf2out_do_cfi_startproc plus emit again currently active CFI insns. Otherwise, compute fde-dw_fde_switch_cfi. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c Is this patch suitable for 4.4.x? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34999
[Bug middle-end/30789] complex folding inexact
--- Comment #9 from ghazi at gcc dot gnu dot org 2009-08-31 03:05 --- Patch for remaining issues posted here: http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01614.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30789
[Bug middle-end/30789] complex folding inexact
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-08-24 14:43 --- Joseph - back in comment#2, you noted that the results of infinity and zero can be ambiguous. I.e. Infinity in either part of a complex number (perhaps infinity of either sign?) is sufficient, and a pair of zeros, explicitly of either sign is also sufficient for zero. This brings up the question that it's possible for GCC to produce a compile-time result (via MPC) that is different from the runtime result (via libgcc2) where both are C99 compliant standard conforming values. Which one the user receives would depend on the context (e.g. static init) or on whether optimizations allowed GCC to fold it at compile-time. Now this happens all the time for finite values, MPFR and MPC are more exact that glibc's math library and often produce different results which are clearly better. However having GCC be more accurate than glibc (where the C library is outside out control) is different IMHO than getting two entirely different results from two parts of GCC, i.e. compile-time folding vs libgcc2. E.g. (Inf NaN) vs (0 -Inf) are both infinities per C99 Annex G. While MPC has committed to producing C99 conforming results for the special cases covered in Annex G, it is entirely possible they may come to different conclusions as to what is best where the standard leaves things ambiguous. Should I continue to pursue having GCC fold the Annex G special cases via MPC if it leads to this kind of discrepancy? Or should be seek to fold these internally, essentially dulpicating the libgcc2 algorithm using real.c functions so that both produce the same result? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30789
