[Bug c++/56961] New: cycle between do_spec_1() / process_brace_body() / handle_braces()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56961
Bug #: 56961
Summary: cycle between do_spec_1() / process_brace_body() /
handle_braces()
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dim...@gmail.com
$ cat x.cpp
struct foo { };
typedef struct
{
volatile foo fields;
}
CSPHandleState;
CSPHandleState a;
void
fn1 ()
{
CSPHandleState b;
b.fields = foo();
}
$ g++ -O0 -c x.cpp
x.cpp: In function 'void fn1()':
x.cpp:12:16: error: passing 'volatile foo' as 'this' argument of 'foo&
foo::operator=(const foo&)' discards qualifiers [-fpermissive]
b.fields = foo();
^
g++: internal compiler error: Segmentation fault (program cc1plus)
0x40950c execute
/home/dimhen/src/gcc-current/gcc/gcc.c:2822
0x409769 do_spec_1
/home/dimhen/src/gcc-current/gcc/gcc.c:4614
0x40c4d9 process_brace_body
/home/dimhen/src/gcc-current/gcc/gcc.c:5871
0x40c4d9 handle_braces
/home/dimhen/src/gcc-current/gcc/gcc.c:5785
0x40a1fa do_spec_1
/home/dimhen/src/gcc-current/gcc/gcc.c:5268
0x40c4d9 process_brace_body
/home/dimhen/src/gcc-current/gcc/gcc.c:5871
0x40c4d9 handle_braces
/home/dimhen/src/gcc-current/gcc/gcc.c:5785
0x40a1fa do_spec_1
/home/dimhen/src/gcc-current/gcc/gcc.c:5268
0x40a5eb do_spec_1
/home/dimhen/src/gcc-current/gcc/gcc.c:5373
0x40c4d9 process_brace_body
/home/dimhen/src/gcc-current/gcc/gcc.c:5871
0x40c4d9 handle_braces
/home/dimhen/src/gcc-current/gcc/gcc.c:5785
0x40a1fa do_spec_1
/home/dimhen/src/gcc-current/gcc/gcc.c:5268
0x40c4d9 process_brace_body
/home/dimhen/src/gcc-current/gcc/gcc.c:5871
0x40c4d9 handle_braces
/home/dimhen/src/gcc-current/gcc/gcc.c:5785
0x40a1fa do_spec_1
/home/dimhen/src/gcc-current/gcc/gcc.c:5268
0x40c4d9 process_brace_body
/home/dimhen/src/gcc-current/gcc/gcc.c:5871
0x40c4d9 handle_braces
/home/dimhen/src/gcc-current/gcc/gcc.c:5785
0x40a1fa do_spec_1
/home/dimhen/src/gcc-current/gcc/gcc.c:5268
0x40c4d9 process_brace_body
/home/dimhen/src/gcc-current/gcc/gcc.c:5871
0x40c4d9 handle_braces
/home/dimhen/src/gcc-current/gcc/gcc.c:5785
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
Thanks to David Blaikie for reduced testcase
(http://lists.cs.uiuc.edu/pipermail/cfe-users/2013-April/85.html)
[Bug c++/56961] Segfault with volatile field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56961 Andrew Pinski changed: What|Removed |Added Summary|ICE: cycle between |Segfault with volatile |do_spec_1() / |field |process_brace_body() / | |handle_braces() | --- Comment #1 from Andrew Pinski 2013-04-15 07:45:37 UTC --- Note the backtrace that is provided is the one from gcc where it is executing cc1plus which is nothing special.
[Bug c++/56961] stack overflow in gimplifier with volatile field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56961 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-15 Summary|Segfault with volatile |stack overflow in |field |gimplifier with volatile ||field Ever Confirmed|0 |1 Known to fail||4.7.0, 4.8.0, 4.9.0 --- Comment #2 from Andrew Pinski 2013-04-15 07:50:53 UTC --- Confirmed.
[Bug target/56897] unaligned memory access on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56897
Uros Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2013-04-15
Ever Confirmed|0 |1
--- Comment #3 from Uros Bizjak 2013-04-15 07:53:58
UTC ---
(In reply to comment #0)
> To reproduce, try this out:
>
> unsigned long foo = 0x010203040a0b0c0d;
> printf("%02x", *((char *)&foo + 7));
>
> With -O (and onwards) it will turn out to be zero; at every &X+15,
> &X+23, etc. Depending on the offset from the frame pointer.
Please create a self-sufficient executable testcase, following the instructions
at [1]. I was not able to confirm the problem from the lines you posted.
[1] http://gcc.gnu.org/bugs/
[Bug c++/56961] stack overflow in gimplifier with volatile field
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56961 --- Comment #3 from Dmitry G. Dyachenko 2013-04-15 08:01:24 UTC --- gcc-4.7.2 / Fedora 18 FAIL too gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC)
[Bug tree-optimization/56962] New: [4.8/4.9 Regression] SLSR caused miscompilation of fftw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56962
Bug #: 56962
Summary: [4.8/4.9 Regression] SLSR caused miscompilation of
fftw
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
Reduced testcase:
extern void abort (void);
long double v[144];
__attribute__((noinline, noclone)) void
bar (long double *x)
{
if (x != &v[29])
abort ();
}
__attribute__((noinline, noclone)) void
foo (long double *x, long y, long z)
{
long double a, b, c;
a = x[z * 4 + y * 3];
b = x[z * 5 + y * 3];
c = x[z * 5 + y * 4];
x[y * 4] = a;
bar (&x[z * 5 + y]);
x[z * 5 + y * 5] = b + c;
}
int
main ()
{
foo (v, 24, 1);
return 0;
}
This fails at -O2, works with -O2 -fno-tree-slsr. Started with
http://gcc.gnu.org/r190220
The *.reassoc2 to *.slsr diff with unimportant stuff removed:
...
_2 = z_1(D) * 4;
_4 = y_3(D) * 3;
_5 = _2 + _4;
...
_12 = z_1(D) * 5;
- _13 = _4 + _12;
+ _13 = _5 + z_1(D);
...
_18 = y_3(D) * 4;
- _19 = _12 + _18;
+ _19 = _13 + y_3(D);
...
- _28 = y_3(D) + _12;
+ _28 = _19 - _5;
...
Here before slsr we have:
_5 = y*3+z*4
_13 = y*3+z*5
_19 = y*4+z*5
_28 = y+z*5
and the _13 and _19 changes look just fine, but the _28 change is changing the
value from y+z*5 to y+z.
[Bug tree-optimization/56962] [4.8/4.9 Regression] SLSR caused miscompilation of fftw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56962 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 CC||wschmidt at gcc dot gnu.org Target Milestone|--- |4.8.1
[Bug c++/56963] New: GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56963 Bug #: 56963 Summary: GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284 Classification: Unclassified Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: vhais...@gmail.com I have tried to compile log4cplus (C++ logging library) on Cygwin64 with -flto GCC option. I am getting the following failure: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284 Here is a link to archive with the minimal amount of .o files and a test.sh script that reproduce the problem for me. https://docs.google.com/file/d/0B-WkLJEfYmSEUVVOdm56X1FSNDA/edit?usp=drive_web
[Bug target/56890] invalid fdtox instruction in 64-bit mode with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56890 --- Comment #8 from Eric Botcazou 2013-04-15 08:35:50 UTC --- Author: ebotcazou Date: Mon Apr 15 08:28:41 2013 New Revision: 197958 URL: http://gcc.gnu.org/viewcvs?rev=197958&root=gcc&view=rev Log: PR target/56890 * config/sparc/sparc.c (enum sparc_mode_class): Add H_MODE value. (S_MODES): Set H_MODE bit. (SF_MODES): Set only S_MODE and SF_MODE bits. (DF_MODES): Set SF_MODES and only D_MODE and DF_MODE bits. (sparc_init_modes) : Set H_MODE bit for sub-word modes. : Do not set SF_MODE for sub-word modes. : Likewise. Added: trunk/gcc/testsuite/gcc.dg/pr56890-1.c trunk/gcc/testsuite/gcc.dg/pr56890-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c trunk/gcc/testsuite/ChangeLog
[Bug target/56890] invalid fdtox instruction in 64-bit mode with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56890 --- Comment #9 from Eric Botcazou 2013-04-15 08:36:16 UTC --- Author: ebotcazou Date: Mon Apr 15 08:31:12 2013 New Revision: 197959 URL: http://gcc.gnu.org/viewcvs?rev=197959&root=gcc&view=rev Log: PR target/56890 * config/sparc/sparc.c (enum sparc_mode_class): Add H_MODE value. (S_MODES): Set H_MODE bit. (SF_MODES): Set only S_MODE and SF_MODE bits. (DF_MODES): Set SF_MODES and only D_MODE and DF_MODE bits. (sparc_init_modes) : Set H_MODE bit for sub-word modes. : Do not set SF_MODE for sub-word modes. : Likewise. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr56890-1.c - copied unchanged from r197958, trunk/gcc/testsuite/gcc.dg/pr56890-1.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr56890-2.c - copied unchanged from r197958, trunk/gcc/testsuite/gcc.dg/pr56890-2.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/sparc/sparc.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug target/56890] invalid fdtox instruction in 64-bit mode with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56890 --- Comment #10 from Eric Botcazou 2013-04-15 08:36:36 UTC --- Author: ebotcazou Date: Mon Apr 15 08:33:56 2013 New Revision: 197960 URL: http://gcc.gnu.org/viewcvs?rev=197960&root=gcc&view=rev Log: PR target/56890 * config/sparc/sparc.c (enum sparc_mode_class): Add H_MODE value. (S_MODES): Set H_MODE bit. (SF_MODES): Set only S_MODE and SF_MODE bits. (DF_MODES): Set SF_MODES and only D_MODE and DF_MODE bits. (sparc_init_modes) : Set H_MODE bit for sub-word modes. : Do not set SF_MODE for sub-word modes. : Likewise. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr56890-1.c - copied unchanged from r197959, trunk/gcc/testsuite/gcc.dg/pr56890-1.c branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/pr56890-2.c - copied unchanged from r197959, trunk/gcc/testsuite/gcc.dg/pr56890-2.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/sparc/sparc.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug target/56890] invalid fdtox instruction in 64-bit mode with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56890 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.4 --- Comment #11 from Eric Botcazou 2013-04-15 08:37:38 UTC --- Thanks for the reduced testcases.
[Bug c++/56963] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56963 Václav Zeman changed: What|Removed |Added Keywords||lto Target||x86_64-pc-cygwin CC||vhaisman at gmail dot com Host||x86_64-pc-cygwin Known to fail||4.8.0 Build||x86_64-pc-cygwin --- Comment #1 from Václav Zeman 2013-04-15 08:37:39 UTC --- Link to the original conversation in cygwin-apps@ ml: http://cygwin.com/ml/cygwin-apps/2013-04/msg00154.html $ uname -a CYGWIN_NT-6.1 HAIVA01W7 1.7.18(0.263/5/3) 2013-04-10 14:35 x86_64 Cygwin $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: /usr/src/ports/gcc/gcc-4.8.0-1/src/gcc-4.8.0/configure --srcdir=/usr/src/ports/gcc/gcc-4.8.0-1/src/gcc-4.8.0 --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var --sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/gcc -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --disable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib Thread model: posix gcc version 4.8.0 (GCC)
[Bug c++/56963] GCC 4.8.0 LTO issue: lto1: internal compiler error: in add_symbol_to_partition, at lto/lto-partition.c:284
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56963 --- Comment #2 from Václav Zeman 2013-04-15 08:39:40 UTC --- None of the tricks (-fno-reorder-blocks, -r, -nostdlib) help here. It still fails the same way.
[Bug bootstrap/50686] [4.7 regression] IRIX 6.5 bootstrap failure: ICE in in lookup_cfa_1, at dwarf2cfi.c:595
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686 --- Comment #41 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-04-15 09:27:09 UTC --- > I'm currently running a bootstrap of gcc 4.7.3 with this patch applied > and without any special --enable-checking=release. It just entered > stage2, so seems to be fine. > > I'll report once the bootstrap completed successfully. This has happened now, so the patch is good to go. Thanks. Rainer
[Bug fortran/53478] gfortran segfaults when module name clashes with C binding name of procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53478 Aron Ahmadia changed: What|Removed |Added CC||aron at ahmadia dot net --- Comment #5 from Aron Ahmadia 2013-04-15 10:06:20 UTC --- I was able to reproduce this on 4.7.2 using Solomon's code snippet. Is there anything else I do to help out here?
[Bug rtl-optimization/56957] [4.9 regression] ICE in add_insn_after, at emit-rtl.c:3783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56957 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug tree-optimization/56962] [4.8/4.9 Regression] SLSR caused miscompilation of fftw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56962 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-04-15 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek 2013-04-15 10:15:16 UTC --- Created attachment 29873 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29873 gcc49-pr56962.patch Untested fix. CAND_ADD can apparently be set even on c->cand_stmt which isn't a addition (e.g. cast of the addition etc.), plus by just silently assuming that if rhs1 isn't equal to c->base_expr, then rhs2 is, doesn't work in all cases. In particular, c->cand_stmt can be e.g. addition of two SSA_NAMEs where each one of those adds in some part, not equal to c->base_expr.
[Bug other/56955] documentation for attribute malloc contradicts itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955
--- Comment #3 from Richard Biener 2013-04-15
10:19:22 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > I think it is talking about the memory returned by malloc/calloc will not
> > point
> > to another memory location while realloc can.
>
> I agree that's essentially what it ought to talk about, and the bug is that
> it's talking about something else -- the contents of the pointed-to memory.
Well, it _is_ actually about the content. There must be no way to compute
a valid pointer to another object from the contents of the pointed-to
memory. So if you initialize the memory to {0, 1, 2, 3, 4 ...} thus
every possible byte value is somewhere and then do
void *p = (void *)(mem[3] << 24 | mem[58] << 16 | ...);
then points-to analysis assumes that from the contents of 'mem' you
can only compute pointers to nothing (NULL). Technically for targets
where NULL is a valid poiner to an object calloc () may not be marked
with malloc.
That is, read it in the way that the code assumes the memory _may_ be
zero-initialized (but only zero-initialized) or uninitialized.
[Bug rtl-optimization/56952] [4.9 regression] ICE in recog.c:2150
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56952 Richard Biener changed: What|Removed |Added Target||i686-pc-cygwin Host||i686-pc-cygwin Target Milestone|--- |4.9.0
[Bug lto/54078] Bytemark 46% bigger binary with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54078 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #9 from Richard Biener 2013-04-15 10:22:59 UTC --- Btw, with -O3 you essentially say you do not care for program size (IPA cloning decisions blow up the unit without limits I think - unlike inlining which is limited by unit-growth for large units).
[Bug c++/56947] [4.7 Regression] Bogus 'XX' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56947 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-15 Known to work||4.7.2, 4.8.0 Target Milestone|--- |4.7.4 Summary|[4.7.3 regression] Bogus|[4.7 Regression] Bogus 'XX' |'XX' was not declared in|was not declared in this |this scope |scope Ever Confirmed|0 |1 Known to fail||4.7.3 --- Comment #1 from Richard Biener 2013-04-15 10:24:57 UTC --- Ick. Confirmed.
[Bug target/56944] Better isfinite in some cases?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56944 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-15 Ever Confirmed|0 |1 --- Comment #2 from Richard Biener 2013-04-15 10:26:12 UTC --- Confirmed.
[Bug tree-optimization/56935] Basic block is not SLP-vectorizeed after r197635.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56935 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-04-15 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Richard Biener 2013-04-15 10:27:55 UTC --- I will have a look. We now _do_ account for some costs more appropriately (well, I think so ;)).
[Bug tree-optimization/56933] [4.9 Regression] Vectorizer missing read-write dependency for interleaved accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56933 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-04-15 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.9.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener 2013-04-15 10:29:19 UTC --- Mine.
[Bug middle-end/56964] New: ICE with -fno-sync-libcalls when target lacks atomic operations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56964
Bug #: 56964
Summary: ICE with -fno-sync-libcalls when target lacks atomic
operations
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@mansr.com
Use of __atomic_* functions when compiling for a target without atomic
operations (e.g. ARMv6) while specifying -fno-sync-libcalls gives an ICE
instead of a proper error message.
$ cat foo.c
int *x;
void foo(void)
{
__atomic_test_and_set(x, 0);
}
$ arm-unknown-linux-gnueabi-gcc-4.8.0 -c foo.c -march=armv6 -fno-sync-libcalls
foo.c: In function 'foo':
foo.c:4:26: internal compiler error: in emit_move_insn, at expr.c:3486
__atomic_test_and_set(x, 0);
^
Please submit a full bug report,
with preprocessed source if appropriate.
This happens for any target without atomic operations in hardware.
[Bug fortran/53478] gfortran segfaults when module name clashes with C binding name of procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53478 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #6 from Tobias Burnus 2013-04-15 11:01:10 UTC --- (In reply to comment #4) > I have the patch in comment #2 in my tree since some time now and it works as > advertised without regression. However, If I have understood Ian Harvey's > answer in comp.lang.fortran > https://groups.google.com/forum/?fromgroups#!topic/comp.lang.fortran/o_hapvMHxIE > the test in comment #3 is invalid. Is this correct? The test case in comment 0 and comment 3 are invalid in Fortran 2003; I think they are valid in Fortran 2008 (cf. PR 48858 comment 9). However, I need a quiet moment to disentangle the standard speak and to create a patch.
[Bug tree-optimization/56933] [4.9 Regression] Vectorizer missing read-write dependency for interleaved accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56933
--- Comment #2 from Richard Biener 2013-04-15
11:18:43 UTC ---
/* { dg-do run } */
extern void abort (void);
void __attribute__((noinline,noclone))
foo (double *b, double *d, double *f)
{
int i;
for (i = 0; i < 1024; i++)
{
d[2*i] = 2. * d[2*i];
d[2*i+1] = 4. * d[2*i+1];
b[i] = d[2*i] - 1.;
f[i] = d[2*i+1] + 2.;
}
}
int main()
{
double b[1024], d[2*1024], f[1024];
int i;
for (i = 0; i < 2*1024; i++)
d[i] = 1.;
foo (b, d, f);
for (i = 0; i < 1024; i+= 2)
{
if (d[2*i] != 2.)
abort ();
if (d[2*i+1] != 4.)
abort ();
}
for (i = 0; i < 1024; i++)
{
if (b[i] != 1.)
abort ();
if (f[i] != 6.)
abort ();
}
return 0;
}
/* { dg-final { cleanup-tree-dump "vect" } } */
[Bug rtl-optimization/56965] New: nonoverlapping_component_refs_p is bogus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56965
Bug #: 56965
Summary: nonoverlapping_component_refs_p is bogus
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
struct S {
int i;
int j;
};
struct U {
struct S s;
} __attribute__((may_alias));
int __attribute__((noinline,noclone))
foo (struct U *p, struct U *q)
{
int i;
q->s.j = 1;
i = p->s.i;
return i;
}
int main()
{
int *p = (int *)__builtin_alloca (sizeof (int) * 3);
p[1] = 0;
if (foo ((struct U *)(p + 1), (struct U *)p) != 1)
__builtin_abort ();
return 0;
}
fails on x86_64 with -O2 -fschedule-insns because scheduling exchanges
the store and the load.
[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959
--- Comment #40 from ro at CeBiTec dot Uni-Bielefeld.DE 2013-04-15 12:51:20 UTC ---
> --- Comment #39 from Jakub Jelinek 2013-04-12
> 16:13:20 UTC ---
> Can this be reproduced with 4.7.3, 4.8.0 or trunk?
At most on the 4.7 branch: the Tru64 UNIX port was obsoleted in 4.7 and
removed in 4.8.
That said, I've no idea how BUILD_CONFIG would end up as bootstrap-debug
on Tru64 UNIX. Even compiling the same source file twice produces
object files that aren't identical. That's the reason config.log has
gcc_cv_prog_cmp_skip='cmp --ignore-initial=16 $$f1 $$f2'
if GNU cmp is installed. compare-debug doesn't take this into account,
so if I manually run this code snippet from configure
if echo "int f (void) { return 0; }" > conftest.c &&
${CC} -c conftest.c &&
mv conftest.o conftest.o.g0 &&
${CC} -c -g conftest.c &&
mv conftest.o conftest.o.g &&
${srcdir}/contrib/compare-debug conftest.o.g0 conftest.o.g
then
echo bootstrap-debug
else
echo none
fi
with CC and srcdir set appropriately, I get none for CC=gcc-4.4 and CC=cc.
Please try this on your system and tell us how you end up with
bootstrap-debug instead of none.
Rainer
[Bug fortran/56919] [4.7/4.8/4.9 Regression] Wrong result for SYSTEM_CLOCK on Cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56919 --- Comment #6 from Tobias Burnus 2013-04-15 12:57:51 UTC --- Author: jb Date: Mon Apr 15 12:43:15 2013 New Revision: 197968 URL: http://gcc.gnu.org/viewcvs?rev=197968&root=gcc&view=rev Log: PR 56919 Improve SYSTEM_CLOCK intrinsic on Windows. frontend ChangeLog: 2013-04-15 Janne Blomqvist PR fortran/56919 * intrinsics.texi (SYSTEM_CLOCK): Update documentation. libgfortran ChangeLog: 2013-04-15 Janne Blomqvist PR fortran/56919 * intrinsics/time_1.h: Check __CYGWIN__ in addition to __MINGW32__. * intrinsics/system_clock.c (GF_CLOCK_MONOTONIC): Check _POSIX_MONOTONIC_CLOCK as well. (system_clock_4): Use GetTickCount on Windows. (system_clock_8): Use QueryPerformanceCounter and QueryPerformanceCounterFrequency on Windows. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/system_clock.c trunk/libgfortran/intrinsics/time_1.h Author: burnus Date: Mon Apr 15 12:51:20 2013 New Revision: 197970 URL: http://gcc.gnu.org/viewcvs?rev=197970&root=gcc&view=rev Log: 2013-04-15 Tobias Burnus * intrinsic.texi (SYSTEM_CLOCK): Recommend kind=8. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi
[Bug fortran/56816] ICE in delete_root
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56816 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #11 from Tobias Burnus 2013-04-15 12:59:44 UTC --- Author: mikael Date: Sun Apr 14 17:50:57 2013 New Revision: 197950 URL: http://gcc.gnu.org/viewcvs?rev=197950&root=gcc&view=rev Log: fortran/ PR fortran/56816 * match.c (gfc_match_select_type): Add syntax error. Move namespace allocation and cleanup... * parse.c (decode_statement): ... here. testsuite/ PR fortran/56816 * gfortran.dg/select_type_33.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/select_type_33.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/56962] [4.8/4.9 Regression] SLSR caused miscompilation of fftw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56962 --- Comment #2 from Bill Schmidt 2013-04-15 13:19:53 UTC --- The fix looks correct to me. Thanks!
[Bug c++/56966] New: [4.7 Regression] wrong warning with -Werror (wrong code without Werror?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56966 Bug #: 56966 Summary: [4.7 Regression] wrong warning with -Werror (wrong code without Werror?) Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org Created attachment 29874 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29874 preprocessed source seen when building OpenJDK-7 on x86_64-linux-gnu, no reduced test case yet. works with 4.6 and 4.8, and a 4.7 branch from march. trying to get one revision. g++-4.7 -fno-rtti -fno-exceptions -fcheck-new -fvisibility=hidden -g -O3 -fno-strict-aliasing -Werror -c g1BlockOffsetTable.ii In file included from /usr/include/string.h:638:0, from /scratch/packages/openjdk/7u15/openjdk-7-7u17-2.3.8/build/zerovm/openjdk/hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp:35, from /scratch/packages/openjdk/7u15/openjdk-7-7u17-2.3.8/build/zerovm/openjdk/hotspot/src/share/vm/utilities/globalDefinitions.hpp:33, from /scratch/packages/openjdk/7u15/openjdk-7-7u17-2.3.8/build/zerovm/openjdk/hotspot/src/share/vm/utilities/debug.hpp:29, from /scratch/packages/openjdk/7u15/openjdk-7-7u17-2.3.8/build/zerovm/openjdk/hotspot/src/share/vm/runtime/globals.hpp:28, from /scratch/packages/openjdk/7u15/openjdk-7-7u17-2.3.8/build/zerovm/openjdk/hotspot/src/share/vm/memory/allocation.hpp:28, from /scratch/packages/openjdk/7u15/openjdk-7-7u17-2.3.8/build/zerovm/openjdk/hotspot/src/share/vm/memory/memRegion.hpp:28, from /scratch/packages/openjdk/7u15/openjdk-7-7u17-2.3.8/build/zerovm/openjdk/hotspot/src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp:28, from /scratch/packages/openjdk/7u15/openjdk-7-7u17-2.3.8/build/zerovm/openjdk/hotspot/src/share/vm/gc_implementation/g1/g1BlockOffsetTable.inline.hpp:28, from /scratch/packages/openjdk/7u15/openjdk-7-7u17-2.3.8/build/zerovm/openjdk/hotspot/src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp:26: In function 'void* memset(void*, int, size_t)', inlined from 'void G1BlockOffsetSharedArray::_ZN24G1BlockOffsetSharedArray16set_offset_arrayEmmh.isra.8(unsigned char*, size_t, size_t, unsigned char)' at /scratch/packages/openjdk/7u15/openjdk-7-7u17-2.3.8/build/zerovm/openjdk/hotspot/src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp:169:52, inlined from 'void G1BlockOffsetArray::set_remainder_to_point_to_start_incl(size_t, size_t)' at /scratch/packages/openjdk/7u15/openjdk-7-7u17-2.3.8/build/zerovm/openjdk/hotspot/src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp:195:67, inlined from 'void G1BlockOffsetArray::_ZN18G1BlockOffsetArray31set_remainder_to_point_to_startEP8HeapWordS1_.part.55(HeapWord*, HeapWord*)' at /scratch/packages/openjdk/7u15/openjdk-7-7u17-2.3.8/build/zerovm/openjdk/hotspot/src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp:168:61, inlined from 'void G1BlockOffsetArray::set_remainder_to_point_to_start(HeapWord*, HeapWord*)' at /scratch/packages/openjdk/7u15/openjdk-7-7u17-2.3.8/build/zerovm/openjdk/hotspot/src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp:369:1, inlined from 'void G1BlockOffsetArray::alloc_block_work2(HeapWord**, size_t*, HeapWord*, HeapWord*)' at /scratch/packages/openjdk/7u15/openjdk-7-7u17-2.3.8/build/zerovm/openjdk/hotspot/src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp:510:53, inlined from 'HeapWord* G1BlockOffsetArray::forward_to_block_containing_addr_slow(HeapWord*, HeapWord*, const void*)' at /scratch/packages/openjdk/7u15/openjdk-7-7u17-2.3.8/build/zerovm/openjdk/hotspot/src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp:394:59: /usr/include/x86_64-linux-gnu/bits/string3.h:81:32: error: call to '__warn_memset_zero_len' declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [-Werror] /usr/include/x86_64-linux-gnu/bits/string3.h:81:32: error: call to '__warn_memset_zero_len' declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [-Werror] /usr/include/x86_64-linux-gnu/bits/string3.h:81:32: error: call to '__warn_memset_zero_len' declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [-Werror] /usr/include/x86_64-linux-gnu/bits/string3.h:81:32: error: call to '__warn_memset_zero_len' declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [-Werror] /usr/include/x86_64-linux-gnu/bits/string3.h:81:32: error: call to
[Bug target/56967] New: Add build exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56967 Bug #: 56967 Summary: Add build exception Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ys...@users.sourceforge.jp Add SH2 and SH2A little-endian exception for sh-*-linux target.
[Bug target/56967] Add build exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56967 --- Comment #1 from Yoshinori Sato 2013-04-15 13:39:23 UTC --- Add exceptions.
[Bug fortran/56968] New: Issue with a procedure defined with a generic name returning procedure pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56968 Bug #: 56968 Summary: Issue with a procedure defined with a generic name returning procedure pointer Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: samuel.debio...@ujf-grenoble.fr Created attachment 29875 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29875 Test case that shows the bug In short, a genericly named procedure fails to return a procedure pointer : ptr => specific_name_get_proc_ptr()! OK ptr => generic_name_get_proc_ptr() ! KO 1 Error: Interface mismatch in procedure pointer assignment at (1): Type/rank mismatch in return value of 'generic_name_get_proc_ptr' Attached is a test case that show the problem with gfortran 4.7, 4.8 and trunk. See http://gcc.gnu.org/ml/fortran/2013-04/msg00151.html for the complete story.
[Bug tree-optimization/56933] [4.9 Regression] Vectorizer missing read-write dependency for interleaved accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56933 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Biener 2013-04-15 14:09:14 UTC --- Author: rguenth Date: Mon Apr 15 14:08:41 2013 New Revision: 197972 URL: http://gcc.gnu.org/viewcvs?rev=197972&root=gcc&view=rev Log: 2013-04-15 Richard Biener PR tree-optimization/56933 * tree-vectorizer.h (struct _stmt_vec_info): Remove read_write_dep member. (GROUP_READ_WRITE_DEPENDENCE): Remove. (STMT_VINFO_GROUP_READ_WRITE_DEPENDENCE): Likewise. * tree-vect-data-refs.c (vect_analyze_group_access): Move dependence check ... vect_analyze_data_ref_dependence (vect_analyze_data_ref_dependence): ... here. * tree-vect-stmts.c (new_stmt_vec_info): Do not initialize GROUP_READ_WRITE_DEPENDENCE. * gcc.dg/vect/pr56933.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr56933.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-stmts.c trunk/gcc/tree-vectorizer.h
[Bug fortran/56969] New: ISO_C_BINDING regression with current trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56969 Bug #: 56969 Summary: ISO_C_BINDING regression with current trunk Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sfilipp...@uniroma2.it Created attachment 29876 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29876 test case Hi, Attached code works with 4.8, fails with trunk. Salvatore - [sfilippo@jacobi BugCBind]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu48/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8.0/configure --prefix=/usr/local/gnu48 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc Thread model: posix gcc version 4.8.0 (GCC) [sfilippo@jacobi BugCBind]$ gfortran -c tst_cbind.f90 [sfilippo@jacobi BugCBind]$ [sfilippo@jacobi BugCBind]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu49/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc : (reconfigured) ../gcc/configure --prefix=/usr/local/gnu49 --enable-languages=c,c++,fortran --with-gmp=/home/travel/GNUBUILD/gmp --with-mpfr=/home/travel/GNUBUILD/mpfr --with-mpc=/home/travel/GNUBUILD/mpc Thread model: posix gcc version 4.9.0 20130411 (experimental) (GCC) [sfilippo@jacobi BugCBind]$ gfortran -c tst_cbind.f90 tst_cbind.f90:57.18: if (c_associated(a%deviceMat%Mat)) then 1 Error: Name 'c_associated' at (1) is an ambiguous reference to 'c_associated' from module '__iso_c_binding' tst_cbind.f90:59.5: end if 1 Error: Expecting END SUBROUTINE statement at (1) [sfilippo@jacobi BugCBind]$
[Bug c++/56970] New: SFINAE does not apply correctly to sizeof.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56970
Bug #: 56970
Summary: SFINAE does not apply correctly to sizeof.
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: yufanyu...@gmail.com
This code compiles with g++ 4.7.3, clang 3.2, but not g++ 4.8.
Error is:
In substitution of ‘template static constexpr int
has::test(decltype (sizeof (C:: x))) [with C = C; T = foo] [with C = foo]’:
required from ‘const int foobar::value’
required from here
error: invalid use of non-static member function ‘int foo::x()’
#include
#include
template
struct has {
template
constexpr static int test(...) {
return 0;
}
template
constexpr static int test(decltype(sizeof(C::x))) { // Doesn't compile.
return 1; // Is a member variable.
}
template x()))>
constexpr static int test(int) {
return 2; // Is a member function.
}
static const int value = test(0);
};
struct foo {
int x();
};
struct bar {
int x;
};
int main() {
std::cout << has::value << std::endl;
std::cout << has::value << std::endl;
std::cout << has::value << std::endl;
}
[Bug tree-optimization/56935] Basic block is not SLP-vectorizeed after r197635.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56935
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #3 from Richard Biener 2013-04-15
14:38:40 UTC ---
Reduced testcase:
typedef struct {
long int x;
long int y;
} S;
void foo (S *s)
{
s->x--;
s->y--;
}
Difference in cost model analysis:
before:
t.c:7: note: Cost model analysis:
Vector inside of basic block cost: 5
Vector prologue cost: 0
Vector epilogue cost: 0
Scalar cost of basic block: 6
after:
t.c:7: note: Cost model analysis:
Vector inside of basic block cost: 5
Vector prologue cost: 1
Vector epilogue cost: 0
Scalar cost of basic block: 6
after is more correct, as we need to synthesize the { 1, 1 } vector.
what isn't really optimal is the unchanged vector inside cost.
It's an unaligned load with cost 2, the vector operation with cost 1
and the unaligned store with cost 2.
Before we generated
pcmpeqd %xmm0, %xmm0
movdqu (%rdi), %xmm1
paddq %xmm1, %xmm0
movdqu %xmm0, (%rdi)
ret
and afterwards
subq$1, (%rdi)
subq$1, 8(%rdi)
I'd say it's obvious that the non-vectorized variant is better.
So, are you sure _this_ basic-block is really the issue?
[Bug fortran/56969] [4.9 Regression] ISO_C_BINDING regression with current trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56969 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-15 CC||bur...@net-b.de Summary|ISO_C_BINDING regression|[4.9 Regression] |with current trunk |ISO_C_BINDING regression ||with current trunk Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres 2013-04-15 14:40:14 UTC --- Revision 196819 (2013-03-20) is OK, while revision 197238 (2013-03-29) gives the error. I suspect revision 197053 (CCed Tobias).
[Bug fortran/56968] [F03] Issue with a procedure defined with a generic name returning procedure pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56968
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Keywords||rejects-valid
Last reconfirmed||2013-04-15
CC||janus at gcc dot gnu.org
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
Summary|Issue with a procedure |[F03] Issue with a
|defined with a generic name |procedure defined with a
|returning procedure pointer |generic name returning
||procedure pointer
--- Comment #1 from janus at gcc dot gnu.org 2013-04-15 14:44:25 UTC ---
Here is a draft patch which fixes the behavior for the test case:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 197943)
+++ gcc/fortran/expr.c(working copy)
@@ -3540,7 +3540,11 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_ex
}
else if (rvalue->expr_type == EXPR_FUNCTION)
{
- s2 = rvalue->symtree->n.sym->result;
+ if (rvalue->symtree->n.sym->attr.generic)
+s2 = rvalue->value.function.esym->result;
+ else
+s2 = rvalue->symtree->n.sym->result;
+
name = s2->name;
}
else
Regtesting now ...
[Bug rtl-optimization/56921] [4.9 Regression] ICE in rtx_cost called by doloop_optimize_loops for PPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56921 --- Comment #11 from Richard Biener 2013-04-15 14:46:49 UTC --- Created attachment 29877 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29877 patch papering over the issue with TODO_do_not_ggc_collect Patch papering over (restoring non-GC collect) attached. Not exactly the best solution as garbage is then again not collected during the in some cases memory expensive passes.
[Bug other/56955] documentation for attribute malloc contradicts itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955
--- Comment #4 from Dan Gohman 2013-04-15 14:53:06
UTC ---
(In reply to comment #3)
> Well, it _is_ actually about the content. There must be no way to compute
> a valid pointer to another object from the contents of the pointed-to
> memory.
Oh wow. That's a subtlety that completely escaped me.
> So if you initialize the memory to {0, 1, 2, 3, 4 ...} thus
> every possible byte value is somewhere and then do
>
> void *p = (void *)(mem[3] << 24 | mem[58] << 16 | ...);
>
> then points-to analysis assumes that from the contents of 'mem' you
> can only compute pointers to nothing (NULL).
Is that example fundamentally different than something like this:
void *q = (void *)(mem[0] + 0xb1ab1ab1a);
In both cases, the information of the pointer value is in the expression, not
in the memory.
Is it the case that the memory must be either actually zeros or uninitialized?
Or could it contain other data which merely transmits no information about
pointer values?
> Technically for targets
> where NULL is a valid poiner to an object calloc () may not be marked
> with malloc.
>
> That is, read it in the way that the code assumes the memory _may_ be
> zero-initialized (but only zero-initialized) or uninitialized.
If this is what it means, then I request that the text be updated to say this.
I'd be willing to propose a wording, once I understand the intent, if that'd be
helpful.
What should we say about the fact that GLIBC uses the malloc attribute on
strdup (and similar things)? strdup actually could be used to transmit
information about pointer values.
[Bug fortran/56969] [4.9 Regression] ISO_C_BINDING regression with current trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56969 Tobias Burnus changed: What|Removed |Added Keywords||rejects-valid CC|bur...@net-b.de |burnus at gcc dot gnu.org Target Milestone|--- |4.9.0 --- Comment #2 from Tobias Burnus 2013-04-15 14:53:36 UTC --- Workaround: module extd_mat_mod ! use iso_c_binding ! << comment this line Or alternatively: use test_mod, only: s_Cmat ! <<< add "only:" The problem seems to be that the indirectly imported function "c_associated" does not seem to get recognized as being the same as the indirectly imported one.
[Bug tree-optimization/56935] Basic block is not SLP-vectorizeed after r197635.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56935 --- Comment #4 from Yuri Rumyantsev 2013-04-15 14:54:50 UTC --- Richard, both subq's are accessed the same cash line and it means that after 1st store tthe 2nd load will stall till finish updating data cash (this is not exact explanation but if you'd like I can find out more strong and correct definition of memory conflict). In result non-vectorizable code will run much slower adn we saw such slowdown on 253.perl from cpu2000.
[Bug tree-optimization/56962] [4.8/4.9 Regression] SLSR caused miscompilation of fftw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56962
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution||FIXED
--- Comment #3 from Jakub Jelinek 2013-04-15
15:02:43 UTC ---
Author: jakub
Date: Mon Apr 15 14:56:36 2013
New Revision: 197978
URL: http://gcc.gnu.org/viewcvs?rev=197978&root=gcc&view=rev
Log:
PR tree-optimization/56962
* gimple-ssa-strength-reduction.c (record_increment): Only set
initializer if gimple_assign_rhs_code is {,POINTER_}PLUS_EXPR and
either rhs1 or rhs2 is equal to c->base_expr.
* gcc.c-torture/execute/pr56962.c: New test.
Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr56962.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c
trunk/gcc/testsuite/ChangeLog
Author: jakub
Date: Mon Apr 15 15:00:06 2013
New Revision: 197979
URL: http://gcc.gnu.org/viewcvs?rev=197979&root=gcc&view=rev
Log:
PR tree-optimization/56962
* gimple-ssa-strength-reduction.c (record_increment): Only set
initializer if gimple_assign_rhs_code is {,POINTER_}PLUS_EXPR and
either rhs1 or rhs2 is equal to c->base_expr.
* gcc.c-torture/execute/pr56962.c: New test.
Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr56962.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/gimple-ssa-strength-reduction.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/56968] [F03] Issue with a procedure defined with a generic name returning procedure pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56968 --- Comment #2 from Dominique d'Humieres 2013-04-15 15:02:48 UTC --- For the record, gfortran 4.4.6 compiles the test, but not 4.5.3, 4.6.4, 4.7.3, 4.8.0, and trunk.
[Bug c++/56970] SFINAE does not apply correctly to sizeof.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56970 Fan Yu changed: What|Removed |Added Severity|normal |major
[Bug rtl-optimization/56921] [4.9 Regression] ICE in rtx_cost called by doloop_optimize_loops for PPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56921 --- Comment #12 from ktkachov at gcc dot gnu.org 2013-04-15 15:26:10 UTC --- (In reply to comment #11) > Created attachment 29877 [details] > patch papering over the issue with TODO_do_not_ggc_collect > > Patch papering over (restoring non-GC collect) attached. Not exactly the > best solution as garbage is then again not collected during the in some > cases memory expensive passes. Fixes ICE while building libgfortran for arm-*-*. Also, no regressions on arm-none-eabi tested with qemu.
[Bug target/56890] invalid fdtox instruction in 64-bit mode with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56890 --- Comment #12 from Rainer Jung 2013-04-15 15:34:42 UTC --- I tried the sparc.c patch on top of GCC 4.7.3 and it works. Thanks for fixing :)
[Bug c++/56971] New: GCC claims a friend function to be overloaded, but it isn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56971
Bug #: 56971
Summary: GCC claims a friend function to be overloaded, but it
isn't
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: henn...@still-hidden.de
template
class rp {
};
template class P>
struct b {
template class FriendP>
friend void f(b from);
};
template class P>
void f(b from) {
}
int main() {
b v;
f(v);
return 0;
}
-
> gcc map.cpp
main.cpp: In function 'int main()':
main.cpp:17:13: error: call of overloaded 'f(b&)' is ambiguous
f(v);
^
main.cpp:17:13: note: candidates are:
main.cpp:12:6: note: void f(b) [with = int; P = rp]
void f(b from) {
^
main.cpp:8:17: note: void f(b) [with = int;
FriendP = rp; P = rp]
friend void f(b from);
^
-
I can't see an overload here.
[Bug c++/56971] GCC claims a friend function to be overloaded, but it isn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56971 --- Comment #1 from henn...@still-hidden.de 2013-04-15 16:19:21 UTC --- > gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/src/gcc-4.8-20130411/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-install-libiberty --disable-multilib --disable-libssp --disable-werror --enable-checking=release Thread model: posix gcc version 4.8.0 20130411 (prerelease) (GCC)
[Bug c/56972] New: Missing "may be used uninitialized" warning for "obvious" uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56972
Bug #: 56972
Summary: Missing "may be used uninitialized" warning for
"obvious" uninitialized
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Google ref: b/8616613
// t.c
int f(int x)
{
int ret;
switch (x) {
case 3:
ret = 0;
break;
}
return ret;
}
int main()
{
return f(2);
}
gcc -c -Wall -Wextra t.c
# no output
gcc -c -Wall -Wextra -O2 t.c
# no output
[Bug c/56972] Missing "may be used uninitialized" warning for "obvious" uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56972 Paul Pluzhnikov changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/56970] SFINAE does not apply correctly to sizeof.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56970 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jakub Jelinek 2013-04-15 16:50:36 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190830 By using __builtin_printf or static_assert one can avoid all the includes.
[Bug fortran/56968] [4.7/4.8/4.9 Regression] [F03] Issue with a procedure defined with a generic name returning procedure pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56968 janus at gcc dot gnu.org changed: What|Removed |Added Summary|[F03] Issue with a |[4.7/4.8/4.9 Regression] |procedure defined with a|[F03] Issue with a |generic name returning |procedure defined with a |procedure pointer |generic name returning ||procedure pointer --- Comment #3 from janus at gcc dot gnu.org 2013-04-15 17:15:51 UTC --- (In reply to comment #2) > For the record, gfortran 4.4.6 compiles the test, but not 4.5.3, 4.6.4, 4.7.3, > 4.8.0, and trunk. Oh, so it's even a regression. The 4.5 and 4.6 branches have been closed by now, I think, but we should probably backport to 4.7 and 4.8.
[Bug fortran/56968] [4.7/4.8/4.9 Regression] [F03] Issue with a procedure defined with a generic name returning procedure pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56968 --- Comment #4 from janus at gcc dot gnu.org 2013-04-15 17:16:50 UTC --- (In reply to comment #1) > Regtesting now ... Completed successfully. Will commit to trunk as obvious ...
[Bug c++/56966] [4.7 Regression] wrong warning with -Werror (wrong code without Werror?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56966
--- Comment #1 from Andrew Pinski 2013-04-15
17:34:20 UTC ---
I don't think this is wrong code at all. The warning is correct for the code
as given but wrong for memset in general.
The code looks like:
void set_offset_array(size_t left, size_t right, u_char offset) {
;
;
size_t num_cards = right - left + 1;
memset(&_offset_array[left], offset, num_cards);
}
num_cards is being turned into 0 which is fine in this case as optimization has
happened. The problem is the memset code is just bogus when it tries to see if
the length is 0.
[Bug fortran/56968] [4.7/4.8/4.9 Regression] [F03] Issue with a procedure defined with a generic name returning procedure pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56968
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #5 from Tobias Burnus 2013-04-15
17:35:57 UTC ---
(In reply to comment #1)
> Index: gcc/fortran/expr.c
> ===
> --- gcc/fortran/expr.c(revision 197943)
> +++ gcc/fortran/expr.c(working copy)
> @@ -3540,7 +3540,11 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_ex
> }
>else if (rvalue->expr_type == EXPR_FUNCTION)
> {
> - s2 = rvalue->symtree->n.sym->result;
> + if (rvalue->symtree->n.sym->attr.generic)
> +s2 = rvalue->value.function.esym->result;
> + else
> +s2 = rvalue->symtree->n.sym->result;
I think you should directly use
if (rvalue->value.function.esym)
s2 = rvalue->value.function.esym->result;
I was additionally wondering whether one should also take care of isym besides
esym, but probably no intrinsic returns a pointer.
[Bug rtl-optimization/56605] Redundant branch introduced during loop2 phases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56605 Bill Schmidt changed: What|Removed |Added AssignedTo|unassigned at gcc dot |wschmidt at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.1 --- Comment #4 from Bill Schmidt 2013-04-15 18:32:53 UTC --- This was fixed in trunk on 2013-03-20. Now that it's burned in for a few weeks, I'll plan to fix it in 4.8.1 shortly, provided there are no objections.
[Bug c++/56973] New: crash when capturing variables in nested lambdas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56973
Bug #: 56973
Summary: crash when capturing variables in nested lambdas
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dirkmoerm...@gmail.com
The valid C++11 program below segfaults on my machine:
=
#include
#include
#include
void test(const char* s)
{
constexpr /*static*/ struct {const char* s;} ar[]={
{"e4"},
{"e5"},
{"Nf3"},
{"Nc6"},
{"Bb5"},
{"a6"}
};
auto it=std::begin(ar);
auto compare=[&it](const char* s)
{
assert(std::strcmp(it->s,s)==0);
};
auto test=[&](const char* s)
{
it=std::begin(ar);
compare(s);
};
test(s);
}
int main(int argc, const char* argv[])
{
test(argv[1]);
test(argv[2]);
test(argv[3]);
return 0;
}
=
I compile with: $ g++ -g -O --std=c++11 bug.cc.
I run as: $ ./a.out e4 e4 e4
My machine is a 64 bit linux intel core duo 2 (T4200).
If I make "ar" static the program passes, so I assume that ar is overwritten
prematurely on the stack.
The error only occurs from optimization-levels "-O" onwards.
[Bug fortran/56968] [4.7/4.8/4.9 Regression] [F03] Issue with a procedure defined with a generic name returning procedure pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56968
--- Comment #6 from janus at gcc dot gnu.org 2013-04-15 18:35:56 UTC ---
(In reply to comment #5)
> (In reply to comment #1)
> > Index: gcc/fortran/expr.c
> > ===
> > --- gcc/fortran/expr.c(revision 197943)
> > +++ gcc/fortran/expr.c(working copy)
> > @@ -3540,7 +3540,11 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_ex
> > }
> >else if (rvalue->expr_type == EXPR_FUNCTION)
> > {
> > - s2 = rvalue->symtree->n.sym->result;
> > + if (rvalue->symtree->n.sym->attr.generic)
> > +s2 = rvalue->value.function.esym->result;
> > + else
> > +s2 = rvalue->symtree->n.sym->result;
>
> I think you should directly use
>
> if (rvalue->value.function.esym)
> s2 = rvalue->value.function.esym->result;
yes, I also thought about this variant. Might indeed be the better choice.
> I was additionally wondering whether one should also take care of isym besides
> esym, but probably no intrinsic returns a pointer.
I could not find any intrinsic function which returns a pointer, and even less
so a procedure pointer (which is what this patch is dealing with).
[Bug c/56972] Missing "may be used uninitialized" warning for "obvious" uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56972 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Manuel López-Ibáñez 2013-04-15 18:46:59 UTC --- Infamous PR18501. With: ~/test1/197214/build/gcc/cc1 -Wall -Wextra -O1 pr56972.c -fdump-tree-all-lineno you can see that pr56972.c.020t.copyrename1 contains the uninit use but pr56972.c.021t.ccp1 has removed it. *** This bug has been marked as a duplicate of bug 18501 ***
[Bug tree-optimization/18501] [4.7/4.8/4.9 Regression] Missing 'used uninitialized' warning (CCP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 Manuel López-Ibáñez changed: What|Removed |Added CC||ppluzhnikov at google dot ||com --- Comment #61 from Manuel López-Ibáñez 2013-04-15 18:46:59 UTC --- *** Bug 56972 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/56921] [4.9 Regression] ICE in rtx_cost called by doloop_optimize_loops for PPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56921 --- Comment #13 from Pat Haugen 2013-04-15 19:37:27 UTC --- (In reply to comment #12) > (In reply to comment #11) > > Created attachment 29877 [details] > > patch papering over the issue with TODO_do_not_ggc_collect > > > > Patch papering over (restoring non-GC collect) attached. Not exactly the > > best solution as garbage is then again not collected during the in some > > cases memory expensive passes. > > Fixes ICE while building libgfortran for arm-*-*. > Also, no regressions on arm-none-eabi tested with qemu. This also fixes the testsuite failures and numerous spec build failures on powerpc.
[Bug debug/56974] New: c++ ref qualifiers not represented in DWARF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56974 Bug #: 56974 Summary: c++ ref qualifiers not represented in DWARF Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: tro...@gcc.gnu.org C++11 added ref qualifiers for methods like "&" and "&&". As far as I can tell these are not present in the debuginfo. I think they ought to be represented somehow; otherwise gdb can't implement overloading properly.
[Bug rtl-optimization/55414] spec2006 416.gamess compilation fails on LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55414 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Steven Bosscher 2013-04-15 23:02:06 UTC --- .
[Bug lto/51432] [4.6 regression] ICE in -flto -std=c++0x -g with cross-compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51432 --- Comment #5 from Tomohiro Kashiwada 2013-04-16 03:33:22 UTC --- no problem at gcc-4.7.3. it works fine. $ rx-elf-g++ -v Using built-in specs. COLLECT_GCC=rx-elf-g++ COLLECT_LTO_WRAPPER=/home/kikairoya/rx/libexec/gcc/rx-elf/4.7.3/lto-wrapper Target: rx-elf Configured with: /home/kikairoya/sources/gcc-4.7.3/configure --prefix=/home/kikairoya/rx --target=rx-elf --disable-nls --enable-target-optspace --with-newlib --enable-languages=c,c++ --without-ppl --enable-checking=release Thread model: single gcc version 4.7.3 (GCC) $ rx-elf-g++ -flto -std=c++0x -g -xc++ /dev/null -include functional /home/kikairoya/rx/lib/gcc/rx-elf/4.7.3/../../../../rx-elf/lib/crt0.o: In function `L0': /home/kikairoya/sources/newlib-1.20.0/libgloss/rx/crt0.S:77: undefined reference to `_main' /home/kikairoya/rx/lib/gcc/rx-elf/4.7.3/../../../../rx-elf/bin/ld: /home/kikairoya/rx/lib/gcc/rx-elf/4.7.3/../../../../rx-elf/lib/crt0.o(P): error: call to undefined function '_main' collect2: error: ld returned 1 exit status
[Bug target/56897] unaligned memory access on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56897 --- Comment #4 from Martynas Venckus 2013-04-16 04:11:52 UTC --- Hi, (In reply to comment #3) > Please create a self-sufficient executable testcase, following the > instructions > at [1]. I was not able to confirm the problem from the lines you posted. Thanks for the feedback, Uros. Did you try it together with the frame growing downwards diff posted in #56898? If so, the locals are actually at the negative offsets and unaligned loads like foo%8-5 will expose this, instead of foo%8-1. I'm attaching the ab-pre.tgz (before the diff) and ab-post.tgz (after the diff) which exercise both frame growing upwards and downwards; RTL dumps included. Feel free to turn it into a testcase (I can't do that at the moment). I'm 100% busy at work this week, so I would appreciate if you took care of this (and #56898). Otherwise, I'll follow up with the official contribution guidelines in the weekend. Martynas.
[Bug target/56897] unaligned memory access on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56897 --- Comment #5 from Martynas Venckus 2013-04-16 04:16:39 UTC --- Created attachment 29878 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29878 ab-pre.tgz > gcc a.c; ./a.out 0d0a 0d0a0401 0d0a0401 > gcc -O a.c; ./a.out 0d0a 0d0a0400 0d0a0400 > cp a.c b.c > gcc -S -dall a.c > gcc -O -S -dall b.c
[Bug target/56897] unaligned memory access on alpha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56897 --- Comment #6 from Martynas Venckus 2013-04-16 04:18:16 UTC --- Created attachment 29879 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29879 ab-post.tgz > gcc a.c; ./a.out 0d0a 0d0a0401 0d0a0401 > gcc -O a.c; ./a.out 0d0a 0d0a0401 0d0a0401 > cp a.c b.c > gcc -S -dall a.c > gcc -O -S -dall b.c
[Bug middle-end/56934] ICE folding a COND_EXPR involving vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56934 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-16 CC||mpolacek at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.8.0, 4.9.0 --- Comment #1 from Marek Polacek 2013-04-16 05:09:52 UTC --- Confirmed with trunk/4.8.
[Bug lto/51432] [4.6 regression] ICE in -flto -std=c++0x -g with cross-compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51432 Jakub Jelinek changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|4.6.4 |4.7.3 --- Comment #6 from Jakub Jelinek 2013-04-16 05:55:08 UTC --- Fixed in 4.7.3 then.
