[Bug fortran/37228] F2008: Support g0.d edit descriptor
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-02 08:51 --- Subject: Bug 37228 Author: domob Date: Tue Sep 2 08:50:13 2008 New Revision: 139886 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139886 Log: 2008-09-01 Jerry DeLisle [EMAIL PROTECTED] PR fortran/37228 * io.c (check_format): Allow specifying precision with g0 format. 2008-09-01 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37301 PR libfortran/37228 * io/io.h (write_real_g0): Declare new function to handle g0.d format. * io/transfer.c (formatted_transfer_scalar): Use new function. * io/format.c (parse_format_list): Enable g0.d. * io/write.c (write_a_char4): Delete unused var. (set_fnode_default): New function to set the default fnode w, d, and e factored from write_real. (write_real): Use new factored function. (write_real_g0): New function that sets d to that passed by g0.d format specifier and set format to ES. Default values for w and e are used from the new function, set_fnode_default. 2008-09-01 Jerry DeLisle [EMAIL PROTECTED] PR fortran/37228 * gfortran.dg/fmt_g0_4.f08: Revised test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_g0_4.f08 trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37228
[Bug fortran/37301] libgfortran/io/write.c:304: warning: unused variable 'j'
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-02 08:51 --- Subject: Bug 37301 Author: domob Date: Tue Sep 2 08:50:13 2008 New Revision: 139886 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139886 Log: 2008-09-01 Jerry DeLisle [EMAIL PROTECTED] PR fortran/37228 * io.c (check_format): Allow specifying precision with g0 format. 2008-09-01 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/37301 PR libfortran/37228 * io/io.h (write_real_g0): Declare new function to handle g0.d format. * io/transfer.c (formatted_transfer_scalar): Use new function. * io/format.c (parse_format_list): Enable g0.d. * io/write.c (write_a_char4): Delete unused var. (set_fnode_default): New function to set the default fnode w, d, and e factored from write_real. (write_real): Use new factored function. (write_real_g0): New function that sets d to that passed by g0.d format specifier and set format to ES. Default values for w and e are used from the new function, set_fnode_default. 2008-09-01 Jerry DeLisle [EMAIL PROTECTED] PR fortran/37228 * gfortran.dg/fmt_g0_4.f08: Revised test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_g0_4.f08 trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37301
[Bug inline-asm/37195] unrelated variables get the same memory address in inline assembly
--- Comment #3 from jdemeyer at cage dot ugent dot be 2008-09-02 08:52 --- Created an attachment (id=16187) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16187action=view) Further testcase simplification The third testcase uses only rm and =rm constraints, which means that it might not be specific to i386 targets. I still have to try other targets. Note that the bug only occurs if there are sufficiently many registers in the clobber list (otherwise the compiler just uses registers for everything). -- jdemeyer at cage dot ugent dot be changed: What|Removed |Added Attachment #16183|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37195
[Bug middle-end/37221] Missed early loop-unroll optimization - causes 40% degradation on SPU
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-09-02 09:04 ---
It looks like SCEV does not see that for
(number_of_iterations_in_loop
(analyze_scalar_evolution
(loop_nb = 4)
(scalar = j_3)
(get_scalar_evolution
(scalar = j_3)
(scalar_evolution = ))
(analyze_initial_condition
(loop_phi_node =
j_3 = PHI j_26(4), j_31(7)
)
(init_cond = j_26))
(analyze_evolution_in_loop
(loop_phi_node = j_3 = PHI j_26(4), j_31(7)
)
(add_to_evolution
(loop_nb = 4)
(chrec_before = j_26)
(to_add = 1)
(res = {j_26, +, 1}_4))
(evolution_function = {j_26, +, 1}_4))
(set_scalar_evolution
(scalar = j_3)
(scalar_evolution = {j_26, +, 1}_4))
)
j_26 is defined by
bb 4:
# j_26 = PHI 0(3), 0(5), 0(12), 0(6)
so it is all zeros. This is because the iterative unrolling only does
a cfg cleanup between iterations and not a full constant-prop.
We can fix this special case in analyze_initial_condition, but a real
fix would be to run a (partial) CCP pass after each set of unrolling.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37221
[Bug middle-end/37221] Missed early loop-unroll optimization - causes 40% degradation on SPU
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-09-02 09:09 --- Created an attachment (id=16188) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16188action=view) patch Like with this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37221
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #30 from rguenther at suse dot de 2008-09-02 09:16 --- Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above On Mon, 1 Sep 2008, dave at hiauly1 dot hia dot nrc dot ca wrote: --- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-01 18:17 --- Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above On hppa64-hp-hpux11.11, the test still fails at certain optimizations: FAIL: gcc.c-torture/execute/20040709-1.c execution, -O0 FAIL: gcc.c-torture/execute/20040709-1.c execution, -O1 I'm also seeing the following two fails which appear at first sight to be related: FAIL: gcc.c-torture/execute/920908-2.c execution, -O0 FAIL: gcc.c-torture/execute/920908-2.c execution, -O1 Interesting. The -O0 failure hints at either wrong IL from the start, problems with expansion or with the backend itself (expansion of bitfield operations nowadays expects to be able to truncate intermediate results to the respective bitfield precision, in former times this was not done). Please try to reduce these large testcases and analyze the -O0 failure. Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug middle-end/37293] [4.4 Regression] r139762 breaks libstdc++ build on darwin
--- Comment #15 from dominiq at lps dot ens dot fr 2008-09-02 09:21 --- With the patch in comment #14 I am now building libjava. Regtesting scheduled for tonight (GMT+2). Note that now objc does not build (see http://gcc.gnu.org/ml/gcc/2008-09/msg8.html). Thanks for the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37293
[Bug tree-optimization/37315] [4.4 Regression]: gcc.c-torture/execute/931018-1.c int-compare.c ieee/inf-2.c mzero6.c
--- Comment #5 from hubicka at ucw dot cz 2008-09-02 10:14 --- Subject: Re: [4.4 Regression]: gcc.c-torture/execute/931018-1.c int-compare.c ieee/inf-2.c mzero6.c Honza, why is tree-inline.c:initialize_cfun not calling allocate_struct_function and *then* change whatever elements need changing? There's no comment to reveal the reason. Now, you're just allocating a cleared area and doing a shallow-copy, which causes the clone to have e.g. the same cfun-machine. Badness results. Well, the code is not mine, but it was wirtten at a time struct_function did hold a lot of extra stuff. I will take a look. Why do we allocate MDEP parts of cfun so early? I will try to deffer it to later stage of compilation. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37315
[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2008-09-02 10:17 --- Created an attachment (id=16189) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16189action=view) Simplified preprocessed source It's still big, but it yields a 353-line assembly file. Compile with -O2 -fomit-frame-pointer -mtune=pentium. In rebuild_cgraph_edges: callcgraph_node movl%eax, 32(%esp) [...] movl48(%esp), %eax callinitialize_inline_failed The offset against %esp should be the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296
[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c
--- Comment #79 from hp at gcc dot gnu dot org 2008-09-02 10:18 --- Any news on the hppa testing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
[Bug pch/37307] [4.4 Regression]: g++.dg/pch/system-2.C
--- Comment #3 from hp at gcc dot gnu dot org 2008-09-02 10:34 --- Yep, it's revision 139762 that exposed this FAIL, which of course (appears to) just change behaviour of some optimization levels. Incidentally, that also exposed some of the FAILs in PR37315 (I think I fumble-fingered the failing revision range in that PR): gcc.c-torture/execute/931018-1.c, gcc.c-torture/execute/ieee/inf-2.c, gcc.c-torture/execute/ieee/mzero6.c. I think it'd be proper to let this PR depend on that one, particularly since it makes sense that re-using a cfun-machine could cause this and this PR seeming nasty to track down (PCH and all). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37307
[Bug tree-optimization/37095] [4.4 regression] Trouble with covariant return
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-02 10:34 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37095
[Bug tree-optimization/37095] [4.4 regression] Trouble with covariant return
--- Comment #6 from jakub at gcc dot gnu dot org 2008-09-02 10:35 --- Subject: Bug 37095 Author: jakub Date: Tue Sep 2 10:33:46 2008 New Revision: 139887 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139887 Log: PR tree-optimization/37095 * cgraph.c (cgraph_node): When creating new cgraph node after assembler_name_hash has been populated, record it in the hash table. * g++.dg/inherit/thunk9.C: New test. Added: trunk/gcc/testsuite/g++.dg/inherit/thunk9.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37095
[Bug tree-optimization/37315] [4.4 Regression]: gcc.c-torture/execute/931018-1.c int-compare.c ieee/inf-2.c mzero6.c
--- Comment #6 from hp at gcc dot gnu dot org 2008-09-02 10:41 --- (In reply to comment #5) Well, the code is not mine, but it was wirtten at a time struct_function did hold a lot of extra stuff. SVN blamed you for that code in tree-inline.c and the revision range is yours. The revision range of this PR indicates the original introduction of the FAILs, but they passed again at r139533 and were seen introduced again at 139762. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37315
[Bug ada/37328] New: ACATS la14021 ICE in gimple_assign_set_rhs1, at gimple.h:1747
/home/guerby/build2/gcc/xgcc -c -B/home/guerby/build2/gcc/ -gnatws -O2
-I/home/guerby/build2/gcc/testsuite/ada/acats/support la140211.adb
+===GNAT BUG DETECTED==+
| 4.4.0 20080902 (experimental) [trunk revision 139884]
(x86_64-unknown-linux-gnu) GCC error:|
| in gimple_assign_set_rhs1, at gimple.h:1747 |
| Error detected around la140211.adb:28|
/home/guerby/build2/gcc/gnat1
-I/home/guerby/build2/gcc/testsuite/ada/acats/support -quiet -dumpbase
la140211.adb -O2 -gnatws -mtune=generic la140211.adb -o /tmp/ccnYmXxH.s
This test was passing as of Results for 4.4.0 20080828 (experimental) [trunk
revision 139702]
Breakpoint 1, internal_error (gmsgid=0xe2d4bd in %s, at %s:%d) at
../../trunk2/gcc/diagnostic.c:639
639 {
(gdb) bt
#0 internal_error (gmsgid=0xe2d4bd in %s, at %s:%d) at
../../trunk2/gcc/diagnostic.c:639
#1 0x00732fec in fancy_abort (file=value optimized out, line=1747,
function=0xe42a90 gimple_assign_set_rhs1) at
../../trunk2/gcc/diagnostic.c:699
#2 0x007f9b3b in gimple_build_assign_with_ops_stat (subcode=value
optimized out, lhs=0x2b353640, op1=0x2b34d4c0, op2=0x2af42690) at
../../trunk2/gcc/gimple.h:1747
#3 0x007fc4e5 in gimple_build_assign_stat (lhs=0x2b353640,
rhs=value optimized out) at ../../trunk2/gcc/gimple.c:412
#4 0x00985930 in sra_build_assignment (dst=0x2b353640,
src=0x2b34d480) at ../../trunk2/gcc/tree-sra.c:2311
#5 0x00988815 in sra_build_elt_assignment (elt=value optimized out,
src=0x2b34d480) at ../../trunk2/gcc/tree-sra.c:2507
#6 0x00988e81 in generate_element_init_1 (elt=0x174a2c0,
init=0x2b34d480, seq_p=0x7fffe560) at ../../trunk2/gcc/tree-sra.c:2727
#7 0x00989167 in generate_element_init_1 (elt=0x174a278,
init=0x2b3543f0, seq_p=0x7fffe560) at ../../trunk2/gcc/tree-sra.c:2807
#8 0x00989167 in generate_element_init_1 (elt=0x174a230,
init=0x2b354390, seq_p=0x7fffe560) at ../../trunk2/gcc/tree-sra.c:2807
#9 0x0098a40c in scalarize_init (lhs_elt=0x174a230,
rhs=0x2b354390, gsi=0x7fffe5b0) at ../../trunk2/gcc/tree-sra.c:2830
#10 0x0098508c in sra_walk_function (fns=0xe8bce0) at
../../trunk2/gcc/tree-sra.c:1013
#11 0x0098a088 in tree_sra () at ../../trunk2/gcc/tree-sra.c:3596
#12 0x0098a3a0 in tree_sra_early () at ../../trunk2/gcc/tree-sra.c:3696
#13 0x00869983 in execute_one_pass (pass=0x120e240) at
../../trunk2/gcc/passes.c:1277
#14 0x00869bc5 in execute_pass_list (pass=0x120e240) at
../../trunk2/gcc/passes.c:1325
#15 0x00869bdd in execute_pass_list (pass=0x120dee0) at
../../trunk2/gcc/passes.c:1326
#16 0x00869ee5 in execute_ipa_pass_list (pass=0x120de80) at
../../trunk2/gcc/passes.c:890
#17 0x00ad3f57 in cgraph_optimize () at
../../trunk2/gcc/cgraphunit.c:1234
#18 0x004227e9 in gnat_write_global_declarations () at
../../trunk2/gcc/ada/gcc-interface/utils.c:4747
#19 0x0090f8bf in toplev_main (argc=value optimized out, argv=value
optimized out) at ../../trunk2/gcc/toplev.c:979
#20 0x2ad1d4ca in __libc_start_main () from /lib/libc.so.6
#21 0x0040479a in _start () at ../sysdeps/x86_64/elf/start.S:113
#2 0x007f9b3b in gimple_build_assign_with_ops_stat (subcode=value
optimized out, lhs=0x2b353640, op1=0x2b34d4c0, op2=0x2af42690) at
../../trunk2/gcc/gimple.h:1747
1747gcc_assert (is_gimple_val (rhs));
(gdb) l
1742 GIMPLE_CHECK (gs, GIMPLE_ASSIGN);
1743
1744 /* If there are 3 or more operands, the 2 operands on the RHS must be
1745 GIMPLE values. */
1746 if (gimple_num_ops (gs) = 3)
1747gcc_assert (is_gimple_val (rhs));
1748 else
1749gcc_assert (is_gimple_operand (rhs));
1750
1751 gimple_set_op (gs, 1, rhs);
--
Summary: ACATS la14021 ICE in gimple_assign_set_rhs1, at
gimple.h:1747
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: laurent at guerby dot net
GCC build triplet: x86_64-linux
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37328
[Bug ada/37328] [4.4 Regression] ACATS la14021 ICE in gimple_assign_set_rhs1, at gimple.h:1747
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-02 11:02 --- The following should fix it. Pre-approved if it passes testing. Index: tree-sra.c === *** tree-sra.c (revision 139886) --- tree-sra.c (working copy) *** sra_build_assignment (tree dst, tree src *** 2308,2315 !useless_type_conversion_p (TREE_TYPE (dst), TREE_TYPE (src))) src = fold_convert (TREE_TYPE (dst), src); ! stmt = gimple_build_assign (dst, src); ! gimple_seq_add_stmt (seq, stmt); return seq; } --- 2308,2314 !useless_type_conversion_p (TREE_TYPE (dst), TREE_TYPE (src))) src = fold_convert (TREE_TYPE (dst), src); ! gimplify_assign (dst, src, seq); return seq; } -- rguenth 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-09-02 11:02:10 date|| Summary|ACATS la14021 ICE in|[4.4 Regression] ACATS |gimple_assign_set_rhs1, at |la14021 ICE in |gimple.h:1747 |gimple_assign_set_rhs1, at ||gimple.h:1747 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37328
[Bug testsuite/37326] [4.4 Regression] gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized conststaticvariable 1
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-02 11:33 --- AIL? I guess another PIC related issue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|AIL: gcc.dg/tree-ssa/ssa- |[4.4 Regression] |store-ccp-3.c scan-tree-|gcc.dg/tree-ssa/ssa-store- |dump-times optimized|ccp-3.c scan-tree-dump-times |conststaticvariable 1 |optimized ||conststaticvariable 1 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37326
[Bug testsuite/37325] [4.4 Regression] Visibility test fails
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-02 11:34 --- I suppose a regression? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|Visibility test fails |[4.4 Regression] Visibility ||test fails Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37325
[Bug preprocessor/37324] [4.4 Regression] FAIL: gcc.dg/utf-array.c (test for errors)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|FAIL: gcc.dg/utf-array.c|[4.4 Regression] FAIL: |(test for errors) |gcc.dg/utf-array.c (test ||for errors) Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37324
[Bug middle-end/37323] [4.4 Regression] __builtin_apply failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37323
[Bug debug/37322] [4.4 Regression] FAIL: gfortran.dg/debug/pr35154-dwarf2.f
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|FAIL: |[4.4 Regression] FAIL: |gfortran.dg/debug/pr35154- |gfortran.dg/debug/pr35154- |dwarf2.f|dwarf2.f Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37322
[Bug debug/37321] FAIL: gcc.dg/debug/dwarf2/dwarf-die3.c scan-assembler-not DW_AT_inline
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-02 11:35 --- There must be a dup for this ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37321
[Bug middle-end/37320] [4.4 Regression] gcc.dg/compat execute test fails
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37320
[Bug fortran/37319] [4.4 Regression] FAIL: gfortran.dg/function_kinds_5.f90
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37319
[Bug middle-end/37318] [4.4 Regression] gcc.dg/compat//scalar-by-value-4_x.c:72: ICE: in emit_group_store, at expr.c:2084
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37318
[Bug middle-end/37318] [4.4 Regression] gcc.dg/compat//scalar-by-value-4_x.c:72: ICE: in emit_group_store, at expr.c:2084
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-02 11:38 --- It has been committed already. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37318
[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37316
[Bug tree-optimization/37327] [4.4 Regression] another ice in set_value_range, at tree-vrp.c:397
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-02 11:53 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Component|c |tree-optimization Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to work||4.3.2 Last reconfirmed|-00-00 00:00:00 |2008-09-02 11:53:28 date|| Summary|another ice in |[4.4 Regression] another ice |set_value_range, at tree- |in set_value_range, at tree- |vrp.c:397 |vrp.c:397 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37327
[Bug ada/37328] [4.4 Regression] ACATS la14021 ICE in gimple_assign_set_rhs1, at gimple.h:1747
--- Comment #2 from laurent at guerby dot net 2008-09-02 12:04 --- don't know if it's related but at revision 139884 with your patch libgcc fails to build: (gdb) r -v -I. -I. -I../.././gcc -I../../../trunk2/libgcc -I../../../trunk2/libgcc/. -I../../../trunk2/libgcc/../gcc -I../../../trunk2/libgcc/../include -I../../../trunk2/libgcc/config/libbid -iprefix /home/guerby/build2/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/ -isystem /home/guerby/build2/./gcc/include -isystem /home/guerby/build2/./gcc/include-fixed -MD bid128_add.d -MF bid128_add.dep -MP -MT bid128_add.o -DIN_GCC -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -isystem /n/17/guerby/install2/x86_64-unknown-linux-gnu/include -isystem /n/17/guerby/install2/x86_64-unknown-linux-gnu/sys-include -isystem ./include ../../../trunk2/libgcc/config/libbid/bid128_add.c -quiet -dumpbase bid128_add.c -mtune=generic -auxbase-strip bid128_add.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -version -fPIC -o /tmp/ccFkUZxO.s Starting program: /home/guerby/build2/gcc/cc1 -v -I. -I. -I../.././gcc -I../../../trunk2/libgcc -I../../../trunk2/libgcc/. -I../../../trunk2/libgcc/../gcc -I../../../trunk2/libgcc/../include -I../../../trunk2/libgcc/config/libbid -iprefix /home/guerby/build2/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/ -isystem /home/guerby/build2/./gcc/include -isystem /home/guerby/build2/./gcc/include-fixed -MD bid128_add.d -MF bid128_add.dep -MP -MT bid128_add.o -DIN_GCC -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -isystem /n/17/guerby/install2/x86_64-unknown-linux-gnu/include -isystem /n/17/guerby/install2/x86_64-unknown-linux-gnu/sys-include -isystem ./include ../../../trunk2/libgcc/config/libbid/bid128_add.c -quiet -dumpbase bid128_add.c -mtune=generic -auxbase-strip bid128_add.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -version -fPIC -o /tmp/ccFkUZxO.s ignoring nonexistent directory /n/17/guerby/install2/x86_64-unknown-linux-gnu/include ignoring nonexistent directory /n/17/guerby/install2/x86_64-unknown-linux-gnu/sys-include ignoring nonexistent directory ./include ignoring nonexistent directory /home/guerby/build2/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include ignoring nonexistent directory /home/guerby/build2/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed ignoring nonexistent directory /home/guerby/build2/gcc/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../x86_64-unknown-linux-gnu/include ignoring nonexistent directory /n/17/guerby/install2/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../x86_64-unknown-linux-gnu/include ignoring duplicate directory . ignoring duplicate directory ../../../trunk2/libgcc/. #include ... search starts here: #include ... search starts here: . ../.././gcc ../../../trunk2/libgcc ../../../trunk2/libgcc/../gcc ../../../trunk2/libgcc/../include ../../../trunk2/libgcc/config/libbid /home/guerby/build2/./gcc/include /home/guerby/build2/./gcc/include-fixed /usr/local/include /n/17/guerby/install2/include /n/17/guerby/install2/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include /n/17/guerby/install2/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed /usr/include End of search list. GNU C (GCC) version 4.4.0 20080902 (experimental) [trunk revision 139884] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21), GMP version 4.2.1, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: efd2f8a991a1ada7acfced811ed20512 Program received signal SIGSEGV, Segmentation fault. 0x00713502 in gimplify_modify_expr (expr_p=0x7fffd5d8, pre_p=0x7fffd678, post_p=0x7fffcd08, want_value=0 '\0') at ../../trunk2/gcc/gimplify.c:4293 4293 if (!gimplify_ctxp-into_ssa (gdb) bt #0 0x00713502 in gimplify_modify_expr (expr_p=0x7fffd5d8, pre_p=0x7fffd678, post_p=0x7fffcd08, want_value=0 '\0') at ../../trunk2/gcc/gimplify.c:4293 #1 0x007220e5 in gimplify_expr (expr_p=0x7fffd5d8, pre_p=0x7fffd678, post_p=0x7fffcd08, gimple_test_f=0x6f3199 is_gimple_stmt, fallback=fb_none) at ../../trunk2/gcc/gimplify.c:6345 #2 0x00717555 in gimplify_stmt (stmt_p=0x7fffd5d8, seq_p=0x7fffd678) at ../../trunk2/gcc/gimplify.c:5025 #3 0x006fb066 in gimplify_and_add (t=0x2b417f80, seq_p=0x7fffd678) at ../../trunk2/gcc/gimplify.c:391 #4 0x006e975d in gimplify_assign (dst=0x2b2170a0, src=0x2b697d20, seq_p=0x7fffd678) at ../../trunk2/gcc/gimple.c:458 #5 0x00950025 in sra_build_assignment (dst=0x2b2170a0, src=0x2b697d20) at ../../trunk2/gcc/tree-sra.c:2311 #6 0x00951152
[Bug tree-optimization/37310] gfortran errors in compilation and the making for upgraded compilers
--- Comment #10 from petermorgan at grapevine dot net dot au 2008-09-02 12:11 --- Subject: Re: gfortran errors in compilation and the making for upgraded compilers Dear Guys Here are the requests that you asked for. The first run is without any mention of f2c in option names. It still fails Running unimake to create Makefile for blsum System name: Linux currawong 2.6.25.14-108.fc9.x86_64 #1 SMP Mon Aug 4 13:46:35 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux System release number translated to 2625 No i86 compiler specification--assuming gfortran (gcc 4.2x) Makefile for blsum remade by unimake gfortran -O -Wuninitialized -fno-automatic -fno-backslash blsum.f ../gen_util/gen_util_lib.a ../../libraries/matrix/kinv_lib.a ../../libraries/comlib/com_lib.a -o blsum rm -f blsum.o gfortran -O -Wuninitialized -fno-automatic -fno-backslash ensum.f ../gen_util/gen_util_lib.a ../../libraries/matrix/kinv_lib.a ../../libraries/comlib/com_lib.a -o ensum rm -f ensum.o gfortran -O -Wuninitialized -fno-automatic -fno-backslash tssum.f ../gen_util/gen_util_lib.a ../../libraries/matrix/kinv_lib.a ../../libraries/comlib/com_lib.a -o tssum tssum.f: In function 'remove_ejmp': tssum.f:712: internal compiler error: in set_uids_in_ptset, at tree-ssa-structalias.c:4789 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make: *** [tssum] Error 1 Failure in make_globk -- install_software terminated --- Here is a second run with only -O set It also has the same error in blsum Running unimake to create Makefile for blsum System name: Linux currawong 2.6.25.14-108.fc9.x86_64 #1 SMP Mon Aug 4 13:46:35 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux System release number translated to 2625 No i86 compiler specification--assuming gfortran (gcc 4.2x) Makefile for blsum remade by unimake gfortran -O blsum.f ../gen_util/gen_util_lib.a ../../libraries/matrix/kinv_lib.a ../../libraries/comlib/com_lib.a -o blsum rm -f blsum.o gfortran -O ensum.f ../gen_util/gen_util_lib.a ../../libraries/matrix/kinv_lib.a ../../libraries/comlib/com_lib.a -o ensum rm -f ensum.o gfortran -O tssum.f ../gen_util/gen_util_lib.a ../../libraries/matrix/kinv_lib.a ../../libraries/comlib/com_lib.a -o tssum tssum.f: In function 'remove_ejmp': tssum.f:712: internal compiler error: in set_uids_in_ptset, at tree-ssa-structalias.c:4789 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make: *** [tssum] Error 1 Failure in make_globk -- install_software terminated - Now I know that I had version 10.33 running under 4.2.2 on a 32 bit machine so I built a version 4.2.2 language system on my 64 bit machine. [EMAIL PROTECTED] blsum]$ gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.2.2.source/configure --prefix=/opt --with-mpfr-lib=/opt/lib --with-mpfr-include=/opt/include --disable-multilib Thread model: posix gcc version 4.2.2 There are no errors in a compilation of GAMIT/GLOBK when I use this package. I have attached the code modules for you. As I said they compile okay under 4.2.2 Please let me know how this helps. cheers Peter kargl at gcc dot gnu dot org wrote: --- Comment #9 from kargl at gcc dot gnu dot org 2008-09-02 03:46 --- (In reply to comment #8) gfortran -O3 -Wuninitialized -fno-f2c -ffast-math -fno-automatic -fno-backslash tssum.f ../gen_util/gen_util_lib.a ../../libraries/matrix/kinv_lib.a ../../libraries/comlib/com_lib.a -o tssum tssum.f: In function 'remove_ejmp': tssum.f:712: internal compiler error: in set_uids_in_ptset, at tree-ssa-structalias.c:4789 Please submit a full bug report, What happens if you use a sane set of options? In particular, DO NOT USE any option with f2c in it name. DO NOT USE --ffast-math, which is misnamed. What happens if you use -O or -O2. Finally, is the source available? -- *** * * * Peter and Carol Morgan * * 20 Goodparla St* * Hawker, ACT, 2614 * * Australia * * * * Home Phone +61 (0)2 6254 0137 * * Peter's Mobile +61 (0)4 1854 0137 * * * * * *** program tssum * Program to generate PBO time series files * * Usages: * tssum dir prod_id -R list of .org files * * where dir -- directory to put the time series in. This directory * will be checked for existing files and these will be appended to * prod_id is product id with form: pbo.final_frame. Characters * 5:9 will used for
[Bug ada/37328] [4.4 Regression] ACATS la14021 ICE in gimple_assign_set_rhs1, at gimple.h:1747
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-02 12:23 ---
Ok, try
Index: tree-sra.c
===
*** tree-sra.c (revision 139886)
--- tree-sra.c (working copy)
*** static gimple_seq
*** 2144,2150
sra_build_assignment (tree dst, tree src)
{
gimple stmt;
! gimple_seq seq = NULL;
/* Turning BIT_FIELD_REFs into bit operations enables other passes
to do a much better job at optimizing the code.
From dst = BIT_FIELD_REF var, sz, off we produce
--- 2144,2150
sra_build_assignment (tree dst, tree src)
{
gimple stmt;
! gimple_seq seq = NULL, seq2 = NULL;
/* Turning BIT_FIELD_REFs into bit operations enables other passes
to do a much better job at optimizing the code.
From dst = BIT_FIELD_REF var, sz, off we produce
*** sra_build_assignment (tree dst, tree src
*** 2308,2313
--- 2308,2315
!useless_type_conversion_p (TREE_TYPE (dst), TREE_TYPE (src)))
src = fold_convert (TREE_TYPE (dst), src);
+ src = force_gimple_operand (src, seq2, false, NULL_TREE);
+ gimple_seq_add_seq (seq, seq2);
stmt = gimple_build_assign (dst, src);
gimple_seq_add_stmt (seq, stmt);
return seq;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37328
[Bug middle-end/37221] Missed early loop-unroll optimization - causes 40% degradation on SPU
--- Comment #8 from tehila at il dot ibm dot com 2008-09-02 12:47 --- Thank you, Richard! This patch indeed does the work and unrolls the loop. The SRA works fine and we get 40% improvement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37221
[Bug ada/37328] [4.4 Regression] ACATS la14021 ICE in gimple_assign_set_rhs1, at gimple.h:1747
--- Comment #4 from laurent at guerby dot net 2008-09-02 13:02 ---
With the second patch I get an ICE during Ada rts build.
+===GNAT BUG DETECTED==+
| 4.4.0 20080902 (experimental) [trunk revision 139884]
(x86_64-unknown-linux-gnu) GCC error:|
| in generate_copy_inout, at tree-sra.c:2602 |
| Error detected around a-ncelfu.ads:23|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report. |
| Include the exact gcc or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+==+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:424
make[7]: *** [a-ncelfu.o] Error 1
make[7]: Leaving directory `/home/guerby/build2/gcc/ada/rts'
$ gdb /home/guerby/build2/./gcc/gnat1
(gdb) b internal_error
Breakpoint 1 at 0x732ef0: file ../../trunk2/gcc/diagnostic.c, line 639.
(gdb) r -gnatwa -quiet -dumpbase a-ncelfu.ads -O2 -W -Wall -fPIC -g -gnatpg
-mtune=generic -gnatO a-ncelfu.o a-ncelfu.ads -o /tmp/ccaIlL98.s
Starting program: /home/guerby/build2/gcc/gnat1 -gnatwa -quiet -dumpbase
a-ncelfu.ads -O2 -W -Wall -fPIC -g -gnatpg -mtune=generic -gnatO a-ncelfu.o
a-ncelfu.ads -o /tmp/ccaIlL98.s
Breakpoint 1, internal_error (gmsgid=0xe2d53d in %s, at %s:%d) at
../../trunk2/gcc/diagnostic.c:639
639 {
(gdb) bt
#0 internal_error (gmsgid=0xe2d53d in %s, at %s:%d) at
../../trunk2/gcc/diagnostic.c:639
#1 0x00732fec in fancy_abort (file=value optimized out, line=2602,
function=0xe8bda0 generate_copy_inout) at ../../trunk2/gcc/diagnostic.c:699
#2 0x00989942 in generate_copy_inout (elt=0x17540d8, copy_out=0 '\0',
expr=0x2b735ee0, seq_p=0x7fffe558) at ../../trunk2/gcc/tree-sra.c:2602
#3 0x0098b828 in scalarize_ldst (elt=0x17540d8, other=0x2b735ee0,
gsi=0x7fffe5b0, is_output=160 '#65533;') at
../../trunk2/gcc/tree-sra.c:3504
#4 0x00984fec in sra_walk_function (fns=0xe8bd60) at
../../trunk2/gcc/tree-sra.c:983
#5 0x0098a0b8 in tree_sra () at ../../trunk2/gcc/tree-sra.c:3598
#6 0x0098a3d0 in tree_sra_early () at ../../trunk2/gcc/tree-sra.c:3698
#7 0x00869983 in execute_one_pass (pass=0x120e2c0) at
../../trunk2/gcc/passes.c:1277
#8 0x00869bc5 in execute_pass_list (pass=0x120e2c0) at
../../trunk2/gcc/passes.c:1325
#9 0x00869bdd in execute_pass_list (pass=0x120df60) at
../../trunk2/gcc/passes.c:1326
#10 0x00869ee5 in execute_ipa_pass_list (pass=0x120df00) at
../../trunk2/gcc/passes.c:890
#11 0x00ad3fd7 in cgraph_optimize () at
../../trunk2/gcc/cgraphunit.c:1234
#12 0x004227e9 in gnat_write_global_declarations () at
../../trunk2/gcc/ada/gcc-interface/utils.c:4747
#13 0x0090f8bf in toplev_main (argc=value optimized out, argv=value
optimized out) at ../../trunk2/gcc/toplev.c:979
#14 0x2ad1d4ca in __libc_start_main () from /lib/libc.so.6
#15 0x0040479a in _start () at ../sysdeps/x86_64/elf/start.S:113
(gdb) c
Continuing.
+===GNAT BUG DETECTED==+
| 4.4.0 20080902 (experimental) [trunk revision 139884]
(x86_64-unknown-linux-gnu) GCC error:|
| in generate_copy_inout, at tree-sra.c:2602 |
| Error detected around a-ncelfu.ads:23|
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37328
[Bug middle-end/37221] Missed early loop-unroll optimization - causes 40% degradation on SPU
--- Comment #9 from rguenther at suse dot de 2008-09-02 13:10 --- Subject: Re: Missed early loop-unroll optimization - causes 40% degradation on SPU On Tue, 2 Sep 2008, tehila at il dot ibm dot com wrote: --- Comment #8 from tehila at il dot ibm dot com 2008-09-02 12:47 --- Thank you, Richard! This patch indeed does the work and unrolls the loop. The SRA works fine and we get 40% improvement. If you give the patch bootstrap testing I'll approve it for trunk. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37221
[Bug ada/37328] [4.4 Regression] ACATS la14021 ICE in gimple_assign_set_rhs1, at gimple.h:1747
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-09-02 13:14 --- up to generate_copy_inout and call debug_generic_expr (expr) call debug_generic_expr (t) call debug_gimple_seq (tmp_seq) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37328
[Bug ada/37328] [4.4 Regression] ACATS la14021 ICE in gimple_assign_set_rhs1, at gimple.h:1747
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-09-02 13:20 --- Probably the following will fix that... *** generate_copy_inout (struct sra_elt *elt *** 2597,2604 t = build2 (COMPLEX_EXPR, elt-type, r, i); tmp_seq = sra_build_bf_assignment (expr, t); ! gcc_assert (gimple_seq_singleton_p (tmp_seq)); ! SSA_NAME_DEF_STMT (expr) = gimple_seq_first_stmt (tmp_seq); gimple_seq_add_seq (seq_p, tmp_seq); } else if (elt-replacement) --- 2599,2605 t = build2 (COMPLEX_EXPR, elt-type, r, i); tmp_seq = sra_build_bf_assignment (expr, t); ! SSA_NAME_DEF_STMT (expr) = gimple_seq_last_stmt (tmp_seq); gimple_seq_add_seq (seq_p, tmp_seq); } else if (elt-replacement) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37328
[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2008-09-02 13:26 --- The offset against %esp should be the same. Actually it should be adjusted to the value of %esp: rebuild_cgraph_edges: pushl %ebp pushl %edi pushl %esi pushl %ebx subl$56, %esp pushl current_function_decl callcgraph_node movl%eax, 32(%esp) [...] .L21: movl48(%esp), %eax callinitialize_inline_failed movl48(%esp), %edx cmpl$0, 76(%edx) jne .L53 addl$44, %esp xorl%eax, %eax popl%ebx popl%esi popl%edi popl%ebp ret so 16(%esp) instead of 48(%esp) if the stack adjustments are correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296
[Bug java/37329] New: ICE during .jar - .bin compilation with -freduced-reflection.
$ /usr/lib64/gcc/x86_64-pld-linux/4.3.2/jc1 \ antlr.jar -fhash-synchronization -fno-use-divide-subroutine \ -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions \ -quiet -dumpbase antlr.jar -mtune=generic -auxbase antlr -g0 \ -freduced-reflection -fbootclasspath=./:/usr/share/java/libgcj-4.3.2.jar *** glibc detected *** /usr/lib64/gcc/x86_64-pld-linux/4.3.2/jc1: malloc(): memory corruption (fast): 0x010e7ae0 *** === Backtrace: = /lib64/libc.so.6[0x7f4979abd4e8] /lib64/libc.so.6[0x7f4979ac03ea] /lib64/libc.so.6(__libc_malloc+0xa1)[0x7f4979ac1b01] /usr/lib64/gcc/x86_64-pld-linux/4.3.2/jc1[0x9270e8] /usr/lib64/gcc/x86_64-pld-linux/4.3.2/jc1[0x5b4f7e] /usr/lib64/gcc/x86_64-pld-linux/4.3.2/jc1[0x5b6b65] /usr/lib64/gcc/x86_64-pld-linux/4.3.2/jc1[0x4070d9] /usr/lib64/gcc/x86_64-pld-linux/4.3.2/jc1[0x408657] /usr/lib64/gcc/x86_64-pld-linux/4.3.2/jc1[0x40a16d] /usr/lib64/gcc/x86_64-pld-linux/4.3.2/jc1[0x40d1e3] /usr/lib64/gcc/x86_64-pld-linux/4.3.2/jc1[0x42d0a2] /usr/lib64/gcc/x86_64-pld-linux/4.3.2/jc1[0x42dcba] /usr/lib64/gcc/x86_64-pld-linux/4.3.2/jc1[0x5bb90b] /lib64/libc.so.6(__libc_start_main+0xe6)[0x7f4979a66486] /usr/lib64/gcc/x86_64-pld-linux/4.3.2/jc1[0x403f69] -- Summary: ICE during .jar - .bin compilation with -freduced- reflection. Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC target triplet: x86_64-gnu-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37329
[Bug java/37329] ICE during .jar - .bin compilation with -freduced-reflection.
--- Comment #1 from pluto at agmk dot net 2008-09-02 13:33 --- Created an attachment (id=16190) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16190action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37329
[Bug bootstrap/37330] New: mpfr 32/64 multilib issue
Hi, My mpfr and gmp 32/64 bits libraries are installed respectively in $PREFIX/lib and $PREFIX/lib64. 'configure' is called as following: configure .. --with-gmp-lib=$PREFIX/lib --with-mpfr-lib=$PREFIX/lib ... It produces a Makefile with the following line: HOST_GMPLIBS = -L$PREFIX/lib -L$PREFIX/lib -lmpfr -lgmp As far as I can see, there is no specific management of multilib context and 'make bootstrap' fails on mpfr link error. As a workaround, I used the 64bits path for gmp and the 32bits path for mpfr: configure .. --with-gmp-lib=$PREFIX/lib64 --with-mpfr-lib=$PREFIX/lib ... The Makefile line becomes: HOST_GMPLIBS = -L$PREFIX/lib64 -L$PREFIX/lib -lmpfr -lgmp Then it works, even on a full 32 bits context (ie. i686-unknown-pc-linux) but it's ugly, doesn't it? ;-) Rgds, Olivier -- Summary: mpfr 32/64 multilib issue Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: olivier dot raoult at st dot com GCC build triplet: x86_64-unknown-linux-gnu (RedHat 3/4) GCC host triplet: x86_64-unknown-linux-gnu (RedHat 3/4) GCC target triplet: x86_64-unknown-linux-gnu (RedHat 3/4) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37330
[Bug tree-optimization/37327] [4.4 Regression] another ice in set_value_range, at tree-vrp.c:397
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-02 13:48 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37327
[Bug tree-optimization/37327] [4.4 Regression] another ice in set_value_range, at tree-vrp.c:397
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-02 13:49 --- Subject: Bug 37327 Author: rguenth Date: Tue Sep 2 13:48:11 2008 New Revision: 139890 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139890 Log: 2008-09-02 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/37327 * tree-vrp.c (register_new_assert_for): Make sure to not have TREE_OVERFLOW set on the bound. * gcc.c-torture/compile/pr37327.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr37327.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37327
[Bug bootstrap/37330] mpfr 32/64 multilib issue
--- Comment #1 from schwab at suse dot de 2008-09-02 13:51 --- Why do you need two flavors? The mfpr/gmp libraries are only used for the compiler which is only built in one flavor. If you are building for x86-64 you should configure with $PREFIX/lib64 for both library directories. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37330
[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c
--- Comment #80 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-02 14:06 --- Subject: Re: [4.4 Regression]: gcc.dg/weak/weak-1.c Any news on the hppa testing? I didn't do anything further with the 32-bit port. I did do a hppa64-hpux11.11 build with your change. I went through the C test results yesterday. Although there are lots of failures, I didn't see any problem related to your proposed change. So, if there are no other problems, I would say submit the change for review. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37170
[Bug bootstrap/37330] mpfr 32/64 multilib issue
--- Comment #2 from olivier dot raoult at st dot com 2008-09-02 14:12 --- Hmm.. maybe! I tried to script a gcc builder program which shall work on i686, and on x86_64. Then, for the second, it shall support native 64 and -m32 modes. As libmpfr and libmgp appear as dynamic libraries, I assumed they will be used ... but 'ldd g++' doesn't confirm. So, the only thing I have to do is to use -with-..-lib=$PREFIX/lib64 on x86_64 machines and -with-..-lib=$PREFIX/lib on i686?!? Good! If it works, it's a non-bug :( .. Sorry and thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37330
[Bug tree-optimization/36766] [4.4 Regression] natGC.cc:229: internal compiler error: Segmentation fault
--- Comment #22 from jakub at gcc dot gnu dot org 2008-09-02 14:23 --- Created an attachment (id=16191) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16191action=view) gcc44-pr36766.patch I don't see tree-ssa-dom.c or tree-ssa-pre.c are at fault here (not guessing that some basic block will be purged as unneeded), so it should be gimple_purge_all_eh_edges that needs to be changed to handle this. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36766
[Bug c/37331] New: ICE trying to compile /dev/null
output of gcc-my432 -v: Using built-in specs. Target: mingw32 Configured with: ../gcc-4.3.2/configure --with-gnu-as --with-gnu-ld --with-dwarf2 --enable-decimal-float=bid --with-gcc --disable-libgomp --host=mingw32 --build=mingw32 --target=mingw32 --program-suffix=-my432 --with-arch=pentium3 --with-tune=pentium3 --disable-werror --prefix=/mingw --with-local-prefix=/mingw/local --enable-threads --disable-nls --enable-languages=c,c++,objc,obj-c++ --disable-win32-registry --disable-sjlj-exceptions --enable-version-specific-runtime-libs --with-gmp=/gmp-423-p2 --with-mpfr=/mpfr-231-p1 --disable-libssp Thread model: win32 gcc version 4.3.2 (GCC) Command line was: (inside of MSYS) gcc-my432 -x c /dev/null And output is: cc1.exe: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Using --save-temps somehow doesn't produce any files at all... Using an older GCC version (gcc version 3.4.5 (mingw special)) does indeed work! :-) I hope you fix this silly bug and that it is perhaps also valuable for compiling other real files. -- Summary: ICE trying to compile /dev/null Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: patriciak784-gccmainling at yahoo dot de GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37331
[Bug c/37331] ICE trying to compile /dev/null
--- Comment #1 from patriciak784-gccmainling at yahoo dot de 2008-09-02 14:37 --- Please be aware that compiling /dev/null is used in glibc to produce empty object files! So it seems not to be a crazy thing to do... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37331
[Bug fortran/37319] [4.4 Regression] FAIL: gfortran.dg/function_kinds_5.f90
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37319
[Bug c++/37332] New: ice for legal code
I just tried to compile the Suse Linux package agg-2.5 with the GNU C++ compiler version 4.4 snapshot 20080829. The compiler said distortions.cpp:705: internal compiler error: in make_decl_rtl, at varasm.c:1297 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Pre-processed source code attached. Compiler flag -O2 required. -- Summary: ice for legal code Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37332
[Bug c++/37332] ice for legal code
--- Comment #1 from dcb314 at hotmail dot com 2008-09-02 14:53 --- Created an attachment (id=16192) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16192action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37332
[Bug c/37333] New: ice for legal C code
I just tried to compile the Suse Linux package apache2-mod_python-3.3.1-122 with the GNU C compiler version 4.4 snapshot 20080829. The compiler said psp_parser.c:1241: internal compiler error: in ira_flattening, at ira-build.c:2146 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Pre-processed source code attached. Flags -O3 -fPIC required. -- Summary: ice for legal C code Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37333
[Bug c/37333] ice for legal C code
--- Comment #1 from dcb314 at hotmail dot com 2008-09-02 14:55 --- Created an attachment (id=16193) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16193action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37333
[Bug testsuite/37325] [4.4 Regression] Visibility test fails
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-02 14:57 --- Subject: Re: [4.4 Regression] Visibility test fails I suppose a regression? No, the tests are new. I'll have to check the assembly output to see why they are failing. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37325
[Bug debug/37322] [4.4 Regression] FAIL: gfortran.dg/debug/pr35154-dwarf2.f
--- Comment #1 from jakub at gcc dot gnu dot org 2008-09-02 15:02 --- Created an attachment (id=16194) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16194action=view) Q I can believe your comment #5, but I can't believe DW_AT_name is not emitted at all (just tried it with x86_64-linux - i686-darwin9 cross). Darwin, as it probably doesn't support mergeable .debug_str, at -gdwarf-2 -O0 -dA outputs DW_AT_name for __BLNK__ and label as inline strings rather than references to .debug_str and the regexps were expecting just the latter. This patch should handle both variants. This fixes this testcase for me in the cross. Can you test it on native darwin? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37322
[Bug c++/37332] [4.4 Regression] ICE in make_decl_rtl, at varasm.c:1297
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-09-02 15:15 --- Reducing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to work||4.3.2 Summary|ice for legal code |[4.4 Regression] ICE in ||make_decl_rtl, at ||varasm.c:1297 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37332
[Bug tree-optimization/37207] [4.4 Regression] ice at tree-ssa-ifcombine.c:222 for -Os
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-09-02 15:16 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37207
[Bug tree-optimization/37185] [4.4 Regression]: gcc.dg/matrix/transpose-3.c:16: internal compiler error: verify_stmts failed
--- Comment #6 from jakub at gcc dot gnu dot org 2008-09-02 15:18 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37185
[Bug rtl-optimization/37333] [4.4 Regression] ICE in ira_flattening, at ira-build.c:2146
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||vmakarov at gcc dot gnu dot ||org Component|c |rtl-optimization Keywords||ice-on-valid-code Summary|ice for legal C code|[4.4 Regression] ICE in ||ira_flattening, at ira- ||build.c:2146 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37333
[Bug debug/37322] [4.4 Regression] FAIL: gfortran.dg/debug/pr35154-dwarf2.f
--- Comment #2 from dominiq at lps dot ens dot fr 2008-09-02 15:30 --- I can believe your comment #5, but I can't believe DW_AT_name is not emitted at all (just tried it with x86_64-linux - i686-darwin9 cross). I am not sure to understand. If I use egrep with label.*DW_AT_name on the assembly file, I get: [ibook-dhum] f90/bug% egrep label.*DW_AT_name pr35154-dwarf2.s .ascii label\0# DW_AT_name So if \label\[^\n\]*\\[^\n\]*DW_AT_name) is some Tcl equivalent of label.*DW_AT_name for egrep, then it is likely that the test pass. I have tried several variants around (with or without debug/, adding gfortran.dg/) make -k check-gfortran RUNTESTFLAGS=dg.exp=debug/pr35154-dwarf2.f. without being able to test the patched file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37322
[Bug inline-asm/37188] There is no way to specify double precision floating point registers in inline asm arguments (VFP)
--- Comment #1 from siarhei dot siamashka at gmail dot com 2008-09-02
15:50 ---
Well, looks like it is not a missing feature, but just incompleteness of
documentation :)
It is possible to use double precision floating point registers and NEON
128-bit registers in the following way:
--
#include arm_neon.h
int16x8_t test_neon(int16x8_t b, int16x8_t c)
{
int16x8_t a;
asm (
vadd.i32 %q0, %q1, %q2 \n\t
: =w (a)
: w (b), w (c)
);
return a;
}
double test_double(double b, double c)
{
double a;
asm (
faddd %P0, %P1, %P2 \n\t
: =w (a)
: w (b), w (c)
);
return a;
}
--
Disassembly of section .text:
test_quad:
0: e52db004push{fp}; (str fp, [sp, #-4]!)
4: e28db000add fp, sp, #0 ; 0x0
8: ec410b12vmovd2, r0, r1
c: ec432b13vmovd3, r2, r3
10: ed9b6b01vldrd6, [fp, #4]
14: ed9b7b03vldrd7, [fp, #12]
18: f2224846vadd.i32q2, q1, q3
1c: ec510b14vmovr0, r1, d4
20: ec532b15vmovr2, r3, d5
24: e28bd000add sp, fp, #0 ; 0x0
28: e8bd0800pop {fp}
2c: e12fff1ebx lr
0030 test_double:
30: ec410b15vmovd5, r0, r1
34: e52db004push{fp}; (str fp, [sp, #-4]!)
38: ec432b16vmovd6, r2, r3
3c: e28db000add fp, sp, #0 ; 0x0
40: ee357b06faddd d7, d5, d6
44: ec510b17vmovr0, r1, d7
48: e28bd000add sp, fp, #0 ; 0x0
4c: e8bd0800pop {fp}
50: e12fff1ebx lr
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37188
[Bug c++/37332] [4.4 Regression] ICE in make_decl_rtl, at varasm.c:1297
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-02 15:58 --- Created an attachment (id=16195) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16195action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37332
[Bug c++/37332] [4.4 Regression] ICE in make_decl_rtl, at varasm.c:1297
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-09-02 15:59 --- Confirmed. -- rguenth 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-09-02 15:59:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37332
[Bug middle-end/37334] New: gcc.dg/fastmath-2.c doesn't work
On Linux/ia32, I got Executing on host: /export/gnu/import/svn/gcc-test/bld/gcc/xgcc -B/export/gnu/import/svn/gcc-test/bld/gcc/ /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/fastmath-2.c -O2 -ffast-math -lm -m32 -o ./fastmath-2.exe(timeout = 300) PASS: gcc.dg/fastmath-2.c (test for excess errors) Setting LD_LIBRARY_PATH to :/export/gnu/import/svn/gcc-test/bld/gcc:/export/gnu/import/svn/gcc-test/bld/gcc/32::/export/gnu/import/svn/gcc-test/bld/gcc:/export/gnu/import/svn/gcc-test/bld/gcc/32:/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/libstdc++-v3/.libs:/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/libmudflap/.libs:/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/libssp/.libs:/export/gnu/import/svn/gcc-test/bld/x86_64-unknown-linux-gnu/libgomp/.libs:/export/gnu/import/svn/gcc-test/bld/./gcc:/export/gnu/import/svn/gcc-test/bld/./prev-gcc FAIL: gcc.dg/fastmath-2.c execution test -- Summary: gcc.dg/fastmath-2.c doesn't work Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37334
[Bug objc++/37335] New: Boostrap failed on obj-c++ too many arguments to function 'build_array_ref'
A bootstrap of the trunk failed at stage 2 with the following: gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber ../../gcc/gcc/objc/objc-act.c -o objcp/objcp-act.o ../../gcc/gcc/objc/objc-act.c: In function build_typed_selector_reference: ../../gcc/gcc/objc/objc-act.c:2634: error: too many arguments to function build_array_ref ../../gcc/gcc/objc/objc-act.c: In function build_selector_reference: ../../gcc/gcc/objc/objc-act.c:2653: error: too many arguments to function build_array_ref ../../gcc/gcc/objc/objc-act.c:2667: error: too many arguments to function build_array_ref ../../gcc/gcc/objc/objc-act.c: In function objc_substitute_decl: ../../gcc/gcc/objc/objc-act.c:3053: error: too many arguments to function build_array_ref make[3]: *** [objcp/objcp-act.o] Error 1 make[3]: Leaving directory `/home/ed/obj/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/ed/obj' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/ed/obj' make: *** [bootstrap] Error 2 Revision 139866 introduced a new argument in objc_substitute_decl in objc-act.c -- Summary: Boostrap failed on obj-c++ too many arguments to function 'build_array_ref' Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: 3dw4rd at verizon dot net GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37335
[Bug target/37283] [4.4 Regression] Cannot build crtbegin.o for ARM
--- Comment #5 from sam at gcc dot gnu dot org 2008-09-02 16:24 --- Subject: Bug 37283 Author: sam Date: Tue Sep 2 16:23:29 2008 New Revision: 139892 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139892 Log: gcc/ PR target/37283 * opts.c (decode_options): Move processing of -fno-unit-at-a-time and -fno-toplevel-reorder after handle_options. Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37283
[Bug target/37283] [4.4 Regression] Cannot build crtbegin.o for ARM
--- Comment #6 from sam at gcc dot gnu dot org 2008-09-02 16:25 --- This is fixed in SVN trunk. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37283
[Bug testsuite/37325] [4.4 Regression] Visibility test fails
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2008-09-02 16:25 --- Subject: Re: [4.4 Regression] Visibility test fails No, the tests are new. I'll have to check the assembly output to see why they are failing. Checked visibility-14.c. The .hidden directive is not being emitted. Same with gcc 4.3.2. See /* Define if your assembler and linker support .hidden. */ #define HAVE_GAS_HIDDEN 1 in auto-host.h. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37325
[Bug bootstrap/36908] [4.4 Regression] bootstrap forever with BOOT_CFLAGS=-O2 -ftree-loop-distribution
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-02 16:44 --- Why got this even marked as regression? GCC 4.3.1 didn't support -ftree-loop-distribution, it is a new option, so it can't regress. The loop in question is: bb 8: # state_89 = PHI state_17(9), state_5(7) # prephitmp.18_6 = PHI state_89(9), pretmp.17_59(7) state_17 = state_89-next_alt_state; state_89-next_alt_state = prephitmp.18_6; first_free_alt_state_lsm.29_18 = state_89; if (state_17 != 0B) goto bb 9; else goto bb 10; bb 9: goto bb 8; and gets distributed into: bb 16: # state_62 = PHI state_22(17), state_5(7) # prephitmp.18_26 = PHI state_62(17), pretmp.17_59(7) state_22 = state_62-next_alt_state; state_62-next_alt_state = prephitmp.18_26; if (state_22 != 0B) goto bb 17; else goto bb 18; bb 17: goto bb 16; bb 18: # prephitmp.18_90 = PHI prephitmp.18_26(16) bb 8: # state_89 = PHI state_17(9), state_5(18) state_17 = state_89-next_alt_state; state_89-next_alt_state = prephitmp.18_90; first_free_alt_state_lsm.29_18 = state_89; if (state_17 != 0B) goto bb 9; else goto bb 10; bb 9: goto bb 8; Perhaps tree-loop-distribution.c is confused by a PHI depending on previous PHI result? -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36908
[Bug tree-optimization/37310] gfortran errors in compilation and the making for upgraded compilers
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu 2008-09-02 16:57 --- Subject: Re: gfortran errors in compilation and the making for upgraded compilers On Tue, Sep 02, 2008 at 12:11:23PM -, petermorgan at grapevine dot net dot au wrote: gfortran -O -Wuninitialized -fno-automatic -fno-backslash tssum.f ../gen_util/gen_util_lib.a ../../libraries/matrix/kinv_lib.a ../../libraries/comlib/com_lib.a -o tssum tssum.f: In function 'remove_ejmp': tssum.f:712: internal compiler error: in set_uids_in_ptset, at tree-ssa-structalias.c:4789 I cannot reproduce this problem with troutmask:sgk[225] gfortran42 --version GNU Fortran (GCC) 4.2.5 20080702 (prerelease) troutmask:sgk[226] gfortran43 --version GNU Fortran (GCC) 4.3.2 20080717 (prerelease) troutmask:sgk[227] gfc4x --version GNU Fortran (GCC) 4.4.0 20080829 (experimental) [trunk revision 139774] Of coures, I can only do a compile test because I do not have the source code for the kinv_lib.a so I can't link a final executable. Can you email me off-list a gzipped tar ball of all the need files? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37310
[Bug fortran/37336] New: Fortran 2003: Finish derived-type finalization
Derived-type finalization as defined in Fortran 2003 is at the moment partially implemented in gfortran. FINAL bindings are parsed and stored/loaded in .mod module files, but finalizers are not yet executed and a not-yet-implemented error appears on using FINAL. -- Summary: Fortran 2003: Finish derived-type finalization Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
-- domob at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug middle-end/37293] [4.4 Regression] r139762 breaks libstdc++ build on darwin
--- Comment #16 from hjl dot tools at gmail dot com 2008-09-02 17:02 --- Revision 139762 also failed to build povray in SPEC CPU 2006. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com, Joey dot ye at intel ||dot com, weiliang dot lin at ||intel dot com, xuepeng dot ||guo at intel dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37293
[Bug middle-end/37293] [4.4 Regression] r139762 breaks libstdc++ build on darwin
--- Comment #17 from hjl dot tools at gmail dot com 2008-09-02 17:05 --- (In reply to comment #16) Revision 139762 also failed to build povray in SPEC CPU 2006. With -O3 -ffast-math on Linux/x86-64, we got g++ -O3 -ffast-math -DSPEC_CPU_LP64atmosph.o bbox.o bcyl.o bezier.o blob.o boxes.o bsphere.o camera.o chi2.o colour.o colutils.o cones.o csg.o defaultplatformbase.o defaultrenderfrontend.o discs.o express.o fileinputoutput.o fncode.o fnintern.o fnpovfpu.o fnsyntax.o fpmetric.o fractal.o function.o hcmplx.o hfield.o histogra.o iff.o image.o interior.o isosurf.o lathe.o lbuffer.o lightgrp.o lighting.o mathutil.o matrices.o media.o mesh.o messageoutput.o normal.o objects.o octree.o optout.o parse.o parsestr.o parstxtr.o pattern.o pgm.o photons.o pigment.o planes.o point.o poly.o polygon.o polysolv.o pov_mem.o pov_util.o povms.o povmscpp.o povmsend.o povmsrec.o povray.o ppm.o prism.o processoptions.o processrenderoptions.o quadrics.o quatern.o rad_data.o radiosit.o ray.o rendctrl.o render.o renderfrontend.o renderio.o sor.o specrand.o spec_qsort.o spheres.o sphsweep.o splines.o statspov.o stringutilities.o super.o targa.o textstream.o textstreambuffer.o texture.o tokenize.o torus.o triangle.o truetype.o txttest.o userdisp.o userio.o vbuffer.o vlbuffer.o warps.o -o povray lighting.o: In function `pov::Reflect(double*, pov::Ray_Struct*, double*, double*, float*, double)': lighting.cpp:(.text+0x26e4): undefined reference to `pov::Trace(pov::Ray_Struct*, float*, double)' lighting.cpp:(.text+0x270c): undefined reference to `pov::Trace(pov::Ray_Struct*, float*, double)' lighting.o: In function `pov::Refract_Guts(float*, double, double*, double*, double*, double, pov::Ray_Struct*, pov::Ray_Struct*, double, double*)': lighting.cpp:(.text+0x28e4): undefined reference to `pov::Trace(pov::Ray_Struct*, float*, double)' lighting.o: In function `pov::compute_backtrace_texture(float*, pov::Texture_Struct*, double*, double*, pov::Ray_Struct*, double, pov::istk_entry*)': lighting.cpp:(.text+0x354b): undefined reference to `pov::Trace(pov::Ray_Struct*, float*, double)' lighting.cpp:(.text+0x3def): undefined reference to `pov::Trace(pov::Ray_Struct*, float*, double)' lighting.o:lighting.cpp:(.text+0x4134): more undefined references to `pov::Trace(pov::Ray_Struct*, float*, double)' follow lighting.o: In function `pov::compute_lighted_texture(float*, pov::Texture_Struct*, double*, double*, pov::Ray_Struct*, double, pov::istk_entry*)': lighting.cpp:(.text+0x9266): undefined reference to `pov::gatherPhotons(double*, double, double*, double*, int, pov::photon_map_struct*)' lighting.cpp:(.text+0x9ce7): undefined reference to `pov::Trace(pov::Ray_Struct*, float*, double)' media.o: In function `pov::sample_media(pov::Light_List_Struct*, int, pov::Ray_Struct*, pov::Media_Struct**, pov::Media_Interval_Struct*, int, double, float*, float*, int, pov::Light_List_Struct*, int)': media.cpp:(.text+0x13a2): undefined reference to `pov::gatherPhotons(double*, double, double*, double*, int, pov::photon_map_struct*)' mesh.o: In function `pov::Initialize_Mesh_Code()': mesh.cpp:(.text+0x122a): undefined reference to `pov::Create_Priority_Queue(unsigned int)' messageoutput.o: In function `pov_frontend::MessageOutput::FileMessage(int, POVMSData*)': messageoutput.cpp:(.text+0xadc): undefined reference to `POVMSUtil_GetInt(POVMSData*, unsigned int, int*)' messageoutput.o: In function `pov_frontend::MessageOutput::Progress(POVMSData*, POVMSData*, int)': messageoutput.cpp:(.text+0xe79): undefined reference to `POVMSUtil_GetInt(POVMSData*, unsigned int, int*)' messageoutput.cpp:(.text+0xec3): undefined reference to `POVMSUtil_GetInt(POVMSData*, unsigned int, int*)' messageoutput.cpp:(.text+0xed7): undefined reference to `POVMSUtil_GetInt(POVMSData*, unsigned int, int*)' messageoutput.cpp:(.text+0xf36): undefined reference to `POVMSUtil_GetInt(POVMSData*, unsigned int, int*)' messageoutput.o:messageoutput.cpp:(.text+0xf4e): more undefined references to `POVMSUtil_GetInt(POVMSData*, unsigned int, int*)' follow parse.o: In function `pov::Parse_Camera(pov::Camera_Struct**)': parse.cpp:(.text+0x6b50): undefined reference to `pov::Allow_Float(double)' parse.cpp:(.text+0x6c08): undefined reference to `pov::Allow_Float(double)' parse.o: In function `pov::Parse_Object_Mods(pov::Object_Struct*)': parse.cpp:(.text+0x9d47): undefined reference to `pov::Allow_Float(double)' parse.cpp:(.text+0x9e73): undefined reference to `pov::Allow_Float(double)' parse.cpp:(.text+0xa804): undefined reference to `pov::Allow_Float(double)' parse.o:parse.cpp:(.text+0xa903): more undefined references to `pov::Allow_Float(double)' follow parstxtr.o: In function `pov::Parse_Texture()': parstxtr.cpp:(.text+0x6c43): undefined reference to `pov::Warn_State(int, int)' parstxtr.cpp:(.text+0x6ddb): undefined reference to `pov::Warn_State(int, int)' parstxtr.cpp:(.text+0x6e13): undefined reference to `pov::Warn_State(int, int)'
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
--- Comment #1 from domob at gcc dot gnu dot org 2008-09-02 17:05 --- Created an attachment (id=16196) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16196action=view) Proposed patch implementing the main part This is an experimental patch that implements the logic to create code finalizing a given entity. Only with this patch, this is however never called; this is merely a preparation for a full implementation of derived-type finalization. This patch was posted to the mailing lists as http://gcc.gnu.org/ml/fortran/2008-08/msg00042.html. It is a split-off from an experimental full finalization patch posted as http://gcc.gnu.org/ml/fortran/2008-06/msg00254.html and follow-up discussion. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
--- Comment #2 from domob at gcc dot gnu dot org 2008-09-02 17:08 --- For the needed parts to actually call finalizers building upon the attached patch from comment #1, some means for temporary-creation before trans are needed to handle things like: x = foo (x) or foo (bar ()) Some ideas were posted to the mailing list as http://gcc.gnu.org/ml/fortran/2008-08/msg00026.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug objc++/37335] Boostrap failed on obj-c++ too many arguments to function 'build_array_ref'
--- Comment #1 from 3dw4rd at verizon dot net 2008-09-02 17:22 --- Graphite just went it. I might just wait till the turbulence dies down and try again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37335
[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc
--- Comment #18 from vmakarov at redhat dot com 2008-09-02 17:29 --- I've looked at the cgraphbuild.i code and I think something is wrong with inlining. There are two paths achieving L21 with different stack adjustments. Here is the code. I marked insns adjusting SP by - and the two insns should refer to the same location by ! .globl rebuild_cgraph_edges .type rebuild_cgraph_edges, @function rebuild_cgraph_edges: pushl %ebp pushl %edi pushl %esi pushl %ebx subl$56, %esp movlcurrent_function_decl, %edx pushl %edx callcgraph_node ! movl%eax, 32(%esp) movl%eax, (%esp) callcgraph_node_remove_callees movlcfun, %eax movl4(%eax), %ecx movl32(%esp), %edi -- addl$16, %esp movl(%ecx), %edx movl36(%edx), %ebx movl40(%edx), %esi movl%esi, 100(%edi) movl%ebx, 96(%edi) movl28(%edx), %edi cmpl4(%ecx), %edi je .L21 ... .L31: movl28(%eax), %edx movl%edx, 12(%esp) cmpw$29, (%edx) jne .L50 cmpl$9, tree_code_type+480 je .L51 movl28(%esp), %edx testl %edx, %edx jle .L52 movl48(%edi), %eax movl%eax, 8(%esp) ---subl$12, %esp pushl %edi callcompute_call_stmt_bb_frequency movl%eax, %ebp popl%eax movl36(%edi), %edx movl40(%edi), %ecx movl24(%esp), %eax pushl %eax movl%edx, 20(%esp) movl%ecx, 16(%esp) callcgraph_node ---addl$12, %esp movl12(%esp), %edx pushl %edx pushl %ebp movl16(%esp), %edx movl12(%esp), %ecx pushl %ecx pushl %edx pushl %esi pushl %eax movl44(%esp), %ebp pushl %ebp callcgraph_create_edge movl8(%ebx), %ebx -- addl$32, %esp testl %ebx, %ebx jne .L42 .p2align 4,,7 .p2align 3 .L45: movlcfun, %eax .L22: movl4(%eax), %edx movl28(%edi), %edi cmpl%edi, 4(%edx) jne .L41 .L21: ! movl48(%esp), %eax callinitialize_inline_failed ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296
[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc
--- Comment #19 from ebotcazou at gcc dot gnu dot org 2008-09-02 17:35
---
I've looked at the cgraphbuild.i code and I think something is wrong with
inlining. There are two paths achieving L21 with different stack
adjustments.
Here is the code. I marked insns adjusting SP by - and the two insns should
refer to the same location by !
Isn't that supposed to be detected by reload?
/* For each label, we record the offset of each elimination. If we reach
a label by more than one path and an offset differs, we cannot do the
elimination. This information is indexed by the difference of the
number of the label and the first label number. We can't offset the
pointer itself as this can cause problems on machines with segmented
memory. The first table is an array of flags that records whether we
have yet encountered a label and the second table is an array of arrays,
one entry in the latter array for each elimination. */
static int first_label_num;
static char *offsets_known_at;
static HOST_WIDE_INT (*offsets_at)[NUM_ELIMINABLE_REGS];
/* This function handles the tracking of elimination offsets around branches.
X is a piece of RTL being scanned.
INSN is the insn that it came from, if any.
INITIAL_P is nonzero if we are to set the offset to be the initial
offset and zero if we are setting the offset of the label to be the
current offset. */
static void
set_label_offsets (rtx x, rtx insn, int initial_p)
{
enum rtx_code code = GET_CODE (x);
rtx tem;
unsigned int i;
struct elim_table *p;
switch (code)
{
case LABEL_REF:
if (LABEL_REF_NONLOCAL_P (x))
return;
x = XEXP (x, 0);
/* ... fall through ... */
case CODE_LABEL:
/* If we know nothing about this label, set the desired offsets. Note
that this sets the offset at a label to be the offset before a label
if we don't know anything about the label. This is not correct for
the label after a BARRIER, but is the best guess we can make. If
we guessed wrong, we will suppress an elimination that might have
been possible had we been able to guess correctly. */
if (! offsets_known_at[CODE_LABEL_NUMBER (x) - first_label_num])
{
for (i = 0; i NUM_ELIMINABLE_REGS; i++)
offsets_at[CODE_LABEL_NUMBER (x) - first_label_num][i]
= (initial_p ? reg_eliminate[i].initial_offset
: reg_eliminate[i].offset);
offsets_known_at[CODE_LABEL_NUMBER (x) - first_label_num] = 1;
}
/* Otherwise, if this is the definition of a label and it is
preceded by a BARRIER, set our offsets to the known offset of
that label. */
else if (x == insn
(tem = prev_nonnote_insn (insn)) != 0
BARRIER_P (tem))
set_offsets_for_label (insn);
else
/* If neither of the above cases is true, compare each offset
with those previously recorded and suppress any eliminations
where the offsets disagree. */
for (i = 0; i NUM_ELIMINABLE_REGS; i++)
if (offsets_at[CODE_LABEL_NUMBER (x) - first_label_num][i]
!= (initial_p ? reg_eliminate[i].initial_offset
: reg_eliminate[i].offset))
reg_eliminate[i].can_eliminate = 0;
return;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296
[Bug bootstrap/37330] mpfr 32/64 multilib issue
--- Comment #3 from brian at dessent dot net 2008-09-02 17:36 --- Subject: Re: mpfr 32/64 multilib issue g++ (and gcc, gfortran, etc.) are just driver programs that invoke other programs, they don't use these libraries. You need to look at cc1 (or cc1plus, f951, etc.) to see the dependency on these libraries. You can use e.g. ldd $(gcc -print-prog-name=cc1) to get the path to them programatically. As pointed out already gmp and mpfr are *host* libraries not *target* libraries. Even when gcc is built in a multilib configuration supporting several targets there is still only a single host compiler, and thus you need to specify the gmp and mpfr appropriate for the host. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37330
[Bug fortran/37099] [4.3, 4.4 regression] Wrong results when comparing a character array to a character expression
-- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-08-12 19:41:55 |2008-09-02 18:04:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37099
[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc
--- Comment #20 from vmakarov at redhat dot com 2008-09-02 18:13 --- Isn't that supposed to be detected by reload? Yea, right. I missed that. Eric, sorry for to be in hurry with the wrong response. I am still working on the issue. I hope to find a solution today or tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296
[Bug rtl-optimization/37251] [4.4 Regression] ICE with ira: delete_allocno_from_bucket
--- Comment #8 from hjl at gcc dot gnu dot org 2008-09-02 18:17 --- Subject: Bug 37251 Author: hjl Date: Tue Sep 2 18:16:24 2008 New Revision: 139900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139900 Log: 2008-09-02 H.J. Lu [EMAIL PROTECTED] Backport from mainline: 2008-09-01 John David Anglin [EMAIL PROTECTED] * ira.c (setup_eliminable_regset): Only declare i if ELIMINABLE_REGS is defined. 2008-08-29 Vladimir Makarov [EMAIL PROTECTED] PR rtl-opt/37251 * ira-color.c (push_allocnos_to_stack): Truncate removed_splay_allocno_vec. 2008-08-29 Vladimir Makarov [EMAIL PROTECTED] PR rtl-opt/37243 * ira-color (ira_fast_allocation): Don't assign hard registers to global allocnos. Added: branches/ira-merge/gcc/ChangeLog.ira Modified: branches/ira-merge/gcc/ira-color.c branches/ira-merge/gcc/ira.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37251
[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation
--- Comment #17 from hjl at gcc dot gnu dot org 2008-09-02 18:17 --- Subject: Bug 37243 Author: hjl Date: Tue Sep 2 18:16:24 2008 New Revision: 139900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139900 Log: 2008-09-02 H.J. Lu [EMAIL PROTECTED] Backport from mainline: 2008-09-01 John David Anglin [EMAIL PROTECTED] * ira.c (setup_eliminable_regset): Only declare i if ELIMINABLE_REGS is defined. 2008-08-29 Vladimir Makarov [EMAIL PROTECTED] PR rtl-opt/37251 * ira-color.c (push_allocnos_to_stack): Truncate removed_splay_allocno_vec. 2008-08-29 Vladimir Makarov [EMAIL PROTECTED] PR rtl-opt/37243 * ira-color (ira_fast_allocation): Don't assign hard registers to global allocnos. Added: branches/ira-merge/gcc/ChangeLog.ira Modified: branches/ira-merge/gcc/ira-color.c branches/ira-merge/gcc/ira.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37243
[Bug c++/37337] New: ice for legal C++ code
I just tried to compile the Suse Linux package bochs-2.2.1-202 with the GNU C++ compiler version 4.4 snapshot 20080829. The compiler said In constructor 'bx_null_pktmover_c::bx_null_pktmover_c(const char*, const char*, void (*)(void*, const void*, unsigned int), void*, char*)': eth_null.cc:88: error: BB 18 can not throw but has EH edges eth_null.cc:88: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Pre-processed source code attached. Flags -O2 -fpermissive required. -- Summary: ice for legal C++ code Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37337
[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation
--- Comment #18 from hjl at gcc dot gnu dot org 2008-09-02 18:24 --- Subject: Bug 37243 Author: hjl Date: Tue Sep 2 18:22:59 2008 New Revision: 139901 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139901 Log: 2008-09-02 Vladimir Makarov [EMAIL PROTECTED] PR rtl-opt/37243 * ira-conflicts.c (REG_SUBREG_P, go_through_subreg): New. (process_regs_for_copy): Process subregs. Refine check when cost is taken into account in ira-costs.c. (process_reg_shuffles): Use REG_SUBREG_P. (add_insn_allocno_copies): Ditto. Ignore modes. * ira-color.c (conflict_allocno_vec): New. (COST_HOP_DIVISOR): New macro. (update_copy_costs_1): Use it. (update_conflict_hard_regno_costs): New function. (assign_hard_reg): Use it. (ira_color): Allocate and free conflict_allocno_vec. Modified: branches/ira-merge/gcc/ChangeLog.ira branches/ira-merge/gcc/ira-color.c branches/ira-merge/gcc/ira-conflicts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37243
[Bug c++/37337] ice for legal C++ code
--- Comment #1 from dcb314 at hotmail dot com 2008-09-02 18:25 --- Created an attachment (id=16197) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16197action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37337
[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation
--- Comment #19 from hjl at gcc dot gnu dot org 2008-09-02 18:28 --- Subject: Bug 37243 Author: hjl Date: Tue Sep 2 18:27:34 2008 New Revision: 139902 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139902 Log: 2008-09-02 Vladimir Makarov [EMAIL PROTECTED] PR rtl-opt/37243 * ira-int.h (ira_loop_tree_node): Rename mentioned_allocnos to all_allocnos. * ira-color.c (print_loop_title): Use all_allocnos. (color_pass): Ditto. Don't add border_allocnos. Check that subloop allocno in the correspdoning bitmap all_allocnos. * ira-emit.c (change_loop): Use all_allocnos. * ira-build.c (create_loop_tree_nodes, finish_loop_tree_node): Ditto. (ira_create_allocno): Set up all_allocnos bit for the created allocno. (create_cap_allocno): Remove setting mentioned_allocnos. (create_insn_allocnos): Ditto. (remove_unnecessary_allocnos): Use all_allocnos. (check_allocno_creation): Check that allocnos are in the corresponding bitmap all_allocnos. Modified: branches/ira-merge/gcc/ChangeLog.ira branches/ira-merge/gcc/ira-build.c branches/ira-merge/gcc/ira-color.c branches/ira-merge/gcc/ira-emit.c branches/ira-merge/gcc/ira-int.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37243
[Bug middle-end/32913] -fprofile-generate/use: Program 24% slower than without
--- Comment #1 from hubicka at gcc dot gnu dot org 2008-09-02 18:36 --- I get 0m9.829s for non-profiled run and 0m9.801s for profiled run, so things seems to be in order on mainline. I would be curious if there are still some profile generate/use related regressions on polyhedron testsuite. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32913
[Bug middle-end/37337] [4.4 Regression] ICE: verify_flow_info failed
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end Keywords||ice-on-valid-code Summary|ice for legal C++ code |[4.4 Regression] ICE: ||verify_flow_info failed Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37337
[Bug c/37171] [4.4 Regression] Canonical spelling optimization dependency
--- Comment #11 from jakub at gcc dot gnu dot org 2008-09-02 18:44 --- Subject: Bug 37171 Author: jakub Date: Tue Sep 2 18:42:48 2008 New Revision: 139904 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139904 Log: PR c/37171 * g++.dg/ext/attrib34.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/attrib34.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37171
[Bug testsuite/36332] [4.4 Regression] FAIL: gcc.dg/torture/type-generic-1.c execution test on powerpc-*
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-02 18:47 --- Subject: Bug 36332 Author: jakub Date: Tue Sep 2 18:46:29 2008 New Revision: 139906 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139906 Log: PR target/36332 * real.c (real_maxval): Clear a lower bit to make real_maxval match get_max_float for IBM long double format. * gcc.c-torture/execute/ieee/pr36332.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/ieee/pr36332.c Modified: trunk/gcc/ChangeLog trunk/gcc/real.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36332
[Bug middle-end/37338] New: [4.4 Regression] gcc.dg/array-init-1.c
On Linux/ia32, revision 139863 gave FAIL: gcc.dg/array-init-1.c scan-assembler-not abcdefghi FAIL: gcc.dg/array-init-1.c scan-assembler-times 7017280452245743464|7523094288207667809|6867666564636261|1684234849|64636261 2 revision 139848 is OK. -- Summary: [4.4 Regression] gcc.dg/array-init-1.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37338
[Bug middle-end/37338] [4.4 Regression] gcc.dg/array-init-1.c
--- Comment #1 from hjl dot tools at gmail dot com 2008-09-02 18:56 --- Revision 139854 is OK and revision 139856 is bad. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jh at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37338
[Bug middle-end/37339] New: [4.4 Regression] gcc.dg/pr33645-3.c scan-assembler-not var1_t
On Linux/ia32, revision revision 139894 gave FAIL: gcc.dg/pr33645-3.c scan-assembler-not var1_t Revision 139891 is OK. Revision 139892 may be the cause. -- Summary: [4.4 Regression] gcc.dg/pr33645-3.c scan-assembler-not var1_t Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37339
[Bug middle-end/37338] [4.4 Regression] gcc.dg/array-init-1.c
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37338
[Bug middle-end/37339] [4.4 Regression] gcc.dg/pr33645-3.c scan-assembler-not var1_t
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4 Regression]|[4.4 Regression] |gcc.dg/pr33645-3.c scan-|gcc.dg/pr33645-3.c scan- |assembler-not var1_t|assembler-not var1_t Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37339
[Bug testsuite/36332] [4.4 Regression] FAIL: gcc.dg/torture/type-generic-1.c execution test on powerpc-*
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-02 19:13 --- Subject: Bug 36332 Author: jakub Date: Tue Sep 2 19:11:55 2008 New Revision: 139907 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139907 Log: PR target/36332 * real.c (real_maxval): Clear a lower bit to make real_maxval match get_max_float for IBM long double format. * gcc.c-torture/execute/ieee/pr36332.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/ieee/pr36332.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/real.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36332
[Bug tree-optimization/36766] [4.4 Regression] natGC.cc:229: internal compiler error: Segmentation fault
--- Comment #23 from jakub at gcc dot gnu dot org 2008-09-02 19:15 --- Subject: Bug 36766 Author: jakub Date: Tue Sep 2 19:13:47 2008 New Revision: 139908 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139908 Log: PR tree-optimization/36766 * tree-cfg.c (gimple_purge_all_dead_eh_edges): Do nothing for already removed basic blocks. * g++.dg/tree-ssa/pr36766.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr36766.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36766
[Bug preprocessor/36906] #pragma GNU poison index()
--- Comment #3 from tromey at gcc dot gnu dot org 2008-09-02 19:22 --- One problem with this approach is that this code would not error: #include string.h char (*fnptr)() = rindex; I tend to agree with Andrew -- poisoning is too crude a tool for this use. Is there a reason you do not use deprecation here? -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36906
