[Bug fortran/32526] [4.3 regression] Spurious error: Name 'x' at (1) is an ambiguous reference to 'x' from module 'y'
--- Comment #8 from pault at gcc dot gnu dot org 2007-07-05 06:50 --- Subject: Bug 32526 Author: pault Date: Thu Jul 5 06:49:54 2007 New Revision: 126354 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126354 Log: 2007-07-05 Paul Thomas <[EMAIL PROTECTED]> PR fortran/32526 * match.c (gfc_match_call): Check, in all cases, that a symbol is neither generic nor a subroutine before trying to add it as a subroutine. PR fortran/32613 * match.c (gfc_match_do): Reset the implied_index attribute. 2007-07-05 Paul Thomas <[EMAIL PROTECTED]> PR fortran/32526 * gfortran.dg/interface_14.f90: New test. PR fortran/32613 * gfortran.dg/do_iterator_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/do_iterator_2.f90 trunk/gcc/testsuite/gfortran.dg/interface_14.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32526
[Bug fortran/32613] [4.3 regression] Different results depending on unnecessary variable declaration
--- Comment #10 from pault at gcc dot gnu dot org 2007-07-05 06:50 --- Subject: Bug 32613 Author: pault Date: Thu Jul 5 06:49:54 2007 New Revision: 126354 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126354 Log: 2007-07-05 Paul Thomas <[EMAIL PROTECTED]> PR fortran/32526 * match.c (gfc_match_call): Check, in all cases, that a symbol is neither generic nor a subroutine before trying to add it as a subroutine. PR fortran/32613 * match.c (gfc_match_do): Reset the implied_index attribute. 2007-07-05 Paul Thomas <[EMAIL PROTECTED]> PR fortran/32526 * gfortran.dg/interface_14.f90: New test. PR fortran/32613 * gfortran.dg/do_iterator_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/do_iterator_2.f90 trunk/gcc/testsuite/gfortran.dg/interface_14.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #21 from jv244 at cam dot ac dot uk 2007-07-05 05:01 --- This is a small testcase (that aborts if miscompiled): > cat test.f90 MODULE cp_log_handling INTEGER, PRIVATE:: stack_pointer=0 INTEGER, PARAMETER, PRIVATE :: max_stack_pointer=10 CONTAINS SUBROUTINE cp_add_default_logger() IF (stack_pointer+1>max_stack_pointer) THEN CALL mp_stop() ENDIF stack_pointer=stack_pointer+1 END SUBROUTINE cp_add_default_logger SUBROUTINE mp_stop() CALL ABORT() END SUBROUTINE END MODULE USE cp_log_handling CALL cp_add_default_logger() END gfortran -v -O2 -pg -march=native test.f90 Driving: gfortran -v -O2 -pg -march=native test.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data/vondele/gcc_trunk/gcc/configure --prefix=/data/vondele/gcc_trunk/build --enable-languages=c,fortran --with-mpfr=/data/programs/mpfr/ Thread model: posix gcc version 4.3.0 20070704 (experimental) /data/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951 test.f90 -march=core2 -mcx16 -msahf --param l1-cache-size=512 --param l1-cache-line-size=64 -mtune=core2 -quiet -dumpbase test.f90 -auxbase test -O2 -version -p -fintrinsic-modules-path /data/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/finclude -o /tmp/cckJso3I.s GNU F95 version 4.3.0 20070704 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.0 20070704 (experimental), GMP version 4.1.4, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 as -V -Qy -o /tmp/ccA9EOak.o /tmp/cckJso3I.s GNU assembler version 2.16.91.0.5 (x86_64-suse-linux) using BFD version 2.16.91.0.5 20051219 (SUSE Linux) /data/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/gcrt1.o /usr/lib/../lib64/crti.o /data/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtbegin.o -L/data/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.3.0 -L/data/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/data/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../.. /tmp/ccA9EOak.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /data/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtend.o /usr/lib/../lib64/crtn.o > ./a.out Aborted -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug tree-optimization/32589] [4.3 Regression] exp_dbug.adb:981: error: invalid array index
--- Comment #5 from aoliva at gcc dot gnu dot org 2007-07-05 04:50 --- FWIW, I haven't been able to bootstrap on ppc64-linux-gnu after this patch went in. I'm not sure I'd tried a full bootstrap before (I've only very recently got easy access to a ppc box), but the failure is bootstrap compare in a bunch of Ada files. bootstrap4 didn't make much difference. I'm trying ppc-linux-gnu now. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32589
[Bug rtl-optimization/32629] New: missing CSE for constant in registers / inefficient memset
gcc version 4.3.0 20070704 (experimental)
test case derived from linux kernel
struct x {
long a,b,c,d,e,f;
char array[32];
};
void f(struct x *p)
{
p->a = 0;
p->b = 0;
p->c = 0;
p->d = 0;
p->e = 0;
p->f = 0;
memset(&p->array, 0, 32);
}
compiled with -O2 or -Os gives
movq$0, (%rdi)
movq$0, 8(%rdi)
movl$8, %ecx
movq$0, 16(%rdi)
movq$0, 24(%rdi)
xorl%eax, %eax
movq$0, 32(%rdi)
movq$0, 40(%rdi)
addq$48, %rdi
rep
stosl
ret
This shows several problems:
- the zero in eax should have been used for all the initializations
replacing the immediate giving shorter code [especially with -Os,
but it would have been a win even with -O2 e.g on decode limited CPUs]
In a more test complex case the xorl was even before all the field
initializations.
- the rep ; stosl should be rep ; stosq because 8 byte alignment is guaranteed
by the type
--
Summary: missing CSE for constant in registers / inefficient
memset
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ak at muc dot de
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32629
[Bug middle-end/32628] [4.3 Regression] bogus integer overflow warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-04 23:34 ---
A simple example is:
void *f(void)
{
char *a = ((char*)0)+(unsigned long long)(-1);
return a;
}
This is caused by pointer_plus so mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Component|c |middle-end
Ever Confirmed|0 |1
Keywords||diagnostic
Last reconfirmed|-00-00 00:00:00 |2007-07-04 23:34:35
date||
Summary|bogus integer overflow |[4.3 Regression] bogus
|warning |integer overflow warning
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32628
[Bug c/32628] New: bogus integer overflow warning
gcc version 4.3.0 20070704 (experimental)
Following test case derived from the Linux ACPI code warns
toverflow.c: In function 'f':
toverflow.c:8: warning: integer overflow in expression
but the warning is not correct because 0 + ULONG_MAX doesn't really overflow.
typedef void *acpi_handle;
typedef unsigned long long UINT64;
typedef unsigned long long acpi_native_uint;
typedef unsigned char u8;
int f(acpi_handle device)
{
if (device == ((acpi_handle *) (void *) u8 *) (void *) void
*)0 + (acpi_native_uint)((UINT64)(~((UINT64) 0)))
return 1;
return 0;
}
--
Summary: bogus integer overflow warning
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ak at muc dot de
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=32628
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #6 from dje at gcc dot gnu dot org 2007-07-04 23:24 --- I use GNU Sed. If we need to add that as a requirement, so be it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug middle-end/30905] [4.3 Regression] Fails to cross-jump
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-07-04 22:35 --- I can't reproduce this on the trunk, unless I am making a mistake. I think the cross jump is happening now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30905
[Bug tree-optimization/24609] [4.0/4.1/4.2/4.3 regression] Same value duplicated in two different registers
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-07-04 22:11 --- For foo4.c > SCCVN says j_3 value numbers to i_2 (VH.3) But that is really PR 28868. The orginal issue here I think is fixed because we now use unsigned int for the addition. The IR looks like: : d = 2; prephitmp.39 = 1; goto ; : d = 1; prephitmp.39 = 0; : MEM[base: a, index: ivtmp.49, step: 4, offset: 4294967292] = d; D.2029 = bar ((short int *) ivtmp.52, (int) (short int) *(pretmp.36 + prephitmp.39), d); Which looks good as there is no duplicated value. Note the offset of -4 is a different and already known issue. Ian do you think this should no longer be a 4.3 Regression or should we even not PRE "PHI<1,2> - 1" ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24609
[Bug tree-optimization/32606] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1026
--- Comment #4 from dberlin at gcc dot gnu dot org 2007-07-04 22:11 --- Subject: Bug 32606 Author: dberlin Date: Wed Jul 4 22:11:14 2007 New Revision: 126338 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126338 Log: 2007-07-04 Daniel Berlin <[EMAIL PROTECTED]> PR tree-optimization/32604 PR tree-optimization/32606 * tree-ssa-pre.c (bb_bitmap_sets): Removed antic_safe_loads. (compute_antic_safe): Removed. (ANTIC_SAFE_LOADS): Ditto. (compute_antic_aux): Don't print ANTIC_SAFE_LOADS. (execute_pre): Don't call compute_antic_safe. (vuse_equiv): New function. (make_values_for_stmt): Use it * tree-ssa-sccvn.c (set_ssa_val_to): Remove assert, since it is not always true. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32606.c trunk/gcc/testsuite/gfortran.fortran-torture/execute/pr32604.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32606
[Bug tree-optimization/32604] [4.3 regression] miscompilation at -O2
--- Comment #7 from dberlin at gcc dot gnu dot org 2007-07-04 22:11 --- Subject: Bug 32604 Author: dberlin Date: Wed Jul 4 22:11:14 2007 New Revision: 126338 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126338 Log: 2007-07-04 Daniel Berlin <[EMAIL PROTECTED]> PR tree-optimization/32604 PR tree-optimization/32606 * tree-ssa-pre.c (bb_bitmap_sets): Removed antic_safe_loads. (compute_antic_safe): Removed. (ANTIC_SAFE_LOADS): Ditto. (compute_antic_aux): Don't print ANTIC_SAFE_LOADS. (execute_pre): Don't call compute_antic_safe. (vuse_equiv): New function. (make_values_for_stmt): Use it * tree-ssa-sccvn.c (set_ssa_val_to): Remove assert, since it is not always true. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32606.c trunk/gcc/testsuite/gfortran.fortran-torture/execute/pr32604.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32604
[Bug target/19923] [4.0/4.1/4.2/4.3 Regression] openssl is slower when compiled with gcc 4.0 than 3.3
--- Comment #39 from pinskia at gcc dot gnu dot org 2007-07-04 21:53 --- I think this has been imrpvoed for 4.3, it would be nice if someone did some timings for 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19923
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #21 from kauer at os dot inf dot tu-dresden dot de 2007-07-04
21:50 ---
This simple testcase triggers the bug, too. Unfortunatelly I didnot test the
patch yet.
--
inline void g(int b)
{
register int reg __asm__ ("eax") = 0;
asm volatile ("nop" : "+r"(reg), "+r"(b));
}
void f(int a)
{
a /= 1000;
g(a);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug target/26290] [4.1/4.2/4.3 Regression]: code pessimization wrt. GCC 4.0 probably due to TARGET_MEM_REF
--- Comment #19 from pinskia at gcc dot gnu dot org 2007-07-04 21:32 --- > lsti = MEM[index: ivtmp.46, offset: 0x0fffc]; H. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords|ra | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26290
[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-04 21:30 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-04 21:30:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749
[Bug target/31331] [avr] ICE on function attribute syntax for main()
--- Comment #5 from aesok at gcc dot gnu dot org 2007-07-04 21:10 --- Subject: Bug 31331 Author: aesok Date: Wed Jul 4 21:10:28 2007 New Revision: 126337 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126337 Log: PR target/31331 * config/avr/avr.c (avr_naked_function_p): Handle receiving a type rather than a decl. (avr_attribute_table): Make "naked" attribute apply to function types rather than to decls. (avr_handle_fntype_attribute): New function. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31331
[Bug tree-optimization/21485] [4.0/4.1/4.2 Regression] codegen regression due to PRE increasing register pressure (missing load PRE really)
--- Comment #23 from pinskia at gcc dot gnu dot org 2007-07-04 21:01 --- I am going to declare this as fixed for 4.3, pointer plus gets the original case correctly and the secondary issues are all file seperately. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] |codegen regression due to |codegen regression due to |PRE increasing register |PRE increasing register |pressure (missing load PRE |pressure (missing load PRE |really) |really) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #5 from pcarlini at suse dot de 2007-07-04 20:39 --- David, can you have a quick look at this issue? Thanks. -- pcarlini at suse dot de changed: What|Removed |Added CC||dje at watson dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug fortran/32613] [4.3 regression] Different results depending on unnecessary variable declaration
--- Comment #9 from patchapp at dberlin dot org 2007-07-04 20:30 --- Subject: Bug number PR32613 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00396.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #20 from ubizjak at gmail dot com 2007-07-04 20:10 --- (In reply to comment #17) > (the variable should be 0), but it looks like the assembly might be wrong: > b.s: > (1)cmpl$9, __cp_log_handling_MOD_stack_pointer(%rip) > callmcount > movq%rdi, %rbx > (2)jle .L21 This _is_ wrong assembly. The call to mcount is clobbering flags reg between CC setting insn (1) and CC receiving insn (2). From there, the problem becomes trivial to track down, but I _really_ need a good sleep now. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-04 20:10:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug fortran/32613] [4.3 regression] Different results depending on unnecessary variable declaration
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu 2007-07-04 20:08 --- Subject: Re: [4.3 regression] Different results depending on unnecessary variable declaration On Wed, Jul 04, 2007 at 08:06:08PM -, pault at gcc dot gnu dot org wrote: > > > --- Comment #7 from pault at gcc dot gnu dot org 2007-07-04 20:06 --- > (In reply to comment #6) > > > I read this as: Works in 4.2.x, fails in 4.3, which is also what I get; I > > therefore changed the summary from "4.2 regression" to "4.3 regression". > > > > Thanks, Tobias. I was about to check whether this was so. I suspect that Al > meant wrt 4.2. > > I am just about to submit the fix. > I marked it as the 4.2 regression, and yes, I meant a regression in trunk with respect to 4.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #19 from pinskia at gmail dot com 2007-07-04 20:07 --- Subject: Re: -pg seemingly causes miscompilation On 4 Jul 2007 19:17:22 -, jv244 at cam dot ac dot uk <[EMAIL PROTECTED]> wrote: > b.s: > > .LCFI15: > cmpl$9, __cp_log_handling_MOD_stack_pointer(%rip) > callmcount > movq%rdi, %rbx > jle .L21 This is obviosuly wrong as the call will most likely clobber the flags register. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
Re: [Bug target/32450] -pg seemingly causes miscompilation
On 4 Jul 2007 19:17:22 -, jv244 at cam dot ac dot uk <[EMAIL PROTECTED]> wrote: b.s: .LCFI15: cmpl$9, __cp_log_handling_MOD_stack_pointer(%rip) callmcount movq%rdi, %rbx jle .L21 This is obviosuly wrong as the call will most likely clobber the flags register. -- Pinski
[Bug fortran/32613] [4.3 regression] Different results depending on unnecessary variable declaration
--- Comment #7 from pault at gcc dot gnu dot org 2007-07-04 20:06 --- (In reply to comment #6) > I read this as: Works in 4.2.x, fails in 4.3, which is also what I get; I > therefore changed the summary from "4.2 regression" to "4.3 regression". > Thanks, Tobias. I was about to check whether this was so. I suspect that Al meant wrt 4.2. I am just about to submit the fix. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug fortran/32627] [ISO Bind C] Accept c_f_pointer for TYPE
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|[ISO Bind C] Accept |[ISO Bind C] Accept |c_pointer_* for TYPE|c_f_pointer for TYPE Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32627
[Bug fortran/32627] New: [ISO Bind C] Accept c_pointer_* for TYPE
From: http://de.wikibooks.org/w/index.php?title=Fortran:_Fortran_und_C:_Fortran_2003#Datenverbund /tmp/ccW1yqyk.o: In function `MAIN__': f.f90:(.text+0x3e): undefined reference to `__iso_c_binding_c_f_pointer_s1' program main use iso_c_binding implicit none type, bind( c ) :: A integer( c_int ) :: xc, yc type( c_ptr ):: str end type type( c_ptr ) :: x type( A ), pointer :: fptr character( len=9 ), pointer :: strptr call c_f_pointer( fptr%str, strptr ) end program main -- Summary: [ISO Bind C] Accept c_pointer_* for TYPE Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid 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=32627
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #18 from ubizjak at gmail dot com 2007-07-04 19:58 --- (In reply to comment #12) > thanks for looking into this, but I'm afraid I don't really understand what > you're asking for. Also the PR mentioned in the above comment is a circular > reference. Sorry for the confusion, I was thinking on PR 32475, "function with asm() does not setup stack frame". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug libstdc++/31957] Build of compiler fails with 'error: #endif without #if'
--- Comment #4 from joerg dot richter at pdv-fs dot de 2007-07-04 19:48 --- Any chance that this gets fixed with 4.2.1? This is the only thing on AIX that prevents an unpatched bootstrap. Or perhaps its only missing documentation that GNU sed must be used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
[Bug libgcj/32619] -static-libgcj includes entire gnu classpath (>30MB executable from 95byte source)
--- Comment #4 from woody77 at gmail dot com 2007-07-04 19:22 --- Marco, thanks for the pointer to JNC. I'm targeting an embedded platform, with only 32MB of storage, so reducing the classes needed is mandatory. >From the size of the executable, it looked like the linker had just failed to prune uncalled code. (since libgcj is ~30MB on it's own). Is there a way to pull a report from the linker to determine what methods/classes are left behind and which are included? I did a check with strings and saw all sorts of classes that I'm sure I'm not using (java.util.zip.ZipInputStream for instance). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32619
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #17 from jv244 at cam dot ac dot uk 2007-07-04 19:17 --- actually, in gdb, I find that the variable is not corrupted: (gdb) bt #0 0x0089dc94 in __message_passing_MOD_mp_stop () #1 0x0050ed2e in __cp_log_handling_MOD_cp_add_default_logger () #2 0x0059a897 in __f77_interface_MOD_init_cp2k () #3 0x00d49638 in MAIN__ () #4 0x00e8786c in main (argc=2, argv=0x7fff1e9b6768) at /data/vondele/gcc_trunk/gcc/libgfortran/fmain.c:22 (gdb) up #1 0x0050ed2e in __cp_log_handling_MOD_cp_add_default_logger () (gdb) print __cp_log_handling_MOD_stack_pointer $1 = 0 (the variable should be 0), but it looks like the assembly might be wrong: g.s: .LCFI15: callmcount cmpl$9, __cp_log_handling_MOD_stack_pointer(%rip) movq%rdi, %rbx jle .L21 movl$108, %edx movl$.LC8, %esi movl$.LC9, %edi call__message_passing_MOD_mp_stop b.s: .LCFI15: cmpl$9, __cp_log_handling_MOD_stack_pointer(%rip) callmcount movq%rdi, %rbx jle .L21 movl$108, %edx movl$.LC8, %esi movl$.LC9, %edi call__message_passing_MOD_mp_stop -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #16 from jv244 at cam dot ac dot uk 2007-07-04 19:09 --- I've added the assembly as obtained from 1044 gfortran -O2 -pg -S cp_log_handling.f90 1045 mv cp_log_handling.s g.s 1046 gfortran -O2 -pg -march=native -S cp_log_handling.f90 1047 mv cp_log_handling.s b.s (i.e. the good and the bad case) for the file that triggers the stop. The stop is triggered by a check on : INTEGER, PRIVATE:: stack_pointer=0 INTEGER, PARAMETER, PRIVATE :: max_stack_pointer=10 [...] IF (stack_pointer+1>max_stack_pointer) THEN CALL mp_stop(100,routineP//& "too many default loggers, increase max_stack_pointer in "//moduleN) ENDIF it must be stack_pointer that gets corrupted somehow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #15 from jv244 at cam dot ac dot uk 2007-07-04 19:03 --- Created an attachment (id=13848) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13848&action=view) good assembly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #14 from jv244 at cam dot ac dot uk 2007-07-04 19:02 --- Created an attachment (id=13847) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13847&action=view) bad assembly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug c++/32245] [4.1/4.2/4.3 Regression] wrong POD type initialization with pointer to member
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32245
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #13 from jv244 at cam dot ac dot uk 2007-07-04 18:51 --- just checked that current trunk (Wed Jul 4 17:21:37 UTC 2007 (revision 126328)) still exhibits the same problem. I don't see the same problem on an opteron, only on a core2 (both using -march=native), so it could be something specific to core2? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug fortran/32601] [ISO Bind C] Access to private components not prevented
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-04 18:48 --- Related: print *, c_loc(4) end gives an ICE. Expected: Error: .f90, line 5: The argument to C_LOC must be a pointer or target additionally with -std=f2003: Error: .f90, line 5: Derived type C_PTR in io-list has PRIVATE components -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32601
[Bug bootstrap/32625] Bootstrap comparison failure!
--- Comment #2 from jv244 at cam dot ac dot uk 2007-07-04 18:34 --- a clean bootstrap passes now -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32625
[Bug fortran/32580] iso_c_binding c_f_procpointer / procedure pointers
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-04 18:29 --- Clean up from my Bind(C) notes: The following should give an error such as: Error: 'fptr' argument of 'c_f_procpointer' intrinsic at (1) must be a PROCEDURE POINTER use iso_c_binding type(c_funptr) :: cfunptr real, pointer :: myFunc call c_f_procpointer(cfunptr, myFunc) end -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Summary|iso_c_binding |iso_c_binding |c_f_procpointer |c_f_procpointer / procedure ||pointers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32580
[Bug fortran/32616] "Too short actual argument" for array element storage sequence
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-04 18:15 --- > A more general case as described in PR30939? Well, my example in PR30939 is actually fixed by PR30940, however, as NAG f95 proofs, one can test this at run time. I thus changed the purpose of that bug. This PR is about the missing parts of the compile-time length check, which I did not implement when fixing PR30940. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32616
[Bug fortran/32626] New: Run-time check for recursive functions
We probably need:
-fcheck-*
with
all
bounds
pointers
recursive
The recursive test is simple. C example:
bla(...)
{
static recursive = 0;
if(recursive)
exit_with_error
recursive = 1
...
recursive = 0; // Last statement
}
--
Summary: Run-time check for recursive functions
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: diagnostic
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=32626
[Bug fortran/32613] [4.3 regression] Different results depending on unnecessary variable declaration
--- Comment #6 from burnus at gcc dot gnu dot org 2007-07-04 18:10 --- > This a regression with respect to 4.2. I read this as: Works in 4.2.x, fails in 4.3, which is also what I get; I therefore changed the summary from "4.2 regression" to "4.3 regression". -- burnus at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.0 Known to work||4.2.1 Summary|[4.2 regression] Different |[4.3 regression] Different |results depending on|results depending on |unnecessary variable|unnecessary variable |declaration |declaration http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug bootstrap/32625] Bootstrap comparison failure!
--- Comment #1 from jv244 at cam dot ac dot uk 2007-07-04 18:00 --- could be due to an interupted & restarted build. I'm trying again with a clean build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32625
[Bug bootstrap/32625] New: Bootstrap comparison failure!
> cat ../gcc/LAST_UPDATED Wed Jul 4 19:21:37 CEST 2007 Wed Jul 4 17:21:37 UTC 2007 (revision 126328) rm -f stage_current make[3]: Leaving directory `/data/vondele/gcc_trunk/obj' Comparing stages 2 and 3 tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtbeginS.o' for reading: No such file or directory tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtbeginT.o' for reading: No such file or directory tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtfastmath.o' for reading: No such file or directory tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtbegin.o' for reading: No such file or directory tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtprec32.o' for reading: No such file or directory tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtprec64.o' for reading: No such file or directory tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtprec80.o' for reading: No such file or directory tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtendS.o' for reading: No such file or directory tail: cannot open `/data/vondele/gcc_trunk/obj/stage2-gcc/./32/crtend.o' for reading: No such file or directory Bootstrap comparison failure! ./32/crtbeginS.o differs ./32/crtbeginT.o differs ./32/crtfastmath.o differs ./32/crtbegin.o differs ./32/crtprec32.o differs ./32/crtprec64.o differs ./32/crtprec80.o differs ./32/crtendS.o differs ./32/crtend.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/data/vondele/gcc_trunk/obj' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/data/vondele/gcc_trunk/obj' make: *** [bootstrap] Error 2 -- Summary: Bootstrap comparison failure! Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32625
[Bug tree-optimization/20643] [4.0/4.1/4.2 Regression] Tree loop optimizer does worse job than RTL loop optimizer
--- Comment #18 from pinskia at gcc dot gnu dot org 2007-07-04 17:58 --- Yep this was fixed by Pointer_plus. The load of hmm->tsc is no longer in the inner most loop. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 Regression]|[4.0/4.1/4.2 Regression] |Tree loop optimizer does|Tree loop optimizer does |worse job than RTL loop |worse job than RTL loop |optimizer |optimizer http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20643
[Bug fortran/32613] [4.2 regression] Different results depending on unnecessary variable declaration
--- Comment #5 from pault at gcc dot gnu dot org 2007-07-04 17:44 --- This is my doing - that makes two this week. *groan* The regression is caused by the patch for pr31204, which goes back to April. For some reason that I do not yet see, the variable i in the statement function is being treated as if it were an implied do-loop iterator. I'm on to it. 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|2007-07-04 16:25:56 |2007-07-04 17:44:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug tree-optimization/32500] [4.2 Regression] Loop optimization limits range to size of array used inside loop
--- Comment #17 from ed at fxq dot nl 2007-07-04 17:35 --- Sorry if I'm being a nitpick... The committed testcase contains a small error; it has an off-by-one bug that causes a small buffer overflow. The line: foo(numbers[i]); should be replaced with: foo(numbers[i - 1]); It shouldn't cause any real problems, because it's just a testcase, but maybe some quite intelligent new optimizer might trip on that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
[Bug c++/31338] [4.1 regression] Cannot apply "!" to complex constants
--- Comment #9 from mmitchel at gcc dot gnu dot org 2007-07-04 17:27 --- Fixed in 4.2.1. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.1/4.2 regression] Cannot |[4.1 regression] Cannot |apply "!" to complex|apply "!" to complex |constants |constants http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31338
[Bug c++/31338] [4.1/4.2 regression] Cannot apply "!" to complex constants
--- Comment #8 from mmitchel at gcc dot gnu dot org 2007-07-04 17:18 --- Subject: Bug 31338 Author: mmitchel Date: Wed Jul 4 17:18:22 2007 New Revision: 126329 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126329 Log: PR c++/31388 * cp-tree.h (ARITHMETIC_TYPE): Include COMPLEX_TYPE. * typeck.c (type_after_usual_arithmetic_conversions): Adjust, as COMPLEX_TYPE is now an ARITHMETIC_TYPE. * init.c (build_zero_init): Adjust, as COMPLEX_TYPE is now a SCALAR_TYPE. * typeck2.c (digest_init): Allow brace-enclosed initializers for COMPLEX_TYPE, even though that is now a SCALAR_TYPE. PR c++/31338 * g++.dg/ext/complex2.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/ext/complex2.C - copied unchanged from r124172, trunk/gcc/testsuite/g++.dg/ext/complex2.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/cp-tree.h branches/gcc-4_2-branch/gcc/cp/init.c branches/gcc-4_2-branch/gcc/cp/typeck.c branches/gcc-4_2-branch/gcc/cp/typeck2.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31338
[Bug target/31388] ICE building libiberty multilib for mips16 multilibs
--- Comment #4 from mmitchel at gcc dot gnu dot org 2007-07-04 17:18 --- Subject: Bug 31388 Author: mmitchel Date: Wed Jul 4 17:18:22 2007 New Revision: 126329 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126329 Log: PR c++/31388 * cp-tree.h (ARITHMETIC_TYPE): Include COMPLEX_TYPE. * typeck.c (type_after_usual_arithmetic_conversions): Adjust, as COMPLEX_TYPE is now an ARITHMETIC_TYPE. * init.c (build_zero_init): Adjust, as COMPLEX_TYPE is now a SCALAR_TYPE. * typeck2.c (digest_init): Allow brace-enclosed initializers for COMPLEX_TYPE, even though that is now a SCALAR_TYPE. PR c++/31338 * g++.dg/ext/complex2.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/ext/complex2.C - copied unchanged from r124172, trunk/gcc/testsuite/g++.dg/ext/complex2.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/cp-tree.h branches/gcc-4_2-branch/gcc/cp/init.c branches/gcc-4_2-branch/gcc/cp/typeck.c branches/gcc-4_2-branch/gcc/cp/typeck2.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31388
[Bug fortran/32526] [4.3 regression] Spurious error: Name 'x' at (1) is an ambiguous reference to 'x' from module 'y'
--- Comment #7 from patchapp at dberlin dot org 2007-07-04 17:15 --- Subject: Bug number PR32526 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00381.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32526
[Bug tree-optimization/16913] [4.0/4.1/4.2/4.3 Regression] restrict does not make a difference
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-07-04 17:02 --- >Which is almost the best you can do :). Well except to use store with update but that is an IV-OPTs issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16913
[Bug target/32337] [4.3 Regression] Error: Register number out of range 0..1
--- Comment #1 from jakub at gcc dot gnu dot org 2007-07-04 16:35 --- Created an attachment (id=13846) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13846&action=view) gcc43-pr32337.patch The problem seems to be caused by the addition of the emitted_frame_related_regs array, there are several issues I found (see this patch) and in the end two of the 3 saved registers (RP, PFS, FP) were saved in the same register, which caused severe havoc. I'll try to bootstrap/regtest this on ia64-linux, so far I have only tested that it cures the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32337
[Bug middle-end/32624] [4.3 Regression] r126198 causes tramp3d slowdown w/o leafify
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-04 16:31 --- So, the following patch brings performance back in-line: Index: tree-inline.c === --- tree-inline.c (revision 126325) +++ tree-inline.c (working copy) @@ -1283,8 +1283,7 @@ setup_one_parameter (copy_body_data *id, ? gimple_default_def (id->src_cfun, p) : NULL); if (value - && value != error_mark_node - && !useless_type_conversion_p (TREE_TYPE (p), TREE_TYPE (value))) + && value != error_mark_node) rhs = fold_build1 (NOP_EXPR, TREE_TYPE (p), value); /* If the parameter is never assigned to, has no SSA_NAMEs created, which doesn't make sense, as it is then just unconditionally adding a temporary and a conversion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
[Bug fortran/32613] [4.2 regression] Different results depending on unnecessary variable declaration
--- Comment #4 from kargl at gcc dot gnu dot org 2007-07-04 16:27 --- Add wrong-code keyword. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug fortran/32613] [4.2 regression] Different results depending on unnecessary variable declaration
--- Comment #3 from kargl at gcc dot gnu dot org 2007-07-04 16:25 --- I thought I had confirmed this as a bug. Let's try again. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-07-03 16:24:15 |2007-07-04 16:25:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug fortran/32613] [4.2 regression] Different results depending on unnecessary variable declaration
--- Comment #2 from kargl at gcc dot gnu dot org 2007-07-04 16:24 ---
I've compared the output of -fdump-tree-original for 4.2 and trunk, and
the only significant difference is
internal (j)
{
int4 k;
+ int4 i;
logical4 __result_internal;
That is, the implicitly typed 'i' in trunk is not being host associated
with the 'i' in the procedure INTERNAL, so INTERNAL gets a local
variable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug libstdc++/30264] libstdc++-v3 compile error - conflicts with previous using declaration
--- Comment #4 from pcarlini at suse dot de 2007-07-04 16:16 --- Feedback not forthcoming. -- pcarlini at suse dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30264
[Bug middle-end/32624] [4.3 Regression] r126198 causes tramp3d slowdown w/o leafify
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-04 16:12 --- Created an attachment (id=13845) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13845&action=view) alias6 dump of the function with the patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
[Bug middle-end/32624] [4.3 Regression] r126198 causes tramp3d slowdown w/o leafify
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-04 16:12 --- Created an attachment (id=13844) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13844&action=view) alias6 dump of the function without the patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
[Bug middle-end/32624] [4.3 Regression] r126198 causes tramp3d slowdown w/o leafify
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-04 16:11 --- This seems to be an aliasing problem. Somehow we do not prune SMTs enough after the patch. MPT grouping doesn't trigger in. An example function to look at is (x86_64) _ZN14MultiArgKernelI9MultiArg4I5FieldI22UniformRectilinearMeshI10MeshTraitsILi3Ed21UniformRectilinearTag12CartesianTagLi3EEEd10BrickViewUES9_S9_S9_E15EvaluateLocLoopIN6Forgas5CentYILi3EEELi3EEE3runEv if you look at the alias6 dump (the one before lim which does no longer move invariant integer loads out of the inner loop) you can see: without the patch: # VUSE D.852018_33 = op$multiArg_m_7->a1_m.fieldEngine_m.data_m.blockControllerPtr_m.ptr_m; with the patch (only the tree-inline.c part is actually necessary): # VUSE D.854673_30 = op$multiArg_m_19->a1_m.fieldEngine_m.data_m.blockControllerPtr_m.ptr_m; it doesn't make sense that there is a difference in pruning. Really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
[Bug libstdc++/31906] "-Xcompiler" is inserted after "-Xlinker" when building libstdc++
--- Comment #5 from pcarlini at suse dot de 2007-07-04 15:34 --- Therefore, can we close the PR? -- pcarlini at suse dot de changed: What|Removed |Added CC||zackw at panix dot com Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
[Bug libfortran/32611] Print sign of negative zero
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-07-04 15:23 --- OK, you talked me into it. :) -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-04 07:08:52 |2007-07-04 15:23:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32611
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #12 from jv244 at cam dot ac dot uk 2007-07-04 14:51 --- (In reply to comment #11) > > Just a wild guess, could this depend on PR32450? Could you check if there is > an > access to stack after leave insn? > Hi Uros, thanks for looking into this, but I'm afraid I don't really understand what you're asking for. Also the PR mentioned in the above comment is a circular reference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug middle-end/32624] New: [4.3 Regression] r126198 causes tramp3d slowdown w/o leafify
The following part of r126198 causes a 5% slowdown of tramp3d for the non-leafify tests (with leafify it makes it run faster): 2007-07-02 Richard Guenther <[EMAIL PROTECTED]> * fold-const.c (fold_convert): Revert fix for PR15988. * tree-inline.c (setup_one_parameter): Instead fix it here by using fold_build1 instead of fold_convert and checking for error_mark_node. Convert only if the conversion is necessary. Index: fold-const.c === --- fold-const.c(revision 126197) +++ fold-const.c(revision 126198) @@ -2262,9 +2262,7 @@ fold_convert (tree type, tree arg) || TREE_CODE (orig) == ERROR_MARK) return error_mark_node; - if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (orig) - || lang_hooks.types_compatible_p (TYPE_MAIN_VARIANT (type), - TYPE_MAIN_VARIANT (orig))) + if (TYPE_MAIN_VARIANT (type) == TYPE_MAIN_VARIANT (orig)) return fold_build1 (NOP_EXPR, type, arg); switch (TREE_CODE (type)) Index: tree-inline.c === --- tree-inline.c (revision 126197) +++ tree-inline.c (revision 126198) @@ -1278,10 +1278,15 @@ setup_one_parameter (copy_body_data *id, tree init_stmt; tree var; tree var_sub; - tree rhs = value ? fold_convert (TREE_TYPE (p), value) : NULL; + tree rhs = value; tree def = (gimple_in_ssa_p (cfun) ? gimple_default_def (id->src_cfun, p) : NULL); + if (value + && value != error_mark_node + && !useless_type_conversion_p (TREE_TYPE (p), TREE_TYPE (value))) +rhs = fold_build1 (NOP_EXPR, TREE_TYPE (p), value); + /* If the parameter is never assigned to, has no SSA_NAMEs created, we may not need to create a new variable here at all. Instead, we may be able to just use the argument value. */ I am investigating why. -- Summary: [4.3 Regression] r126198 causes tramp3d slowdown w/o leafify Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: middle-end AssignedTo: rguenth at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32624
[Bug fortran/32594] INDEX is not simplified, leads to ICE
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-07-04 14:36
---
Please forget comment #3. The reason for the ICE is that substring
simplification was written without taking into account the possibility of
foo(14:) or foo(:14), ie one of the substring bounds being implicit. The
following patch fixes it, I'm regtesting and will try to write a few more
testcases before submitting it for review:
Index: expr.c
===
--- expr.c (revision 126249)
+++ expr.c (working copy)
@@ -1503,9 +1503,19 @@ gfc_simplify_expr (gfc_expr *p, int type
char *s;
int start, end;
- gfc_extract_int (p->ref->u.ss.start, &start);
- start--; /* Convert from one-based to zero-based. */
- gfc_extract_int (p->ref->u.ss.end, &end);
+ if (p->ref->u.ss.start)
+ {
+ gfc_extract_int (p->ref->u.ss.start, &start);
+ start--; /* Convert from one-based to zero-based. */
+ }
+ else
+ start = 0;
+
+ if (p->ref->u.ss.end)
+ gfc_extract_int (p->ref->u.ss.end, &end);
+ else
+ end = p->value.character.length - 1;
+
s = gfc_getmem (end - start + 2);
memcpy (s, p->value.character.string + start, end - start);
s[end - start + 1] = '\0'; /* TODO: C-style string. */
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Keywords||patch
Last reconfirmed|2007-07-04 07:47:17 |2007-07-04 14:36:19
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32594
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #11 from ubizjak at gmail dot com 2007-07-04 14:26 ---
Hm...
--cut here--
// just a stupid testcase, don't bother with source
long long test(long long a, long long b)
{
return a / b;
}
--cut here--
cc1 -O2:
test:
.LFB2:
movq%rdi, %rdx
movq%rdi, %rax
sarq$63, %rdx
idivq %rsi
ret
cc1 -O1 -p:
test:
.LFB2:
pushq %rbp
.LCFI0:
movq%rsp, %rbp
.LCFI1:
callmcount
movq%rdi, %rdx
movq%rdi, %rax
sarq$63, %rdx
idivq %rsi
leave
ret
cc1 -O2 -p
test:
.LFB2:
pushq %rbp
.LCFI0:
movq%rsp, %rbp
.LCFI1:
callmcount
leave
movq%rdi, %rdx
movq%rdi, %rax
sarq$63, %rdx
idivq %rsi
ret
Just a wild guess, could this depend on PR32450? Could you check if there is an
access to stack after leave insn?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug tree-optimization/32606] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1026
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-07-04 14:24 ---
Here is a reduced testcase which has only one function in it:
int inb(int);
void is870(unsigned int wkport, unsigned char j)
{
unsigned int tmport;
unsigned char i;
for (i = 0; i < 16; i++)
{
tmport = wkport + 0x18;
tmport += 0x07;
while ((inb(tmport) & 0x80) == 0)
{
if ((inb(tmport) & 0x01) != 0)
{
tmport -= 0x06;
tmport += 0x06;
}
}
tmport = wkport + 0x14;
tmport += 0x04;
tmport += 0x07;
widep_in1:
if ((j & 0x01) != 0)
{
tmport -= 0x06;
tmport += 0x06;
goto widep_in1;
}
while ((inb(tmport) & 0x80) == 0) {}
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32606
[Bug tree-optimization/32328] [4.2/4.3 Regression] -fstrict-aliasing causes skipped code
--- Comment #14 from dberlin at gcc dot gnu dot org 2007-07-04 14:16 --- Subject: Re: [4.2/4.3 Regression] -fstrict-aliasing causes skipped code On 4 Jul 2007 03:29:25 -, mmitchel at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > -- Just as an update: I have been working with richi (I code, he tests :P) diligently on a patch for mainline, and have one that fixes the dealii regression (and thus, should fix this as well). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32328
Re: [Bug tree-optimization/32328] [4.2/4.3 Regression] -fstrict-aliasing causes skipped code
On 4 Jul 2007 03:29:25 -, mmitchel at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: -- Just as an update: I have been working with richi (I code, he tests :P) diligently on a patch for mainline, and have one that fixes the dealii regression (and thus, should fix this as well).
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #10 from ubizjak at gmail dot com 2007-07-04 14:16 --- (In reply to comment #9) > So, it loads %r11 and calls mcount. The only thing that can go wrong is, that > some value in %r11 gets rewritten. Not even that because x86_64 is a NO_PROFILE_COUNTERS by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug target/32450] -pg seemingly causes miscompilation
--- Comment #9 from ubizjak at gmail dot com 2007-07-04 14:11 --- (In reply to comment #1) > Most likely -pg is changing the alignment of the stack which is incorrect. Oh > -pg code is emitted by the target specific code so this is a target issue. Hm, on x86_64 pg inserts: fprintf (file, "\tleaq\t%sP%d@(%%rip),%%r11\n", LPREFIX, labelno); fprintf (file, "[EMAIL PROTECTED](%%rip)\n", MCOUNT_NAME); So, it loads %r11 and calls mcount. The only thing that can go wrong is, that some value in %r11 gets rewritten. Could you look what happens with %r11 around the point of failure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
[Bug fortran/32526] [4.3 regression] Spurious error: Name 'x' at (1) is an ambiguous reference to 'x' from module 'y'
--- Comment #6 from pault at gcc dot gnu dot org 2007-07-04 14:05 --- (In reply to comment #5) OK, I now have it understood. The patch in the previous comment is the clue. The patch for pr31494 was marking generic interfaces as subroutines, thereby screwing up the mechanism for detecting ambiguity. The "correct" solution is regtesting, right now. 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|2007-06-27 21:05:26 |2007-07-04 14:05:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32526
[Bug middle-end/32004] [4.1/4.2/4.3 regression] : can't find a register in class 'GENERAL_REGS' while reloading 'asm'
--- Comment #20 from bonzini at gnu dot org 2007-07-04 13:54 --- The attached patch makes PR30311 resurface; this seems like a minor problem because that code is dubious, and can be worked around by not doing the transformation when the modes mismatch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32004
[Bug target/32622] BOOT_CFLAGS is not passed to stage2 and stage3 compile
--- Comment #5 from spop at gcc dot gnu dot org 2007-07-04 13:42 --- Subject: Re: BOOT_CFLAGS is not passed to stage2 and stage3 compile > Actually this is caused by config/mh-x86omitfp. If you disable BOOT_CFLAGS in > that file, it will just work. Right, that's also what I saw, and the fix that I'm testing now is to replace that line from mh-x86omitfp by BOOT_CFLAGS += -fomit-frame-pointer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32622
[Bug other/31349] [4.3 Regression] gcc -v --help returns no options for C, C++
--- Comment #7 from nickc at redhat dot com 2007-07-04 13:40 --- Subject: Re: [4.3 Regression] gcc -v --help returns no options for C, C++ Hi Brooks, > So, if I understand correctly: all of the options are listed somewhere, but we > no longer provide any information about which of the shared options under > "language related options" are supported by a given language's front end? Correct. Well by default anyway. See below. > While this may have been intentional, I do not think it counts as a feature - > the listing of the "common" options without definitions at the top of the > option listing did not take up a significant amount of space, and it provided > very useful information that's now absent. OK. > (On the other hand, moving the _descriptions_ of the shared options to a > single > listing is a good thing, IMO -- I want to make it clear that I'm not objecting > to the bulk of this change!) You can find out all the options supported by a given language, including the ones that it shares with other languages and including those that do not have a description by using the --help= feature. For example: % gcc --help=java The following options are supported by the language Java: -I This switch lacks documentation -M This switch lacks documentation -MD_This switch lacks documentation -MF This switch lacks documentation -MM This switch lacks documentation -MMD_ This switch lacks documentation -MP This switch lacks documentation -MT This switch lacks documentation -Wall This switch lacks documentation -Wall-deprecation This switch lacks documentation -Wall-javadoc This switch lacks documentation -Wassert-identifier This switch lacks documentation -Wchar-concat This switch lacks documentation -Wcondition-assign This switch lacks documentation -Wconstructor-name This switch lacks documentation -Wdep-ann This switch lacks documentation -WdeprecatedWarn if a deprecated compiler feature, class, method, or field is used [etc...] So I think that the bone of contention here is what should be listed by "--help -v". I think that leaving out options which have no description is a good default. If for no other reason than to encourage people to write descriptions for the options so that they are then listed in the --help output. Do you still feel that "--help -v" should list undocumented options ? Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31349
[Bug rtl-optimization/31849] [4.3 Regression] Code size regression caused by fix to PR 31360
--- Comment #18 from rakdver at gcc dot gnu dot org 2007-07-04 13:32 --- (In reply to comment #0) > The fix to PR31360 has caused significant code size regressions on ARM-EABI. > An example of this is from zlib (adler32.c) and is attached, compile with -Os > -mcpu=arm7tdmi -fno-short-enums -w > > The new code: > 1) Hoists a register containing 0 out of the loop > 2) Uses that *only* as a copy into another register (mov reg, #0 costs exactly > the same as mov reg, reg) Actually, rtx_cost claims that mov reg, #0 costs 20, while mov reg, reg costs 16. Fixing this (assuming that is indeed wrong) will not fix the problem (without further changes to the invariant motion), but it is the first step. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31849
[Bug target/32558] v850: unrecognizable insn compiling libgcc2 on 64-bit CPU
--- Comment #3 from nickc at redhat dot com 2007-07-04 13:28 --- Hi Rask, Well the patch is definitely an improvement, so I have applied it. I will try to find time to look at the regressions in the next week or two. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32558
[Bug target/32622] BOOT_CFLAGS is not passed to stage2 and stage3 compile
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-07-04 13:27 --- Actually this is caused by config/mh-x86omitfp. If you disable BOOT_CFLAGS in that file, it will just work. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|bootstrap |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32622
[Bug fortran/30929] -pedantic-error and -Werror don't produce errors!
--- Comment #6 from manu at gcc dot gnu dot org 2007-07-04 13:08 ---
(In reply to comment #4)
>
> No idea how to untangle -pedantic from -Wtabs or -Wampersand if
> -pedantic-errors has been given, but -Werror has not.
>
What gfortran should do is that if pedantic enables Wtabs, then the warnings
should be of the form:
if (pedantic && warn_tabs)
pedantic("whatever");
else if (warn_tabs)
warning("whatever");
pedantic() emits errors if -pedantic-errors, otherwise it emits warnings.
warning() emits errors if -Werror, otherwise it emits warnings.
I guess there would be similar functions in gfortran. (It would be great to
integrate the diagnostics machinery but making things work in a similar way is
already a step forward).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30929
[Bug tree-optimization/32500] [4.2 Regression] Loop optimization limits range to size of array used inside loop
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-07-04 12:40 --- 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=32500
[Bug tree-optimization/32500] [4.2 Regression] Loop optimization limits range to size of array used inside loop
--- Comment #15 from rguenth at gcc dot gnu dot org 2007-07-04 12:39 --- Subject: Bug 32500 Author: rguenth Date: Wed Jul 4 12:39:42 2007 New Revision: 126316 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126316 Log: 2007-07-04 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/32500 * gcc.c-torture/execute/pr32500.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr32500.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
[Bug tree-optimization/32500] [4.2 Regression] Loop optimization limits range to size of array used inside loop
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-07-04 12:38 --- Subject: Bug 32500 Author: rguenth Date: Wed Jul 4 12:38:23 2007 New Revision: 126315 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126315 Log: 2007-07-04 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/32500 * tree-ssa-loop-niter.c (infer_loop_bounds_from_undefined): Only use basic blocks that are always executed to infer loop bounds. * gcc.c-torture/execute/pr32500.c: New testcase. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/pr32500.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/tree-ssa-loop-niter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
[Bug target/31897] [4.3 Regression] 30% speed regression with -m32 on Opteron with rnflow
--- Comment #4 from ubizjak at gmail dot com 2007-07-04 12:32 --- (In reply to comment #1) > gfortran -ffast-math -funroll-loops -O3 -msse3 -mfpmath=387 rnflow.f90 > > time ./a.out > user0m37.982s > gfortran -ffast-math -funroll-loops -O3 -msse3 -mfpmath=387 -ftree-vectorize > rnflow.f90 > > time ./a.out > user0m55.031s This is on XEON as in Comment #3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31897
[Bug tree-optimization/32032] [4.3 Regression] Inliner not setting has_volatile_ops
--- Comment #4 from jakub at gcc dot gnu dot org 2007-07-04 12:31 --- This doesn't ICE any longer on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32032
[Bug target/31897] [4.3 Regression] 30% speed regression with -m32 on Opteron with rnflow
--- Comment #3 from ubizjak at gmail dot com 2007-07-04 12:29 --- (In reply to comment #2) > Can't reproduce this, gcc 4.3 actually seems to be faster (tests done on Intel > quadcore Core2): On core2 the bug doesn't trigger, but it shows on FC4 with: vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 3.60GHz stepping: 10 cpu MHz : 3600.970 cache size : 2048 KB This is one of most mysterious bugs I've ever seen. The _idamax routine is exactly the same for both builds, but it shows such a difference. I have analyzed this with cachegrind but nothing sticks out there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31897
[Bug tree-optimization/32500] [4.2 Regression] Loop optimization limits range to size of array used inside loop
--- Comment #13 from ed at fxq dot nl 2007-07-04 12:06 --- Hello Richard, I can confirm that the patch fixes this regression. I just installed a patch compiler on my FreeBSD box and I get a proper binary, even when I build it with '-O2 -ftree-vrp' (just to be sure). Thanks! Any chance this patch will make it into 4.2.1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
[Bug target/31897] [4.3 Regression] 30% speed regression with -m32 on Opteron with rnflow
--- Comment #2 from jakub at gcc dot gnu dot org 2007-07-04 11:57 --- Can't reproduce this, gcc 4.3 actually seems to be faster (tests done on Intel quadcore Core2): /usr/src/gcc-4.2/obj/gcc/gfortran -B /usr/src/gcc-4.2/obj/gcc/ -L /usr/src/gcc-4.2/obj/x86_64-unknown-linux-gnu/32/libgfortran/.libs/ -Wl,-rpath,/usr/src/gcc-4.2/obj/x86_64-unknown-linux-gnu/32/libgfortran/.libs/ -m32 -march=opteron -ffast-math -funroll-loops -ftree-vectorize -ftree-loop-linear -O3 rnflow.f90 -o rnflow42 /usr/src/gcc/obj/gcc/gfortran -B /usr/src/gcc/obj/gcc/ -L /usr/src/gcc/obj/x86_64-unknown-linux-gnu/32/libgfortran/.libs/ -Wl,-rpath,/usr/src/gcc/obj/x86_64-unknown-linux-gnu/32/libgfortran/.libs/ -m32 -march=opteron -ffast-math -funroll-loops -ftree-vectorize -ftree-loop-linear -O3 rnflow.f90 -o rnflow43 gfortran -m32 -march=opteron -ffast-math -funroll-loops -ftree-vectorize -ftree-loop-linear -O3 rnflow.f90 -o rnflow41 for i in 1 2 3; do time ./rnflow4$i > /dev/null; time ./rnflow4$i > /dev/null; done real0m30.003s user0m29.601s sys 0m0.399s real0m29.811s user0m29.436s sys 0m0.370s real0m29.875s user0m29.468s sys 0m0.403s real0m29.824s user0m29.441s sys 0m0.378s real0m26.007s user0m25.627s sys 0m0.376s real0m25.822s user0m25.403s sys 0m0.415s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31897
[Bug tree-optimization/32482] [4.3 Regression] ICE verify_ssa failed
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-07-04 11:46 --- 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=32482
[Bug tree-optimization/32482] [4.3 Regression] ICE verify_ssa failed
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-04 11:45 --- Subject: Bug 32482 Author: rguenth Date: Wed Jul 4 11:44:58 2007 New Revision: 126314 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126314 Log: 2007-07-04 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/32482 * tree-ssa-ifcombine.c (recognize_single_bit_test): Use the original ssa name if we didn't find a shift expression. Fix shift constant for bit zero test. * gcc.c-torture/compile/pr32482.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32482.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ifcombine.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32482
[Bug fortran/31197] [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings
--- Comment #21 from pault at gcc dot gnu dot org 2007-07-04 11:32 --- > Warsaw, 18.5 C, overcast. Of course, Paul's work on gfortran is more > important than anything else :-) > There is also the question of what I am expected to do over the weekend after three weeks away from home. Catching up with gfc will not even be on the list. P -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)
--- Comment #8 from eres at il dot ibm dot com 2007-07-04 11:24 --- I think c__lsm.63_30 is created during the store motion optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #30 from dnovillo at google dot com 2007-07-04 11:22 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code On 7/3/07 11:28 PM, mmitchel at gcc dot gnu dot org wrote: > --- Comment #29 from mmitchel at gcc dot gnu dot org 2007-07-04 03:28 > --- > Diego, does this problem still exist on the 4.2 branch? I see that you > checked > in a patch, which you suggest may not be a complete fix, but does this test > case still fail? Yes, the problem still exists on 4.2 and mainline. The patch is valid in that it fixes a codegen deficiency, but it only works around this bug. The test case does not fail anymore, and getting another one to fail may be tricky (it's a fairly rare bug, unfortunately). A real fix is in the works, but it's not clear when it might be ready. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)
--- Comment #7 from dorit at gcc dot gnu dot org 2007-07-04 11:14 --- The vectorizer reports: pr25621.f90:7: note: reduction used in loop. pr25621.f90:7: note: Unknown def-use cycle pattern. because of the seemingly redundant assignment: c__lsm.63_30 = D.1361_38; which uses the reduction variable D.1361_38 inside the loop (only to be used outside the loop). Need to teach the vectorizer to ignore this assignment or clean it away before the vectorizer. : # prephitmp.57_5 = PHI # i_3 = PHI <1(3), i_40(5)> D.1357_31 = i_3 + -1; D.1358_33 = (*a_32(D))[D.1357_31]; D.1359_36 = (*b_35(D))[D.1357_31]; D.1360_37 = D.1359_36 * D.1358_33; D.1361_38 = prephitmp.57_5 + D.1360_37; c__lsm.63_30 = D.1361_38; i_40 = i_3 + 1; if (i_3 == D.1339_28) goto ; else goto ; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
[Bug fortran/31197] [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings
--- Comment #20 from Tobias dot Schlueter at physik dot uni-muenchen dot de 2007-07-04 10:51 --- Subject: Re: [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings jv244 at cam dot ac dot uk wrote: > --- Comment #19 from jv244 at cam dot ac dot uk 2007-07-04 10:05 --- > (In reply to comment #18) >> I'll spend this afternoon on >> it, rather than going on the conference excursion. > > depending on location/weather, I'd go for the conference excursion ;-) Warsaw, 18.5 C, overcast. Of course, Paul's work on gfortran is more important than anything else :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug target/32623] New: m68k: Inaccurate multiply cost on some V2 ColdFire CPUs.
When building for a ColdFire V2 CPU, GCC will prefer using shift-and-add over multiply, even if multiply would generate code that is smaller and as fast, if not faster, on the target CPU in question. This happens because the multiply cost is based on ColdFire version rather than the capabilities. Basing the multiply cost on the presence of a MAC (or EMAC) unit on the target CPU would be more accurate, at least on ColdFire V2. See the definitions of MULL_COST and MULW_COST in gcc/config/m68k/m68k.c, at about line 2138. -- Summary: m68k: Inaccurate multiply cost on some V2 ColdFire CPUs. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: betheking at spray dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32623
[Bug c++/30854] [4.3 Regression] Wrong number of arguments printed for constructor
-- 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 Last reconfirmed|2007-02-23 00:09:52 |2007-07-04 10:37:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30854
[Bug c/30595] gcc3.4.6 generates incorrect ppc32 code for combination of bitfields and shifts
--- Comment #1 from clemens dot koller at anagramm dot de 2007-07-04 10:34 --- Cannot reproduce this problem on PPC32 with gcc-4.2.0. The result is with all -Ox correct: 234500 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30595
[Bug tree-optimization/32500] [4.2 Regression] Loop optimization limits range to size of array used inside loop
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-07-04 10:16
---
This is SCEV. From
:;
i_7 = ASSERT_EXPR 4>;
i.10_10 = (unsigned int) i_7;
D.2489_11 = i.10_10 - 7;
if (D.2489_11 <= 2) goto ; else goto ;
we have
Found new range for i.10_10: [5, 12]
Visiting statement:
D.2489_11 = i.10_10 - 7;
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = D.2489_11)
(get_scalar_evolution
(scalar = D.2489_11)
(scalar_evolution = {4294967290, +, 1}_1))
(set_scalar_evolution
(scalar = D.2489_11)
(scalar_evolution = {4294967290, +, 1}_1))
)
(instantiate_parameters
(loop_nb = 1)
(chrec = {4294967290, +, 1}_1)
(res = {4294967290, +, 1}_1))
Found new range for D.2489_11: [4294967290, +INF]
which is wrong. The new range should be ~[5, 4294967290].
scev_probably_wraps_p() returns false for the above chrec because for
the loop in question estimated_nb_iterations is 4(!) which is derived
from infer_loop_bounds_from_undefined. On the trunk this is fixed
by rewriting number of iterations analysis. On the 4.2 branch we
can fix this conservatively by
Index: tree-ssa-loop-niter.c
===
--- tree-ssa-loop-niter.c (revision 126260)
+++ tree-ssa-loop-niter.c (working copy)
@@ -1747,6 +1747,12 @@ infer_loop_bounds_from_undefined (struct
{
bb = bbs[i];
+ /* If BB is not executed in each iteration of the loop, we cannot
+use the operations in it to infer reliable upper bound on the
+# of iterations of the loop. */
+ if (!dominated_by_p (CDI_DOMINATORS, loop->latch, bb))
+ continue;
+
for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
{
tree stmt = bsi_stmt (bsi);
I'm going to test this.
--
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|NEW |ASSIGNED
Last reconfirmed|2007-06-26 10:45:47 |2007-07-04 10:16:51
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32500
[Bug fortran/31197] [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings
--- Comment #19 from jv244 at cam dot ac dot uk 2007-07-04 10:05 --- (In reply to comment #18) > I'll spend this afternoon on > it, rather than going on the conference excursion. depending on location/weather, I'd go for the conference excursion ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
