[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with complex type conversion
--- Comment #32 from gdr at cs dot tamu dot edu 2008-01-07 08:00 --- Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with complex type conversion mark at codesourcery dot com [EMAIL PROTECTED] writes: | --- Comment #31 from mark at codesourcery dot com 2008-01-07 07:48 --- | Subject: Re: [4.2/4.3 regression] ICE with incompatible types | for ?: with complex type conversion | | gdr at cs dot tamu dot edu wrote: | | But, as that hypothetical user, I would not have any ground to be unhappy. | After all, it was code based on unfounded extrapolations. | | I think this is a mistake. The real mistake was when I make that constructor unary. It was a terrible mistake. And I apologize for that. The fix isn't to build more brittle tower on top of it in the name of hypothetical codes written with unfounded assumptions. [...] | One of the most frequent complaints I get about GCC is that we break | existing code with every release. I get that complain too. But only for documented features. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with complex type conversion
--- Comment #33 from gdr at cs dot tamu dot edu 2008-01-07 08:10 --- Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with complex type conversion mark at codesourcery dot com [EMAIL PROTECTED] writes: | Subject: Re: [4.2/4.3 regression] ICE with incompatible types | for ?: with complex type conversion | | gdr at cs dot tamu dot edu wrote: | | | Is it conceivable that ISO C++ will ever add a | | complexdouble::complex(int) constructor that doesn't set the real part | | to the value of the argument (converted to double), and the imaginary | | part to zero? | | That isn't the issue. My concern is whether ISO C++ will ever | change conversion rules, say from integers to floats or doubles. The | answer is likely. | | What's the likely change? Ban implicit narrowing conversions, in the sense that a round trip will not give the same value back. The exact rules are in flux (there was a specification discussed at the last Kona meeting, but it got changed based on feedback, and may likely change from now to Sophia Antipolis meeting). However, the general idea meets consensus. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug fortran/34545] ICE when compiling Fortran 95 code
--- Comment #18 from pault at gcc dot gnu dot org 2008-01-07 08:15 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34545
[Bug middle-end/34701] New: ICE in tree-ssa-ccp.c with -fipa-struct-reorg
The following testcase fails for me when run with -fipa-struct-reorg:
#include stdlib.h
typedef struct baba
{
int a;
int b[10];
} type_struct;
type_struct *str1;
int main()
{
int i;
str1 = malloc (10 * sizeof (type_struct));
for (i=0; i=9; i++)
str1[i].a = str1[i].b[0];
return 0;
}
The failure is:
try2.c: In function main:
try2.c:12: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:486
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE in tree-ssa-ccp.c with -fipa-struct-reorg
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alond at il dot ibm dot com
GCC build triplet: powerpc-suse-linux
GCC host triplet: powerpc-suse-linux
GCC target triplet: powerpc-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34701
[Bug middle-end/34701] ICE in tree-ssa-ccp.c with -fipa-struct-reorg
--- Comment #1 from alond at il dot ibm dot com 2008-01-07 09:47 ---
(In reply to comment #0)
When looking into try2.c.051i.ipa_struct_reorg, there is something strange like
10=40 there:
bb 2:
D.1885_2 = malloc (440);
str1.0_3 = (struct type_struct *) D.1885_2;
10 = 40;
D.1904_18 = malloc (D.1903_17(D));
str1.0.3_19 = (struct baba_sub.0 *) D.1904_18;
D.1905_20 = 10 2;
D.1906_21 = malloc (D.1905_20);
str1.0.4_22 = (struct baba_sub.1 *) D.1906_21;
str1 ={v} str1.0_3;
str1.1 ={v} str1.0.4_22;
str1.0 ={v} str1.0.3_19;
goto bb 4;
Alon
--
alond at il dot ibm dot com changed:
What|Removed |Added
CC||alond at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34701
[Bug middle-end/34622] [4.3 Regression] gcc.c-torture/execute/20000801-4.c fails at -O1 and above
--- Comment #7 from jakub at gcc dot gnu dot org 2008-01-07 09:47 --- Can anyone who can reproduce this please post assembly of 2801-4.c at -O1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34622
[Bug c/34697] gcc -std=gnu99 emits global symbol for extern inline function declarations
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-07 10:04 --- Update your gmp, this was fixed in 4.2.2. Well, if you were right, then gnu99 and gnu89 would have the same behavior, but they don't: gnu99 behaves like c99. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34697
[Bug middle-end/34622] [4.3 Regression] gcc.c-torture/execute/20000801-4.c fails at -O1 and above
--- Comment #8 from dominiq at lps dot ens dot fr 2008-01-07 10:06 --- .cstring LC0: .ascii \0 .space 1 .text .globl _foo _foo: pushl %ebp movl%esp, %ebp subl$8, %esp call___i686.get_pc_thunk.cx L001$pb: lealLC0-L001$pb(%ecx), %eax cmpb$0, 1(%eax) sete%al movzbl %al, %eax leave ret .cstring LC1: .ascii x\0 .text .globl _main _main: pushl %ebp movl%esp, %ebp pushl %ebx subl$36, %esp call___i686.get_pc_thunk.bx L002$pb: movzwl LC1-L002$pb(%ebx), %eax movw%ax, -10(%ebp) leal-10(%ebp), %edx movlL_t$non_lazy_ptr-L002$pb(%ebx), %eax movl%edx, (%eax) call_foo testl %eax, %eax je L4 movl$0, (%esp) callL_exit$stub L4: callL_abort$stub .comm _t,4,2 .picsymbol_stub L_abort$stub: .indirect_symbol _abort callLPC$1 LPC$1: popl%eax movlL1$lz-LPC$1(%eax),%edx jmp *%edx L_abort$stub_binder: lea L1$lz-LPC$1(%eax),%eax pushl %eax jmp dyld_stub_binding_helper .lazy_symbol_pointer L1$lz: .indirect_symbol _abort .long L_abort$stub_binder .picsymbol_stub L_exit$stub: .indirect_symbol _exit callLPC$2 LPC$2: popl%eax movlL2$lz-LPC$2(%eax),%edx jmp *%edx L_exit$stub_binder: lea L2$lz-LPC$2(%eax),%eax pushl %eax jmp dyld_stub_binding_helper .lazy_symbol_pointer L2$lz: .indirect_symbol _exit .long L_exit$stub_binder .non_lazy_symbol_pointer L_t$non_lazy_ptr: .indirect_symbol _t .long 0 .subsections_via_symbols .section __TEXT,__textcoal_nt,coalesced,pure_instructions .weak_definition___i686.get_pc_thunk.cx .private_extern ___i686.get_pc_thunk.cx ___i686.get_pc_thunk.cx: movl(%esp), %ecx ret .weak_definition___i686.get_pc_thunk.bx .private_extern ___i686.get_pc_thunk.bx ___i686.get_pc_thunk.bx: movl(%esp), %ebx ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34622
[Bug middle-end/34701] ICE in tree-ssa-ccp.c with -fipa-struct-reorg
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-07 10:14 --- You should be more specific regarding the options you used. Confirmed with -O -fipa-struct-reorg -fipa-type-escape -fwhole-program. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|powerpc-suse-linux | GCC host triplet|powerpc-suse-linux | GCC target triplet|powerpc-suse-linux | Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2008-01-07 10:14:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34701
[Bug c/34389] -Wconversion produces wrong warning
--- Comment #4 from manu at gcc dot gnu dot org 2008-01-07 10:40 --- @Andrew, I would like to fix this before GCC 4.3 is released but I just don't know how. Any hints? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34389
[Bug libstdc++/34680] [4.3 Regression] Unconditional use of dynamic_cast in locale_facets.tcc breaks compilation with -fno-rtti
--- Comment #16 from paolo at gcc dot gnu dot org 2008-01-07 11:11 --- Subject: Bug 34680 Author: paolo Date: Mon Jan 7 11:11:02 2008 New Revision: 131372 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131372 Log: 2008-01-07 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/34680 * include/bits/locale_classes.h (has_facet, use_facet): Do not use dynamic_cast when run-time type identification is disabled; do not mark inline; only declare, define... * include/bits/locale_classes.tcc: ... here. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/locale_classes.h trunk/libstdc++-v3/include/bits/locale_classes.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34680
[Bug libstdc++/34680] [4.3 Regression] Unconditional use of dynamic_cast in locale_facets.tcc breaks compilation with -fno-rtti
--- Comment #17 from pcarlini at suse dot de 2008-01-07 11:12 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34680
[Bug libstdc++/34680] [4.3 Regression] Unconditional use of dynamic_cast in locale_facets.tcc breaks compilation with -fno-rtti
--- Comment #18 from pcarlini at suse dot de 2008-01-07 11:14 --- . -- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34680
[Bug tree-optimization/31914] FRE does not do const or copy propagation while it could
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-07 12:11 --- Created an attachment (id=14893) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14893action=view) patch for copyprop in the simple case Produced while working on PR34683 (though doesn't help that significantly). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31914
[Bug target/34682] 70% slowdown with SSE enabled
--- Comment #5 from ubizjak at gmail dot com 2008-01-07 12:19 ---
Confirmed by following testcase:
--cut here--
#include stdio.h
void __attribute__((noinline))
dtime (void)
{
__asm__ __volatile__ ( : : : memory);
}
double sa, sb, sc, sd;
double one, two, four, five;
double piref, piprg, pierr;
int
main (int argc, char *argv[])
{
double s, u, v, w, x;
long i, m;
piref = 3.14159265358979324;
one = 1.0;
two = 2.0;
four = 4.0;
five = 5.0;
m = 51200;
dtime();
s = -five;
sa = -one;
dtime();
for (i = 1; i = m; i++)
{
s = -s;
sa = sa + s;
}
dtime();
sc = (double) m;
u = sa;
v = 0.0;
w = 0.0;
x = 0.0;
dtime();
for (i = 1; i = m; i++)
{
s = -s;
sa = sa + s;
u = u + two;
x = x + (s - u);
v = v - s * u;
w = w + s / u;
}
dtime();
m = (long) (sa * x / sc);
sa = four * w / five;
sb = sa + five / v;
sc = 31.25;
piprg = sb - sc / (v * v * v);
pierr = piprg - piref;
printf (%13.4le\n, pierr);
return 0;
}
--cut here--
.L5:
xorb$-128, -17(%ebp)#, s
addl$1, %eax#, i.65
addsd %xmm4, %xmm1# two.16, u
cmpl$51201, %eax#, i.65
movsd -24(%ebp), %xmm0# s, tmp90
addsd -24(%ebp), %xmm2# s, sa_lsm.48
mulsd %xmm1, %xmm0# u, tmp90
subsd %xmm0, %xmm3# tmp90, v
movsd -24(%ebp), %xmm0# s, tmp91
divsd %xmm1, %xmm0# u, tmp91
addsd -16(%ebp), %xmm0# w, tmp91
movsd %xmm0, -16(%ebp)# tmp91, w
jne .L5 #,
It is somehow possible to tolerate that s and w are not pushed into
registers due to non-existent live range splitting (PR 23322), the main problem
here is that the sign of sis changed in the memory by using (unaligned) xorb
insn. The same situation is in the first (shorter) loop:
.L4:
xorb$-128, -17(%ebp)#, s
addl$1, %eax#, i
cmpl$51201, %eax#, i
addsd -24(%ebp), %xmm0# s, sa_lsm.97
jne .L4 #,
The performance regression is caused by partial memory stall [1].
[1] Agner Fog: How to optimize for the Pentium family of microprocessors,
section 14.7
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-01-07 12:19:54
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
[Bug middle-end/34694] [4.3 regression] Wrong line number for uninitialized variable
-- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-07 12:46:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34694
[Bug middle-end/34701] ICE in tree-ssa-ccp.c with -fipa-struct-reorg
--- Comment #3 from alond at il dot ibm dot com 2008-01-07 13:01 ---
I have tested the following patch. It fixes the problem. All struct-reorg tests
has also passed on my machine.
It looks like the input to malloc was not calculated correctly in case the size
of the structure is not the order of 2.
Index: ipa-struct-reorg.c
===
--- ipa-struct-reorg.c (revision 131371)
+++ ipa-struct-reorg.c (working copy)
@@ -623,7 +623,12 @@
add_referenced_var (*res);
if (exact_log2 (struct_size_int) == -1)
-new_stmt = build_gimple_modify_stmt (num, struct_size);
+{
+ tree size = build_int_cst (TREE_TYPE (num), struct_size_int);
+ new_stmt = build_gimple_modify_stmt (*res, build2 (MULT_EXPR,
+TREE_TYPE (num),
+num, size));
+}
else
{
tree C = build_int_cst (TREE_TYPE (num), exact_log2 (struct_size_int));
Ok to submit this patch?
Alon
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34701
[Bug fortran/34672] [4.3 Regression] .mod file misses renamed, USEd symbol
--- Comment #3 from pault at gcc dot gnu dot org 2008-01-07 13:06 --- Since I have submitted the patch, I should take it on! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-01-04 13:24:02 |2008-01-07 13:06:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34672
[Bug middle-end/34701] ICE in tree-ssa-ccp.c with -fipa-struct-reorg
--- Comment #4 from olga at gcc dot gnu dot org 2008-01-07 13:11 --- (In reply to comment #3) Ok to submit this patch? It looks good. Please bootstrap and submit along with the testcase. Olga Alon -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34701
[Bug c++/34152] Erratic behaviour: Exception translation (throw from signal handlers)
--- Comment #10 from asteinarson at gmail dot com 2008-01-07 13:24 --- (In reply to comment #9) (In reply to comment #8) Subject: Bug 34152 * libsupc++/eh_personality.cc (PERSONALITY_FUNCTION): Check _GLIBCXX_HAVE_GETIPINFO instead of HAVE_GETIPINFO. I've checked this. From line 446 of libsupc++/eh_personality.cc: The trouble was that the GCC 4.3 was linking executables to the old version of libstdc++ (4.1). Setting LD_LIBRARY_PATH did the trick. Both test cases work now. Regards // ATS -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34152
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-01-07 13:25 --- Most of the operand scanner time is caused by cfg_cleanup: tree CFG cleanup : 93.71 (79%) usr 1.16 (54%) sys 95.03 (78%) wall 474427 kB (28%) ggc globbing CFG cleanup (and operand scanner) time to the passes that trigger it reveals: tree PHI const/copy prop: 27.30 (16%) usr 0.27 ( 9%) sys 31.33 (16%) wall 9 kB ( 0%) ggc tree FRE : 25.01 (15%) usr 0.75 (25%) sys 27.63 (14%) wall 1061857 kB (62%) ggc complete unrolling: 100.00 (59%) usr 1.46 (49%) sys 111.81 (58%) wall 482221 kB (28%) ggc wheee ;) looking where we spend most of the time it seems to be building tree lists in ssa_redirect_edge. I have a hack to make this a single allocation of a VEC on the heap, still in cfg_cleanup remove_forwarder_block_with_phi there is a linear search(!) in the list of pending PHI args. Profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 48.75 52.8552.85 2734252 0.00 0.00 ggc_alloc_stat 11.07 64.8512.00 35486689 0.00 0.00 add_vars_for_offset 4.22 69.42 4.57 327924414 0.00 0.00 var_ann 3.89 73.64 4.22 138084 0.00 0.00 finalize_ssa_stmt_operands 3.22 77.13 3.49 44525266 0.00 0.00 add_virtual_operand ... the add_vars_for_offset is PR33870 related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #28 from olga at gcc dot gnu dot org 2008-01-07 13:38 --- (In reply to comment #27) Would you please try the Alon's patch for PR 34701. I am not sure but maybe it's related. Thank you, Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug tree-optimization/34534] Multiple gcc.dg/struct/wo_prof_xxxx execution failures
--- Comment #9 from olga at gcc dot gnu dot org 2008-01-07 13:48 --- (In reply to comment #8) Would you please try the Alon's patch from PR 34701? I am not sure but may be it's related. Thank you, Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34534
[Bug target/34682] 70% slowdown with SSE enabled
--- Comment #6 from ubizjak at gmail dot com 2008-01-07 14:02 --- Patch in testing. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-01-07 12:19:54 |2008-01-07 14:02:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
[Bug middle-end/34688] [4.1/4.2] ICE: output_operand: invalid expression as operand
-- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added CC||mkuvyrkov at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-07 14:04:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34688
[Bug target/34682] 70% slowdown with SSE enabled
--- Comment #7 from ubizjak at gmail dot com 2008-01-07 14:09 --- Patched gcc: 387: FLOPS C Program (Double Precision), V2.0 18 Dec 1992 Module ErrorRunTime MFLOPS (usec) 1 -8.1208e-11 0.0128 1094.6170 2 -1.5485e-13 0.0061 1145.7086 SSE: FLOPS C Program (Double Precision), V2.0 18 Dec 1992 Module ErrorRunTime MFLOPS (usec) 1 4.0146e-13 0.0114 1227.3206 2 -1.4166e-13 0.0050 1399.9125 [ 2 -1.4166e-13 0.0269260.2975 ] So, 5.36x faster. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-01-07 14:32 --- -fno-tree-loop-optimize reduces compile-time of this testcase from 117s to 35s with -O -fstrict-aliasing. try_unroll_loop_completely calls update_ssa, for every loop unrolled, added by r98599, which seems to be necessary - mainly because of the interesting PHI redirect re-use of PENDING_STMT. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug target/34702] New: 1.0 is not the inverse of 1.0 with -mrecip on x86
The following test integer :: i, n real :: x, y(10) x =1.0 n = 10 do i = 1, n y(i) = 1.0/x x = 2.0*x end do print *, y end when compiled with -O -ffast-math -mrecip, gives 0.9994 0.4997 0.2499 0.1249 6.2463E-02 3.12499981E-02 1.56249991E-02 7.81249953E-03 3.90624977E-03 1.95312488E-03 the inverse of an integer power of 2 is not an integer power of 2 with -mrecip on i686-apple-darwin9 and x86_64-unknown-linux-gnu. Since x0*(2.0-x*x0) does not have round-off errors when x=2.0**i and x0=2.0**(-i), I assume that rcp* don't return an integer power of 2 if the input is an integer power of 2. In addition the result of a Newton-Raphson iteration is not the same from above of from below: real :: x, y x = 1.0 y = nearest(x,x) print *, y*(2.0-x*y) y = nearest(x,-x) print *, y*(2.0-x*y) end gives 1. 0.9994 This result is quite unfortunate since the integer powers of 2 are the only floating point numbers having an exact inverse. This numerical error probably not be fixed in an effective way, but should probably be documented. As a side note, I stumbled on the problem while trying to run the aermod.f90 polyhedron test with -mrecip. I have been chasing a resulting bus error at execution for a while until I found the culprit as line 35369 of the subroutine NUMRISE: IF ( FLOAT(NNP/NP).EQ.FLOAT(NNP)/XNP ) THEN for which the comparison fails even if NP=1 and XNP=1.0 with -mrecip. It follows that the variable NN, initialized within this IF block, is not initialized, thus in some case leading to a variable DELN negative or bigger than 1 at line 35514, leading to an access out of bounds. Note also that there is no point to discuss (at least with me) the way the program is written: I am well aware of the dangers of testing floating points for equality! A way to limit this kind of problems while letting people use -mrecip if it speeds up their code, could be (if possible) to use the exact division within IF expressions. -- Summary: 1.0 is not the inverse of 1.0 with -mrecip on x86 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34702
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-01-07 14:50 --- Subject: Bug 34683 Author: rguenth Date: Mon Jan 7 14:49:36 2008 New Revision: 131375 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131375 Log: 2008-01-07 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/34683 * tree-ssa-sccvn.c (vuses_to_vec): Pre-allocate the vector of VOPs of the needed size to save memory. Use VEC_quick_push to save compile-time. (vdefs_to_vec): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug tree-optimization/34703] New: (Unsafe) optization of IF(AB/C) as IF(A*CB)
As reported on PR34702 I stumbled over expressions such as IF ( FLOAT(NNP/NP).EQ.FLOAT(NNP)/XNP ) THEN or IF (RADIUS=X(N)/100.0 .AND. RADIUS=X(N+1)/100.0) EXIT which can obviously be rearranged as IF (XNP* FLOAT(NNP).EQ.FLOAT(NP*NNP) ) THEN or IF (100.0*RADIUS=X(N) .AND. 100.0*RADIUS=X(N+1)) EXIT The first change overcome the problem in PR34702 with aermod.f90 and -mrecip, while the second gives some speed up to gas_dyn.f90 (for large numbers of iterations: 13% for 20 iterations). Such optimizations are indeed assuming that there is no overflow (-ffinite-math-only?) and that the code is not relying on side effects due to the division round-off (-funsafe-math-optimizations?). Would such an optimization make sense and be difficult to implement (with the appropriate option(s), e.g., one or both of the above)? -- Summary: (Unsafe) optization of IF(AB/C) as IF(A*CB) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34703
[Bug middle-end/34622] [4.3 Regression] gcc.c-torture/execute/20000801-4.c fails at -O1 and above
--- Comment #9 from jakub at gcc dot gnu dot org 2008-01-07 14:59 --- Guess you want something like: 2008-01-07 Jakub Jelinek [EMAIL PROTECTED] PR target/34622 * config/darwin.c (darwin_mergeable_string_section): Don't use .cstring if int_size_in_bytes != TREE_STRING_LENGTH. --- gcc/config/darwin.c.jj 2007-10-11 10:54:22.0 +0200 +++ gcc/config/darwin.c 2008-01-07 15:57:52.0 +0100 @@ -1136,6 +1136,8 @@ darwin_mergeable_string_section (tree ex TREE_CODE (exp) == STRING_CST TREE_CODE (TREE_TYPE (exp)) == ARRAY_TYPE align = 256 + (int_size_in_bytes (TREE_TYPE (exp)) + == TREE_STRING_LENGTH (exp)) ((size_t) TREE_STRING_LENGTH (exp) == strlen (TREE_STRING_POINTER (exp)) + 1)) return darwin_sections[cstring_section]; But, it is not a regression in that case, even 4.1 had that bug. Can't test on darwin though... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34622
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #21 from rguenth at gcc dot gnu dot org 2008-01-07 15:08 --- Without the loop optimizer the profile looks like: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 9.77 2.96 2.96 14743868 0.00 0.00 add_vars_for_offset 8.00 5.38 2.42 vuses_compare 7.06 7.51 2.14 44262948 0.00 0.00 add_virtual_operand 6.65 9.52 2.01 235204852 0.00 0.00 var_ann 4.83 10.98 1.46 68814811 0.00 0.00 iterative_hash_expr 4.66 12.39 1.41 172 0.01 0.04 DFS 4.63 13.79 1.40 69248754 0.00 0.00 htab_find_with_hash 4.28 15.09 1.30 1229783 0.00 0.00 ggc_alloc_stat 4.13 16.34 1.25 206399974 0.00 0.00 VN_INFO 4.00 17.55 1.21 19029637 0.00 0.00 set_bb_for_stmt 3.74 18.68 1.1312610 0.00 0.00 get_call_expr_operands 2.88 19.55 0.87 266239 0.00 0.00 valueize_vuses 2.31 20.25 0.70 68677290 0.00 0.00 uid_decl_map_eq 2.25 20.93 0.68 129473 0.00 0.00 visit_reference_op_store 1.90 21.50 0.58 114366877 0.00 0.00 is_gimple_reg 1.49 21.95 0.45 147496 0.00 0.00 vec_gc_o_reserve_1 1.41 22.38 0.43 68653081 0.00 0.00 referenced_var_lookup and most of the time (cfgcleanup and operand scanner globbed into passes) is spent in tree PHI const/copy prop: 27.82 (42%) usr 0.05 ( 5%) sys 27.95 (41%) wall 8 kB ( 0%) ggc tree FRE : 24.94 (37%) usr 0.78 (73%) sys 25.73 (38%) wall 508759 kB (80%) ggc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug fortran/34704] New: Derived-type initialization ignored unless save attribute is present
It looks like a derived-type variable, containing an allocatable array and a variable set to an initial value, picks some random number instead of the initial value, unless it has the save attribute. The following piece of code demonstrates the problem: the only difference between the first and the second subroutine is the presence of the save attribute to t. No problem if t%a is a fixed-dimension array. t%n should be 1023. ! program boh ! call mah0 call mah1 ! end program boh ! subroutine mah0 ! type mix_type real(8), allocatable :: a(:) integer :: n=1023 end type mix_type type(mix_type) :: t ! allocate(t%a(1)) t%a=3.1415926 print *, 'n,a=',t%n,t%a deallocate(t%a) ! end subroutine mah0 ! subroutine mah1 ! type mix_type real(8), allocatable :: a(:) integer :: n=1023 end type mix_type type(mix_type), save :: t ! allocate(t%a(1)) t%a=3.1415926 print *, 'n,a=',t%n,t%a deallocate(t%a) ! end subroutine mah1 gfortran -v Using built-in specs. Target: i386-apple-darwin8.10.1 Configured with: /tmp/gfortran-20071231/ibin/../gcc/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --with-gmp=/tmp/gfortran-20071231/gfortran_libs --enable-bootstrap Thread model: posix gcc version 4.3.0 20071231 (experimental) [trunk revision 131236] (GCC) $ gfortran boh.f90 $ ./a.out n,a= 2123354 3.1415925025939941 n,a=1023 3.1415925025939941 $ gfortran -O3 boh.f90 $ ./a.out n,a= -1 3.1415925025939941 n,a=1023 3.1415925025939941 -- Summary: Derived-type initialization ignored unless save attribute is present Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: p dot giannozzi at fisica dot uniud dot it GCC build triplet: i386-apple-darwin8.10.1 GCC host triplet: i386-apple-darwin8.10.1 GCC target triplet: i386-apple-darwin8.10.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34704
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #22 from rguenth at gcc dot gnu dot org 2008-01-07 15:56 --- A histogram over the number of VUSEs/VDEFs that are being sorted by sort_vuses reveals: 180 2 281964 256 1498 4 that is, we call qsort 281964 times with 256 virtual operands in the VEC. Now, curiously(?), virtual operands are sorted already, but after DECL_UID, not SSA_NAME_VERSION (see operand_build_sort_virtual). Adjusting the tree-vn sorting order to that of the operand scanner lets us improve these numbers to 27 2 28665 256 128 4 a reduction of a factor of 10. Profile after that: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 10.37 2.91 2.91 14769893 0.00 0.00 add_vars_for_offset 7.91 5.13 2.22 44264182 0.00 0.00 add_virtual_operand 7.16 7.14 2.01 235231611 0.00 0.00 var_ann 5.24 8.61 1.47 206399974 0.00 0.00 VN_INFO 5.20 10.07 1.46 172 0.01 0.04 DFS 5.17 11.52 1.45 68814811 0.00 0.00 iterative_hash_expr 4.92 12.90 1.3812610 0.00 0.00 get_call_expr_operands 4.74 14.23 1.33 1439173 0.00 0.00 ggc_alloc_stat 4.63 15.53 1.30 69275355 0.00 0.00 htab_find_with_hash 3.88 16.62 1.09 19029637 0.00 0.00 set_bb_for_stmt 3.56 17.62 1.00 266239 0.00 0.00 valueize_vuses 2.21 18.24 0.62 129473 0.00 0.00 visit_reference_op_store 1.96 18.79 0.55 68703417 0.00 0.00 uid_decl_map_eq 1.92 19.33 0.54 operand_build_cmp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug c++/34152] Erratic behaviour: Exception translation (throw from signal handlers)
--- Comment #11 from jakub at gcc dot gnu dot org 2008-01-07 16:06 --- Subject: Bug 34152 Author: jakub Date: Mon Jan 7 16:05:27 2008 New Revision: 131376 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131376 Log: PR c++/34152 * libsupc++/eh_personality.cc (PERSONALITY_FUNCTION): Check _GLIBCXX_HAVE_GETIPINFO instead of HAVE_GETIPINFO. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/libsupc++/eh_personality.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34152
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with complex type conversion
--- Comment #34 from mark at codesourcery dot com 2008-01-07 16:17 --- Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with complex type conversion gdr at cs dot tamu dot edu wrote: | What's the likely change? Ban implicit narrowing conversions, in the sense that a round trip will not give the same value back. Which direction is narrowing, between int and float? (Both have values unrepresentable in the other, of course.) Would you please give an example of how this change, together with the new constructors, would make some program behave differently than the standard says it should? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug target/34622] [4.3 Regression] gcc.c-torture/execute/20000801-4.c fails at -O1 and above
--- Comment #10 from jakub at gcc dot gnu dot org 2008-01-07 16:18 --- On the 2801-4.c testcase with this patch .cstring is no longer used, instead .const is, which is desirable, at least if Darwin mergeable string sections work at least roughly similarly to ELF, and I've checked that .cstring is still used for string literals with len the same as zero terminated string's strlen + 1 for terminator. Could somebody please bootstrap/regtest this on darwin native? Thanks. -- 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|WAITING |ASSIGNED Component|middle-end |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-07 16:18:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34622
[Bug fortran/34704] [4.3 Regression] Derived-type initialization ignored unless save attribute is present
-- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i386-apple-darwin8.10.1 | GCC host triplet|i386-apple-darwin8.10.1 | GCC target triplet|i386-apple-darwin8.10.1 | Keywords||wrong-code Known to fail||4.3.0 Known to work||4.2.2 Last reconfirmed|-00-00 00:00:00 |2008-01-07 16:40:32 date|| Summary|Derived-type initialization |[4.3 Regression] Derived- |ignored unless save |type initialization ignored |attribute is present|unless save attribute is ||present Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34704
[Bug fortran/34704] [4.3 Regression] Derived-type initialization ignored unless save attribute is present
--- Comment #1 from pault at gcc dot gnu dot org 2008-01-07 16:44 --- I have a fix for this and PR34681. I was hoping to submit tonight but it now looks like it will be tomorrow. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-01-07 16:40:32 |2008-01-07 16:44:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34704
[Bug fortran/34672] [4.3 Regression] .mod file misses renamed, USEd symbol
--- Comment #4 from pault at gcc dot gnu dot org 2008-01-07 16:45 --- Subject: Bug 34672 Author: pault Date: Mon Jan 7 16:44:43 2008 New Revision: 131377 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131377 Log: 2008-01-07 Paul Thomas [EMAIL PROTECTED] PR fortran/34672 * module.c (write_generic): Rewrite completely. (write_module): Change call to write_generic. 2008-01-07 Paul Thomas [EMAIL PROTECTED] PR fortran/34672 * gfortran.dg/use_only_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/use_only_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34672
[Bug tree-optimization/34703] (Unsafe) optization of IF(AB/C) as IF(A*CB)
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-01-07 16:57 --- -ffinite-math-only is not enoug - that only assumes input operands are never Inf or Nan and results of operations in the source are not Inf or Nan. But as you say you cannot guarantee that RADIUS * 100.0 does not overflow, so this transformation is invalid. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34703
[Bug fortran/34672] [4.3 Regression] .mod file misses renamed, USEd symbol
--- Comment #5 from pault at gcc dot gnu dot org 2008-01-07 16:46 --- Fixed on trunk Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34672
[Bug tree-optimization/34683] [4.3 Regression] Fortran FE generated IL pessimizes middle-end IL and analysis
--- Comment #23 from rguenth at gcc dot gnu dot org 2008-01-07 17:08 --- Zdenek, can you have a look if there is sth low-hanging with the tree level loop unroller? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34683
[Bug fortran/34705] New: Reuse I/O structures to save memory and help the ME
Based on PR 34683. Richard writes there (text below slightly edited by me): So, to sum up, the situation could be significantly improved by improving the FE. Like I noticed for I/O statements, where I provided a patch - that was not accepted - to share temporary variables created for the I/O context. Which is this one: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01762.html basically it mentiones async I/O as a reason to not do it, but instead the callee can copy the I/O structure in that case instead (it probably needs to anyway, as currently those structures live on the stack, so with async I/O you'd need otherwise to guarantee that the I/O finished before the current frame is left). So, currently you can build up arbitrary large chains of virtual clobbers with WRITE statements; as each of those writes create two un-partitionable SFTs. For arrays temporaries this is the same. Actually it isn't that bad for I/O as long as there are no pointers to the dt_parm structs in the IL (function arguments are ok). -- Summary: Reuse I/O structures to save memory and help the ME Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34705
[Bug preprocessor/30363] [4.0/4.1/4.2/4.3 Regression] Support for -traditional-cpp is incomplete in current gcc relative to gcc 2.95.3
--- Comment #6 from tromey at gcc dot gnu dot org 2008-01-07 17:24 --- Subject: Bug 30363 Author: tromey Date: Mon Jan 7 17:23:40 2008 New Revision: 131379 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131379 Log: libcpp 2008-01-07 Fred Fish [EMAIL PROTECTED] PR preprocessor/30363: * traditional.c (replace_args_and_push): Add local variable cxtquote, calculate the replacement text size assuming a worst case of every input character quoted with backslash, and properly handle output quoting of quote characters in actual arguments used in function-like macros. gcc/testsuite 2008-01-07 Fred Fish [EMAIL PROTECTED] PR preprocessor/30363: * gcc.dg/cpp/trad/macroargs.c: Add code to test quoting in macro expansions. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cpp/trad/macroargs.c trunk/libcpp/ChangeLog trunk/libcpp/traditional.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30363
[Bug preprocessor/30363] [4.0/4.1/4.2 Regression] Support for -traditional-cpp is incomplete in current gcc relative to gcc 2.95.3
--- Comment #7 from tromey at gcc dot gnu dot org 2008-01-07 17:25 --- Slightly modified version of this patch checked in on trunk. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.2.3 3.0.4 2.95.3 |3.2.3 3.0.4 2.95.3 4.3.0 Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] |Support for -traditional-cpp|Support for -traditional-cpp |is incomplete in current gcc|is incomplete in current gcc |relative to gcc 2.95.3 |relative to gcc 2.95.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30363
[Bug fortran/34706] New: FE should reuse array temporaries, reduce temporaties and tell ME the array-size type
Based on PR 34683 and related to PR 34705. Richard writes there (text is slightly edited by me): The problem is we have loads of unpartitionable SFTs. The FE generated IL causes the first alias pass to emit too conservative alias info as well: # VUSE MPT.5965_208230 D.6049_4652 = atmp.1110.data; D.6050_4653 = (complex(kind=4)[0:] *) D.6049_4652; D.6051_4654 = S.1113_289 + D.3340_4634; # VUSE SFT... D.6052_4655 = (*D.6050_4653)[D.6051_4654]; I suppose the atmp.1110.data type is something like (void *), so the cast is required. But this really pessimizes the middle-end IL and it looks like the FE knows it will be complex(kind=4)[4] at the point of creation. Note fixing this will also improve optimization and thus runtime performance. I also see the FE creates lots of array temporaries: struct array2_complex(kind=4) atmp.1093; complex(kind=4) A.1094[4]; struct array2_complex(kind=4) atmp.1095; complex(kind=4) A.1096[4]; struct array2_complex(kind=4) atmp.1100; complex(kind=4) A.1101[4]; struct array2_complex(kind=4) atmp.1102; complex(kind=4) A.1103[4]; struct array2_complex(kind=4) atmp.1106; complex(kind=4) A.1107[4]; real(kind=4) D.3326; ... instead of re-using a single one. This also causes internal representation to blow up. So, to sum up, the situation could be significantly improved by improving the FE. For array temporaries the pinning of SFTs happens because we have the address of the actual array _data_ in the IL: # SFT.10_52 = VDEF SFT.10_51(D) atmp.0.data = A.1; the array descriptor itself is not the problem (the redundant descriptors still consume memory, but should not cause compile-time problems where observed). As of optimization, the conversion sequence atmp.0.data = A.1; D.540_5 = atmp.0.data; D.541_6 = (real(kind=4)[0:] *) D.540_5; ... (*D.541_6)[S.5_1] = D.545_14; can be optimized to A.1[S.5_1] = D.545_14; with the following patch that makes sure we use (real(kind=4)[4] *) instead of the unknown size array type. Index: trans-types.c === --- trans-types.c (revision 131336) +++ trans-types.c (working copy) @@ -1511,10 +1511,12 @@ gfc_get_array_type_bounds (tree etype, i /* TODO: known offsets for descriptors. */ GFC_TYPE_ARRAY_OFFSET (fat_type) = NULL_TREE; - /* We define data as an unknown size array. Much better than doing + /* We define data as an array with the correct size. Much better than doing pointer arithmetic. */ arraytype = -build_array_type (etype, gfc_array_range_type); +build_array_type (etype, build_range_type (gfc_array_index_type, + gfc_index_zero_node, int_const_binop (MINUS_EXPR, stride, + integer_one_node, 0))); arraytype = build_pointer_type (arraytype); GFC_TYPE_ARRAY_DATAPTR_TYPE (fat_type) = arraytype; (the patch needs to be adjusted for the cases stride is not the actual array size, but you should get the idea) -- Summary: FE should reuse array temporaries, reduce temporaties and tell ME the array-size type Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34706
[Bug middle-end/23868] [4.1/4.2/4.3 regression] builtin_apply uses wrong mode for multi-hard-register return values
--- Comment #10 from steven at gcc dot gnu dot org 2008-01-07 17:29 --- Though the patch from the patch URL probably does not apply anymore to the current trunk, it looks entirely reasonable IMHO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868
[Bug middle-end/28690] [4.2/4.3 Regression] Performace problem with indexed load/stores on powerpc
--- Comment #44 from steven at gcc dot gnu dot org 2008-01-07 17:34 --- Hello world. Please, a status update. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28690
[Bug c++/34696] Overloaded template losing type in invoking a superclass method?
--- Comment #1 from bangerth at dealii dot org 2008-01-07 17:34 --- (In reply to comment #0) o arg; This line calls the global operator ostream operator (ostream, char*) whereas this one std::ostringstream::operator(arg); clearly needs a member function operator. The best one is the one with void* argument. So not a bug. W. -- bangerth at dealii dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34696
[Bug middle-end/29609] [4.1/4.2/4.3 Regression] Even with -O0 -g gcc optimizes a goto away and I cannot debug
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2007-04-30 11:52:08 |2008-01-07 17:40:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609
[Bug target/30826] alignment error
--- Comment #10 from tom dot culliton at oracle dot com 2008-01-07 17:42 --- We've run afoul of this issue as well attempting to use gcc 4.1.1 and 4.1.2 on this platform, and it means that G++ is essentially unusable for us. Not following the IA64 ABI/Runtime Standard is a pretty serious bug. Is there a reliable work around for this problem? -- tom dot culliton at oracle dot com changed: What|Removed |Added CC||tom dot culliton at oracle ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30826
[Bug target/34641] [4.3 Regression] ICE in reload_cse_simplify_operands, at postreload.c:395
--- Comment #5 from krebbel at gcc dot gnu dot org 2008-01-07 17:28 --- The (const_int 3148725999 [0xbbadbeef]) is accepted by legitimate_constant_p since it is expected to end up in the literal pool. But in this case the constant becomes part of a REG_EQUIV note of an insn moving the constant into a pseudo register. Generating a reload for a later insn using the pseudo as memory base register the REG_EQUIV note is used by push_reload to replace the pseudo directly with the constant. The emitted move insn can't be recognized since none of the constraints of the move pattern accepts the large constant. I think push_reload has to make sure that the move pattern to be emitted is able to deal with the constant taken from the reg_equiv_constant array. -- krebbel 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-01-07 17:28:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34641
[Bug c/34707] New: failing to build gnu c compiler on Mac OS X ver 10.4.11 darwin
I've been trying to build GNU compilers on Mac OS X Version 10.4.11, 800MHz PowerPC G4 Memory 768 MB This fails. I think this is due to the make/config thinking I've got texinfo/gettext when I don't. gcc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs Thread model: posix Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 20020420 (prerelease) I expanded gcc-4.2.2.tar into /Users/desmond/programs/gcc/gcc-4.2.2 mkdir objdir cd objdir ../configure --enable-languages=c make builds some object files then fails 2nd make invokation gives [ -f stage_final ] || echo stage3 stage_final rm -f stage_current make[4]: Nothing to be done for `all'. rm -f stamp-h1 /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged test -f config.h || (rm -f stamp-h1 make stamp-h1) gcc -c -g -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -DHAVE_CONFIG_H -DLOCALEDIR=\/usr/local/share/locale\ -I. -I../../intl ../../intl/dcigettext.c ../../intl/dcigettext.c:242:21: search.h: No such file or directory ../../intl/dcigettext.c: In function `libintl_dcigettext': ../../intl/dcigettext.c:575: warning: passing arg 1 of `mempcpy' makes pointer from integer without a cast make[3]: *** [dcigettext.o] Error 1 make[2]: *** [all-stage1-intl] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 There is no /usr/include/search.h file on my computer. gcc -v -save-temps -c -g -no-cpp-precomp -DHAVE_DESIGNATED_INITIALIZERS=0 -DHAVE_CONFIG_H -DLOCALEDIR=/usr/local/share/locale -I. -I../../intl ../../intl/dcigettext.c Reading specs from /usr/libexec/gcc/darwin/ppc/3.1/specs Thread model: posix Apple Computer, Inc. GCC version 1175, based on gcc version 3.1 20020420 (prerelease) /usr/libexec/gcc/darwin/ppc/3.1/cpp0 -lang-c -v -I. -I../../intl -D__GNUC__=3 -D__GNUC_MINOR__=1 -D__GNUC_PATCHLEVEL__=0 -D__APPLE_CC__=1175 -D__ppc__ -D__POWERPC__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__ -D__ppc__ -D__POWERPC__ -D__NATURAL_ALIGNMENT__ -D__MACH__ -D__BIG_ENDIAN__ -D__APPLE__ -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__DYNAMIC__ -DHAVE_DESIGNATED_INITIALIZERS=0 -DHAVE_CONFIG_H -DLOCALEDIR=/usr/local/share/locale ../../intl/dcigettext.c dcigettext.i GNU CPP version 3.1 20020420 (prerelease) (cpplib) (Darwin/PowerPC) ignoring nonexistent directory /usr/lib/gcc-lib/ppc-darwin/3.1/../../../../ppc-darwin/include ignoring nonexistent directory /Local/Library/Frameworks #include ... search starts here: #include ... search starts here: . ../../intl /usr/local/include /usr/include/gcc/darwin/3.1 /usr/include End of search list. Framework search starts here: /System/Library/Frameworks /Library/Frameworks End of framework search list. ../../intl/dcigettext.c:242:21: search.h: No such file or directory # Variables # environment TERM_PROGRAM = Apple_Terminal # environment SECURITYSESSIONID = 905e70 # environment HOME = /Users/andresruiz # environment PWD = /Users/desmond/programs/gcc/gcc-4.2.2/objdir # environment MACHTYPE = powerpc # environment USER = andresruiz # environment SHELL = /bin/tcsh # environment HOSTTYPE = powermac # environment GROUP = staff # environment TERM = xterm-color # environment LOGNAME = andresruiz # environment VENDOR = apple # environment SHLVL = 1 # environment __CF_USER_TEXT_ENCODING = 0x1F5:0:0 # environment HOST = redsox.gene.ucl.ac.uk # environment OSTYPE = darwin # environment PATH = /bin:/sbin:/usr/bin:/usr/sbin:/Users/andresruiz/bin:/analysis/fastlink:/usr/local/bin/ # environment TERM_PROGRAM_VERSION = 133 # 18 variables in 523 hash buckets. # average of 0.0 variables per bucket, max 1 in one bucket. # Directories # No files, no impossibilities in 0 directories. # Implicit Rules # No implicit rules. # Pattern-specific variable values # No pattern-specific variable values. # Files # No files. # VPATH Search Paths # No `vpath' search paths. # No general (`VPATH' variable) search path. # Finished Make data base on Mon Jan 7 17:47:52 2008 regards desmond -- Summary: failing to build gnu c compiler on Mac OS X ver 10.4.11 darwin Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: D dot Campbell at ucl dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34707
[Bug c++/33916] [4.2/4.3 Regression] Default constructor fails to initialize array members
--- Comment #4 from mmitchel at gcc dot gnu dot org 2008-01-07 18:13 --- I still agree that we should fix this -- but it is worth noting that value-initialization did not exist in C++98. I believe that the current G++ behavior conforms to the original C++98 specification. Does anyone know if this change was in C++98 TC1? Or not until C++0x? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33916
[Bug middle-end/33699] [4.1/4.2/4.3 regression], missing optimization on const addr area store
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-07 18:24 --- This is related to some work done in the past for auto-increment addressing modes (even though there are no auto-inc/dec modes in the reporter's assembly). See one of Joern's old patches: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01612.html Look at the comment before optimize_related_value() to understand what this patch is supposed to achieve. Let's not talk about how it achieved this -- it suffices to say that the patch is not in the trunk -- but we really do need a pass over RTL to optimize this kind of thing. -- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-12-26 01:33:50 |2008-01-07 18:24:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33699
[Bug target/34622] [4.3 Regression] gcc.c-torture/execute/20000801-4.c fails at -O1 and above
--- Comment #11 from dominiq at lps dot ens dot fr 2008-01-07 18:31 --- Subject: Re: [4.3 Regression] gcc.c-torture/execute/2801-4.c fails at -O1 and above Could somebody please bootstrap/regtest this on darwin native? Seems to work on a quick test, but I have to regtest ~1 hour from now Thanks for the patch. Dominique -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34622
[Bug c++/33916] [4.2/4.3 Regression] Default constructor fails to initialize array members
--- Comment #5 from crowl at google dot com 2008-01-07 18:58 --- Subject: Re: [4.2/4.3 Regression] Default constructor fails to initialize array members Value initialization was in C++98 TC1 (2003) as a result of core issue 178. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33916
[Bug c++/33802] g++ says `z' is used uninitialized but this is not true
--- Comment #5 from bagnara at cs dot unipr dot it 2008-01-07 19:20 --- Indeed the testcase does not compile with GCC 4.3 (while compiling perfectly with GCC 4.0, 4.1 and 4.2). For some reason, GCC 4.3 dislikes the implementation of the STL that is shipped with previous versions. I have thus reconstructed the testcase by compiling the non-preprocessed sources with GCC version 4.3.0 20071228. Here is what happens (note that, differently from what was the case, now the warning is give three times in a row): $ bunzip2 bug2.cc.bz2 $ md5sum bug2.cc 63b807d5f4dc8d88c00d84a2e951f048 bug2.cc $ g++ -W -Wall -Wno-parentheses -O2 -c bug.cc bug.cc: In function void Parma_Polyhedra_Library::add_mul_assign(Parma_Polyhedra_Library::Checked_NumberT, P, const Parma_Polyhedra_Library::Checked_NumberT, P, const Parma_Polyhedra_Library::Checked_NumberT, P) [with T = long int, Policy = Parma_Polyhedra_Library::Checked_Number_Default_Policy]: bug.cc:3675: warning: z is used uninitialized in this function bug.cc:3669: note: z was declared here bug.cc: In member function Parma_Polyhedra_Library::Poly_Gen_Relation Parma_Polyhedra_Library::Octagonal_ShapeT::relation_with(const Parma_Polyhedra_Library::Generator) const [with T = __gmp_expr__mpq_struct [1], __mpq_struct [1]]: bug.cc:3669: warning: z may be used uninitialized in this function bug.cc:3669: note: z was declared here bug.cc:3669: warning: z may be used uninitialized in this function bug.cc:3669: note: z was declared here bug.cc:3669: warning: z may be used uninitialized in this function bug.cc:3669: note: z was declared here $ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802
[Bug c++/33802] g++ says `z' is used uninitialized but this is not true
--- Comment #6 from bagnara at cs dot unipr dot it 2008-01-07 19:30 --- Please, forget comment #5. Let me try again. Indeed the testcase does not compile with GCC 4.3 (while compiling perfectly with GCC 4.0, 4.1 and 4.2). For some reason, GCC 4.3 dislikes the implementation of the STL that is shipped with previous versions. I have thus reconstructed the testcase by compiling the non-preprocessed sources with GCC version 4.3.0 20071228. Here is what happens (note that, differently from what was the case, now the warning is give three times in a row): $ bunzip2 bug2.cc.bz2 $ md5sum bug2.cc 63b807d5f4dc8d88c00d84a2e951f048 bug2.cc $ g++ -W -Wall -Wno-parentheses -O2 -c bug2.cc bug.cc: In function void Parma_Polyhedra_Library::add_mul_assign(Parma_Polyhedra_Library::Checked_NumberT, P, const Parma_Polyhedra_Library::Checked_NumberT, P, const Parma_Polyhedra_Library::Checked_NumberT, P) [with T = long int, Policy = Parma_Polyhedra_Library::Checked_Number_Default_Policy]: bug.cc:3675: warning: z is used uninitialized in this function bug.cc:3669: note: z was declared here bug.cc: In member function Parma_Polyhedra_Library::Poly_Gen_Relation Parma_Polyhedra_Library::Octagonal_ShapeT::relation_with(const Parma_Polyhedra_Library::Generator) const [with T = __gmp_expr__mpq_struct [1], __mpq_struct [1]]: bug.cc:3669: warning: z may be used uninitialized in this function bug.cc:3669: note: z was declared here bug.cc:3669: warning: z may be used uninitialized in this function bug.cc:3669: note: z was declared here bug.cc:3669: warning: z may be used uninitialized in this function bug.cc:3669: note: z was declared here $ g++ --version g++ (GCC) 4.3.0 20071228 (experimental) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802
[Bug c++/33802] g++ says `z' is used uninitialized but this is not true
--- Comment #7 from bagnara at cs dot unipr dot it 2008-01-07 19:32 --- Created an attachment (id=14894) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14894action=view) New testcase showing the problem with GCC 4.3.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802
[Bug target/34682] 70% slowdown with SSE enabled
--- Comment #8 from rootkit85 at yahoo dot it 2008-01-07 19:47 --- Created an attachment (id=14895) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14895action=view) minimal testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
[Bug target/34682] 70% slowdown with SSE enabled
--- Comment #9 from rootkit85 at yahoo dot it 2008-01-07 19:47 --- Created an attachment (id=14896) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14896action=view) minimal testcase, compiled with -mfpmath=387 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
[Bug target/34682] 70% slowdown with SSE enabled
--- Comment #10 from rootkit85 at yahoo dot it 2008-01-07 19:47 --- Created an attachment (id=14897) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14897action=view) minimal testcase, compiled with -mfpmath=sse -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
[Bug target/34682] 70% slowdown with SSE enabled
--- Comment #11 from rootkit85 at yahoo dot it 2008-01-07 19:49 --- very very minimal testcase added -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
[Bug fortran/34705] Reuse I/O structures to save memory and help the ME
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-01-07 19:59 --- Confirmed. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-07 19:59:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34705
[Bug fortran/34706] FE should reuse array temporaries, reduce temporaties and tell ME the array-size type
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-01-07 19:59 --- Confirmed. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-07 19:59:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34706
[Bug target/34622] [4.3 Regression] gcc.c-torture/execute/20000801-4.c fails at -O1 and above
--- Comment #12 from dominiq at lps dot ens dot fr 2008-01-07 20:03 --- Subject: Re: [4.3 Regression] gcc.c-torture/execute/2801-4.c fails at -O1 and above The patch fix the problem on i686-apple-darwin9 32 and 64 bit modes without regression on gcc testsuite. BTW I never said that it was a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34622
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #29 from dominiq at lps dot ens dot fr 2008-01-07 20:04 --- Subject: Re: wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605 Would you please try the Alon's patch for PR 34701. I did but the reported failures are still there. Too bad!-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug target/34682] 70% slowdown with SSE enabled
--- Comment #12 from uros at gcc dot gnu dot org 2008-01-07 20:07 --- Subject: Bug 34682 Author: uros Date: Mon Jan 7 20:06:34 2008 New Revision: 131381 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131381 Log: PR target/34682 * config/i386/i386.md (negmode2): Rename from negsf2, negdf2 and negxf2. Macroize expander using X87MODEF mode iterator. Change predicates of op0 and op1 to register_operand. (absmode2): Rename from abssf2, absdf2 and negxf2. Macroize expander using X87MODEF mode iterator. Change predicates of op0 and op1 to register_operand. (*absnegmode2_mixed, *absnegmode2_sse): Rename from corresponding patterns and macroize using MODEF macro. Change predicates of op0 and op1 to register_operand and remove m constraint. Disparage r alternative with !. (*absnegmode2_i387): Rename from corresponding patterns and macroize using X87MODEF macro. Change predicates of op0 and op1 to register_operand and remove m constraint. Disparage r alternative with !. (absneg splitter with memory operands): Remove. (*negmode2_1, *absmode2_1): Rename from corresponding patterns and macroize using X87MODEF mode iterator. * config/i386/sse.md (negv4sf2, absv4sf2, neg2vdf2, absv2df2): Change predicate of op1 to register_operand. * config/i386/i386.c (ix86_expand_fp_absneg_operator): Remove support for memory operands. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/sse.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
[Bug preprocessor/34695] Preprocessor warning-error conversion from -Werror is silent
--- Comment #2 from tromey at gcc dot gnu dot org 2008-01-07 20:08 --- I agree this is a bug. I think this patch is insufficient. For best results I think that libcpp and diagnostic.c should agree on whether the warnins being treated as errors message has been emitted. One way to do this would be to finally switch libcpp to emit all errors via diagnostic.c. Though I suppose that, even if we do this, we may still need something like this patch for other users of libcpp. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-07 20:08:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34695
[Bug target/34682] 70% slowdown with SSE enabled
--- Comment #13 from ubizjak at gmail dot com 2008-01-07 20:10 --- Fixed in SVN. -- ubizjak at gmail dot com changed: What|Removed |Added URL|http://teknoraver.campuslife|http://gcc.gnu.org/ml/gcc- |.it/software/gcc-sse/ |patches/2008- ||01/msg00254.html Status|ASSIGNED|RESOLVED Keywords||ssemmx Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34682
[Bug preprocessor/34692] [4.2/4.3 regression] Internal error with pragma in macro
--- Comment #2 from tromey at gcc dot gnu dot org 2008-01-07 20:18 --- Confirmed. 4.1 seems to have silently accepted this. I will try to read the standard to figure out what is correct. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-07 20:18:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34692
[Bug c++/5458] address of overloaded template function as argument for template
--- Comment #13 from v dot haisman at sh dot cvut dot cz 2008-01-07 20:47 --- This still fails in 4.3.0. Know to fail sorted and without duplicates should read: 2.95.3 3.0.4 3.2.3 3.3.3 4.0.0 4.1.0 4.2.0 4.3.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5458
[Bug libstdc++/34680] [4.3 Regression] Unconditional use of dynamic_cast in locale_facets.tcc breaks compilation with -fno-rtti
--- Comment #19 from paolo at gcc dot gnu dot org 2008-01-07 20:55 --- Subject: Bug 34680 Author: paolo Date: Mon Jan 7 20:54:49 2008 New Revision: 131382 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131382 Log: 2008-01-06 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/34680 * doc/cpp.texi ([Common Predefined Macros]): Document. Modified: trunk/gcc/doc/cpp.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34680
[Bug testsuite/34575] gcc.target/powerpc/parity-1.c and popcount-1.c scan-assembler popcntb on darwin9
--- Comment #3 from janis at gcc dot gnu dot org 2008-01-07 21:03 --- Subject: Bug 34575 Author: janis Date: Mon Jan 7 21:02:24 2008 New Revision: 131383 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131383 Log: 2008-01-07 Jack Howarth [EMAIL PROTECTED] PR testsuite/34575 * gcc.target/powerpc/popcount-1.c: Skip on darwin. * gcc.target/powerpc/parity-1.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/parity-1.c trunk/gcc/testsuite/gcc.target/powerpc/popcount-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34575
[Bug tree-optimization/34708] New: Inlining heuristics issue
openbabel doesn't build on ppc64-linux with 4.3 (works with 4.1), with
-mminimal-toc -O2 -fPIC .toc1 section overflows (is bigger than 64KB).
About 2/3 of .toc1 entries are as with 4.1 various pointers to .rodata.str1.8
(i.e. string literals), but newly there are over 3600 pointers into .text.
This comes down to:
static __attribute__ ((__unused__)) const char*
SWIG_Perl_ErrorType(int code) {
const char* type = 0;
switch(code) {
case -12:
type = MemoryError;
break;
case -2:
type = IOError;
break;
case -3:
type = RuntimeError;
break;
case -4:
type = IndexError;
break;
case -5:
type = TypeError;
break;
case -6:
type = ZeroDivisionError;
break;
case -7:
type = OverflowError;
break;
case -8:
type = SyntaxError;
break;
case -9:
type = ValueError;
break;
case -10:
type = SystemError;
break;
case -11:
type = AttributeError;
break;
default:
type = RuntimeError;
}
return type;
}
extern C int puts (const char *);
void f1 (int code)
{
puts (SWIG_Perl_ErrorType (code));
}
void f2 (int code)
{
puts (SWIG_Perl_ErrorType (code));
}
void f3 (int code)
{
puts (SWIG_Perl_ErrorType (code));
}
void f4 (int code)
{
puts (SWIG_Perl_ErrorType (code));
}
void f5 (int code)
{
puts (SWIG_Perl_ErrorType (code));
}
where 4.1 doesn't inline the SWIG_Perl_ErrorType function at -O2, but 4.3 does
because of -finline-small-functions. SWIG_Perl_ErrorType isn't very small
though, especially with -fPIC it is fairly expensive, a bigger SWITCH_EXPR
which needs to use a jump table and then a dozen of string literal loads.
estimate_num_insns guesses 1 though :(.
--
Summary: Inlining heuristics issue
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34708
[Bug target/34709] New: [4.3 regression]: revision 131342 miscompiled 481.wrf on Linux/Intel64
This patch http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00191.html miscompiled 481.wrf in SPEC CPU 2006 on Linux/Intel64 with -O2 -ffast-math. The resulting 481.wrf segfaulted. -- Summary: [4.3 regression]: revision 131342 miscompiled 481.wrf on Linux/Intel64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34709
[Bug target/34622] [4.3 Regression] gcc.c-torture/execute/20000801-4.c fails at -O1 and above
--- Comment #13 from jakub at gcc dot gnu dot org 2008-01-07 21:50 --- Subject: Bug 34622 Author: jakub Date: Mon Jan 7 21:49:27 2008 New Revision: 131386 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131386 Log: PR target/34622 * config/darwin.c (darwin_mergeable_string_section): Don't use .cstring if int_size_in_bytes != TREE_STRING_LENGTH. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34622
[Bug target/34702] [4.3 Regression] 1.0 is not the inverse of 1.0 with -mrecip on x86
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|i686-apple-darwin9 | GCC host triplet|i686-apple-darwin9 | GCC target triplet|i686-apple-darwin9 |i?86-*-* Keywords||wrong-code Summary|1.0 is not the inverse of |[4.3 Regression] 1.0 is not |1.0 with -mrecip on x86 |the inverse of 1.0 with - ||mrecip on x86 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34702
[Bug tree-optimization/31079] 300% difference between ifort/gfortran
--- Comment #4 from jv244 at cam dot ac dot uk 2008-01-07 22:00 --- timings have improved a lot with a recent gfortran, at least on an opteron, I have now for ifort 3.7s for gfortran 4.5s (20% slower only) for the following code: SUBROUTINE collocate_core_2_2_0_0(jg,cmax) IMPLICIT NONE integer, INTENT(IN) :: jg,cmax INTEGER, PARAMETER :: wp = SELECTED_REAL_KIND ( 14, 200 ) INTEGER, PARAMETER :: N=10,Nit=1 TYPE vec real(wp) :: a(2) END TYPE vec TYPE(vec) :: dpy(1000) TYPE(vec) :: pxy(1000) TYPE(vec) :: s(02) integer :: i,j DO i=1,N pxy(i)%a=0.0_wp ENDDO DO i=1,N dpy(i)%a=0.0_wp ENDDO s(01)%a(1)=0.0_wp s(01)%a(2)=0.0_wp s(02)%a(1)=0.0_wp s(02)%a(2)=0.0_wp CALL USE(dpy,pxy,s) ! this is the hot loop DO j=1,Nit DO i=1,N s(01)%a(:)=s(01)%a(:)+pxy(i)%a(:)*dpy(i)%a(1) s(02)%a(:)=s(02)%a(:)+pxy(i)%a(:)*dpy(i)%a(2) ENDDO ENDDO CALL USE(dpy,pxy,s) END SUBROUTINE SUBROUTINE USE(a,b,c) INTEGER, PARAMETER :: wp = SELECTED_REAL_KIND ( 14, 200 ) REAL(kind=wp) :: a(*),b(*),c(*) END SUBROUTINE USE PROGRAM TEST integer, parameter :: cmax=5 integer*8 :: t1,t2,tbest real :: time1,time2 jg=0 CALL cpu_time(time1) tbest=huge(tbest) DO i=1,1 ! t1=nanotime_ia32() CALL collocate_core_2_2_0_0(0,cmax) ! t2=nanotime_ia32() ! if(t2-t10 .AND. t2-t1tbest) tbest=t2-t1 ENDDO CALL cpu_time(time2) ! write(6,*) tbest,time2-time1 write(6,*) time2-time1 END PROGRAM TEST using ifort -xW -O3 test.f90 gfortran -march=native -O3 -ffast-math test.f90 gfortran's inner loop asm looks like: .L8: movlpd (%rbp,%rax), %xmm0 movsd %xmm0, %xmm1 mulsd (%rbx,%rax), %xmm1 addsd %xmm1, %xmm2 movsd %xmm2, 32000(%rsp) mulsd 8(%rbx,%rax), %xmm0 addsd %xmm0, %xmm5 movsd %xmm5, 32008(%rsp) movlpd 8(%rbp,%rax), %xmm0 movsd %xmm0, %xmm1 mulsd (%rbx,%rax), %xmm1 addsd %xmm1, %xmm4 movsd %xmm4, 32016(%rsp) mulsd 8(%rbx,%rax), %xmm0 addq$16, %rax cmpq$160, %rax addsd %xmm0, %xmm3 movsd %xmm3, 32024(%rsp) jne .L8 while ifort's loop looks like: ..B3.7: # Preds ..B3.7 ..B3.6 movsd collocate_core_2_2_0_0_$DPY.0.0(%rdx), %xmm2 #31.41 movsd 8+collocate_core_2_2_0_0_$DPY.0.0(%rdx), %xmm3 #32.41 movapscollocate_core_2_2_0_0_$PXY.0.0(%rdx), %xmm4 #31.7 unpcklpd %xmm2, %xmm2 #31.41 mulpd %xmm4, %xmm2 #31.40 addpd %xmm2, %xmm1 #31.7 unpcklpd %xmm3, %xmm3 #32.41 mulpd %xmm3, %xmm4 #32.40 addpd %xmm4, %xmm0 #32.7 addq $16, %rdx #30.5 cmpq $160, %rdx#30.5 jl..B3.7# Prob 90% #30.5 so I guess ifort vectorizes where gfortran does not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31079
[Bug target/34622] [4.3 Regression] gcc.c-torture/execute/20000801-4.c fails at -O1 and above
--- Comment #14 from jakub at gcc dot gnu dot org 2008-01-07 22:07 --- Fixed on the trunk. -- 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=34622
[Bug tree-optimization/34708] Inlining heuristics issue
--- Comment #1 from hubicka at gcc dot gnu dot org 2008-01-07 22:09 --- mine. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-07 22:09:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34708
[Bug tree-optimization/34708] Inlining heuristics issue
--- Comment #2 from hubicka at ucw dot cz 2008-01-07 22:38 --- Subject: Re: New: Inlining heuristics issue I should also add that this is one of examples where Martin's switch optimization pass would do miracles. If organized before inlining we would end up with one static array. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34708
[Bug fortran/33375] ICE (segfault) gfortran.dg/common_6.f90
--- Comment #9 from hjl at lucon dot org 2008-01-07 22:57 ---
We are processing common block symbols which we have rejected/freed before.
This patch works for me:
Index: symbol.c
===
--- symbol.c(revision 131352)
+++ symbol.c(working copy)
@@ -2726,14 +2726,14 @@ gfc_commit_symbol (gfc_symbol *sym)
/* Recursive function that deletes an entire tree and all the common
head structures it points to. */
-static void
-free_common_tree (gfc_symtree * common_tree)
+void
+gfc_free_common_tree (gfc_symtree * common_tree)
{
if (common_tree == NULL)
return;
- free_common_tree (common_tree-left);
- free_common_tree (common_tree-right);
+ gfc_free_common_tree (common_tree-left);
+ gfc_free_common_tree (common_tree-right);
gfc_free (common_tree);
}
@@ -2863,7 +2863,7 @@ gfc_free_namespace (gfc_namespace *ns)
free_sym_tree (ns-sym_root);
free_uop_tree (ns-uop_root);
- free_common_tree (ns-common_root);
+ gfc_free_common_tree (ns-common_root);
for (cl = ns-cl_list; cl; cl = cl2)
{
Index: gfortran.h
===
--- gfortran.h (revision 131352)
+++ gfortran.h (working copy)
@@ -2137,6 +2137,7 @@ int gfc_symbols_could_alias (gfc_symbol
void gfc_undo_symbols (void);
void gfc_commit_symbols (void);
void gfc_commit_symbol (gfc_symbol *);
+void gfc_free_common_tree (gfc_symtree *);
void gfc_free_namespace (gfc_namespace *);
void gfc_symbol_init_2 (void);
Index: match.c
===
--- match.c (revision 131352)
+++ match.c (working copy)
@@ -2956,6 +2956,8 @@ done:
return MATCH_YES;
syntax:
+ gfc_free_common_tree (gfc_current_ns-common_root);
+ gfc_current_ns-common_root = NULL;
gfc_syntax_error (ST_COMMON);
cleanup:
I don't know if it is 100% correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33375
[Bug c/34710] New: FORTIFY_SOURCE matches to many patterns
The following is a short code fragment similar to code to be found in the open
source Argyll CMS (http://www.argyllcms.com/)
---
#include stdio.h
struct _iFile {
int (*fprintf)(struct _iFile *p, const char *format, ...);
};
typedef struct _iFile iFile;
static int testprint(iFile *p, const char *format, ...) { };
int main(int argc, char* argv[]) {
iFile p;
p.fprintf = testprint;
p.fprintf(p, %i, 123);
}
-
gcc -D_FORTIFY_SOURCE=2 -O2 test.c -E | tail
-
typedef struct _iFile iFile;
static int testprint(iFile *p, const char *format, ...) { };
int main(int argc, char* argv[]) {
iFile p;
p.fprintf = testprint;
p.__fprintf_chk (p, 2 - 1, %i, 123);
}
-
The second to last line is clearly wrong (or at least unintended)
--
Summary: FORTIFY_SOURCE matches to many patterns
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stefan dot bruens at rwth-aachen dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34710
[Bug target/34711] New: g++.dg/tree-ssa/ivopts-1.C fails for power
There are already two other problem reports for failures of this test: PR target/26726 for i?86 and x86_64, and PR target/27707 for hppa. Those are not regressions. The test started failing for powerpc64-linux-gnu, both -m32 and -m64, with this patch: http://gcc.gnu.org/viewcvs?view=revrev=128272 r128272 | rakdver | 2007-09-08 13:18:49 + (Sat, 08 Sep 2007) Test results for other powerpc targets show that they start failing later; here are the targets and the ranges in which they start failing, plus a couple of arm targets: powerpc-ibm-aix5.3.0.0 2007-10-20 to 2007-10-30 powerpc-apple-darwin8.5.0 2007-10-24 to 2007-11-01 arm-none-eabi 2007-10-27 to 2007-10-29 arm-none-linux-gnueabi 2007-12-25 to 2007-12-26 I'll find out which patches caused the test to start failing for these targets. -- Summary: g++.dg/tree-ssa/ivopts-1.C fails for power Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org GCC target triplet: powerpc*-*-linux* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34711
[Bug c/34710] FORTIFY_SOURCE matches to many patterns
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-01-07 23:46 --- Two things, fprintf is valid as being done as a macro and second thing is that this is a glibc issue and not a GCC issue as you are using a define and GCC just includes the header file. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34710
[Bug tree-optimization/34708] Inlining heuristics issue
--- Comment #3 from hubicka at ucw dot cz 2008-01-07 23:46 --- Subject: Re: New: Inlining heuristics issue Hi, I am testing the attached patch. It simply accounts two instructions for each case label, I guess it does not make much sense to try to do something smarter until we move lowering of swithc constructs to tree level. Interestingly enough the function manages to be small when just one switch is accounted. I wonder if removing * 2 still fixes the real testcase (ie the extreme growth is caused by too much of cascaded inlining). The inlining costs are quite biassed not taking into account the cost of address operations assuming that real work dominates the CPU time, that is probably still the case but we get to extreme side cases like this in other metricts.. Honza Index: tree-inline.c === *** tree-inline.c (revision 131386) --- tree-inline.c (working copy) *** estimate_num_insns_1 (tree *tp, int *wal *** 2387,2395 break; case SWITCH_EXPR: ! /* TODO: Cost of a switch should be derived from the number of !branches. */ ! d-count += d-weights-switch_cost; break; /* Few special cases of expensive operations. This is useful --- 2387,2400 break; case SWITCH_EXPR: ! /* Take into account cost of the switch + guess 2 conditional jumps for ! each case label. ! !TODO: once switch expansion algorithm is sufficiently separated !from RTL expansion, we might ask it for real cost of the switch !construct. */ ! d-count += (d-weights-switch_cost ! + TREE_VEC_LENGTH (SWITCH_LABELS (x)) * 2); break; /* Few special cases of expensive operations. This is useful -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34708
[Bug libfortran/34712] New: Formatted write of float broken (mingw32)
This is target specific: program bug double precision x x=7.0 print *, x end gfortran.exe bug.f $ ./a.exe ** This acts like field width is being miscalculated in output_float. It works fine with Cygwin binary. -- Summary: Formatted write of float broken (mingw32) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34712
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with complex type conversion
--- Comment #35 from gdr at cs dot tamu dot edu 2008-01-08 02:52 --- Subject: Re: [4.2/4.3 regression] ICE with incompatible types for ?: with complex type conversion mark at codesourcery dot com [EMAIL PROTECTED] writes: | --- Comment #34 from mark at codesourcery dot com 2008-01-07 16:17 --- | Subject: Re: [4.2/4.3 regression] ICE with incompatible types | for ?: with complex type conversion | | gdr at cs dot tamu dot edu wrote: | | | What's the likely change? | | Ban implicit narrowing conversions, in the sense that a round trip will not | give the same value back. | | Which direction is narrowing, between int and float? The rule is not just based on 'type'; if the source value is a constant, then the implementation determine whether a round trip is OK. Otherwise, it uses 'just' the type rule (for safe approximation). furthermore, based on feedback from Koan meeting, it is also proposed that narrowing should not cross integer-float barrier. | (Both have | values unrepresentable in the other, of course.) Would you please give | an example of how this change, together with the new constructors, would | make some program behave differently than the standard says it should? Please see the details in the proposal put foward by BS, me, and JSA titled `initializer list' (post Toronto meeting), and the recent `rationale' paper by BS in the mid-term mailing. Look for the section or word `narrowing'. (I'm currently in a location in san francisco where the nhe flakky network connection does not ease extended mail). -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug c++/31780] [4.2/4.3 regression] ICE with incompatible types for ?: with complex type conversion
--- Comment #36 from mark at codesourcery dot com 2008-01-08 03:39 ---
Subject: Re: [4.2/4.3 regression] ICE with incompatible types
for ?: with complex type conversion
gdr at cs dot tamu dot edu wrote:
| (Both have
| values unrepresentable in the other, of course.) Would you please give
| an example of how this change, together with the new constructors, would
| make some program behave differently than the standard says it should?
Please see the details in the proposal put foward by BS, me, and JSA titled
`initializer list' (post Toronto meeting), and the recent `rationale'
paper by BS in the mid-term mailing. Look for the section or word
`narrowing'.
I don't know where to find those things, unfortunately. Do you have a URL?
Would you please provide an example of how:
complexfloat {
Complex (int i) : real_(i) {};
Complex (float f): real_f() {};
float real_;
float imag_;
};
would be different than just:
complexfloat {
Complex (float f): real_f() {};
float real_;
float imag_;
};
when passed an int? I'm having a hard time seeing how making the
conversion in the constructor would be different than making it at the
call site, whether or not the argument is a constant.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31780
[Bug fortran/33375] ICE (segfault) gfortran.dg/common_6.f90
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-01-08 04:16 --- No longer segfaults on x86-64 Valgrind reports with common_6.f90 ==10016== 1,160 bytes in 5 blocks are definitely lost in loss record 2 of 6 ==10016==at 0x4A059F6: malloc (vg_replace_malloc.c:149) ==10016==by 0xB3FBD7: xmalloc (xmalloc.c:147) ==10016==by 0x448EC4: gfc_getmem (misc.c:37) ==10016==by 0x442281: gfc_get_common (match.c:2701) ==10016==by 0x443F29: gfc_match_common (match.c:2793) ==10016==by 0x452419: match_word (parse.c:64) ==10016==by 0x45316F: decode_statement (parse.c:195) ==10016==by 0x4535F4: next_statement (parse.c:505) ==10016==by 0x4568E1: gfc_parse_file (parse.c:3317) ==10016==by 0x47F414: gfc_be_parse_file (f95-lang.c:260) ==10016==by 0x6F25E4: toplev_main (toplev.c:1042) ==10016==by 0x3B7EC1E073: (below main) (in /lib64/libc-2.7.so) ==10016== ==10016== LEAK SUMMARY: ==10016==definitely lost: 1,160 bytes in 5 blocks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33375
[Bug libfortran/34712] Formatted write of float broken (mingw32)
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-01-08 04:56 --- Adding FX to cc. FX do you see this failure on your mingw binaries? -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34712
