[Bug middle-end/51285] [4.7 Regression] internal compiler error: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51285 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |irar at il dot ibm.com |gnu.org | --- Comment #7 from Ira Rosen irar at il dot ibm.com 2011-12-04 10:50:41 UTC --- Created attachment 25985 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25985 patch
[Bug middle-end/51351] undefined reference to __sync_fetch_and_ior_4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51351 --- Comment #1 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-12-04 11:15:30 UTC --- Author: rsandifo Date: Sun Dec 4 11:15:26 2011 New Revision: 181985 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181985 Log: gcc/ PR middle-end/51351 * optabs.c (init_sync_libfuncs): Use or rather than ior in the external names. Modified: trunk/gcc/ChangeLog trunk/gcc/optabs.c
[Bug bootstrap/51240] [4.7] fortran bootstrap failure due to non-static dt_lower_string and dt_upper_string lacking prototypes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51240 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2011-12-04 11:31:39 UTC --- Fixed by r181881: http://gcc.gnu.org/ml/gcc-cvs/2011-12/msg00017.html
[Bug middle-end/51351] undefined reference to __sync_fetch_and_ior_4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51351 Kazumoto Kojima kkojima at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-12-04 11:45:25 UTC --- Thanks for the quick fix!
[Bug libfortran/51407] New: Use of BOZ edit descriptors to edit real and complex data and F2008
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51407 Bug #: 51407 Summary: Use of BOZ edit descriptors to edit real and complex data and F2008 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: bur...@net-b.de, jvdeli...@gcc.gnu.org, thenl...@users.sourceforge.net Consider the following code (borrowed from Iain Sandoe): real(kind=16) :: x character(len=32) :: str1 x = 1.0_16 + 2.0_16**(-105) write (str1,'(z32)') x print *, str1 end Without any -std=xx the executable outputs (on x86_64-apple-darwin10): 3FFF0080 With -std=xx, xx in f95, f2003, and f2008, it ouputs At line 4 of file boz_real.f90 Fortran runtime error: Expected INTEGER for item 1 in formatted transfer, got REAL (z32) ^ Altough the standards state 10.5.1 Numeric editing The I, B, O, Z, F, E, EN, ES, D, and G edit descriptors may be used to specify the input/output of integer, real, and complex data. The following general rules apply: I think the use of BOZ edit descriptors to edit real and complex data is implicitly forbidden in f95 and f2003 by (f95) 10.5.1.2 Real and complex editing The F, E, EN, ES, and D edit descriptors specify the editing of real and complex data. An input/output list item corresponding to an F, E, EN, ES, or D edit descriptor shall be real or complex. The G edit descriptor also may be used to edit real and complex data (10.5.4.1.2). or (f2003) 10.6.1.2 Real and complex editing The F, E, EN, ES, and D edit descriptors specify the editing of real and complex data. An input/output list item corresponding to an F, E, EN, ES, or D edit descriptor shall be real or complex. The G edit descriptor also may be used to edit real and complex data (10.6.4.1.2). but explicitly allowed in f2008 by 10.7.2.3.1 General The F, E, EN, ES, and D edit descriptors specify the editing of real and complex data. An input/output list item corresponding to an F, E, EN, ES, or D edit descriptor shall be real or complex. The G, B, O, and Z edit descriptors also may be used to edit real and complex data (10.7.5.2.2, 10.7.2.4). Is this reading of the standards correct?
[Bug target/51393] Wrong parameter type for _mm256_insert_epi64 in avxintrin.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51393 --- Comment #4 from uros at gcc dot gnu.org 2011-12-04 12:47:28 UTC --- Author: uros Date: Sun Dec 4 12:47:25 2011 New Revision: 181986 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181986 Log: PR target/51393 * config/i386/avxintrin.h (_mm256_insert_epi64): Declare second parameter as long long. testsuite/ChangeLog: 2011-12-04 Uros Bizjak ubiz...@gmail.com Jérémie Detrey jeremie.det...@loria.fr PR target/51393 * gcc.target/i386/pr51393.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr51393.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avxintrin.h trunk/gcc/testsuite/ChangeLog
[Bug target/51393] Wrong parameter type for _mm256_insert_epi64 in avxintrin.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51393 Jérémie Detrey Jeremie.Detrey at loria dot fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Jérémie Detrey Jeremie.Detrey at loria dot fr 2011-12-04 12:51:53 UTC --- Perfect, thank you very much!
[Bug target/51408] New: Miscompilation in arm.md:*minmax_arithsi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51408
Bug #: 51408
Summary: Miscompilation in arm.md:*minmax_arithsi
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: k...@gcc.gnu.org
The following testcase, reduced from efgcvt_r.c:fcvt_r in glibc, gets
miscompiled:
extern void abort (void);
int __attribute__((noinline))
foo (int a, int b)
{
int max = (b 0) ? b : 0;
return max - a;
}
int
main (void)
{
if (foo (3, -1) != -3)
abort ();
return 0;
}
arm-none-eabi-gcc -O1 generates:
foo:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
cmpr1, #0
rsbger0, r0, r1
bxlr
This would be equivalent to:
return b = 0 ? b - a : a;
which is different from:
return b = 0 ? b - a : -a;
That is, in assembly code, we should have an else clause like so:
cmpr1, #0
rsbger0, r0, r1 - then clause
rsbltr0, r0, #0 - else clause
bxlr
This bug comes from gcc/config/arm/arm.md:*minmax_arithsi, not
outputting an else clause on the MINUS case.
I've tested a patch and will post it shortly.
[Bug target/51393] Wrong parameter type for _mm256_insert_epi64 in avxintrin.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51393 --- Comment #6 from uros at gcc dot gnu.org 2011-12-04 13:23:52 UTC --- Author: uros Date: Sun Dec 4 13:23:48 2011 New Revision: 181988 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181988 Log: PR target/51393 * config/i386/avxintrin.h (_mm256_insert_epi64): Declare second parameter as long long. testsuite/ChangeLog: PR target/51393 * gcc.target/i386/pr51393.c: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gcc.target/i386/pr51393.c Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/i386/avxintrin.h branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug target/51393] Wrong parameter type for _mm256_insert_epi64 in avxintrin.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51393 --- Comment #7 from uros at gcc dot gnu.org 2011-12-04 13:39:03 UTC --- Author: uros Date: Sun Dec 4 13:38:58 2011 New Revision: 181989 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181989 Log: PR target/51393 * config/i386/avxintrin.h (_mm256_insert_epi64): Declare second parameter as long long. testsuite/ChangeLog: PR target/51393 * gcc.target/i386/pr51393.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.target/i386/pr51393.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/avxintrin.h branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug target/51393] Wrong parameter type for _mm256_insert_epi64 in avxintrin.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51393 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86 URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-12/msg00272.htm ||l Target Milestone|--- |4.5.4 --- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2011-12-04 13:42:32 UTC --- .
[Bug c++/51392] Wrong code with -Os when __attribute__((__const__)) function returns structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51392 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2011-12-04 14:04:06 UTC --- I can reproduce the error on i686-linux with g++ 4.7-20111203, 4.6-20111202, and 4.5-20111201 at -Os/-O1. Works at -O0/-O3, -O2 varies. 4.4-2008 seems to work.
[Bug libgomp/51132] [4.7 Regression] FAIL: libgomp.graphite/force-parallel-[678].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51132
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011-12-04
Target Milestone|--- |4.7.0
Ever Confirmed|0 |1
--- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-12-04 14:25:31
UTC ---
Confirmed:
force-parallel-1.c:
Program received signal SIGSEGV, Segmentation fault.
0x004006d0 in parloop (N=1000) at force-parallel-1.c:3
3 void parloop (int N)
Missing separate debuginfos, use: debuginfo-install glibc-2.14.90-19.x86_64
libgcc-4.6.2-1.fc16.x86_64 libgomp-4.6.2-1.fc16.x86_64
(gdb) li
1 void abort (void);
2
3 void parloop (int N)
4 {
5 int i;
6 int x[1000];
7
8 for (i = 0; i N; i++)
9 x[i] = i + 3;
10
(gdb) disass
Dump of assembler code for function parloop:
0x004006a0 +0: push %r12
0x004006a2 +2: push %rbp
0x004006a3 +3: mov%edi,%ebp
0x004006a5 +5: push %rbx
0x004006a6 +6: sub$0x2625a10,%rsp
0x004006ad +13:test %edi,%edi
0x004006af +15:jle0x40071c parloop+124
0x004006b1 +17:lea-0x1(%rdi),%r12d
0x004006b5 +21:cmp$0x18f,%r12d
0x004006bc +28:jbe0x400728 parloop+136
0x004006be +30:lea0x10(%rsp),%rbx
0x004006c3 +35:mov$0x4,%edx
0x004006c8 +40:mov%rsp,%rsi
0x004006cb +43:mov$0x400760,%edi
= 0x004006d0 +48:mov%r12d,0x8(%rsp)
0x004006d5 +53:add$0x2,%ebp
0x004006d8 +56:mov%rbx,(%rsp)
0x004006dc +60:callq 0x400548 GOMP_parallel_start@plt
force-parallel-7.c:
Program received signal SIGSEGV, Segmentation fault.
0x00400671 in foo () at force-parallel-7.c:3
3 int foo(void)
Missing separate debuginfos, use: debuginfo-install glibc-2.14.90-19.x86_64
libgcc-4.6.2-1.fc16.x86_64 libgomp-4.6.2-1.fc16.x86_64
(gdb) li
1 #define N 500
2
3 int foo(void)
4 {
5 int i, j, k;
6 int A[N+5][N+5][N+5];
7
8 /* Loop i: carried no dependency. */
9 for (i = 0; i N; i++)
10 for (j = 0; j N; j++)
(gdb) disass
Dump of assembler code for function foo:
0x00400650 +0: push %r14
0x00400652 +2: mov$0x4,%edx
0x00400657 +7: mov$0x400780,%edi
0x0040065c +12:push %r13
0x0040065e +14:push %r12
0x00400660 +16:push %rbp
0x00400661 +17:push %rbx
0x00400662 +18:sub$0x1eb492d0,%rsp
0x00400669 +25:lea0x20(%rsp),%r13
0x0040066e +30:mov%rsp,%rsi
= 0x00400671 +33:mov%r13,(%rsp)
0x00400675 +37:callq 0x400500 GOMP_parallel_start@plt
force-parallel-8.c:
Program received signal SIGSEGV, Segmentation fault.
0x0040068d in foo () at force-parallel-8.c:3
3 int foo(void)
Missing separate debuginfos, use: debuginfo-install glibc-2.14.90-19.x86_64
libgcc-4.6.2-1.fc16.x86_64 libgomp-4.6.2-1.fc16.x86_64
(gdb) li
1 #define N 1500
2
3 int foo(void)
4 {
5 int i, j;
6 int x[N][N], y[N];
7
8 for (i = 0; i N; i++)
9 {
10y[i] = i;
(gdb) disass
Dump of assembler code for function foo:
0x00400650 +0: push %r14
0x00400652 +2: push %r13
0x00400654 +4: push %r12
0x00400656 +6: mov$0xa,%r12d
0x0040065c +12:push %rbp
0x0040065d +13:push %rbx
0x0040065e +14:xor%ebx,%ebx
0x00400660 +16:sub$0x896be0,%rsp
0x00400667 +23:lea0x17a0(%rsp),%r13
0x0040066f +31:lea0x30(%rsp),%r14
0x00400674 +36:lea0x7d0(%r13),%rbp
0x0040067b +43:nopl 0x0(%rax,%rax,1)
0x00400680 +48:mov$0x4,%edx
0x00400685 +53:mov%rsp,%rsi
0x00400688 +56:mov$0x400740,%edi
= 0x0040068d +61:mov%ebx,(%r14,%rbx,4)
0x00400691 +65:mov%bx,(%rsp)
0x00400695 +69:mov%r13,0x8(%rsp)
0x0040069a +74:callq 0x400500 GOMP_parallel_start@plt
force-parallel-6.c:
==28261== Memcheck, a memory error detector
==28261== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==28261== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==28261== Command: ./a.out
==28261==
==28261== Warning: client switching stacks? SP change: 0x7fefffc98 --
0x7fe85dab0
==28261== to suppress, use:
[Bug libgomp/48241] libgomp.graphite/force-parallel-1.c FAILs on Solaris 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48241 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Depends on||51132 --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-12-04 14:27:06 UTC --- Similar to PR 51132.
[Bug libgomp/51132] [4.7 Regression] FAIL: libgomp.graphite/force-parallel-[678].c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51132 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-04 14:39:46 UTC --- force-parallel-1.c needs more than 38MB on the stack, e.g. on Linux the default limit is usually 8 or 10MB. The other testcases have smaller needs, but still over 8MB or close to it, which with address space randomization adds to the problems.
[Bug middle-end/51285] [4.7 Regression] internal compiler error: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51285 --- Comment #8 from irar at gcc dot gnu.org 2011-12-04 14:52:06 UTC --- Author: irar Date: Sun Dec 4 14:52:01 2011 New Revision: 181990 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181990 Log: PR middle-end/51285 * tree-vect-loop.c (vect_create_epilog_for_reduction): Create exit phi nodes for outer loop in case of double reduction. Added: trunk/gcc/testsuite/gfortran.dg/vect/pr51285.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug target/51409] New: [avr] Build fails if configured for other languages than from c-family
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51409 Bug #: 51409 Summary: [avr] Build fails if configured for other languages than from c-family Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: build Severity: blocker Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gcc.gnu.org CC: eric.wedding...@atmel.com Target: avr There is no generic function to get the name of an address space. As avr.c needs the name for diagnostics, it uses c_addr_space_name which is only available if C frontend is linked and thus building the compiler for any language not in c-family will abort with a linker complaint for missing c_addr_space_name. Fix is to use C-only languages, e.g. configure with --disable-lto or apply the patch below.
[Bug target/51409] [avr] Build fails if configured for other languages than from c-family
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51409 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-12-04 15:14:39 UTC --- Created attachment 25986 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25986 addrspace-name.diff Patch against trunk r181773 as posted for review here: http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02574.html
[Bug target/51409] [avr] Build fails if configured for other languages than from c-family
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51409 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Keywords||patch Last reconfirmed||2011-12-04 CC||wiml at dot org Ever Confirmed|0 |1
[Bug c++/51406] [4.5/4.6/4.7 Regression][c++0x] Incorrect result of static_cast to rvalue reference to base class.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51406 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-12-04 15:26:07 UTC --- the conversions create unnecessary temporaries int a = static_castA(x).a; int b = static_castB(x).b; std::couta=a, b=bstd::endl; shows they have the same address
[Bug c++/51392] Wrong code with -Os when __attribute__((__const__)) function returns structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51392
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-12-04
15:50:40 UTC ---
__attribute__((__const__))
Vector3f pie_SurfaceNormal3fv(Vector3f a, Vector3f b)
{
return Vector3f(a.y*b.z - a.z*b.y, a.z*b.x - a.x*b.z, a.x*b.y - a.y*b.x);
}
I think it is illegal to use the const attribute when the C++ frontend
may elide the return value copy to being passed by invisible reference.
That way the middle-end sees a store to global memory which is a side-effect
that the const attribute does not allow (similar for pure btw.).
Note that the Vector3f() constructors are not const either but they are
both called from pie_SurfaceNormal3fv.
[Bug target/51390] Builtin changes on November 29th, broke recip-5.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51390 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-12-04 15:52:47 UTC --- On powerpc-apple-darwin9 (G5) at revision 181953, I see FAIL: gcc.target/powerpc/recip-5.c (internal compiler error) FAIL: gcc.target/powerpc/recip-5.c (test for excess errors) UNRESOLVED: gcc.target/powerpc/recip-5.c scan-assembler-times xvredp 4 UNRESOLVED: gcc.target/powerpc/recip-5.c scan-assembler-times xvresp 5 UNRESOLVED: gcc.target/powerpc/recip-5.c scan-assembler-times xsredp 2 UNRESOLVED: gcc.target/powerpc/recip-5.c scan-assembler-times fres 2 The ICE is [karma] f90/bug% gfc -mrecip=all -ffast-math -mcpu=power7 /opt/gcc/work/gcc/testsuite/gcc.target/powerpc/recip-5.c /opt/gcc/work/gcc/testsuite/gcc.target/powerpc/recip-5.c: In function 'd_recip': /opt/gcc/work/gcc/testsuite/gcc.target/powerpc/recip-5.c:12:39: error: Builtin function __builtin_recipdiv is not supported with the current options /opt/gcc/work/gcc/testsuite/gcc.target/powerpc/recip-5.c:12:39: internal compiler error: Bus error There was no failure for gcc.target/powerpc/recip-5.c at revision res-181782.
[Bug c++/51318] [4.7 Regression] segfault on Eigen3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51318 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-04 16:32:52 UTC --- For some reason, in mainline tsubst_template_arg (thus tsubst_expr - tsubst_copy_and_build, which crashes because TREE_TYPE (r) is null) handles an INDIRECT_REF (with a COND_EXPR as arg 0) instead of a COND_EXPR.
[Bug fortran/51383] [OOP] arrays of extended types break when associated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51383 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-04 16:33:52 UTC --- FIXED on the trunk (4.7). Thanks for the bug report!
[Bug debug/51410] New: duplicate variable DIE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51410
Bug #: 51410
Summary: duplicate variable DIE
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@gcc.gnu.org
CC: tro...@redhat.com
This used to confuse systemtap, it has been fixed by searching the symbol table
to find the address of a variable if no location description is available if
the var DIE is marked external. It can certainly be argued that systemtap
should just search harder and find the other var DIE that does contain a
location description. But it sure is confusing IMHO.
Given the following source code:
int x;
int main(int argc, char **argv)
{
return x;
}
compiled with gcc (GCC) 4.6.1 20110908 (Red Hat 4.6.1-9)
$ gcc -g -O2 -o /tmp/x x.c
produces the following .debug_info:
DWARF section [28] '.debug_info' at offset 0x6a5:
[Offset]
Compilation unit at offset 0:
Version: 3, Abbreviation section offset: 0, Address size: 4, Offset size: 4
[ b] compile_unit
producer (strp) GNU C 4.6.1 20110908 (Red Hat 4.6.1-9)
language (data1) ISO C89 (1)
name (string) x.c
comp_dir (strp) /home/mark/src/tests
ranges (data4) range list [ 0]
low_pc (addr) 00
entry_pc (addr) 00
stmt_list(data4) 0
[29]subprogram
external (flag) Yes
name (strp) main
decl_file(data1) 1
decl_line(data1) 3
prototyped (flag) Yes
type (ref4) [61]
low_pc (addr) 0x080482e0 main
high_pc (addr) 0x080482e6
frame_base (block1) [ 0] call_frame_cfa
sibling (ref4) [61]
[44] formal_parameter
name (strp) argc
decl_file(data1) 1
decl_line(data1) 3
type (ref4) [61]
location (block1) [ 0] fbreg 0
[52] formal_parameter
name (strp) argv
decl_file(data1) 1
decl_line(data1) 3
type (ref4) [68]
location (block1) [ 0] fbreg 4
[61]base_type
byte_size(data1) 4
encoding (data1) signed (5)
name (string) int
[68]pointer_type
byte_size(data1) 4
type (ref4) [6e]
[6e]pointer_type
byte_size(data1) 4
type (ref4) [74]
[74]base_type
byte_size(data1) 1
encoding (data1) signed_char (6)
name (strp) char
[7b]variable
name (string) x
decl_file(data1) 1
decl_line(data1) 1
type (ref4) [61]
external (flag) Yes
declaration (flag) Yes
[86]variable
name (string) x
decl_file(data1) 1
decl_line(data1) 1
type (ref4) [61]
external (flag) Yes
location (block1) [ 0] addr 0x8049634
x
Note that there are two variable DIEs for x, 7b and 86, neither of which is
references in the rest of the CU. Since 86 doesn't refer to 7b, it isn't clear
to me how a consumer can know this is the same variable. In any case it seems
redundant to have both, even if the consumer is supposed to discard the one
marked as declaration.
This isn't an issue for static variables, which will have only one var DIE. It
is also a regression compared to gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-51)
which would produce only one variable DIE for x.
[Bug fortran/51383] [OOP] arrays of extended types break when associated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51383 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-12-04 16:33:19 UTC --- Author: burnus Date: Sun Dec 4 16:33:15 2011 New Revision: 181992 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181992 Log: 2011-12-04 Tobias Burnus bur...@net-b.de PR fortran/51383 * resolve.c (find_array_spec): Use ref-u.c.component directly without starting from ts.u.derived. 2011-12-04 Tobias Burnus bur...@net-b.de PR fortran/51383 * gfortran.dg/associate_10.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/associate_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug c++/51404] [c++0x] [4.7 Regression] ICE with invalid use of auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51404 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-04 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-12-04 17:37:38 UTC --- On it.
[Bug tree-optimization/51315] [4.6 regression] unaligned memory accesses generated with -ftree-sra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51315 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target||sparc*-*-* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-12-04 Known to work||4.4.6, 4.5.4 AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org Target Milestone|--- |4.6.3 Summary|gcc 4.6.2 miscompilation|[4.6 regression] unaligned |with -ftree-sra (included |memory accesses generated |in -O2) on Debian/sparc |with -ftree-sra Ever Confirmed|0 |1 Known to fail||4.6.2, 4.7.0 --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-04 18:20:36 UTC --- It's not, this one is caused by r161655 (Richard G's big MEM-REF change): http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html Investigating then.
[Bug middle-end/51411] New: ICE: in function_and_variable_visibility, at ipa.c:835 with -O -fgnu-tm and overriding virtual transaction_safe function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51411 Bug #: 51411 Summary: ICE: in function_and_variable_visibility, at ipa.c:835 with -O -fgnu-tm and overriding virtual transaction_safe function Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: patrick.marl...@gmail.com Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 25987 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25987 reduced testcase Compiler output: $ gcc -O -fgnu-tm testcase.C testcase.C:9:2: internal compiler error: in function_and_variable_visibility, at ipa.c:835 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 fancy_abort (file=0x142aa48 /mnt/svn/gcc-trunk/gcc/ipa.c, line=835, function=0x142ac40 function_and_variable_visibility) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:898 #1 0x00a041b7 in function_and_variable_visibility (whole_program=false) at /mnt/svn/gcc-trunk/gcc/ipa.c:834 #2 0x00a044d6 in whole_program_function_and_variable_visibility () at /mnt/svn/gcc-trunk/gcc/ipa.c:999 #3 0x00a88845 in execute_one_pass (pass=0x198b720) at /mnt/svn/gcc-trunk/gcc/passes.c:2074 #4 0x00a8900a in execute_ipa_pass_list (pass=0x198b720) at /mnt/svn/gcc-trunk/gcc/passes.c:2441 #5 0x0083fc90 in ipa_passes () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2076 #6 cgraph_optimize () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:2147 #7 0x008400ca in cgraph_finalize_compilation_unit () at /mnt/svn/gcc-trunk/gcc/cgraphunit.c:1327 #8 0x0066100b in cp_write_global_declarations () at /mnt/svn/gcc-trunk/gcc/cp/decl2.c:4050 #9 0x00b7d994 in compile_file (argc=15, argv=0x7fffdae8) at /mnt/svn/gcc-trunk/gcc/toplev.c:573 #10 do_compile (argc=15, argv=0x7fffdae8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1928 #11 toplev_main (argc=15, argv=0x7fffdae8) at /mnt/svn/gcc-trunk/gcc/toplev.c:2004 #12 0x76178d2d in __libc_start_main () from /lib64/libc.so.6 #13 0x00584119 in _start () Tested revisions: r181984 - crash
[Bug c++/51412] New: [c++0x] Broken diagnostic with invalid lambda expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51412
Bug #: 51412
Summary: [c++0x] Broken diagnostic with invalid lambda
expressions
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
A broken diagnostic is generated for the following invalid code snippet since
GCC 4.5.0:
==
void foo(int);
templateint void bar()
{
foo([]{}...);
}
==
bug.cc: In function 'void bar()':
bug.cc:5:11: error: expansion pattern '#'lambda_expr' not supported by
dump_expr#expression error' contains no argument packs
A slightly modified testcase results in a similar diagnostic:
==
void foo(int);
templateint void bar()
{
foo([]{}=0 ...);
}
==
bug.cc: In function 'void bar()':
bug.cc:5:14: error: expansion pattern '(#'lambda_expr' not supported by
pp_c_expression#)=0' contains no argument packs
[Bug c++/51413] New: Broken diagnostic with __builtin_offsetof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51413
Bug #: 51413
Summary: Broken diagnostic with __builtin_offsetof
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
A broken diagnostic is generated for the following invalid code snippet since
GCC 4.1.2:
=
struct A
{
static void foo();
};
int i = __builtin_offsetof(A, foo[1][1]);
=
bug.cc:6:36: warning: pointer to a function used in arithmetic
[-Wpointer-arith]
bug.cc:6:39: warning: pointer to a function used in arithmetic
[-Wpointer-arith]
bug.cc:6:40: error: cannot apply 'offsetof' to member function '#'indirect_ref'
not supported by dump_decl#declaration error'
[Bug ada/49084] [4.7 regression] bootstrap failure with Ada enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49084 --- Comment #14 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-04 21:59:13 UTC --- (gdb) call pn(gnat_root) N_Compilation_Unit (Node_Id=1707) (source,analyzed) Parent = empty Sloc = 9966 a-charac.ads:16:12 Context_Items = List (List_Id=-9988) Unit = N_Package_Declaration (Node_Id=1722) Aux_Decls_Node = N_Compilation_Unit_Aux (Node_Id=1708) It seems OK to me on the Ada side. I wonder what makes it trigger the assertion gcc_assert (Nkind (gnat_root) == N_Compilation_Unit) Maybe the C accessor Nkind is not working well for some reason? Yes, there is something really weird going on at the interface between C and Ada. Unfortunately I don't seem to be able to reproduce on Linux. Could you see what object code has been generated for the line gcc_assert (Nkind (gnat_root) == N_Compilation_Unit); in stage1-gcc/ada/trans.o and prev-gcc/ada/trans.o?
[Bug c++/51319] [4.7 Regression] Eigen3 enums not accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51319 fabien at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||fabien at gcc dot gnu.org Resolution||DUPLICATE --- Comment #2 from fabien at gcc dot gnu.org 2011-12-04 22:07:45 UTC --- (In reply to comment #0) This is likely related to Bug 51312 and/or Bug 51305 Most likely Bug 51382 ;-) *** This bug has been marked as a duplicate of bug 51382 ***
[Bug c++/51382] Incorrect diagnostic cannot appear in a constant-expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51382 fabien at gcc dot gnu.org changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #8 from fabien at gcc dot gnu.org 2011-12-04 22:07:45 UTC --- *** Bug 51319 has been marked as a duplicate of this bug. ***
[Bug c++/51414] New: Broken diagnostic with invalid use of __underlying_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51414 Bug #: 51414 Summary: Broken diagnostic with invalid use of __underlying_type Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: reich...@gcc.gnu.org A broken diagnostic is generated on trunk for the following invalid code snippet: == __underlying_type(int[1]) i; == bug.cc:1:25: error: '#'array_type' not supported by dump_expr#expression error' is not an enumeration type bug.cc:1:28: error: invalid type in declaration before ';' token
[Bug c++/51415] New: Broken diagnostic: 'vec_init_expr' not supported by dump_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51415
Bug #: 51415
Summary: Broken diagnostic: 'vec_init_expr' not supported by
dump_expr
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
A broken diagnostic is generated since GCC 4.5.0 for the following invalid code
snippet:
===
void foo()
{
int x[1];
[x]{} = 0;
}
===
bug.cc: In function 'void foo()':
bug.cc:4:11: error: no match for 'operator=' in '{#'vec_init_expr' not
supported by dump_expr#expression error} = 0'
bug.cc:4:11: note: candidate is:
bug.cc:4:5: note: foo()::lambda() foo()::lambda()::operator=(const
foo()::lambda()) deleted
bug.cc:4:5: note: no known conversion for argument 1 from 'int' to 'const
foo()::lambda()'
[Bug c++/51225] [c++0x] [4.7 Regression] ICE with invalid template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51225
--- Comment #2 from Volker Reichelt reichelt at gcc dot gnu.org 2011-12-04
22:46:24 UTC ---
Here's another code snippet that triggers a similar ICE:
struct A {};
templatetypename struct B
{
static constexpr A a = A(x);
};
bug.cc:5:28: error: 'x' was not declared in this scope
bug.cc:5:29: internal compiler error: unexpected expression '(const
A)(A)(expression error)' of kind implicit_conv_expr
Please submit a full bug report, [etc.]
[Bug c++/51415] Broken diagnostic: 'vec_init_expr' not supported by dump_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51415
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-12-04
23:05:35 UTC ---
By comparison, clang 3.0 prints:
pr51415.cc:4:3: error: expected expression
[x]{} = 0;
^
1 error generated.
[Bug c++/51414] Broken diagnostic with invalid use of __underlying_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51414 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org 2011-12-04 23:07:46 UTC --- Clang 3.0: pr51414.cc:1:1: error: only enumeration types have underlying types __underlying_type(int[1]) i; ^ 1 error generated.
[Bug c++/51416] New: [c++0x] [4.6/4.7 Regression] ICE with invalid use of auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51416
Bug #: 51416
Summary: [c++0x] [4.6/4.7 Regression] ICE with invalid use of
auto
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following code snippet triggers an ICE since GCC 4.6.0:
==
void foo();
templatetypename T, typename... U void foo(T, U... u)
{
auto foo(u...);
}
void bar()
{
foo(0);
}
==
bug.cc: In instantiation of 'void foo(T, U ...) [with T = int; U = {}]':
bug.cc:10:8: required from here
bug.cc:5:16: internal compiler error: in build_zero_init_1, at cp/init.c:278
Please submit a full bug report, [etc.]
[Bug c++/51416] [c++0x] [4.6/4.7 Regression] ICE with invalid use of auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51416 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Target Milestone|--- |4.6.3
[Bug other/51417] New: Cross-compiler - wrappers for ar, nm, ranlib installed under wrong names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51417
Bug #: 51417
Summary: Cross-compiler - wrappers for ar, nm, ranlib installed
under wrong names
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com
Host: i686-pc-linux-gnu
Target: i686-w64-mingw32
Build: i686-pc-linux-gnu
Under ${target}-gcc-{ar,nm,ranlib} and ${target}-${target}-gcc-{ar,nm,ranlib}.
(Shouldn't it be ${target}-gcc-{ar,nm,ranlib}-${version} ??? Because they pass
plugin of a specific version.)
[Bug fortran/51418] New: Fortran format sp,f0.0 output wrong with NaN and 0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51418 Bug #: 51418 Summary: Fortran format sp,f0.0 output wrong with NaN and 0.0 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: john.har...@vuw.ac.nz This 6-line program prints NaN when IMHO it should print NaN and +. when IMHO it should print +0. rimu[~]$ cat gftest.f90 character:: cnan*3 = 'NaN', fmt*13 = '(SP,A,F0.0,A)' real xnan read(cnan,*) xnan print fmt, '',xnan,'' print fmt, '',0.0 ,'' end rimu[~]$ gfortran -v Using built-in specs. Target: i386-redhat-linux6E Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --disable-gnu-unique-object --enable-languages=c,c++,fortran --disable-libgcj --with-mpfr=/builddir/build/BUILD/gcc-4.4.4-20100726/obj-i386-redhat-linux6E/mpfr-install/ --with-ppl=/builddir/build/BUILD/gcc-4.4.4-20100726/obj-i386-redhat-linux6E/ppl-install --with-cloog=/builddir/build/BUILD/gcc-4.4.4-20100726/obj-i386-redhat-linux6E/cloog-install --with-tune=generic --with-arch=i586 --build=i386-redhat-linux6E Thread model: posix gcc version 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC) rimu[~]$ gfortran gftest.f90 rimu[~]$ ./a.out NaN +. rimu[~]$ The output is the same on another machine: regent[~/Jfh] % gfortran -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
[Bug rtl-optimization/51366] [cygwin] ICE in maybe_record_trace_start, at dwarf2cfi.c:2244
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51366 --- Comment #2 from gee jojelino at gmail dot com 2011-12-05 05:02:23 UTC --- Created attachment 25988 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25988 preprocessed source g++ -L/tmp/winsup/i686-pc-cygwin/winsup -L/tmp/winsup/i686-pc-cygwin/winsup/cygwin -L/tmp/winsup/i686-pc-cygwin/winsup/w32api/lib -isystem /tmp/winsup/winsup/include -isystem /tmp/winsup/winsup/cygwin/include -isystem /tmp/winsup/winsup/w32api/include -B/tmp/winsup/i686-pc-cygwin/newlib/ -isystem /tmp/winsup/i686-pc-cygwin/newlib/targ-include -isystem /tmp/winsup/newlib/libc/include-c -nostdinc++ -DHAVE_CONFIG_H -O2 -fomit-frame-pointer -mstackrealign -march=core2 -mfpmath=sse -MMD -fmerge-constants -ftracer -mno-use-libstdc-wrappers -Wall -Wstrict-aliasing -Wwrite-strings -fno-common -pipe -fbuiltin -fmessage-length=0 -I. -I/tmp/winsup/winsup/cygwin -I/tmp/winsup/winsup/w32api/include -I../../.././winsup/cygwin/config/i386 -I/usr/lib/gcc/i686-pc-cygwin/4.7.0/include -fno-rtti -fno-exceptions -o ./strace.o /tmp/winsup/winsup/cygwin/strace.cc -save-temps -v g++: warning: -pipe ignored because -save-temps specified Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-cygwin/4.7.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ./configure --config-cache --prefix=/usr --disable-win32-registry --enable-threads=win32 --with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared --disable-sjlj-exceptions --enable-gomp --enable-cloog-backend=isl --enable-languages=c,c++,fortran,lto --no-create --no-recursion Thread model: win32 gcc version 4.7.0 2025 (experimental) (GCC) COLLECT_GCC_OPTIONS='-L/tmp/winsup/i686-pc-cygwin/winsup' '-L/tmp/winsup/i686-pc-cygwin/winsup/cygwin' '-L/tmp/winsup/i686-pc-cygwin/winsup/w32api/lib' '-isystem' '/tmp/winsup/winsup/include' '-isystem' '/tmp/winsup/winsup/cygwin/include' '-isystem' '/tmp/winsup/winsup/w32api/include' '-B' '/tmp/winsup/i686-pc-cygwin/newlib/' '-isystem' '/tmp/winsup/i686-pc-cygwin/newlib/targ-include' '-isystem' '/tmp/winsup/newlib/libc/include' '-c' '-nostdinc++' '-D' 'HAVE_CONFIG_H' '-O2' '-fomit-frame-pointer' '-mstackrealign' '-march=core2' '-mfpmath=sse' '-MMD' '-fmerge-constants' '-ftracer' '-mno-use-libstdc-wrappers' '-Wall' '-Wstrict-aliasing' '-Wwrite-strings' '-fno-common' '-pipe' '-fbuiltin' '-fmessage-length=0' '-I' '.' '-I' '/tmp/winsup/winsup/cygwin' '-I' '/tmp/winsup/winsup/w32api/include' '-I' '../../.././winsup/cygwin/config/i386' '-I' '/usr/lib/gcc/i686-pc-cygwin/4.7.0/include' '-fno-rtti' '-fno-exceptions' '-o' './strace.o' '-save-temps' '-v' '-shared-libgcc' /usr/libexec/gcc/i686-pc-cygwin/4.7.0/cc1plus.exe -E -quiet -nostdinc++ -v -I . -I /tmp/winsup/winsup/cygwin -I /tmp/winsup/winsup/w32api/include -I ../../.././winsup/cygwin/config/i386 -I /usr/lib/gcc/i686-pc-cygwin/4.7.0/include -MMD ./strace.d -MQ ./strace.o -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/lib/../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/lib/../../include/w32api -D HAVE_CONFIG_H -isystem /tmp/winsup/winsup/include -isystem /tmp/winsup/winsup/cygwin/include -isystem /tmp/winsup/winsup/w32api/include -isystem /tmp/winsup/i686-pc-cygwin/newlib/targ-include -isystem /tmp/winsup/newlib/libc/include /tmp/winsup/winsup/cygwin/strace.cc -mstackrealign -march=core2 -mfpmath=sse -mno-use-libstdc-wrappers -Wall -Wstrict-aliasing -Wwrite-strings -fomit-frame-pointer -fmerge-constants -ftracer -fno-common -fbuiltin -fmessage-length=0 -fno-rtti -fno-exceptions -O2 -fpch-preprocess -o strace.ii ignoring nonexistent directory /tmp/winsup/winsup/include ignoring duplicate directory /usr/include ignoring duplicate directory /usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/lib/../../include/w32api ignoring duplicate directory /tmp/winsup/winsup/w32api/include as it is a non-system directory that duplicates a system directory ignoring duplicate directory /usr/lib/gcc/i686-pc-cygwin/4.7.0/include as it is a non-system directory that duplicates a system directory #include ... search starts here: #include ... search starts here: . /tmp/winsup/winsup/cygwin ../../.././winsup/cygwin/config/i386 /tmp/winsup/winsup/cygwin/include /tmp/winsup/winsup/w32api/include /tmp/winsup/i686-pc-cygwin/newlib/targ-include /tmp/winsup/newlib/libc/include /usr/lib/gcc/i686-pc-cygwin/4.7.0/include /usr/local/include /usr/lib/gcc/i686-pc-cygwin/4.7.0/include-fixed /usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/include /usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/lib/../include/w32api End of search list. COLLECT_GCC_OPTIONS='-L/tmp/winsup/i686-pc-cygwin/winsup' '-L/tmp/winsup/i686-pc-cygwin/winsup/cygwin' '-L/tmp/winsup/i686-pc-cygwin/winsup/w32api/lib' '-isystem' '/tmp/winsup/winsup/include' '-isystem' '/tmp/winsup/winsup/cygwin/include'
[Bug debug/51419] New: length of dwarf2 debug-info-section-label too small if sizeof(void *)==2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51419 Bug #: 51419 Summary: length of dwarf2 debug-info-section-label too small if sizeof(void *)==2 Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: kikair...@gmail.com Created attachment 25989 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25989 proposal patch In dwarf2, length of debug-info-section-label (DWARF_REF_SIZE) is defined to DWARF2_ADDR_SIZE, but it is too small (2bytes) on some target. This causes an error in compiling libstdc++: /bin/sh ../libtool --tag CXX --mode=compile /tmp/ggg/./gcc/xgcc -shared-libgcc -B/tmp/ggg/./gcc -nostdinc++ -L/tmp/ggg/h8300-elf/libstdc++-v3/src -L/tmp/ggg/h8300-elf/libstdc++-v3/src/.libs -B/home/kikairoya/gcc/h8300-elf/bin/ -B/home/kikairoya/gcc/h8300-elf/lib/ -isystem /home/kikairoya/gcc/h8300-elf/include -isystem /home/kikairoya/gcc/h8300-elf/sys-include -I/tmp/ggg/h8300-elf/libstdc++-v3/include/h8300-elf -I/tmp/ggg/h8300-elf/libstdc++-v3/include -I/home/kikairoya/repos/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -Os -c -o wlocale-inst.lo /home/kikairoya/repos/gcc/libstdc++-v3/src/wlocale-inst.cc libtool: compile: /tmp/ggg/./gcc/xgcc -shared-libgcc -B/tmp/ggg/./gcc -nostdinc++ -L/tmp/ggg/h8300-elf/libstdc++-v3/src -L/tmp/ggg/h8300-elf/libstdc++-v3/src/.libs -B/home/kikairoya/gcc/h8300-elf/bin/ -B/home/kikairoya/gcc/h8300-elf/lib/ -isystem /home/kikairoya/gcc/h8300-elf/include -isystem /home/kikairoya/gcc/h8300-elf/sys-include -I/tmp/ggg/h8300-elf/libstdc++-v3/include/h8300-elf -I/tmp/ggg/h8300-elf/libstdc++-v3/include -I/home/kikairoya/repos/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -Os -c /home/kikairoya/repos/gcc/libstdc++-v3/src/wlocale-inst.cc -o wlocale-inst.o /tmp/cc12NgrP.s: Assembler messages: /tmp/cc12NgrP.s:74233: Error: value of 72828 too large for field of 2 bytes at 72912 target: h8300-elf, binutils: 2.22, gcc: 4.6.2 (both of host and cross) I think DWARF2_ADDR_SIZE needs at least 4. attach a proposal patch.
[Bug c++/51420] New: [c++0x] ICE with invalid user-defined literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51420
Bug #: 51420
Summary: [c++0x] ICE with invalid user-defined literals
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following invalid code snippet triggers an ICE on trunk:
void foo()
{
float x = operator _F();
float y = 0_F;
}
bug.cc: In function 'void foo()':
bug.cc:3:27: error: 'operator _F' was not declared in this scope
bug.cc:4:13: internal compiler error: tree check: expected function_type or
method_type, have error_mark in lookup_literal_operator, at cp/parser.c:3566
Please submit a full bug report, [etc.]
[Bug c++/51421] New: [c++0x] ICE with invalid use of auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51421
Bug #: 51421
Summary: [c++0x] ICE with invalid use of auto
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following invalid code snippet triggers an ICE since GCC 4.4.0:
=
int foo(int);
void bar()
{
auto i = foo(i);
}
=
bug.cc: In function 'void bar()':
bug.cc:5:17: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in lookup_conversions,
at cp/search.c:2499
Please submit a full bug report, [etc.]
A slightly different example triggers an ICE in a different position:
=
struct A {};
A foo(A);
void bar()
{
auto a = foo(a);
}
=
bug.cc: In function 'void bar()':
bug.cc:7:17: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in lookup_base, at
cp/search.c:212
Please submit a full bug report, [etc.]
[Bug c++/51422] New: [c++0x] ICE with invalid lambda expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51422
Bug #: 51422
Summary: [c++0x] ICE with invalid lambda expression
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reich...@gcc.gnu.org
The following invalid code snippet triggers an ICE on trunk:
===
templatetypename struct A {};
void foo()
{
[i] { Adecltype(i)(); };
[i] { Adecltype(i)(); };
}
===
bug.cc: In function 'void foo()':
bug.cc:5:4: error: 'i' was not declared in this scope
bug.cc: In lambda function:
bug.cc:5:22: error: template argument 1 is invalid
bug.cc: In lambda function:
bug.cc:6:20: internal compiler error: in is_normal_capture_proxy, at
cp/semantics.c:8797
Please submit a full bug report, [etc.]
