[Bug tree-optimization/49227] [4.7 Regression] ice in inline_small_functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49227 --- Comment #2 from Arthur O'Dwyer 2011-07-02 08:04:20 UTC --- Created attachment 24657 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24657 Another testcase, fairly reduced I just ran into the same ICE via automatic test generation. I'm attaching "bug120673164-reduced.c", a 65-line C99 test case exposing the bug. gcc -std=c99 -w -O2 -finline-functions -fnon-call-exceptions -fno-tree-fre bug120673164-reduced.c bug120673164-reduced.c:77:1: internal compiler error: in inline_small_functions, at ipa-inline.c:1398 This test case is reduced from the output of Csmith 2.1.0 (git hash 01aa8b04, https://github.com/Quuxplusone/csmith/), using the following command line: csmith --paranoid --no-longlong --no-pointers --arrays --jumps --consts --no-volatiles --checksum --divs --no-muls --no-bitfields --packed-struct -s 120673164
[Bug tree-optimization/49227] [4.7 Regression] ice in inline_small_functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49227 Arthur O'Dwyer changed: What|Removed |Added CC||arthur.j.odwyer at gmail ||dot com --- Comment #3 from Arthur O'Dwyer 2011-07-02 08:06:32 UTC --- (In reply to comment #2) Shoot, as soon as I clicked "Save" I noticed that the line number is different: ipa-inline.c:1348 versus ipa-inline.c:1398. So my ICE might be something different. Nevertheless, they're both in the same file and both regressed very recently, so the root cause is likely the same in both cases.
[Bug fortran/49562] [4.6/4.7 Regression] [OOP] assigning value to type-bound function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49562 --- Comment #7 from janus at gcc dot gnu.org 2011-07-02 11:08:45 UTC --- Author: janus Date: Sat Jul 2 11:08:41 2011 New Revision: 175779 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175779 Log: 2011-07-02 Janus Weil PR fortran/49562 * expr.c (gfc_check_vardef_context): Handle type-bound procedures. 2011-07-02 Janus Weil PR fortran/49562 * gfortran.dg/typebound_proc_23.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_proc_23.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/49598] [C++0x] Ice on lambda with implicit capture by value.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49598
Jonathan Wakely changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.07.02 11:25:48
CC||jason at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #3 from Jonathan Wakely 2011-07-02
11:25:48 UTC ---
The ICE seems to be when initialising the closure type's data member for an
object of reference type implicitly-captured by copy.
Slightly further reduced:
int
main()
{
int i = 10;
int& ir = i;
[=]
{
(void) ir;
}();
}
(In reply to comment #1)
> With [=, ir] I get a warning:
> lamb3.cpp:10:7: warning: explicit by-copy capture of ‘ir’ redundant with
> by-copy capture default [enabled by default]
> But it compiles.
>
> With [=, i] I get the ICE.
That's invalid:
"If a lambda-capture includes a capture-default that is =, the lambda-capture
shall not contain this and each identifier it contains shall be preceded by &."
[Bug libgomp/49613] New: Error with OpenMP / gomp and gcc detected by valgrind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49613
Summary: Error with OpenMP / gomp and gcc detected by valgrind
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cx-t...@web.de
Created attachment 24658
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24658
Code, makefile and result log.
Hey,
I've got a error when compiling
#include
int main()
{
int i,max=100;
double r[max];
#pragma omp parallel private(i) shared(r)
{
#pragma omp for schedule(static,2) nowait
for(i=0;i
[Bug libgomp/49613] Error with OpenMP / gomp and gcc detected by valgrind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49613 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Jakub Jelinek 2011-07-02 11:56:44 UTC --- These aren't errors of any kind.
[Bug inline-asm/49611] Inline asm should support input/output of flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611 --- Comment #1 from Richard Guenther 2011-07-02 12:36:44 UTC --- Making this work reliably is probably more work than making GCC use the flags from more cases from regular C code.
[Bug lto/49612] LTO cannot link objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49612 --- Comment #1 from Richard Guenther 2011-07-02 12:40:38 UTC --- please try GCC 4.6.x. Are you sure you are using GCC 4.5.x? You shouldn't see this kind of output with -flto there.
[Bug target/49614] New: FAIL: gcc.dg/vmx/gcc-bug-i.c -O0 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49614
Summary: FAIL: gcc.dg/vmx/gcc-bug-i.c -O0 (test for excess
errors)
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: hubi...@gcc.gnu.org, ch...@gcc.gnu.org
Target: powerpc*-*-*
Since revision 175247, powerpc*-*-* shows the following failures
FAIL: gcc.dg/vmx/gcc-bug-i.c -O0 (test for excess errors)
FAIL: gcc.dg/vmx/gcc-bug-i.c -O1 (test for excess errors)
FAIL: gcc.dg/vmx/gcc-bug-i.c -O2 (test for excess errors)
FAIL: gcc.dg/vmx/gcc-bug-i.c -O3 -fomit-frame-pointer (test for excess
errors)
FAIL: gcc.dg/vmx/gcc-bug-i.c -O3 -fomit-frame-pointer -funroll-loops (test
for excess errors)
FAIL: gcc.dg/vmx/gcc-bug-i.c -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions (test for excess errors)
FAIL: gcc.dg/vmx/gcc-bug-i.c -O3 -g (test for excess errors)
FAIL: gcc.dg/vmx/gcc-bug-i.c -Os (test for excess errors)
FAIL: gcc.dg/vmx/gcc-bug-i.c -O2 -flto -flto-partition=none (test for excess
errors)
FAIL: gcc.dg/vmx/gcc-bug-i.c -O2 -flto (test for excess errors)
due to
FAIL: gcc.dg/vmx/gcc-bug-i.c -O0 (test for excess errors)
Excess errors:
/opt/gcc/work/gcc/testsuite/gcc.dg/vmx/gcc-bug-i.c:16:22: warning:
always_inline function might not be inlinable [-Wattributes]
This warning has been introduced at revision 175239
Author:chrbr
Date:Tue Jun 21 06:42:05 2011 UTC (11 days, 5 hours ago)
Changed paths:16
Log Message:
PR middle-end/49139 fix always_inline diagnostics
--- trunk/gcc/cgraphunit.c2011/06/21 06:27:35175238
+++ trunk/gcc/cgraphunit.c2011/06/21 06:42:05175239
@@ -986,6 +986,14 @@
DECL_ATTRIBUTES (decl) = remove_attribute ("weakref",
DECL_ATTRIBUTES (decl));
}
+
+ if (lookup_attribute ("always_inline", DECL_ATTRIBUTES (decl))
+ && !DECL_DECLARED_INLINE_P (decl)
+ /* redefining extern inline function makes it DECL_UNINLINABLE. */
+ && !DECL_UNINLINABLE (decl))
+warning_at (DECL_SOURCE_LOCATION (decl), OPT_Wattributes,
+"always_inline function might not be inlinable");
+
process_common_attributes (decl);
}
for (vnode = varpool_nodes; vnode != first_var; vnode = vnode->next)
Is the test bogus, or is it enough to "dg-prune-output" the warning?
[Bug libffi/49594] bootstrap failure in libffi:darwin_closure for powerpc-darwin8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49594 --- Comment #8 from Iain Sandoe 2011-07-02 13:10:10 UTC --- I tested the patch on darwin 8 on a G5 and with crosses from darwin 9 - > darwin 8. results are shown in: http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00134.html FWIW: unless there's a real need to generate m64 to target a different box, I don't think there's a whole lot of point in building the multi-libs in general on darwin 8 on a G4. It makes a huge difference to build & test as well. Even on a G5, there are missing m64 libraries that prevent java from working, and also there's no NeXT m64 ObjC support. Having said that, m64 c, c++, fortran and GNU ObjC work fine on darwin 8.
[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466 --- Comment #10 from janus at gcc dot gnu.org 2011-07-02 13:46:23 UTC --- Author: janus Date: Sat Jul 2 13:46:21 2011 New Revision: 175780 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175780 Log: 2011-07-02 Janus Weil PR fortran/49466 * trans-array.c (structure_alloc_comps): Make sure sub-components and extended types are correctly deallocated. 2011-07-02 Janus Weil PR fortran/49466 * gfortran.dg/allocatable_scalar_9.f90: Modified. * gfortran.dg/extends_14.f03: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/extends_14.f03 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/trans-array.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90
[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from janus at gcc dot gnu.org 2011-07-02 13:52:18 UTC --- Fixed on trunk and the 4.6 branch. This means that the fix will be part of the upcoming release 4.6.2, which is tentatively scheduled for September. Thanks for reporting, Rich!
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #20 from Georg-Johann Lay 2011-07-02 17:29:23 UTC --- (In reply to comment #19) > Indeed, I simply made all bare-metal targets use newlib-stdint.h as a > default, but since AVR has its own libc it seems more appropriate to put > the defines in avr-stdint.h or avr.h and not use newlib-stdint.h. (And > the point of having separate headers such as newlib-stdint.h is that there > may not otherwise be a header shared between all relevant targets. If all > AVR targets use avr-libc, putting the defines in avr.h makes sense, but if > avr-rtems is using newlib like other RTEMS targets then you probably want > a separate header only for AVR targets using avr-libc.) The extra header is not needed because of avr-libc; there is nothing special about avr-libc and it conforms to the standard (except when you explicitely link some lean implementation of *printf* or so. Jörg will correct me if I'm wrong). The extra avr specific header is just needed to avoid shredding avr-gcc with -mint8 and arrange for int=QI. -mint8 it not a multilib option, and isn't supported by avr-libc except that it provides conditional type definitions in stdint.h et al.
[Bug target/41885] AVR Rotate patterns do not correctly consider overlap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41885 Georg-Johann Lay changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.5.0 --- Comment #3 from Georg-Johann Lay 2011-07-02 17:54:09 UTC --- Fixed with Andy's patch. 4.5.0 passes the testcase.
[Bug c++/49615] New: internal compiler error: verify_stmts failed / LHS in noreturn call with pointer-to-never-returning-member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49615
Summary: internal compiler error: verify_stmts failed / LHS in
noreturn call with pointer-to-never-returning-member
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: har...@gigawatt.nl
I came across this while reducing another testcase (which I'll report
separately):
$ cat bug.ii
template
static inline bool Dispatch (T* obj, bool (T::*func) ())
{
return (obj->*func) ();
}
class C
{
bool f (int);
bool g ();
};
bool C::f (int n)
{
bool b;
switch (n)
{
case 0:
b = Dispatch (this, &C::g);
case 1:
b = Dispatch (this, &C::g);
}
}
bool C::g ()
{
for (;;) { }
}
$ gcc -O bug.ii
bug.ii: In member function ‘bool C::f(int)’:
bug.ii:11:6: error: LHS in noreturn call
b_48 = C::g (D.2160_46);
bug.ii:11:6: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
$ gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/pkgbuild/sys-devel/gcc-4.6.1/work/gcc-4.6.1/configure
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --prefix=/usr
--libdir='/usr/lib64' --sysconfdir=/etc --enable-languages=c,c++
--enable-checking --enable-build-with-cxx
Thread model: posix
gcc version 4.6.1 (GCC)
[Bug c++/49615] internal compiler error: verify_stmts failed / LHS in noreturn call with pointer-to-never-returning-member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49615
--- Comment #1 from Harald van Dijk 2011-07-02
20:35:39 UTC ---
Actually, I'll include the other slightly different testcase here, since it'll
probably be the same problem. If you prefer me reporting it as a separate bug,
I will do so.
$ cat bug.ii
template
static inline bool Dispatch (T* obj, void (T::*func) ())
{
(obj->*func) ();
}
class C
{
bool f (int);
void g ();
};
bool C::f (int n)
{
bool b;
switch (n)
{
case 0:
b = Dispatch (this, &C::g);
case 1:
b = Dispatch (this, &C::g);
}
}
void C::g ()
{
for (;;) { }
}
$ gcc -c -O bug.ii # works
$ gcc -c -O bug.ii -g
bug.ii: In member function ‘bool C::f(int)’:
bug.ii:11:6: error: control flow in the middle of basic block 4
bug.ii:11:6: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
[Bug target/43088] [avr] Suspect optimizer missed code in gcc 4.4.3..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43088 --- Comment #6 from Georg-Johann Lay 2011-07-02 21:07:50 UTC --- Created attachment 24659 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24659 C source file Compile with -mmcu=atmega168 -Os. This file shows the flaw in function foo_3f that compares against 0x3f in comparison to foo_3e that compares against 0x3e. If the comparison is against 0x3e the code is fine. The difference happens in pass combine. For 0x3f, combine tryes ZERO_EXTRACT: Trying 8, 9 -> 10: Failed to match this instruction: (parallel [ (set (cc0) (compare (zero_extract:HI (reg:QI 43 [ count.3 ]) (const_int 6 [0x6]) (const_int 0 [0])) (const_int 0 [0]))) (clobber (scratch:QI)) ]) Failed to match this instruction: (set (cc0) (compare (zero_extract:HI (reg:QI 43 [ count.3 ]) (const_int 6 [0x6]) (const_int 0 [0])) (const_int 0 [0]))) Failed to match this instruction: (set (reg:HI 52) (zero_extract:HI (reg:QI 43 [ count.3 ]) (const_int 6 [0x6]) (const_int 0 [0]))) . But for 0x3e it tryes AND, which matches (presumably combine-split): Trying 8, 9 -> 10: Failed to match this instruction: (parallel [ (set (cc0) (compare (and:QI (reg:QI 43 [ count.1 ]) (const_int 62 [0x3e])) (const_int 0 [0]))) (clobber (scratch:QI)) ]) Failed to match this instruction: (set (cc0) (compare (and:QI (reg:QI 43 [ count.1 ]) (const_int 62 [0x3e])) (const_int 0 [0]))) Successfully matched this instruction: (set (reg:QI 52) (and:QI (reg:QI 43 [ count.1 ]) (const_int 62 [0x3e]))) Successfully matched this instruction: (set (cc0) (compare (reg:QI 52) (const_int 0 [0]))) deferring deletion of insn with uid = 8. ...
[Bug target/39819] [avr] Missed optimisation when setting 4-byte values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39819
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||gjl at gcc dot gnu.org
Known to work||4.6.1
Resolution||WONTFIX
--- Comment #2 from Georg-Johann Lay 2011-07-02
21:23:59 UTC ---
Closed as WONTFIX.
Compiled the following code in 4.6.1, -std=c99 -mmcu=atmega88 -Os
typedef unsigned char uint8_t;
typedef unsigned long int uint32_t;
uint8_t as[4];
uint8_t bs[4];
static const uint8_t sz = 4;
void foo1(void) {
for (uint8_t i = 0; i < sz; i++) {
bs[i] = as[1];
}
}
void foo2(void) {
for (uint8_t i = 0; i < sz; i++) {
*(bs + i) = *(as + 1);
}
}
The result is:
foo1:
lds r24,as+1
sts bs,r24
sts bs+1,r24
sts bs+2,r24
sts bs+3,r24
ret
foo2:
lds r24,as+1
sts bs,r24
sts bs+1,r24
sts bs+2,r24
sts bs+3,r24
ret
So the difference has gone.
[Bug bootstrap/49469] GCC fails to bootstrap when building with embedded zlib on Mac OS X 10.6.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49469 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #1 from Hans-Peter Nilsson 2011-07-02 22:53:49 UTC --- (In reply to comment #0) > And the build log is attached. No, please attach it.
[Bug bootstrap/49469] GCC fails to bootstrap when building with embedded zlib on Mac OS X 10.6.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49469 --- Comment #2 from Xiyue Deng 2011-07-03 04:29:09 UTC --- Created attachment 24660 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24660 gcc_4.7_build.log.gz Here is the build log with gcc trunk 'git pull'ed today, still the same problem.
