[Bug middle-end/47646] [4.6 Regression] Revision 169918 caused many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47646 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||FIXED --- Comment #2 from Eric Botcazou 2011-02-09 08:16:12 UTC --- Test adjusted.
[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47324
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #22 from Jakub Jelinek 2011-02-09
08:23:36 UTC ---
The #c14 dwarf2out.c hunks look reasonable, though I'd probably just declare
the r variable inside of the if block (i.e.
...
{
unsigned long r
= DWARF2_FRAME_REG_OUT (cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
...
). And for consistency DWARF2_FRAME_REG_OUT should be probably used in
output_cfa_loc_raw too, just with unconditional 1 as for_eh.
That said, I very much doubt r157762 did anything here, for this purpose it
just swapped the two operands, but the code wasn't using DWARF2_FRAME_REG_OUT
before that check in either. r157762 would only matter in output_cfis which is
called when doing hot/cold section partitioning (which eh-alloca-1.C is not).
[Bug middle-end/47646] [4.6 Regression] Revision 169918 caused many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47646
--- Comment #3 from Dominique d'Humieres 2011-02-09
08:26:12 UTC ---
The following patch is missing for
gcc/testsuite/obj-c++.dg/attributes/method-noreturn-1.mm:
---
/opt/gcc/_gcc_clean/gcc/testsuite/obj-c++.dg/attributes/method-noreturn-1.mm
2010-11-02 10:36:25.0 +0100
+++
/opt/gcc/gcc-4.6-work/gcc/testsuite/obj-c++.dg/attributes/method-noreturn-1.mm
2011-02-09 09:19:24.0 +0100
@@ -18,11 +18,11 @@
+ (id) method1
{
return self; /* { dg-warning "function declared .noreturn. has a .return.
statement" } */
-} /* { dg-warning ".noreturn. function does return" } */
+} /* { dg-warning ".noreturn. function does return" "" { target
*-*-* } 20 } */
- (id) method2
{
return self; /* { dg-warning "function declared .noreturn. has a .return.
statement" } */
-} /* { dg-warning ".noreturn. function does return" } */
+} /* { dg-warning ".noreturn. function does return" "" { target
*-*-* } 24 } */
+ (id) method3
{
abort ();
[Bug middle-end/47646] [4.6 Regression] Revision 169918 caused many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47646 --- Comment #4 from Eric Botcazou 2011-02-09 08:31:01 UTC --- > The following patch is missing for > gcc/testsuite/obj-c++.dg/attributes/method-noreturn-1.mm: Can't you simply move the dg directives ?
[Bug middle-end/47646] [4.6 Regression] Revision 169918 caused many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47646 --- Comment #5 from Andreas Krebbel 2011-02-09 08:35:32 UTC --- (In reply to comment #4) > > The following patch is missing for > > gcc/testsuite/obj-c++.dg/attributes/method-noreturn-1.mm: > > Can't you simply move the dg directives ? No. The problem is that two dg-warnings would be at the same line then. I think the patch is ok. I cannot approve it but its an obvious change. Thanks!
[Bug fortran/47642] real(kind=16) - libquadmath - segfault on amd64 FreeBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47642 --- Comment #9 from Jakub Jelinek 2011-02-09 08:44:54 UTC --- On sparc64 obviously libquadmath isn't used and thus it is expected it works there and has nothing to do with libquadmath - on sparc*/s390* long double is IEEE quad already, so it is libc job to do the right thing.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #6 from Michael Haubenwallner 2011-02-09 09:03:05 UTC --- (In reply to comment #5) > Created attachment 23120 [details] > Patch to simply not use bss section with .bs, but private-data-section instead > > I'm going to try this patch with gcc-4.2.4 now... This patch works quite well here.
[Bug lto/47641] gcc.dg/lto/20101009-1 c_lto_20101009-1_0.o-c_lto_20101009-1_0.o link ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47641 Uros Bizjak changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #6 from Uros Bizjak 2011-02-09 09:16:15 UTC --- *** Bug 47652 has been marked as a duplicate of this bug. ***
[Bug lto/47652] [4.6 Regression] FAIL: gcc.dg/lto/20101009-1 c_lto_20101009-1_0.o-c_lto_20101009-1_0.o link
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47652 Uros Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Uros Bizjak 2011-02-09 09:16:15 UTC --- Dup of 47641. *** This bug has been marked as a duplicate of bug 47641 ***
[Bug tree-optimization/47657] New: missed vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47657 Summary: missed vectorization Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch the following is not vectorized with gfortran (4.6 / 4.5) gfortran -O3 -ffast-math -ftree-vectorizer-verbose=6 -S -march=native ( -march=amdfam10 -mcx16 -msahf -mpopcnt -mabm ) SUBROUTINE smm_dnn_8_8_8_4_1_2_1(A,B,C) REAL(KIND=8) :: C(8,8), B(8,8), A(8,8) INTEGER ::i,j,l DO j= 1 , 8 , 2 DO l= 1 , 8 , 1 DO i= 1 , 8 , 1 C(i+0,j+0)=C(i+0,j+0)+A(i+0,l+0)*B(l+0,j+0) C(i+0,j+1)=C(i+0,j+1)+A(i+0,l+0)*B(l+0,j+1) ENDDO ENDDO ENDDO END SUBROUTINE while the cray ftn compiler does, yielding about twice the speed. reference asm: : 0: 53 push %rbx 1: 48 89 7c 24 f8 mov%rdi,-0x8(%rsp) 6: 48 89 74 24 f0 mov%rsi,-0x10(%rsp) b: 48 89 54 24 e8 mov%rdx,-0x18(%rsp) 10: 31 c0 xor%eax,%eax 12: 48 89 d1mov%rdx,%rcx 15: 49 89 c0mov%rax,%r8 18: 49 89 c1mov%rax,%r9 1b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 20: 66 0f 10 04 02 movupd (%rdx,%rax,1),%xmm0 25: 66 0f 10 4c 02 40 movupd 0x40(%rdx,%rax,1),%xmm1 2b: 66 0f 10 54 02 10 movupd 0x10(%rdx,%rax,1),%xmm2 31: 66 0f 10 5c 02 50 movupd 0x50(%rdx,%rax,1),%xmm3 37: 66 0f 10 64 02 20 movupd 0x20(%rdx,%rax,1),%xmm4 3d: 66 0f 10 6c 02 60 movupd 0x60(%rdx,%rax,1),%xmm5 43: 66 0f 10 74 02 30 movupd 0x30(%rdx,%rax,1),%xmm6 49: 66 0f 10 7c 02 70 movupd 0x70(%rdx,%rax,1),%xmm7 4f: 45 31 d2xor%r10d,%r10d 52: 4d 89 d3mov%r10,%r11 55: 66 66 2e 0f 1f 84 00nopw %cs:0x0(%rax,%rax,1) 5c: 00 00 00 00 60: 66 46 0f 10 44 1f 30movupd 0x30(%rdi,%r11,1),%xmm8 67: 4b 8d 1c 02 lea(%r10,%r8,1),%rbx 6b: f2 44 0f 12 4c de 40movddup 0x40(%rsi,%rbx,8),%xmm9 72: 66 45 0f 28 d1 movapd %xmm9,%xmm10 77: 66 45 0f 59 d0 mulpd %xmm8,%xmm10 7c: 66 41 0f 58 fa addpd %xmm10,%xmm7 81: f2 44 0f 12 14 de movddup (%rsi,%rbx,8),%xmm10 87: 66 45 0f 59 c2 mulpd %xmm10,%xmm8 8c: 66 41 0f 58 f0 addpd %xmm8,%xmm6 91: 66 46 0f 10 44 1f 20movupd 0x20(%rdi,%r11,1),%xmm8 98: 66 45 0f 28 d9 movapd %xmm9,%xmm11 9d: 66 45 0f 59 d8 mulpd %xmm8,%xmm11 a2: 66 41 0f 58 eb addpd %xmm11,%xmm5 a7: 66 45 0f 59 c2 mulpd %xmm10,%xmm8 ac: 66 41 0f 58 e0 addpd %xmm8,%xmm4 b1: 66 46 0f 10 44 1f 10movupd 0x10(%rdi,%r11,1),%xmm8 b8: 66 45 0f 28 d9 movapd %xmm9,%xmm11 bd: 66 45 0f 59 d8 mulpd %xmm8,%xmm11 c2: 66 41 0f 58 db addpd %xmm11,%xmm3 c7: 66 45 0f 59 c2 mulpd %xmm10,%xmm8 cc: 66 41 0f 58 d0 addpd %xmm8,%xmm2 d1: 66 46 0f 10 04 1f movupd (%rdi,%r11,1),%xmm8 d7: 66 45 0f 59 c8 mulpd %xmm8,%xmm9 dc: 66 41 0f 58 c9 addpd %xmm9,%xmm1 e1: 66 45 0f 59 d0 mulpd %xmm8,%xmm10 e6: 66 41 0f 58 c2 addpd %xmm10,%xmm0 eb: 49 83 c3 40 add$0x40,%r11 ef: 49 ff c2inc%r10 f2: 49 83 fa 08 cmp$0x8,%r10 f6: 0f 8c 64 ff ff ff jl 60 fc: f2 0f 11 7c 01 70 movsd %xmm7,0x70(%rcx,%rax,1) 102: 66 0f 17 7c 01 78 movhpd %xmm7,0x78(%rcx,%rax,1) 108: f2 0f 11 74 02 30 movsd %xmm6,0x30(%rdx,%rax,1) 10e: 66 0f 17 74 02 38 movhpd %xmm6,0x38(%rdx,%rax,1) 114: f2 0f 11 6c 02 60 movsd %xmm5,0x60(%rdx,%rax,1) 11a: 66 0f 17 6c 02 68 movhpd %xmm5,0x68(%rdx,%rax,1) 120: f2 0f 11 64 02 20 movsd %xmm4,0x20(%rdx,%rax,1) 126: 66 0f 17 64 02 28 movhpd %xmm4,0x28(%rdx,%rax,1) 12c: f2 0f 11 5c 02 50 movsd %xmm3,0x50(%rdx,%rax,1) 132: 66 0f 17 5c 02 58 movhpd %xmm3,0x58(%rdx,%rax,1) 138: f2 0f 11 54 02 10 movsd %xmm2,0x10(%rdx,%rax,1) 13e: 66 0f 17 54 02 18 movhpd %xmm2,0x18(%rdx,%rax,1) 144: f2 0f 11 4c 02 40 movsd %xmm1,0x40(%rdx,%rax,1) 14a: 66 0f 17 4c 02 48 movhpd %xmm1,0x48(%rdx,%rax,1) 150: f2 0f 11 04 02 movsd %xmm0,(%rdx,%rax,1) 155: 66 0f 17 44 02 08 movhpd %xmm0,0x8(%rdx,%rax,1) 15b: 49 83 c0 10 add$0x10,%r8 15f: 48 83 e8 80 sub$0xff80,%rax 163: 49 ff c1inc%r9 166: 49 83 f9 04 cmp$0x4,%r9 16a: 0f 8c b0 fe ff ff jl 20 170: 5b po
[Bug c++/47658] New: -Os generates bigger code than -O2/3 for many small inline functions (objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47658
Summary: -Os generates bigger code than -O2/3 for many small
inline functions (objects)
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kice...@gmail.com
I've noticed that, when I use a class which is a wrapper for a pointer to
volatile variable too often, then the -Os generates code bigger than -O2/-O3.
here's a big example:
class A
{
volatile int * const ptr;
public:
inline A(int * a):ptr(a)
{}
inline int read() const
{
return *ptr;
}
inline void write(int v) const
{
*ptr=v;
}
};
class B
{
const A a1,a2,a3;
public:
inline B(int *a):a1(a),a2(a-2),a3(a-1)
{}
inline int operator()() const
{
return a2.read();
}
inline const B &operator=(int v) const
{
a1.write(v);
return *this;
}
inline void foo(int v) const
{
a3.write(v);
}
};
template
class C
{
public:
C()
{
B foo(addr),bar(addr2);
foo=56;
foo.foo(67);
bar=58;
bar.foo(345);
};
void foo1()
{
B foo(addr),bar(addr2);
foo=bar();
foo.foo(12);
bar.foo(foo());
foo2(2);
}
void foo2(int v)
{
B foo(addr),bar(addr2);
bar=foo();
bar.foo(34*v);
foo.foo(bar());
}
void foo3()
{
B foo(addr),bar(addr2);
for (int i=0;i<128; i++)
{
foo.foo(i);
foo=bar();
bar.foo(i+1);
}
}
};
template
class D
{
public:
D()
{
B foo(addr),bar(addr2);
foo=56;
foo.foo(67);
bar=58;
bar.foo(345);
};
void foo1()
{
B foo(addr),bar(addr2);
foo=bar();
foo.foo(12);
bar.foo(foo());
foo2(2);
}
void foo2(int v)
{
B foo(addr),bar(addr2);
bar=foo();
bar.foo(34*v);
foo.foo(bar());
}
void foo3()
{
B foo(addr),bar(addr2);
for (int i=0;i<128; i++)
{
foo.foo(i);
foo=bar();
bar.foo(i+1);
}
}
};
template
class E
{
public:
E()
{
B foo(addr),bar(addr2);
foo=56;
foo.foo(67);
bar=58;
bar.foo(345);
};
void foo1()
{
B foo(addr),bar(addr2);
foo=bar();
foo.foo(12);
bar.foo(foo());
foo2(2);
}
void foo2(int v)
{
B foo(addr),bar(addr2);
bar=foo();
bar.foo(34*v);
foo.foo(bar());
}
void foo3()
{
B foo(addr),bar(addr2);
for (int i=0;i<128; i++)
{
foo.foo(i);
foo=bar();
bar.foo(i+1);
}
}
};
int a,b;
int a2,b2;
int a3,b3;
void f() __attribute__((used));
void f()
{
C<&a,&b> c;
D<&a2,&b2> d;
E<&a3,&b3> e;
c.foo3();
c.foo1();
d.foo3();
d.foo1();
e.foo3();
e.foo1();
}
int main()
{
C<&a,&b> c;
D<&a2,&b2> d;
E<&a3,&b3> e;
c.foo1();
c.foo3();
d.foo1();
d.foo3();
e.foo1();
e.foo3();
return 1;
}
class A is a wrapper, class B expands it. Then classes C and D are using class
B. While the program is small (just comment function void f()), all calls to
class' A and class' B functions are inlined and code is small (as all those
functions are simple movs). But then the code is big (like above) g++ expands
all functions to standalone ones (when -Os is used) and code is getting bigger.
-O2 keeps all functions to be inlined.
So the problem is that g++ thinks that many inlines of same functions are
bigger than calling non-inlined versions of them (which is wrong in this case).
[michal@Kicer michal]$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-mandriva-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-mandriva-linux-gnu
Configured with: ../gcc-4.5.2/configure --host=x86_64-mandriva-linux-gnu
--build=x86_64-mandriva-linux-gnu --program-prefix= --prefix=/usr
--exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
--libexecdir=/usr/libexec --localstatedir=/usr/var --sharedstatedir=/usr/com
--mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release
--enable-languages=c,c++,objc,obj-c++,fortran --with-system-zlib
--enable-threads=posix --enable-shared --enable-long-long --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --enable-gtk-cairo
--disable-libjava-multilib --enable-ssp --disable-libssp --disable-werror
--enable-lto --program-suffix=-4.5.2 CFLAGS= CXXFLAGS=
Thread model: posix
gcc version 4.5.2 (GCC)
[michal@Kicer michal]$
[Bug bootstrap/46456] cppbuiltin.o fails to build for arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46456 Ian Bolton changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #3 from Ian Bolton 2011-02-09 09:38:57 UTC --- *** Bug 46276 has been marked as a duplicate of this bug. ***
[Bug target/46276] cppbuiltin.c:154:7: error: 'or' of unmatched not-equal tests is always 1 [-Werror]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46276 Ian Bolton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ibolton at gcc dot gnu.org Resolution||DUPLICATE --- Comment #5 from Ian Bolton 2011-02-09 09:38:57 UTC --- This is a duplicate of a fixed bug (PR46456), so marking RESOLVED DUPLICATE. *** This bug has been marked as a duplicate of bug 46456 ***
[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #5 from Kai Tietz 2011-02-09 09:40:28
UTC ---
So it seems to be an issue of lto and file-caching. There is a dangling
file-handle, which can cause this issue.
Could you please test the following patch, if it solves the unlink issue?
Please make sure that lto-plugin is unmodified version.
Thanks in advance,
Kai
Index: lto.c
===
--- lto.c(revision 169962)
+++ lto.c(working copy)
@@ -593,7 +593,11 @@
fd_name = xstrdup (file_data->file_name);
fd = open (file_data->file_name, O_RDONLY|O_BINARY);
if (fd == -1)
-return NULL;
+{
+ free (fd_name);
+ fd_name = NULL;
+ return NULL;
+}
}
#if LTO_MMAP_IO
@@ -619,9 +623,17 @@
|| read (fd, result, len) != (ssize_t) len)
{
free (result);
- return NULL;
+ result = NULL;
}
-
+#ifdef __MINGW32__
+ /* Native windows doesn't supports delayed unlink on opened file. So
+ We close file here again. This produces higher I/O load, but at least
+ it prevents to have dangling file handles preventing unlink. */
+ free (fd_name);
+ fd_name = NULL;
+ close (fd);
+ fd = -1;
+#endif
return result;
#endif
}
[Bug fortran/47637] [OOP] Memory leak involving INTENT(OUT) CLASS argument w/ allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47637 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code --- Comment #3 from janus at gcc dot gnu.org 2011-02-09 09:56:31 UTC --- The patch in comment #2 regtests cleanly on x86_64-unknown-linux-gnu, without any failures.
[Bug libffi/46661] 32-bit cls_pointer.c, cls_pointer_stack.c FAIL on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46661 --- Comment #2 from Rainer Orth 2011-02-09 10:01:11 UTC --- Author: ro Date: Wed Feb 9 10:01:07 2011 New Revision: 169963 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169963 Log: PR libffi/46661 * testsuite/libffi.call/cls_pointer.c (main): Cast void * to uintptr_t first. * testsuite/libffi.call/cls_pointer_stack.c (main): Likewise. Modified: trunk/libffi/ChangeLog trunk/libffi/testsuite/libffi.call/cls_pointer.c trunk/libffi/testsuite/libffi.call/cls_pointer_stack.c
[Bug fortran/47659] New: -Wconversion[-extra] should emit warning for constant expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47659 Summary: -Wconversion[-extra] should emit warning for constant expressions Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net When the options -Wconversion or -Wconversion-extra are in effect, the compiler does not generate a warning if a constant real expression is converted to a different real kind There should be a warning in this case because the conversion can give surprising results, e.g.: real(8) d1, d2 d1 = .13 ! <== no warning d2 = .13d0 print *, d1, d2, d2-d1 end Output: 0.1299523162842 0.13000 4.76837158647214210E-009 In this case the option -Wconversion-extra should give a warning on "d1 = .13" because a constant was specified which does not represent the decimal value with the same precision as the target variable can hold. The user most likely wanted to specify "d1 = .13d0"
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.09 10:40:36 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #6 from Richard Guenther 2011-02-09 10:40:36 UTC --- See http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00956.html for a patch (queued for 4.7, several tree-dump check testcases have to be adjusted).
[Bug fortran/47660] New: Retain warning text of -Wconversion messages when -Wconversion-extra is in effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47660 Summary: Retain warning text of -Wconversion messages when -Wconversion-extra is in effect Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net A warning for a construct which is printed for -Wconversion should be printed with the same text when -Wconversion-extra is in effect. In other words, when -Wconversion-extra is in effect, conversions which are likely to change the expression's value should have a distinctly different warning text than conversions which don't. This makes it easier for the user to find the most relevant issues in the source code more quickly without running the compiler two times with -Wconversion and -Wconversion-extra. For example: real(4) r1 real(8) r2 integer(4) i r1 = r2 r1 = 0_8 i = 0._8 end $ gfortran -Wconversion testconv2.f90 testconv2.f90:4.5: r1 = r2 1 Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1) testconv2.f90:5.5: r1 = 0_8 1 Warning: Possible change of value in conversion from INTEGER(8) to REAL(4) at (1 ) testconv2.f90:6.4: i = 0._8 1 Warning: Possible change of value in conversion from REAL(8) to INTEGER(4) at (1 ) $ gfortran -Wconversion-extra testconv2.f90 testconv2.f90:4.5: r1 = r2 1 Warning: Conversion from REAL(8) to REAL(4) at (1) testconv2.f90:5.5: r1 = 0_8 1 Warning: Conversion from INTEGER(8) to REAL(4) at (1) testconv2.f90:6.4: i = 0._8 1 Warning: Possible change of value in conversion from REAL(8) to INTEGER(4) at (1) The first two warnings should have the same text in both runs.
[Bug c++/47658] -Os generates bigger code than -O2/3 for many small inline functions (objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47658 --- Comment #1 from Richard Guenther 2011-02-09 10:58:01 UTC --- It works for me, the abstraction is completely eliminated by early inlining. At -Os we do not inline E::foo2 into E::foo1 but that isn't abstraction and it isn't easily visible that this is profitable. That results in the -Os code being around 10% larger than -O2 code. You can check the dump generated by -fdump-tree-einline-details for reasoning and size estimates used.
[Bug tree-optimization/47657] missed vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47657 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.09 11:06:56 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-02-09 11:06:56 UTC --- It is vectorized with -fno-vect-cost-model. The cray compiler probably exchanged loops and/or did more agressive unrolling than us here (the code with -fno-vect-cost-model shows the cost model is right ;))
[Bug tree-optimization/47657] missed vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47657 --- Comment #2 from Joost VandeVondele 2011-02-09 11:25:42 UTC --- Created attachment 23283 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23283 testcase including timing routine, last number is flop rate. the cray compiler is supposed to *not* interchange loops, as I'm using: ftn -O3,ipa0,nointerchange,vector3 testcase.f90 to compile. This gives about 5.6Gflops. Unrolling still seems to happen (there are 16 mults in the inner loop), and ftn -O3,ipa0,nointerchange,vector3,unroll0 testcase.f90 yields poor performance (2.3Gflops). Gfortran 4.5 yields 3.424Gflops : gfortran -O3 -ffast-math -funroll-loops -march=native testcase.f90
[Bug middle-end/45505] [4.6 Regression] gfortran.dg/pr25923.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505 --- Comment #20 from Martin Jambor 2011-02-09 11:48:11 UTC --- Author: jamborm Date: Wed Feb 9 11:48:09 2011 New Revision: 169964 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169964 Log: 2011-02-09 Martin Jambor PR middle-end/45505 * tree-sra.c (struct access): New flags grp_scalar_read and grp_scalar_write. Changed description of assignment read and write flags. (dump_access): Dump new flags, reorder all of them. (sort_and_splice_var_accesses): Set the new flag accordingly, use them to detect multiple scalar reads. (analyze_access_subtree): Use the new scalar read write flags instead of the old flags. Adjusted comments. * testsuite/gfortran.dg/pr25923.f90: Remove xfails. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr25923.f90 trunk/gcc/tree-sra.c
[Bug middle-end/45505] [4.6 Regression] gfortran.dg/pr25923.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45505 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #21 from Martin Jambor 2011-02-09 11:48:47 UTC --- Fixed.
[Bug middle-end/47661] New: predict is confused by FP comparisons when math can trap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47661
Summary: predict is confused by FP comparisons when math can
trap
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: hubi...@gcc.gnu.org, espind...@google.com
Without -fno-trapping-math we split away FP comparisons from the actual
conditional jump like
D.2683 = x < 0.0;
if (D.2683 != 0) goto ; else goto ;
this results in different prediction results for BB frequencies compared to
if (x < 0.0) goto ; else goto ;
which is odd (for C-ray this causes us to belive ray_sphere is more
costly time-wise with -ffast-math).
It is dubious that we use tree_could_trap_p in is_gimple_condexpr
instead of tree_could_throw_p (which would conditionalize the above
on -fnon-call-exceptions -fexceptions at least). 4.3 did neither,
tuples introduced that check with
2008-05-02 Rafael Espíndola
* tree-gimple.c (is_gimple_condexpr): Do not allow
trapping comparisons.
* tree-eh.c (tree_could_trap_p): Fix handling of floating
point comparisons.
Still the prediction will be off with exceptions turned on.
I can't see any reason why
Index: gimple.c
===
--- gimple.c(revision 169963)
+++ gimple.c(working copy)
@@ -2581,7 +2581,7 @@ bool
is_gimple_condexpr (tree t)
{
return (is_gimple_val (t) || (COMPARISON_CLASS_P (t)
- && !tree_could_trap_p (t)
+ && !tree_could_throw_p (t)
&& is_gimple_val (TREE_OPERAND (t, 0))
&& is_gimple_val (TREE_OPERAND (t, 1;
}
would be incorrect. Rafael, do you remember anything about the reasoning
to use tree_could_trap_p instead of tree_could_throw_p?
[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47324
--- Comment #23 from Jack Howarth 2011-02-09
12:31:27 UTC ---
Any comments on this bit of Mike's patch...
+int
+darwin_dbx_register_number(n)
+{
+#if 1
+ /* Without -O3, eh-alloc-1.c -m32 fails. */
+ /* Works! */
+ if (write_symbols == DWARF2_DEBUG && !dwarf2out_do_frame())
+return svr4_dbx_register_map[n];
+#else
+ /* Works! */
+ if (!(write_symbols == DWARF2_DEBUG
+|| write_symbols == NO_DEBUG))
+return svr4_dbx_register_map[n];
+#endif
+ return dbx_register_map[n];
+}
[Bug bootstrap/45381] [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: error: AltiVec argument passed to unprototyped function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45381
--- Comment #13 from Iain Sandoe 2011-02-09 12:35:57
UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > I think altivec should disabled with "gcc version 4.0.1 (Apple Inc. build
> > 5493)". Otherwise this pr could be closed as wontfix.
>
> I'd prefer it if you provided some amount of detail about *what*
> fails with the patch attached to this PR, rather than just reporting
> the bare fact of not working.
Sorry ... I should have read the audit trail better.
The fault is a very subtle header-ordering 'gotcha'...
[At least on Darwin] One cannot include external headers after system.h because
of the fact that system.h re-defines bool.
... the reason that comment #12 works (which is essentially the same thing as
your attachment) is that is included before system.h.
I guess on ppc64-linux there is no difference in the size of bool - and I don't
wish to re-open the debate about Darwin's way of doing it ('tis out of our
control in any event).
I still don't know if it's worth doing any more than below, for 4.6:
Index: libcpp/lex.c
===
--- libcpp/lex.c(revision 169914)
+++ libcpp/lex.c(working copy)
@@ -512,7 +513,7 @@ init_vectorized_lexer (void)
search_line_fast = impl;
}
-#elif defined(__GNUC__) && defined(__ALTIVEC__)
+#elif defined(__GNUC__) && (GCC_VERSION >= 4005) && defined(__ALTIVEC__)
/* A vection of the fast scanner using AltiVec vectorized byte compares. */
/* ??? Unfortunately, attribute(target("altivec")) is not yet supported,
[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241
--- Comment #6 from coolypf 2011-02-09 12:54:46 UTC ---
(In reply to comment #5)
> So it seems to be an issue of lto and file-caching. There is a dangling
> file-handle, which can cause this issue.
>
> Could you please test the following patch, if it solves the unlink issue?
> Please make sure that lto-plugin is unmodified version.
>
> Thanks in advance,
> Kai
>
> Index: lto.c
> ===
> --- lto.c(revision 169962)
> +++ lto.c(working copy)
> @@ -593,7 +593,11 @@
>fd_name = xstrdup (file_data->file_name);
>fd = open (file_data->file_name, O_RDONLY|O_BINARY);
>if (fd == -1)
> -return NULL;
> +{
> + free (fd_name);
> + fd_name = NULL;
> + return NULL;
> +}
> }
>
> #if LTO_MMAP_IO
> @@ -619,9 +623,17 @@
>|| read (fd, result, len) != (ssize_t) len)
> {
>free (result);
> - return NULL;
> + result = NULL;
> }
> -
> +#ifdef __MINGW32__
> + /* Native windows doesn't supports delayed unlink on opened file. So
> + We close file here again. This produces higher I/O load, but at least
> + it prevents to have dangling file handles preventing unlink. */
> + free (fd_name);
> + fd_name = NULL;
> + close (fd);
> + fd = -1;
> +#endif
>return result;
> #endif
> }
The patch does not take effect.
The errno before "could not unlink output file" message
in lto-plugin.c is still 13.
[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241 --- Comment #7 from Kai Tietz 2011-02-09 13:10:24 UTC --- So there seems to be another dangling file-handle on it ... you are sure new plugin was used by ld? Another thing of interest, is the file it tries to remove still existing or already removed, and if existing what access-rights it has?
[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241 --- Comment #8 from coolypf 2011-02-09 13:50:15 UTC --- (In reply to comment #7) > So there seems to be another dangling file-handle on it ... you are sure new > plugin was used by ld? Another thing of interest, is the file it tries to > remove still existing or already removed, and if existing what access-rights > it > has? The filename is something like 'ccGQSy8u.ltrans0.ltrans.o'. It still exists in TEMP dir. The file is created by: lto1.exe -quiet -dumpbase ccGQSy8u.ltrans0.o -mtune=generic -march=pentiumpro -auxbase-strip ccGQSy8u.ltrans0.ltrans.o -version -fltrans @cckZmRUy -o ccuOzyFX.s as -v -o ccGQSy8u.ltrans0.ltrans.o ccuOzyFX.s
[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241 --- Comment #9 from coolypf 2011-02-09 13:53:17 UTC --- (In reply to comment #8) > (In reply to comment #7) > > So there seems to be another dangling file-handle on it ... you are sure new > > plugin was used by ld? Another thing of interest, is the file it tries to > > remove still existing or already removed, and if existing what > > access-rights it > > has? > > The filename is something like 'ccGQSy8u.ltrans0.ltrans.o'. > It still exists in TEMP dir. > > The file is created by: > > lto1.exe -quiet -dumpbase ccGQSy8u.ltrans0.o -mtune=generic -march=pentiumpro > -auxbase-strip ccGQSy8u.ltrans0.ltrans.o -version -fltrans @cckZmRUy -o > ccuOzyFX.s > > as -v -o ccGQSy8u.ltrans0.ltrans.o ccuOzyFX.s So, I don't think the bug is related to lto1.exe, because it doesn't produce .o files.
[Bug fortran/46321] [OOP] Polymorphic deallocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46321 --- Comment #1 from Tobias Burnus 2011-02-09 13:59:09 UTC --- Note: There are four cases where a polymorphic deallocate is needed - though some might end up in the same code path: - explicit DEALLOCATE (cf. comment 0) - implicit deallocate at the end of the scope - implicit deallocate via INTENT(OUT) (cf. PR 47637) - implicit deallocate when doing polymorphic reallocate on assignment (PR 43366)
[Bug fortran/47637] [OOP] Memory leak involving INTENT(OUT) CLASS argument w/ allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47637 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus 2011-02-09 14:02:58 UTC --- See bug 46321 regarding the required full solution for polymophic allocatables. Special case solution, cf. approved patch at http://gcc.gnu.org/ml/fortran/2011-02/msg00067.html
[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47324 --- Comment #24 from Ian Lance Taylor 2011-02-09 14:10:25 UTC --- The first branch of darwin_dbx_register_number looks like it will use the wrong register numbers in debug info. The second branch looks like it will do the wrong thing for -gstabs. I don't think either change is necessary at all given your other patch.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #40 from Martin Jambor 2011-02-09 14:12:57 UTC --- (In reply to comment #39) > That could well be https://bugzilla.mozilla.org/show_bug.cgi?id=629638 > Can you check with a changeset newer than > http://hg.mozilla.org/mozilla-central/rev/2772a0cf36d1 ? I have just checked-out mozilla-central entirely by doing hg clone http://hg.mozilla.org/mozilla-central/ and the elfhack test still segfaults for me (with lto).
[Bug libstdc++/47662] New: [4.6 Regression] -fno-operator-names no longer works with STL headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47662 Summary: [4.6 Regression] -fno-operator-names no longer works with STL headers Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org echo '#include ' | g++ -fno-operator-names -xc++ - -o /tmp/x.s no longer works, as bits/c++config.h now uses #if defined(_GLIBCXX_DEBUG) or defined(_GLIBCXX_PROFILE) any reason why it can't use || instead of or?
[Bug libstdc++/47662] [4.6 Regression] -fno-operator-names no longer works with STL headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47662 Jakub Jelinek changed: What|Removed |Added CC||bkoz at gcc dot gnu.org, ||paolo at gcc dot gnu.org Target Milestone|--- |4.6.0
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #7 from joe at mcknight dot de 2011-02-09 14:22:48 UTC --- (In reply to comment #6) > See http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00956.html for a patch > (queued for 4.7, several tree-dump check testcases have to be adjusted). Cool, I can confirm that this fixes the example that I brought up in the beginning! :-) Now the remaining issue is wrong (non-C) output for function declarations with function pointers. Thanks!
[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47324 --- Comment #25 from Jack Howarth 2011-02-09 14:25:23 UTC --- Ian, does that mean you believe we should just need... int darwin_dbx_register_number(n) return dbx_register_map[n];
[Bug libstdc++/47662] [4.6 Regression] -fno-operator-names no longer works with STL headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47662 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.09 14:27:29 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2011-02-09 14:27:29 UTC --- I'll fix it tonight if noone beats me to it.
[Bug c++/47172] [4.6 Regression] [C++0x] cannot call member function without object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47172 --- Comment #3 from Dodji Seketeli 2011-02-09 14:27:44 UTC --- Candidate patch posted to http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00603.html
[Bug middle-end/47646] [4.6 Regression] Revision 169918 caused many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47646 --- Comment #6 from Eric Botcazou 2011-02-09 14:28:03 UTC --- > No. The problem is that two dg-warnings would be at the same line then. Then merge them, it's essentially the same warning issued twice.
[Bug libstdc++/47662] [4.6 Regression] -fno-operator-names no longer works with STL headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47662 --- Comment #2 from Jonathan Wakely 2011-02-09 14:32:50 UTC --- I've also just noticed the manual for -fno-operator-names could do with some improvement: those alternative tokens aren't technically keywords, they're certainly not "synonyms as keywords" because that doesn't even make sense :)
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #41 from Mike Hommey 2011-02-09 14:34:08 UTC --- (In reply to comment #40) > I have just checked-out mozilla-central entirely by doing > > hg clone http://hg.mozilla.org/mozilla-central/ > > and the elfhack test still segfaults for me (with lto). Segfaults or aborts ?
[Bug libffi/46661] 32-bit cls_pointer.c, cls_pointer_stack.c FAIL on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46661 --- Comment #3 from Rainer Orth 2011-02-09 14:40:18 UTC --- Author: ro Date: Wed Feb 9 14:40:15 2011 New Revision: 169972 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169972 Log: PR libffi/46661 * testsuite/libffi.call/cls_pointer.c (main): Cast void * to uintptr_t first. * testsuite/libffi.call/cls_pointer_stack.c (main): Likewise. Modified: branches/gcc-4_5-branch/libffi/ChangeLog branches/gcc-4_5-branch/libffi/testsuite/libffi.call/cls_pointer.c branches/gcc-4_5-branch/libffi/testsuite/libffi.call/cls_pointer_stack.c
[Bug libffi/46661] 32-bit cls_pointer.c, cls_pointer_stack.c FAIL on IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46661 Rainer Orth changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Rainer Orth 2011-02-09 14:43:02 UTC --- Fixed for 4.5.3, 4.6.0.
[Bug libstdc++/47662] [4.6 Regression] -fno-operator-names no longer works with STL headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47662 --- Comment #3 from Paolo Carlini 2011-02-09 15:10:39 UTC --- Thanks Jon, for sure that 'or' hasn't been added on purpose.
[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47324 --- Comment #26 from Ian Lance Taylor 2011-02-09 15:13:22 UTC --- I think the patch to dwarf2out.c is all you need and I don't understand why you are thinking about any patch to config/i386/darwin.h and config/i386/darwin.c at all.
[Bug fortran/47583] [4.6 Regression] Inquire affected by previous read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47583 --- Comment #13 from Jerry DeLisle 2011-02-09 15:47:26 UTC --- There is some debate whether or not I did this properly. I was rushing last night, cobbled the PR number in the email subject, omitted the patch to the mailing list, left the pr number off the Changlog entry ... I hope I did not break the build and I apologize for any inconveniance I caused. I posted this here because I do not have regular email at my work location which is quite remote at the moment. Cheers everyone and I will do better next time. ;) (The service is free, as in free beer)
[Bug middle-end/47663] New: Very simple wrapper not inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47663
Summary: Very simple wrapper not inlined
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: rgue...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: hubi...@gcc.gnu.org
int foo0();
inline void bar0() { foo0(); }
void foobar() { bar0(); }
is not inlined at -O[12] because
;; Function foobar (foobar)
Analyzing function body size: foobar
freq: 1000 size: 1 time: 10 bar0 ();
freq: 1000 size: 1 time: 2 return;
will eliminated by inlining
Overall function body time: 12-2 size: 4-3
With function call overhead time: 12-12 size: 4-4
;; Function bar0 (bar0)
Analyzing function body size: bar0
freq: 1000 size: 2 time: 11 foo0 ();
freq: 1000 size: 1 time: 2 return;
will eliminated by inlining
Overall function body time: 13-2 size: 5-3
With function call overhead time: 13-12 size: 5-4
and thus
;; Function foobar (foobar)
Considering inline candidate bar0.
Not inlining: code size would grow by 1.
for some reason an unused return value in a call has a cost.
I have a patch.
[Bug middle-end/47664] New: early inliner now needs iteration for multiple calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47664
Summary: early inliner now needs iteration for multiple calls
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
void foo0();
inline void bar0() { foo0(); }
void foobar() { bar0(); bar0(); bar0(); }
;; Function foobar (foobar)
Considering inline candidate bar0.
Inlining bar0 into foobar.
Processing frequency bar0
Called by bar0 that is normal or hot
Inlining bar0 to foobar with frequency 1000
Considering inline candidate bar0.
Inlining bar0 into foobar.
Processing frequency bar0
Called by bar0 that is normal or hot
Inlining bar0 to foobar with frequency 1000
Considering inline candidate bar0.
Inlining bar0 into foobar.
Processing frequency bar0
Called by bar0 that is normal or hot
Inlining bar0 to foobar with frequency 1000
Iterations: 3
I have a patch.
[Bug fortran/47637] [OOP] Memory leak involving INTENT(OUT) CLASS argument w/ allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47637 --- Comment #5 from janus at gcc dot gnu.org 2011-02-09 15:58:11 UTC --- Author: janus Date: Wed Feb 9 15:58:05 2011 New Revision: 169978 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169978 Log: 2011-02-09 Janus Weil PR fortran/47637 * trans-decl.c (init_intent_out_dt): Handle CLASS arguments. 2011-02-09 Janus Weil PR fortran/47637 * gfortran.dg/auto_dealloc_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/auto_dealloc_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/47637] [OOP] Memory leak involving INTENT(OUT) CLASS argument w/ allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47637 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from janus at gcc dot gnu.org 2011-02-09 16:01:04 UTC --- Fixed with r169978. Thanks for the report, Rich! Note that further memory leaks are to expected for cases where the dynamic type is different from the declared type (and has additional allocatable components), cf. PR 46321.
[Bug testsuite/47622] [4.6 Regression] FAIL: gcc.dg/pr42631.c scan-rtl-dump-not web "Web oldreg"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47622 --- Comment #5 from Jie Zhang 2011-02-09 16:04:53 UTC --- I think my patch which causes this bug might be wrong after checking this test case in details. I may work out a new patch following Jeff's suggestion.
[Bug middle-end/47663] Very simple wrapper not inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47663
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.02.09 16:11:54
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther 2011-02-09
16:11:54 UTC ---
It's actually not that simple as we have to match the caller / callee side
of costs to not run into negative limits. We could disregard returns in
registers completely or account for the cost (benefit) by not accounting
the return statement at all. It would at least be nice to have a way
to positively bias inlining of
struct X { ...large... } foo();
at a call-site that does not use the return value. Currently call-sites
that do use the return value get a benefit as well (independent of, for
example, if the return slot is passed by reference). Not handling the
return type at all would at least remove that false benefit accounting.
[Bug fortran/47659] -Wconversion[-extra] should emit warning for constant expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47659 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 CC||kargl at gcc dot gnu.org Severity|normal |enhancement
[Bug target/47665] New: [4.6 Regression] ICE in trunc_int_for_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47665
Summary: [4.6 Regression] ICE in trunc_int_for_mode
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
Target: i686-linux
#include
__m128d
foo (double *x, __m128i y)
{
return _mm_load_pd (x + _mm_cvtsi128_si32 (_mm_srli_si128 (_mm_slli_epi32 (y,
2), 0)));
}
ICEs on i686-linux with -O2 -m32 -msse2, starting in between r166288 and
r166429.
[Bug target/47665] [4.6 Regression] ICE in trunc_int_for_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47665 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug fortran/47660] Retain warning text of -Wconversion messages when -Wconversion-extra is in effect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47660 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 CC||kargl at gcc dot gnu.org
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650
--- Comment #8 from joe at mcknight dot de 2011-02-09 16:23:44 UTC ---
(In reply to comment #6)
> See http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00956.html for a patch
> (queued for 4.7, several tree-dump check testcases have to be adjusted).
Richard, I've found another example for incorrect output of
print_generic_decl().
Here:
typedef struct {
double dvar;
int ivar;
} *tpdefp;
int myfunc(tpdefp var);
The output would not treat the variable as being of the new type but it would
repeat the declaration of the struct in print_generic_decl() and output
(including newlines):
extern int myfunc (struct
{
double dvar;
int ivar;
} *);
That could be related to the function pointer issue where print_generic_decl()
also rather repeats the declaration instead of printing the new type.
Thanks.
[Bug target/47665] [4.6 Regression] ICE in trunc_int_for_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47665 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.09 16:27:40 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-02-09 16:27:40 UTC --- Confirmed.
[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47324
--- Comment #27 from Jack Howarth 2011-02-09
16:28:55 UTC ---
Ian,
Just using...
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c(revision 169978)
+++ gcc/dwarf2out.c(working copy)
@@ -474,8 +474,8 @@ static bool clobbers_queued_reg_save (co
static void dwarf2out_frame_debug_expr (rtx, const char *);
/* Support for complex CFA locations. */
-static void output_cfa_loc (dw_cfi_ref);
-static void output_cfa_loc_raw (dw_cfi_ref);
+static void output_cfa_loc (dw_cfi_ref, bool);
+static void output_cfa_loc_raw (dw_cfi_ref, bool);
static void get_cfa_from_loc_descr (dw_cfa_location *,
struct dw_loc_descr_struct *);
static struct dw_loc_descr_struct *build_cfa_loc
@@ -3317,7 +3317,7 @@ output_cfi (dw_cfi_ref cfi, dw_fde_ref f
case DW_CFA_def_cfa_expression:
case DW_CFA_expression:
- output_cfa_loc (cfi);
+ output_cfa_loc (cfi, for_eh);
break;
case DW_CFA_GNU_negative_offset_extended:
@@ -3422,7 +3422,7 @@ output_cfi_directive (dw_cfi_ref cfi)
case DW_CFA_def_cfa_expression:
case DW_CFA_expression:
fprintf (asm_out_file, "\t.cfi_escape %#x,", cfi->dw_cfi_opc);
- output_cfa_loc_raw (cfi);
+ output_cfa_loc_raw (cfi, 1);
fputc ('\n', asm_out_file);
break;
@@ -5451,14 +5451,15 @@ output_loc_sequence_raw (dw_loc_descr_re
description based on a cfi entry with a complex address. */
static void
-output_cfa_loc (dw_cfi_ref cfi)
+output_cfa_loc (dw_cfi_ref cfi, bool for_eh)
{
dw_loc_descr_ref loc;
unsigned long size;
if (cfi->dw_cfi_opc == DW_CFA_expression)
{
- dw2_asm_output_data (1, cfi->dw_cfi_oprnd1.dw_cfi_reg_num, NULL);
+ unsigned long r = DWARF2_FRAME_REG_OUT
(cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
+ dw2_asm_output_data (1, r, NULL);
loc = cfi->dw_cfi_oprnd2.dw_cfi_loc;
}
else
@@ -5475,14 +5476,15 @@ output_cfa_loc (dw_cfi_ref cfi)
/* Similar, but used for .cfi_escape. */
static void
-output_cfa_loc_raw (dw_cfi_ref cfi)
+output_cfa_loc_raw (dw_cfi_ref cfi, bool for_eh)
{
dw_loc_descr_ref loc;
unsigned long size;
if (cfi->dw_cfi_opc == DW_CFA_expression)
{
- fprintf (asm_out_file, "%#x,", cfi->dw_cfi_oprnd1.dw_cfi_reg_num);
+ unsigned long r = DWARF2_FRAME_REG_OUT
(cfi->dw_cfi_oprnd1.dw_cfi_reg_num, for_eh);
+ fprintf (asm_out_file, "%#lx,", r);
loc = cfi->dw_cfi_oprnd2.dw_cfi_loc;
}
else
still gives you the failures at -O3 -g for -m32.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650
--- Comment #9 from rguenther at suse dot de
2011-02-09 16:33:30 UTC ---
On Wed, 9 Feb 2011, joe at mcknight dot de wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650
>
> --- Comment #8 from joe at mcknight dot de 2011-02-09 16:23:44 UTC ---
> (In reply to comment #6)
> > See http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00956.html for a patch
> > (queued for 4.7, several tree-dump check testcases have to be adjusted).
>
> Richard, I've found another example for incorrect output of
> print_generic_decl().
>
> Here:
>
> typedef struct {
> double dvar;
> int ivar;
> } *tpdefp;
>
> int myfunc(tpdefp var);
>
> The output would not treat the variable as being of the new type but it would
> repeat the declaration of the struct in print_generic_decl() and output
> (including newlines):
>
> extern int myfunc (struct
> {
> double dvar;
> int ivar;
> } *);
>
> That could be related to the function pointer issue where print_generic_decl()
> also rather repeats the declaration instead of printing the new type.
You should use a debugger to see why that happens, it should end up
printing TYPE_NAME which should be a TYPE_DECL with a DECL_NAME
which should be an IDENTIFIER_NODE. You can also try TDF_SLIM.
Richard.
[Bug ada/47666] New: [4.6 Regression] ICE in dfs_walk_once
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47666
Summary: [4.6 Regression] ICE in dfs_walk_once
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
template
struct A
{
int a;
};
template
struct B : public A
{
};
class D : public B
{
virtual D & operator= (const D &);
};
class E : virtual public D
{
};
class F : public E
{
virtual void foo ();
};
ICEs in dfs_walk_once, starting in between r161566 and r161597.
[Bug c++/47666] [4.6 Regression] ICE in dfs_walk_once
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47666 Jakub Jelinek changed: What|Removed |Added Component|ada |c++ Target Milestone|--- |4.6.0
[Bug c++/47666] [4.6 Regression] ICE in dfs_walk_once
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47666 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.09 16:49:45 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-02-09 16:49:45 UTC --- Confirmed.
[Bug target/47324] r157762 caused g++.dg/torture/stackalign failures with -O3 -g at -m32 on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47324 --- Comment #28 from Ian Lance Taylor 2011-02-09 16:53:22 UTC --- Then let's find out why that is. The patch in comment #23 looks clearly incorrect to me.
[Bug fortran/47667] New: I/O for reals: READ waits for input after "i" and "n"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47667 Summary: I/O for reals: READ waits for input after "i" and "n" Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: jvdeli...@gcc.gnu.org Based on https://www.jiscmail.ac.uk/cgi-bin/webadmin?A1=ind1102&L=COMP-FORTRAN-90#2 If one uses: READ (*,*) real_variable and enters "i" or "n", gfortran does not immediately return with an error but waits for further input. As it does not accept "N""aN" but only "NaN" and "Inf"/"Infinity" as input, this behaviour does not not make sense. For other characters, e.g. "e" or "d" it immediately returns with an error. Expected: As NAG, ifort, pathf95 do (for the linked test case): -9.990E+02 Input new value: i ioerr = 140 a = -9.990E+02 Result with gfortran (note extra input line): -999.0 Input new value: i ioerr = 5010 a = -999.0 Input new value: i nf ioerr = 5010 a = -999.0
[Bug middle-end/47383] ivopts miscompiles Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47383 --- Comment #11 from hjl at gcc dot gnu.org 2011-02-09 17:20:07 UTC --- Author: hjl Date: Wed Feb 9 17:20:00 2011 New Revision: 169979 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169979 Log: Disable ivopts for non-constant base with negative step and Pmode !== ptr_mode. gcc/ 2011-02-09 H.J. Lu PR middle-end/47383 * tree-ssa-loop-ivopts.c (find_bivs): Disabled for non-constant base with negative step and Pmode !== ptr_mode. (find_givs_in_stmt): Return for non-constant base with negative step and Pmode !== ptr_mode. (generic_type_for): Change arguments to base and step. Check non-constant base with negative step and Pmode !== ptr_mode. gcc/testsuite/ 2011-02-08 H.J. Lu PR middle-end/47383 * gcc.dg/torture/pr47383.c: New. Added: branches/x32/gcc/testsuite/gcc.dg/torture/pr47383.c Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/testsuite/ChangeLog.x32 branches/x32/gcc/tree-ssa-loop-ivopts.c
[Bug target/47665] [4.6 Regression] ICE in trunc_int_for_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47665 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #2 from Jakub Jelinek 2011-02-09 17:33:42 UTC --- Created attachment 23284 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23284 gcc46-pr47665.patch Untested patch.
[Bug c/47530] [trans-mem] tail call optimization problem with _ITM_commitTransaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47530 Richard Henderson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.02.09 17:36:18 AssignedTo|unassigned at gcc dot |rth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Henderson 2011-02-09 17:36:18 UTC --- Mine. We aren't representing these functions as setjmp because we have more detailed information about the control flow, and it's (eventually) explicitly represented. For instance, if a function has two transactions we know that the commit for the second transaction cannot branch to the restart of the first transaction. The problem here is that these extra edges are not inserted until after the tail-call discovery pass is run. Thankfully, no actual transform is actually performed at that spot. All we have to do later is clear the bit that the tail-call discovery pass set.
[Bug fortran/47667] I/O for reals: READ waits for input after "i" and "n"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47667 --- Comment #1 from Tobias Burnus 2011-02-09 18:03:08 UTC --- Other input which is handled specially is: Input new value: .e 3 ioerr = 5010 a = -999.0 Interestingly the following works: Input new value: .e4 ioerr =0 a =0.000 Input new value: . ioerr =0 a =0.000 while ifort and NAG show an error for that input. (g95 has the same result as gfortran.)
[Bug middle-end/47646] [4.6 Regression] Revision 169918 caused many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47646 --- Comment #7 from Dominique d'Humieres 2011-02-09 18:06:22 UTC --- > > No. The problem is that two dg-warnings would be at the same line then. > > Then merge them, it's essentially the same warning issued twice. 1) I have noticed the failures for the obj-c++ testsuite: FAIL: obj-c++.dg/attributes/method-noreturn-1.mm -fgnu-runtime (test for warnings, line 21) FAIL: obj-c++.dg/attributes/method-noreturn-1.mm -fgnu-runtime (test for warnings, line 25) FAIL: obj-c++.dg/attributes/method-noreturn-1.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/attributes/method-noreturn-1.mm -fnext-runtime (test for warnings, line 21) FAIL: obj-c++.dg/attributes/method-noreturn-1.mm -fnext-runtime (test for warnings, line 25) FAIL: obj-c++.dg/attributes/method-noreturn-1.mm -fnext-runtime (test for excess errors) 2) I have applyied the patch of revision 169927 for its sibling test for the objc testsuite: objc.dg/attributes/method-noreturn-1.m 3) I have tested it. 4) I have posted the patch to this pr before leaving my office for the day. 5) I have been busy with real life up to now;-) So any comment for obj-c++.dg/attributes/method-noreturn-1.mm applies as well to objc.dg/attributes/method-noreturn-1.m. Last point I don't have any commit right.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #10 from joe at mcknight dot de 2011-02-09 18:08:32 UTC --- Created attachment 23285 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23285 A small test plugin that calls print_generic_decl()
[Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463 --- Comment #11 from janus at gcc dot gnu.org 2011-02-09 18:08:45 UTC --- The strange behavior of the test case in comment #9 can be cured by just removing one peculiar line of code: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c(revision 169977) +++ gcc/fortran/resolve.c(working copy) @@ -5894,7 +5894,6 @@ resolve_typebound_subroutine (gfc_code *code) name = name ? name : code->expr1->value.function.esym->name; code->expr1->symtree = expr->symtree; code->expr1->ref = gfc_copy_ref (expr->ref); - expr->symtree->n.sym->ts.u.derived = declared; gfc_add_vptr_component (code->expr1); gfc_add_component_ref (code->expr1, name); code->expr1->value.function.esym = NULL; This line seems completely bogus to me. I have no idea what it's supposed to do. In any case it came from the following commit: http://gcc.gnu.org/viewcvs/trunk/gcc/fortran/resolve.c?r1=162313&r2=162312&pathrev=162313
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #11 from joe at mcknight dot de 2011-02-09 18:11:10 UTC --- Created attachment 23286 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23286 A C file that provokes wrong output of print_generic_decl()
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #12 from joe at mcknight dot de 2011-02-09 18:14:36 UTC --- > > That could be related to the function pointer issue where > > print_generic_decl() > > also rather repeats the declaration instead of printing the new type. > > You should use a debugger to see why that happens, it should end up > printing TYPE_NAME which should be a TYPE_DECL with a DECL_NAME > which should be an IDENTIFIER_NODE. You can also try TDF_SLIM. Unfortunately I'm not too experienced with debugging gcc... I tried TDF_SLIM but this makes things rather worse than better. Instead I have added a small testcase, a basic plugin that outputs a function declaration and a small .c file containing functions that are incorrectly output by the plugin. I hope this is of help for someone more knowledgeable in debugging gcc than me. If I can provide any further help, please let me know. Thanks.
[Bug rtl-optimization/47614] [4.6 Regression] cpu2000 benchmark 301.apsi fails with revision 169782
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614 --- Comment #10 from Jakub Jelinek 2011-02-09 18:30:29 UTC --- Created attachment 23287 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23287 gcc46-pr47614.patch Actually, I can reproduce it, I've just been looking for pre_modify instead of pre_inc that is actually removed. So, either we use check_for_inc_dec there...
[Bug rtl-optimization/47614] [4.6 Regression] cpu2000 benchmark 301.apsi fails with revision 169782
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614 --- Comment #11 from Jakub Jelinek 2011-02-09 18:31:51 UTC --- Created attachment 23288 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23288 gcc46-pr47614-2.patch Or simply reject side effects, similarly how we reject them elsewhere in postreload.
[Bug rtl-optimization/47614] [4.6 Regression] cpu2000 benchmark 301.apsi fails with revision 169782
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614 --- Comment #12 from Eric Botcazou 2011-02-09 18:42:01 UTC --- > Or simply reject side effects, similarly how we reject them elsewhere in > postreload. Yes, I think that's good enough for now.
[Bug libstdc++/47668] New: missing 'typename' in debug-mode map
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47668 Summary: missing 'typename' in debug-mode map Product: gcc Version: 4.3.5 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org include/debug/map.h refers to a type in a dependent base class, without using 'typename' using _Base::value_compare; I'm not sure if this is actually *wrong* - EDG accepts it too, as long as we don't try to use value_compare in that scope without adding 'typename' (and we don't do that.) However, clang++ rejects it, so debug mode maps cannot be used with clang: /opt/gcc/include/c++/4.4.3/debug/map.h:72:20: error: dependent using declaration resolved to type without 'typename' using _Base::value_compare; ^ adding 'typename' allows debug/map.h to be used with clang++, and doesn't seem to fall foul of PR 14258 (again, because we don't actually use the type in that scope) Another fix would be typedef typename _Base::value_compare value_compare; present in all active releases, not a regression same problem exists in include/debug/multimap.h
[Bug rtl-optimization/47614] [4.6 Regression] cpu2000 benchmark 301.apsi fails with revision 169782
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47614 Jakub Jelinek changed: What|Removed |Added Attachment #23288|0 |1 is obsolete|| --- Comment #13 from Jakub Jelinek 2011-02-09 18:48:46 UTC --- Created attachment 23289 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23289 gcc46-pr47614-2.patch Actually, the second patch is not enough, we don't delete the insn in that case, but still reload_cse_simplify_operands optimizes the MEM into a register, ignoring its side-effects. I think this should work. Alternatively, if we go the first patch route, I think side_effects_p guard in reload_cse_simplify_operands is still desirable.
[Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463 Tobias Burnus changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #12 from Tobias Burnus 2011-02-09 18:52:10 UTC --- (In reply to comment #11) > This line seems completely bogus to me. I have no idea what it's supposed to > do. In any case it came from the following commit: Cf. PR 42385 / http://gcc.gnu.org/viewcvs?view=revision&revision=162313 which was committed by Paul. I do not see whether the line makes sense or not. The idea seems to be to fix not fully resolved TBP -- but it is not completely clear to me whether that is ever needed in such a way. As the test case [cf. comment 9 (b)] shows, the current way is definitely wrong.
[Bug middle-end/47646] [4.6 Regression] Revision 169918 caused many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47646 --- Comment #8 from Eric Botcazou 2011-02-09 18:58:16 UTC --- > So any comment for obj-c++.dg/attributes/method-noreturn-1.mm applies as well > to objc.dg/attributes/method-noreturn-1.m. Last point I don't have any commit > right. OK, will take care of it, as well as the adjustment for Ada.
[Bug libstdc++/47668] missing 'typename' in debug-mode map
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47668 --- Comment #1 from Jonathan Wakely 2011-02-09 19:01:03 UTC --- This certainly isn't high priority to fix, and I'm not sure what the best fix is given that G++ has problems with parsing the required typename (PR 14258) so I'm not going to change anything right away, I just wanted to record the issue
[Bug middle-end/47646] [4.6 Regression] Revision 169918 caused many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47646 --- Comment #9 from Eric Botcazou 2011-02-09 19:23:06 UTC --- Author: ebotcazou Date: Wed Feb 9 19:23:02 2011 New Revision: 169982 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169982 Log: PR middle-end/47646 * gnat.dg/uninit_func.adb: Adjust dg directive. * obj-c++.dg/attributes/method-noreturn-1.mm: Adjust dg directives. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gnat.dg/uninit_func.adb trunk/gcc/testsuite/obj-c++.dg/attributes/method-noreturn-1.mm
[Bug c++/47666] [4.6 Regression] ICE in dfs_walk_once
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47666 H.J. Lu changed: What|Removed |Added CC||jason at redhat dot com --- Comment #2 from H.J. Lu 2011-02-09 19:23:37 UTC --- It is caused by revision 161579: http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg01497.html
[Bug c++/47658] -Os generates bigger code than -O2/3 for many small inline functions (objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47658 --- Comment #2 from Michał Walenciak 2011-02-09 19:34:18 UTC --- (In reply to comment #1) > It works for me, what do you mean by "works" ?:) > the abstraction is completely eliminated by early inlining. > At -Os we do not inline E::foo2 into E::foo1 but that isn't abstraction and > it isn't easily visible that this is profitable. That results in the > -Os code being around 10% larger than -O2 code. and this imho is the problem. As -Os suggests, code should be as small as it's posiible. So i expect that if I use Os, the code will be the smallest that gcc can produce. However in this example I have to use -O2 or even -O3 to get the smallest code, and it's misleading.
[Bug objc/46710] fast enumeration tests failing on ia64-suse-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46710 Nicola Pero changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #5 from Nicola Pero 2011-02-09 19:37:19 UTC --- This failure is no longer reported in any of the automated testsuite checkers. I have to assume it was fixed on 10 January. Thanks
[Bug middle-end/47646] [4.6 Regression] Revision 169918 caused many testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47646 --- Comment #10 from Dominique d'Humieres 2011-02-09 19:41:50 UTC --- > OK, will take care of it, as well as the adjustment for Ada. Thanks!-)
[Bug middle-end/47664] early inliner now needs iteration for multiple calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47664 --- Comment #1 from Richard Guenther 2011-02-09 20:05:01 UTC --- Author: rguenth Date: Wed Feb 9 20:04:56 2011 New Revision: 169983 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169983 Log: 2011-02-09 Richard Guenther PR tree-optimization/47664 * ipa-inline.c (cgraph_decide_inlining_incrementally): Visit all edges again. * gcc.dg/tree-ssa/inline-7.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/inline-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/47664] early inliner now needs iteration for multiple calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47664 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Richard Guenther 2011-02-09 20:05:18 UTC --- Fixed.
[Bug c++/47658] -Os generates bigger code than -O2/3 for many small inline functions (objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47658
--- Comment #3 from Richard Guenther 2011-02-09
20:12:20 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > It works for me,
>
> what do you mean by "works" ?:)
works as "expected" ;) At -Os we inline to remove abstraction penalty
which usually causes code size savings. More inlining in 90% of all
cases increases code-size. As we can't really know at the time of
inlining whether we will hit the remaining 10% (without doing both
inlining and not inlining and later throwing away the larger variant)
we choose the heuristics that usually produce the smallest possible code.
> > the abstraction is completely eliminated by early inlining.
> > At -Os we do not inline E::foo2 into E::foo1 but that isn't abstraction and
> > it isn't easily visible that this is profitable. That results in the
> > -Os code being around 10% larger than -O2 code.
>
> and this imho is the problem. As -Os suggests, code should be as small as it's
> posiible. So i expect that if I use Os, the code will be the smallest that gcc
> can produce. However in this example I have to use -O2 or even -O3 to get the
> smallest code, and it's misleading.
But expected - perfection is not achievable here.
So to say, this bug is either WORKSFORME (as expected) or WONTFIX (aka,
it's impossible to generate the "smallest possible").
Citing the documentation:
@item -Os
@opindex Os
Optimize for size. @option{-Os} enables all @option{-O2} optimizations that
do not typically increase code size. It also performs further
optimizations designed to reduce code size.
It says "Optimize for size", not "Produce smaller code than -O2 or -O3
in all cases".
[Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463 --- Comment #13 from janus at gcc dot gnu.org 2011-02-09 20:18:31 UTC --- (In reply to comment #12) > I do not see whether the line makes sense or not. The idea seems to be to fix > not fully resolved TBP -- but it is not completely clear to me whether that is > ever needed in such a way. Apparently it's not needed, since removing the line does not introduce any regressions in the testsuite. Perhaps it was making up for another bug which is fixed by now. I am going to commit the patch in comment #11 as obvious ...
[Bug lto/47669] New: bootstrap failure due to undefined references
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47669 Summary: bootstrap failure due to undefined references Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: anhvofrc...@gmail.com Host: MinGW Target: MinGW Build: bootstrap Below is the trail end of error messages when boostrap failure occurs. The build was configured with option --enable-languages=ada,c. make[3]: Leaving directory `/c/Gcc/Build-4.6.x/libdecnumber' make[3]: Entering directory `/c/Gcc/Build-4.6.x/lto-plugin' /bin/sh ./libtool --tag=CC --tag=disable-static --mode=compile gcc -DHAVE_CON G_H -I. -I../../gcc-4.6-20110205/lto-plugin -I../../gcc-4.6-20110205/lto-plug /../include -DHAVE_CONFIG_H -Wall -Werror -g -fkeep-inline-functions -c -o lt plugin.lo ../../gcc-4.6-20110205/lto-plugin/lto-plugin.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../gcc-4.6-20110205/lto-plugin I../../gcc-4.6-20110205/lto-plugin/../include -DHAVE_CONFIG_H -Wall -Werror -g fkeep-inline-functions -c ../../gcc-4.6-20110205/lto-plugin/lto-plugin.c -DDL EXPORT -DPIC -o .libs/lto-plugin.o /bin/sh ./libtool --tag=CC --tag=disable-static --mode=link gcc -Wall -Werror g -fkeep-inline-functions -no-undefined -bindir "/usr/local/bin" -bindir /usr/ cal/libexec/gcc/i686-pc-mingw32/4.6.0 -Wl,--stack,12582912 -o liblto_plugin.l -rpath /usr/local/libexec/gcc/i686-pc-mingw32/4.6.0 lto-plugin.lo ../libiberty ic/libiberty.a *** Warning: Trying to link with static lib archive ../libiberty/pic/libiberty . *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because the file extensions .a of this argument makes me believe *** that it is just a static archive that I should not use here. libtool: link: gcc -shared .libs/lto-plugin.o-Wl,--stack -Wl,12582912 - .libs/liblto_plugin-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib - inker .libs/liblto_plugin.dll.a Creating library file: .libs/liblto_plugin.dll.a .libs/lto-plugin.o: In function `parse_table_entry': c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:2 : undefined reference to `xstrdup' c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:2 : undefined reference to `concat' c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:2 : undefined reference to `xstrdup' .libs/lto-plugin.o: In function `translate': c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:2 : undefined reference to `xrealloc' c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:2 : undefined reference to `xrealloc' .libs/lto-plugin.o: In function `add_output_files': c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:4 : undefined reference to `xmalloc' c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:4 : undefined reference to `xrealloc' c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:4 : undefined reference to `xrealloc' .libs/lto-plugin.o: In function `exec_lto_wrapper': c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:5 : undefined reference to `make_temp_file' c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:5 : undefined reference to `writeargv' c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:5 : undefined reference to `concat' c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:5 : undefined reference to `pex_init' c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:5 : undefined reference to `pex_run' c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:5 : undefined reference to `pex_read_output' c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:5 : undefined reference to `pex_get_status' c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:5 : undefined reference to `pex_free' .libs/lto-plugin.o: In function `all_symbols_read_handler': c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:6 : undefined reference to `xcalloc' .libs/lto-plugin.o: In function `hash_sym': c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:6 : undefined reference to `htab_hash_string' .libs/lto-plugin.o: In function `resolve_conflicts': c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:7 : undefined reference to `htab_create' c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-plugin/lto-plugin.c:7 : undefined reference to `xmalloc' c:\Gcc\Build-4.6.x\lto-plugin/../../gcc-4.6-20110205/lto-pl
[Bug c/47530] [trans-mem] tail call optimization problem with _ITM_commitTransaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47530 --- Comment #2 from Richard Henderson 2011-02-09 20:24:02 UTC --- Author: rth Date: Wed Feb 9 20:23:56 2011 New Revision: 169984 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169984 Log: PR 47530 * trans-mem.c (expand_block_edges): Reset tail-call bit. Added: branches/transactional-memory/gcc/testsuite/g++.dg/tm/pr47530.C Modified: branches/transactional-memory/gcc/ChangeLog.tm branches/transactional-memory/gcc/trans-mem.c
[Bug c/47530] [trans-mem] tail call optimization problem with _ITM_commitTransaction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47530 Richard Henderson changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Richard Henderson 2011-02-09 20:24:26 UTC --- Fixed.
[Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463 --- Comment #14 from janus at gcc dot gnu.org 2011-02-09 20:30:23 UTC --- Author: janus Date: Wed Feb 9 20:30:20 2011 New Revision: 169985 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169985 Log: 2011-02-09 Janus Weil PR fortran/47463 * resolve.c (resolve_typebound_subroutine): Remove erroneous line. 2011-02-09 Janus Weil PR fortran/47463 * gfortran.dg/typebound_assignment_2.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_assignment_2.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/47668] missing 'typename' in debug-mode map
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47668 --- Comment #2 from Paolo Carlini 2011-02-09 20:35:45 UTC --- What if we remove the using altogether?
[Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from janus at gcc dot gnu.org 2011-02-09 20:37:04 UTC --- I think r169985 should fix all remaining problems in this PR. The original test case now gives me: gfortran-4.6 -std=f2003 -c hydro_types.f90 gfortran-4.6 -std=f2003 -c hydro_state.f90 gfortran-4.6 -std=f2003 -c hydro_speeds.f90 gfortran-4.6 -std=f2003 -c hydro_grid.f90 gfortran-4.6 -std=f2003 -c hydro_flow.f90 gfortran-4.6 -std=f2003 -c hydro_recon.f90 gfortran-4.6 -std=f2003 -c hydro_evolve.f90 hydro_evolve.f90:10.18: use hydro_fluxes 1 Fatal Error: Can't open module file 'hydro_fluxes.mod' for reading at (1): No such file or directory Closing as fixed.
