[Bug c++/60185] [4.9 Regression] ICE with invalid default parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60185 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-14 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r207332.
[Bug tree-optimization/60172] ARM performance regression from trunk@207239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 --- Comment #2 from Joey Ye joey.ye at arm dot com --- Created attachment 32131 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32131action=edit The function that causes the regression Attached Proc_8 from dhrystone, header file and good/bad.s It is the only function that generated code diffs with/without the commit.
[Bug fortran/60191] New: test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60191
Bug ID: 60191
Summary: test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on
ARMv7
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
This test case fails only with -O0, that's interesting.
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/ed/gnu/arm-linux-gnueabihf/libexec/gcc/armv7l-unknown-linux-gnueabihf/4.9.0/lto-wrapper
Target: armv7l-unknown-linux-gnueabihf
Configured with: ../gcc-4.9-20140209/configure
--prefix=/home/ed/gnu/arm-linux-gnueabihf
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go --with-arch=armv7-a
--with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
Thread model: posix
gcc version 4.9.0 20140209 (experimental) (GCC)
Debuging the first test case shows this:
The following function gets called:
(gdb) disass make_real
Dump of assembler code for function __m_MOD_make_real:
0x86d8 +0:push{r11}; (str r11, [sp, #-4]!)
0x86dc +4:addr11, sp, #0
0x86e0 +8:subsp, sp, #20
0x86e4 +12:strr0, [r11, #-16]
0x86e8 +16:ldrr3, [r11, #-16]
0x86ec +20:ldrr3, [r3]
0x86f0 +24:ldrr3, [r3]
0x86f4 +28:vmovs15, r3
0x86f8 +32:vcvt.f32.s32s15, s15
0x86fc +36:vstrs15, [r11, #-8]
0x8700 +40:ldrr3, [r11, #-8]
0x8704 +44:vmovs15, r3
0x8708 +48:vmov.f32s0, s15
0x870c +52:subsp, r11, #0
0x8710 +56:pop{r11}; (ldr r11, [sp], #4)
0x8714 +60:bxlr
the result is returned in register s0 (42.0)
but the caller expects it in register r0.
0x8754 +0:push{r11, lr}
0x8758 +4:addr11, sp, #4
0x875c +8:subsp, sp, #8
0x8760 +12:movwr3, #35292; 0x89dc
0x8764 +16:movtr3, #0
0x8768 +20:strr3, [r11, #-8]
0x876c +24:movwr3, #3032; 0xbd8
0x8770 +28:movtr3, #1
0x8774 +32:strr3, [r11, #-12]
0x8778 +36:ldrr3, [r11, #-8]
0x877c +40:ldrr3, [r3, #32]
0x8780 +44:subr2, r11, #12
0x8784 +48:movr0, r2
0x8788 +52:blxr3
0x878c +56:vmovs14, r0
= 0x8790 +60:vldrs15, [pc, #400]; 0x8928 MAIN__+468
0x8794 +64:vcmp.f32s14, s15
0x8798 +68:vmrsAPSR_nzcv, fpscr
0x879c +72:beq0x87a4 MAIN__+80
0x87a0 +76:bl0x8428 _gfortran_abort
[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60191 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This sounds like the front-end is not producing the correct function type for the call.
[Bug middle-end/60175] ICE on gcc.dg/asan/nosanitize-and-inline.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60175 --- Comment #2 from Yury Gribov y.gribov at samsung dot com --- Created attachment 32132 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32132action=edit Proposed patch So it looks like we are using wrong function here. Frequency does not need to have the same bounds as probability. I'm attaching a draft patch (only checked it for code in question).
[Bug middle-end/60175] ICE on gcc.dg/asan/nosanitize-and-inline.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60175 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||tejohnson at google dot com --- Comment #3 from Yury Gribov y.gribov at samsung dot com --- Adding Jan and Teresa (who worked on this piece of code) to comment on proposed patch.
[Bug middle-end/60192] New: Test case gcc.dg/tree-ssa/sra-12.c fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60192
Bug ID: 60192
Summary: Test case gcc.dg/tree-ssa/sra-12.c fails on ARM
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
FAIL: gcc.dg/tree-ssa/sra-12.c scan-tree-dump-times release_ssa l; 0
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/ed/gnu/arm-linux-gnueabihf/libexec/gcc/armv7l-unknown-linux-gnueabihf/4.9.0/lto-wrapper
Target: armv7l-unknown-linux-gnueabihf
Configured with: ../gcc-4.9-20140209/configure
--prefix=/home/ed/gnu/arm-linux-gnueabihf
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go --with-arch=armv7-a
--with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard
Thread model: posix
gcc version 4.9.0 20140209 (experimental) (GCC)
$ cat ../gcc-4.9-20140209/LAST_UPDATED
Obtained from SVN: trunk revision 207646
cat sra-12.c.036t.release_ssa
;; Function foo (foo, funcdef_no=0, decl_uid=4136, symbol_order=0)
Released 2 names, 22.22%, removed 2 holes
foo (struct S * p)
{
int l$i;
struct S l;
int _4;
bb 2:
l = *p_2(D);
l$i_5 = MEM[(struct S *)p_2(D)];
_4 = l$i_5 + 1;
MEM[(struct S *)l] = _4;
*p_2(D) = l;
l ={v} {CLOBBER};
return;
}
Test fails because l; is found in above file.
[Bug middle-end/60192] Test case gcc.dg/tree-ssa/sra-12.c fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60192
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Well, then SRA didn't work. The aggregate copy should have been elided and
the local 'l' should have been removed:
Released 11 names, 183.33%, removed 11 holes
foo (struct S * p)
{
int l$i;
int _3;
bb 2:
l$i_4 = MEM[(struct S *)p_2(D)];
_3 = l$i_4 + 1;
MEM[(struct S *)p_2(D)] = _3;
return;
}
(from x86_64)
Maybe some cost oddity on arm prevents this?
[Bug tree-optimization/60183] [4.7/4.8/4.9 Regression] phiprop creates invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60183 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-02-14 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Doesn't abort for me. phiprop does Inserting PHI for result of load _6 = *y_5; for edge defining c inserting load _19 = MEM[(long unsigned int *)c]; for edge defining y_13 inserting load _20 = *y_13; _6 = PHI _19(2), _20(3) on bb 2: w_4 = *x_2(D); goto bb 4; bb 3: _6 = *y_5; w_8 = _6 ^ w_7; _9 = MEM[(long unsigned int *)y_5 + 8B]; w_10 = w_8 + _9; _11 = MEM[(long unsigned int *)y_5 + 16B]; w_12 = w_10 ^ _11; y_13 = MEM[(void *)y_5 + 32B]; _14 = MEM[(long unsigned int *)y_5 + 24B]; w_15 = w_12 + _14; i_17 = i_16 + 1; bb 4: # y_5 = PHI c(2), y_13(3) which results in bb 2: w_4 = *x_2(D); _19 = MEM[(long unsigned int *)c]; goto bb 4; bb 3: w_8 = _6 ^ w_7; _9 = MEM[(long unsigned int *)y_5 + 8B]; w_10 = w_8 + _9; _11 = MEM[(long unsigned int *)y_5 + 16B]; w_12 = w_10 ^ _11; y_13 = MEM[(void *)y_5 + 32B]; _14 = MEM[(long unsigned int *)y_5 + 24B]; w_15 = w_12 + _14; i_17 = i_16 + 1; _20 = *y_13; bb 4: # y_5 = PHI c(2), y_13(3) # _6 = PHI _19(2), _20(3) I see nothing wrong with that. Ah, but the load is conditional on i = 7, so we effectively speculate it. Mine.
[Bug tree-optimization/60183] [4.7/4.8/4.9 Regression] phiprop creates invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60183
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Updated testcase that segfaults for me, no -fsanitize=address is then needed to
trigger it. Works with -O0 or -O? -fno-tree-phiprop:
unsigned char c[0x31] = { 1 };
int j = 2;
static void
foo (unsigned long *x, unsigned char *y)
{
int i;
unsigned long w = x[0];
for (i = 0; i j; i++)
{
w += *y;
y += 0x10;
w += *y;
y += 0x10;
}
x[1] = w;
}
__attribute__ ((noinline, noclone)) void
bar (unsigned long *x)
{
foo (x, c);
}
int
main ()
{
unsigned long a[2] = { 0, -1UL };
asm volatile (::r (c):memory);
c[0] = 0;
bar (a);
if (a[1] != 0)
__builtin_abort ();
return 0;
}
Perhaps phiprop is confused by the MEM[(void *)y_5 + 2097152B] and thinks that
because of the MEM_REF in there it is safe to dereference it?
[Bug tree-optimization/60183] [4.7/4.8/4.9 Regression] phiprop creates invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60183
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
Updated testcase that segfaults for me, no -fsanitize=address is then needed
to trigger it. Works with -O0 or -O? -fno-tree-phiprop:
unsigned char c[0x31] = { 1 };
int j = 2;
static void
foo (unsigned long *x, unsigned char *y)
{
int i;
unsigned long w = x[0];
for (i = 0; i j; i++)
{
w += *y;
y += 0x10;
w += *y;
y += 0x10;
}
x[1] = w;
}
__attribute__ ((noinline, noclone)) void
bar (unsigned long *x)
{
foo (x, c);
}
int
main ()
{
unsigned long a[2] = { 0, -1UL };
asm volatile (::r (c):memory);
c[0] = 0;
bar (a);
if (a[1] != 0)
__builtin_abort ();
return 0;
}
Perhaps phiprop is confused by the MEM[(void *)y_5 + 2097152B] and thinks
that because of the MEM_REF in there it is safe to dereference it?
It doesn't check whether it's safe to dereference because it thinks it's
dereferenced anyway. It wasn't supposed to speculate loads. We miss
Index: tree-ssa-phiprop.c
===
--- tree-ssa-phiprop.c (revision 207757)
+++ tree-ssa-phiprop.c (working copy)
@@ -309,6 +309,10 @@ propagate_with_phi (basic_block bb, gimp
gimple def_stmt;
tree vuse;
+ /* Only replace loads in the same block as the PHI node. */
+ if (gimple_bb (use_stmt) != bb)
+ continue;
+
/* Check whether this is a load of *ptr. */
if (!(is_gimple_assign (use_stmt)
TREE_CODE (gimple_assign_lhs (use_stmt)) == SSA_NAME
or really a post-dominator check - but we don't compute post-dominators
and I'm not sure it would be worth doing that.
[Bug target/60193] New: [4.7.4/4.8/4.9 regression] ICE on big nested frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60193
Bug ID: 60193
Summary: [4.7.4/4.8/4.9 regression] ICE on big nested frame
Product: gcc
Version: 4.7.4
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ebotcazou at gcc dot gnu.org
CC: ktietz at gcc dot gnu.org
Depends on: 56807
Target: x86_64-*-mingw
The fix for PR target/56807 has introduced ICEs on big nested frames:
eric@polaris:~/gnat/bugs/N213-061 cat t.c
void foo (int i)
{
void nested (void)
{
char arr[1U 31];
arr[i] = 0;
}
nested ();
}
eric@polaris:~/gnat/bugs/N213-061 ~/gnat/gnat7_47/x86_64-pc-mingw32/gcc/cc1
-quiet t.c
t.c: In function 'nested':
t.c:7:3: internal compiler error: in change_address_1, at emit-rtl.c:2001
Please submit a full bug report,
with preprocessed source if appropriate.
Contact http://gcc.gnu.org/bugs.html for instructions.
[Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807 --- Comment #25 from Eric Botcazou ebotcazou at gcc dot gnu.org --- The patch has introduced ICEs on x86-64, see PR target/60193.
[Bug target/60181] constant folding of complex number incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I think that it needs to be decided on a case-by-case basis whether the runtime complex division routine is precise enough. But yes, you generally cannot expect constant folding and runtime execution to produce the exact same result. This is FP after all ... (I would expect it for operations that are specified to be rounded correctly to 0.5ulp precision though) Note that the goal we have instead is that cross-compiling from all hosts produces the same constant folding results for a target (code generation doesn't depend on the host).
[Bug target/60193] [4.7.4/4.8/4.9 regression] ICE on big nested frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60193 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug target/60193] [4.7.4/4.8/4.9 regression] ICE on big nested frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60193 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-02-14 Ever confirmed|0 |1 --- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org --- Hmm, I can't reproduce this with recent 4.9 gcc. There is no ICE.
[Bug target/60193] [4.7.4/4.8/4.9 regression] ICE on big nested frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60193 --- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org --- I built recent 4.8 cross-compiler and tested. Again no ICE for this testcase
[Bug target/60193] [4.7.4/4.8/4.9 regression] ICE on big nested frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60193
--- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Sorry, minor pilot error, try with:
void foo (int i)
{
void nested (void)
{
char arr[(1U 31) + 4];
arr[i] = 0;
}
nested ();
}
[Bug c++/60177] Unable to deduce template base of derived class in call to function taking a `simple-template-id`
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60177 --- Comment #1 from Filip Roséen filip.roseen at gmail dot com --- Created attachment 32133 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32133action=edit testcase.cpp
[Bug target/60193] [4.7.4/4.8/4.9 regression] ICE on big nested frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60193 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org --- Confirmed. It seems to be related to array-size?!? During debugging I found that r10 seems to live, and rax doesn't. I will look into it.
[Bug tree-optimization/60172] ARM performance regression from trunk@207239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
I can't really interpret the asm differences but it seems we need more
registers?
Forwprop applies the association transform (those that fold-const.c already
does when presented with large enough GENERIC trees) - it transforms
(p +p off1) +p off2 to (p +p (off1 + off2)), that is, associates the
pointer that is offsetted first and computes the offset using unsigned
integer arithmetic. That enables the reassociation pass to process
the offset expression and simplifying it (that pass cannot handle a
pointer addition chain).
This happens in forwprop4 only - thus does -fdisable-tree-forwprop4 fix the
regression?
I really can't see a fundamental difference (but the associated adds) in
the resulting code. So I wonder what RTL transform does / does not trigger
with one of the variants.
On x86_64 the code difference with -O2 [-fno-tree-forwprop4] is
@@ -11,22 +11,25 @@
.cfi_startproc
leal5(%rdx), %r8d
movslq %edx, %rdx
+ salq$2, %rdx
movslq %r8d, %rax
leaq0(,%rax,4), %r9
- addq%r9, %rax
leaq(%rdi,%r9), %r10
- leaq(%rax,%rax,4), %rax
+ addq%r9, %rax
movl%ecx, (%r10)
movl%ecx, 4(%rdi,%r9)
- leaq(%rsi,%rax,4), %rax
+ leaq(%rax,%rax,4), %rcx
movl%r8d, 60(%rdi,%r9)
- leaq(%rax,%rdx,4), %rax
+ salq$2, %rcx
+ leaq(%rdx,%rcx), %rax
+ addq%rsi, %rax
addl$1, 16(%rax)
movl%r8d, 20(%rax)
movl%r8d, 24(%rax)
- movl(%r10), %edx
+ movl(%r10), %edi
+ leaq1000(%rsi,%rcx), %rax
movl$5, Int_Glob(%rip)
- movl%edx, 1020(%rax)
+ movl%edi, 20(%rdx,%rax)
ret
.cfi_endproc
If we look at immediate uses before RTL expansion relevant changes
(single-use - non-single-use change or vice-versa - enables combine/fwprop)
are
-_32 : -- single use.
+_32 : --2 uses.
+_16 = _41 + _32;
_33 = Arr_2_Par_Ref_22(D) + _32;
which happens when associating
_32 = pretmp_20 + 1000;
_33 = Arr_2_Par_Ref_22(D) + _32;
_34 = *_8;
- _51 = _33 + _41;
+ _16 = _41 + _32;
+ _51 = Arr_2_Par_Ref_22(D) + _16;
MEM[(int[25] *)_51 + 20B] = _34;
but _33 is dead after the transform.
+_33 : -- no uses
so that's a spurious difference. Stmts with no uses are not expanded,
but it seems to change what TER does. Hmm.
-_32 replace with -- _32 = pretmp_20 + 1000;
-
Killing dead stmts with
Index: gcc/tree-outof-ssa.c
===
--- gcc/tree-outof-ssa.c(revision 207757)
+++ gcc/tree-outof-ssa.c(working copy)
@@ -876,6 +876,21 @@ eliminate_useless_phis (void)
}
}
}
+
+ for (unsigned i = 1; i num_ssa_names; ++i)
+{
+ tree name = ssa_name (i);
+ if (!name || !has_zero_uses (name) || virtual_operand_p (name))
+ continue;
+ gimple def_stmt = SSA_NAME_DEF_STMT (name);
+ if (!is_gimple_assign (def_stmt)
+ || gimple_has_side_effects (def_stmt)
+ || stmt_could_throw_p (def_stmt))
+ continue;
+ gimple_stmt_iterator gsi = gsi_for_stmt (def_stmt);
+ gsi_remove (gsi, true);
+ release_defs (def_stmt);
+}
}
fixes that (hack alert). With that we get strictly more TER. Does
-fno-tree-ter also make the testcase regress, even with
-fdisable-tree-forwprop4?
[Bug c/60194] New: -Wformat should also warn when using %d (instead of %u) for unsigned arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60194
Bug ID: 60194
Summary: -Wformat should also warn when using %d (instead of
%u) for unsigned arguments
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
cppcheck has the following warning:
(warning) %d in format string (no. 1) requires 'int' but the argument type is
'unsigned int'
I think it would be useful to have the same warning with -Wformat. [One can
argue whether the warning should be always printed with -Wformat[=1] or only
with -Wformat=2 (+ -Wformat-unsigned).]
And of course also the other way round, e.g. using %lu or %lz with an
argument which is (signed) long.
Example:
#include stdio.h
#include limits.h
void foo(unsigned i) {
printf(%d\n, i);
}
int main() {
foo(UINT_MAX);
return 0;
}
[Bug tree-optimization/60172] ARM performance regression from trunk@207239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 --- Comment #4 from Joey Ye joey.ye at arm dot com --- -fdisable-tree-forwprop4 doesn't help. -fno-tree-ter makes it even worse.
[Bug target/60193] [4.7.4/4.8/4.9 regression] ICE on big nested frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60193 --- Comment #5 from Kai Tietz ktietz at gcc dot gnu.org --- Ok found issue. Problem is that x86_64 instructions have a maximum-offset of 2^31. Legitimate instruction doesn't detect here that constant is unsigned, so it fails. Nevertheless issue would happen always too for (1U 32) even for x86_64 abi. Solution might be here to use the eax-register for addressing instead of constant.
[Bug target/60193] [4.7.4/4.8/4.9 regression] ICE on big nested frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60193 --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- Patch posted to ML at http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00900.html
[Bug target/60181] constant folding of complex number incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181 --- Comment #3 from Andreas Krebbel krebbel at gcc dot gnu.org --- I'll keep the bugreport open with low prio. If I find the time I will at least try to understand what's going on before closing it. The testcase is extracted from gcc/testsuite/go.test/test/ken/cplx2.go which fails due to this problem currently on s390.
[Bug target/60179] [4.9 Regression] target optimization attribute streaming is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60179 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Feb 14 12:03:43 2014 New Revision: 207783 URL: http://gcc.gnu.org/viewcvs?rev=207783root=gccview=rev Log: 2014-02-14 Richard Biener rguent...@suse.de PR lto/60179 * lto-streamer-out.c (DFS_write_tree_body): Do not follow DECL_FUNCTION_SPECIFIC_TARGET. (hash_tree): Do not hash DECL_FUNCTION_SPECIFIC_TARGET. * tree-streamer-out.c (pack_ts_target_option): Remove. (streamer_pack_tree_bitfields): Do not stream TS_TARGET_OPTION. (write_ts_function_decl_tree_pointers): Do not stream DECL_FUNCTION_SPECIFIC_TARGET. * tree-streamer-in.c (unpack_ts_target_option): Remove. (unpack_value_fields): Do not stream TS_TARGET_OPTION. (lto_input_ts_function_decl_tree_pointers): Do not stream DECL_FUNCTION_SPECIFIC_TARGET. lto/ * lto.c (compare_tree_sccs_1): Do not compare DECL_FUNCTION_SPECIFIC_TARGET. (lto_read_decls): Re-build DECL_FUNCTION_SPECIFIC_TARGET. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c trunk/gcc/tree-streamer-in.c trunk/gcc/tree-streamer-out.c
[Bug target/60179] [4.9 Regression] target optimization attribute streaming is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60179 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/60172] ARM performance regression from trunk@207239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Joey Ye from comment #4) -fdisable-tree-forwprop4 doesn't help. -fno-tree-ter makes it even worse. The former is strange because it's the only pass that does sth that is changed by the patch? As said, make sure to include the fix for PR59993 in your testing. Does -fno-tree-forwprop fix the regression?
[Bug go/60134] runtime_unmarkspan panics with unaligned pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60134 Dominik Vogt vogt at linux dot vnet.ibm.com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #5 from Dominik Vogt vogt at linux dot vnet.ibm.com --- Fix verified by reporter.
[Bug c/60194] -Wformat should also warn when using %d (instead of %u) for unsigned arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60194 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- And of course also the other way round, e.g. using %lu or %lz with an argument which is (signed) long. (Ignore '%lz' that should be '%zu'.) Thinking a bit more about it, -Wformat-unsigned (implied by -Wformat=2) is probably the best - and ignoring the signdness for %c / character. (Currently, the code has the following. However, the example of comment 0 doesn't trigger even with -pedantic as it only covers pointers.) c-family/c-format.c's check_format_types has: /* Don't warn about differences merely in signedness, unless -Wpedantic. With -Wpedantic, warn if the type is a pointer target and not a character type, and for character types at a second level of indirection. */ if (TREE_CODE (wanted_type) == INTEGER_TYPE TREE_CODE (cur_type) == INTEGER_TYPE (!pedantic || i == 0 || (i == 1 char_type_flag)) (TYPE_UNSIGNED (wanted_type) ? wanted_type == c_common_unsigned_type (cur_type) : wanted_type == c_common_signed_type (cur_type))) continue;
[Bug tree-optimization/60183] [4.7/4.8/4.9 Regression] phiprop creates invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60183 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Ok, we do need the post-dominators to avoid FAIL: g++.dg/tree-ssa/pr21463.C -std=gnu++98 scan-tree-dump-times phiopt1 MIN_ EXPR 2 FAIL: g++.dg/tree-ssa/pr21463.C -std=gnu++98 scan-tree-dump-times phiopt1 MAX_ EXPR 2 FAIL: g++.dg/tree-ssa/pr21463.C -std=gnu++11 scan-tree-dump-times phiopt1 MIN_ EXPR 2 FAIL: g++.dg/tree-ssa/pr21463.C -std=gnu++11 scan-tree-dump-times phiopt1 MAX_ EXPR 2 FAIL: g++.dg/tree-ssa/pr57380.C -std=gnu++98 scan-tree-dump phiopt1 MAX_EXPR FAIL: g++.dg/tree-ssa/pr57380.C -std=gnu++11 scan-tree-dump phiopt1 MAX_EXPR Re-testing that variant.
[Bug tree-optimization/60172] ARM performance regression from trunk@207239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Note that we can probably avoid regressing TER by removing the dead stmt in forwprop itself (which would be appropriate at this stage). But as that doesn't help this still needs more analysis.
[Bug pch/60010] AArch64: sigsegv in cc1plus using pch without defining TRY_EMPTY_VM_SPACE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60010 --- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Author: rearnsha Date: Fri Feb 14 14:14:03 2014 New Revision: 207785 URL: http://gcc.gnu.org/viewcvs?rev=207785root=gccview=rev Log: PR pch/60010 2014-02-14 Kyle McMartin k...@redhat.com * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for AArch64. Modified: trunk/gcc/ChangeLog trunk/gcc/config/host-linux.c
[Bug c/60195] New: Strange warnings using atomic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60195 Bug ID: 60195 Summary: Strange warnings using atomic types Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jp.deplaix at gmail dot com Created attachment 32134 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32134action=edit Test case Two warnings are raised while compiling the attached test-case. The first one in the function f: warning: variable 'y' set but not used but clearly it is. For example if you replace atomic_int by int here, the warning desapears. The second one in the function g at the line of « y = 0 »: warning: right-hand operand of comma has no effect this warning make no sense, since there is no comma at this line. This was experienced with gcc 4.9.0 20140111 for the first warning and gcc 4.9.0 20140213 for both warnings.
[Bug middle-end/60175] ICE on gcc.dg/asan/nosanitize-and-inline.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60175 --- Comment #4 from Teresa Johnson tejohnson at google dot com --- On Fri, Feb 14, 2014 at 1:01 AM, y.gribov at samsung dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60175 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||tejohnson at google dot com --- Comment #3 from Yury Gribov y.gribov at samsung dot com --- Adding Jan and Teresa (who worked on this piece of code) to comment on proposed patch. The patch looks good to me, but I can't approve. The other calls to combine_probabilities from this module look ok to me, but this one should be apply_probability as you note. Thanks, Teresa -- You are receiving this mail because: You are on the CC list for the bug.
[Bug middle-end/60175] ICE on gcc.dg/asan/nosanitize-and-inline.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60175 --- Comment #5 from Yury Gribov y.gribov at samsung dot com --- Thanks, I'll run regtests on Monday and send patch for gcc-patches approve if all goes well.
[Bug middle-end/60175] ICE on gcc.dg/asan/nosanitize-and-inline.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60175 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- The bug is far before loop unrolling, I see the problem already during expansion, where the out of bound frequency 19992 is present.
[Bug tree-optimization/60196] New: Incorrect compilation with -fwrapv and -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60196
Bug ID: 60196
Summary: Incorrect compilation with -fwrapv and
-ftree-vectorize
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dpb at corrigendum dot ru
Created attachment 32135
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32135action=edit
Preprocessed source for the reproducer
This program should print 36 (preprocessed source attached):
#include stdio.h
static int foo(const short * a, int len)
{
int x;
int x1 = 0;
for( x = 0; x len; x++ )
x1 += x * a[x];
return x1;
}
int main()
{
short stuff[9] = {1,1,1,1,1,1,1,1,1};
printf(%d\n, foo(stuff, 9));
return 0;
}
However, if compiled with -O1 -fwrapv -ftree-vectorize, it prints 16 instead.
Omitting any of those flags gives the correct result.
I can reproduce this on 4.8.2 and 4.8 branch head. It doesn't reproduce on
trunk, though. (All three built from vanilla source.) Target is
x86_64-unknown-linux-gnu.
I also tested it on a bunch of Ubuntu's prebuilt GCC versions. It reproduces on
4.6.4, 4.7.3, 4.8.1, but not on 4.4.7.
[Bug c/60197] New: ICE with _Cilk_spawn in expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60197
Bug ID: 60197
Summary: ICE with _Cilk_spawn in expression
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following valid(?) code snippet (compiled with -fcilkplus) triggers
an ICE on trunk:
===
int foo()
{
return (_Cilk_spawn foo()) + 1;
}
===
gimplification failed:
statement_list 0x7f6dc2014420
type void_type 0x7f6dc1eed000 void VOID
align 8 symtab 0 alias set -1 canonical type 0x7f6dc1eed000
pointer_to_this pointer_type 0x7f6dc1eed0a8
head (nil) tail (nil) stmts
bug.c: In function 'foo':
bug.c:9:30: internal compiler error: gimplification failed
return (_Cilk_spawn foo()) + 1;
^
0x84252a gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:8356
0x8411dc gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:8135
0x83e6fb gimplify_modify_expr
../../gcc/gcc/gimplify.c:4507
0x84058b gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7448
0x844726 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5341
0x842c1e gimplify_and_add
../../gcc/gcc/gimplify.c:384
0x842c1e gimplify_return_expr
../../gcc/gcc/gimplify.c:1241
0x842c1e gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7695
0x844726 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5341
0x840cd6 gimplify_and_add
../../gcc/gcc/gimplify.c:384
0x840cd6 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7785
0x844726 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5341
0x84084b gimplify_statement_list
../../gcc/gcc/gimplify.c:1412
0x84084b gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7863
0x844726 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5341
0x84542f gimplify_bind_expr
../../gcc/gcc/gimplify.c:1079
0x84029e gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7645
0x844726 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gcc/gimplify.c:5341
0x845f69 gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:8555
0x846546 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:8708
Please submit a full bug report, [etc.]
[Bug c/60197] ICE with _Cilk_spawn in expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60197 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||bviyer at gcc dot gnu.org Known to fail||4.9.0 --- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org --- Balaji, this is your domain, would you mind having a look?
[Bug target/60181] constant folding of complex number incorrect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org --- Could this because of the use of fma for s390 and PPC inside the division code?
[Bug c++/60198] New: ICE with _Cilk_spawn in expression within template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60198
Bug ID: 60198
Summary: ICE with _Cilk_spawn in expression within template
function
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following valid(?) code snippet (compiled with -fcilkplus) triggers
an ICE on trunk:
===
templatetypename T int foo()
{
int i = (_Cilk_spawn fooT()) + 0;
return i;
}
template int fooint();
===
bug.cc: In instantiation of 'int foo() [with T = int]':
bug.cc:7:23: required from here
bug.cc:3:31: internal compiler error: in tsubst_copy, at cp/pt.c:12887
int i = (_Cilk_spawn fooT()) + 0;
^
0x62a933 tsubst_copy
../../gcc/gcc/cp/pt.c:12887
0x607956 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15110
0x608fda tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14188
0x6115c6 tsubst_expr
../../gcc/gcc/cp/pt.c:13812
0x61435d tsubst_expr
../../gcc/gcc/cp/pt.c:13327
0x611093 tsubst_expr
../../gcc/gcc/cp/pt.c:13219
0x61208c tsubst_expr
../../gcc/gcc/cp/pt.c:13424
0x60f2a9 instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:19690
0x64d8c7 instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:19806
0x688bed cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4148
Please submit a full bug report, [etc.]
[Bug c++/60198] ICE with _Cilk_spawn in expression within template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60198 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||bviyer at gcc dot gnu.org Known to fail||4.9.0 --- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org --- Balaji, this is your domain, would you mind having a look?
[Bug c++/60199] New: 'error: field initializer is not constant' error when initializing static member function pointer to a function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60199
Bug ID: 60199
Summary: 'error: field initializer is not constant' error when
initializing static member function pointer to a
function
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: abigail.buccaneer at gmail dot com
The following code compiles in Clang 3.3, but not GCC 4.8.2:
//---
// g++ -std=c++11 -Wall -Wextra -pedantic
void f() {}
static constexpr void (*g1)() = f; // ok
static constexpr void (*g2)() = f; // ok
struct S {
static constexpr void (*g3)() = f; // ok
static constexpr void (*g4)() = f; // error: field initializer is not
constant
};
//---
[Bug c++/60200] New: [c++11] ICE with invalid use of auto in typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60200
Bug ID: 60200
Summary: [c++11] ICE with invalid use of auto in typedef
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with -std=c++11) triggers
an ICE on trunk:
===
templatetypename struct A
{
typedef auto X;
};
Aint a;
===
bug.cc:3:16: error: typedef declared 'auto'
typedef auto X;
^
bug.cc: In instantiation of 'struct Aint':
bug.cc:6:8: required from here
bug.cc:3:16: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in tsubst_decl, at cp/pt.c:10817
0xdc0407 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9243
0x631b69 tree_class_check
../../gcc/gcc/tree.h:2832
0x631b69 tsubst_decl
../../gcc/gcc/cp/pt.c:10817
0x61be9f tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11357
0x64a34a instantiate_class_template_1
../../gcc/gcc/cp/pt.c:9010
0x64a34a instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9274
0x6db973 complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:134
0x5c4f38 start_decl_1(tree_node*, bool)
../../gcc/gcc/cp/decl.c:4719
0x5ede67 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:4682
0x6c7e9e cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16680
0x6c9929 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11205
0x6acc13 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6d3ec2 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10983
0x6d2bb8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6d445a cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6d445a c_parse_file()
../../gcc/gcc/cp/parser.c:31536
0x7f37c3 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
[Bug c++/60200] [4.9 Regression] [c++11] ICE with invalid use of auto in typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60200 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Known to work||4.7.0, 4.8.0 Target Milestone|--- |4.9.0 Summary|[c++11] ICE with invalid|[4.9 Regression] [c++11] |use of auto in typedef |ICE with invalid use of ||auto in typedef Known to fail||4.9.0
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org Target Milestone|--- |4.9.0 --- Comment #21 from Rainer Orth ro at gcc dot gnu.org --- The new test FAILs on Solaris 11 (both SPARC and x86), which, unlike Solaris 10, has posix_memalign in libc: FAIL: gcc.dg/torture/pr60092.c -O0 execution test The posix_memalign invocation with size = -1 cannot be right, and indeed the function returns ENOMEM. Rainer
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Rainer Orth from comment #21) The new test FAILs on Solaris 11 (both SPARC and x86), which, unlike Solaris 10, has posix_memalign in libc: FAIL: gcc.dg/torture/pr60092.c -O0 execution test The posix_memalign invocation with size = -1 cannot be right, and indeed the function returns ENOMEM. The invocation uses size -1 intentionally, and expects ENOMEM, but if Solaris libc stores to what the first argument points to even when it fails, then it violates POSIX.
[Bug c++/59347] [4.9 Regression] ICE on invalid: tree check: expected class 'type', have 'exceptional' (error_mark) in tsubst_decl, at cp/pt.c:10798
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59347
Volker Reichelt reichelt at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||4.7.0, 4.8.0
Keywords||error-recovery,
||ice-on-invalid-code
Last reconfirmed||2014-02-14
CC||reichelt at gcc dot gnu.org
Ever confirmed|0 |1
Summary|ICE on invalid: tree check: |[4.9 Regression] ICE on
|expected class 'type', have |invalid: tree check:
|'exceptional' (error_mark) |expected class 'type', have
|in tsubst_decl, at |'exceptional' (error_mark)
|cp/pt.c:10798 |in tsubst_decl, at
||cp/pt.c:10798
Target Milestone|--- |4.9.0
Known to fail||4.9.0
--- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org ---
Confirmed.
Here's a simplified testcase that produces less error message before crashing:
===
templateint struct A
{
typedef int ::X;
};
A0 a;
===
The problem might be related to PR60200.
[Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535 --- Comment #16 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Fri Feb 14 16:18:29 2014 New Revision: 207787 URL: http://gcc.gnu.org/viewcvs?rev=207787root=gccview=rev Log: 2014-02-14 Vladimir Makarov vmaka...@redhat.com Richard Earnshaw rearn...@arm.com PR rtl-optimization/59535 * lra-constraints.c (process_alt_operands): Encourage alternative when unassigned pseudo class is superset of the alternative class. (inherit_reload_reg): Don't inherit when optimizing for code size. * config/arm/arm.h (MODE_BASE_REG_CLASS): Add version for LRA returning CORE_REGS for anything but Thumb1 and BASE_REGS for modes not less than 4 for Thumb1. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.h trunk/gcc/lra-constraints.c
[Bug c++/59347] [4.9 Regression] ICE on invalid: tree check: expected class 'type', have 'exceptional' (error_mark) in tsubst_decl, at cp/pt.c:10798
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59347 --- Comment #2 from Volker Reichelt reichelt at gcc dot gnu.org --- Output for the testcase from comment#1: bug.cc:3:17: error: typedef name may not be a nested-name-specifier typedef int ::X; ^ bug.cc: In instantiation of 'struct A0': bug.cc:6:6: required from here bug.cc:3:17: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in tsubst_decl, at cp/pt.c:10817 0xdc0407 tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) ../../gcc/gcc/tree.c:9243 0x631b69 tree_class_check ../../gcc/gcc/tree.h:2832 0x631b69 tsubst_decl ../../gcc/gcc/cp/pt.c:10817 0x61be9f tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/pt.c:11357 0x64a34a instantiate_class_template_1 ../../gcc/gcc/cp/pt.c:9010 0x64a34a instantiate_class_template(tree_node*) ../../gcc/gcc/cp/pt.c:9274 0x6db973 complete_type(tree_node*) ../../gcc/gcc/cp/typeck.c:134 0x5c4f38 start_decl_1(tree_node*, bool) ../../gcc/gcc/cp/decl.c:4719 0x5ede67 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int, tree_node*, tree_node*, tree_node**) ../../gcc/gcc/cp/decl.c:4682 0x6c7e9e cp_parser_init_declarator ../../gcc/gcc/cp/parser.c:16680 0x6c9929 cp_parser_simple_declaration ../../gcc/gcc/cp/parser.c:11205 0x6acc13 cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:11086 0x6d3ec2 cp_parser_declaration ../../gcc/gcc/cp/parser.c:10983 0x6d2bb8 cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:10869 0x6d445a cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4014 0x6d445a c_parse_file() ../../gcc/gcc/cp/parser.c:31536 0x7f37c3 c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1060 Please submit a full bug report, [etc.]
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 --- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Rainer Orth from comment #21) The new test FAILs on Solaris 11 (both SPARC and x86), which, unlike Solaris 10, has posix_memalign in libc: FAIL: gcc.dg/torture/pr60092.c -O0 execution test The posix_memalign invocation with size = -1 cannot be right, and indeed the function returns ENOMEM. The invocation uses size -1 intentionally, and expects ENOMEM, but if Solaris libc stores to what the first argument points to even when it fails, then it violates POSIX. POSIX.1 doesn't explicitly forbid setting *memptr on error: http://pubs.opengroup.org/onlinepubs/007904975/functions/posix_memalign.html But I agree it seems strange, and in the OpenSolaris sources you see that *memptr is set to the memalign() return value (NULL in this case). Rainer
[Bug c++/60200] [4.9 Regression] [c++11] ICE with invalid use of auto in typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60200 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-14 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r199779.
[Bug c++/59347] [4.9 Regression] ICE on invalid: tree check: expected class 'type', have 'exceptional' (error_mark) in tsubst_decl, at cp/pt.c:10798
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59347 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Indeed, both the #c0 and #c1 testcases started to ICE with r199779.
[Bug middle-end/60175] ICE on gcc.dg/asan/nosanitize-and-inline.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60175 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Even on x86_64 one can see the bogus frequencies like 2 when or 1999N when maximum is 1, but only in the epilogue blocks.
[Bug middle-end/60175] ICE on gcc.dg/asan/nosanitize-and-inline.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60175
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org ---
The incorrect frequencies can be seen even on say -O1 -fsanitize=address
-fdump-rtl-expand-all:
static void *stack_base;
void mark_memory (void **start, void **end);
int
main (void)
{
void *dummy;
stack_base = dummy;
void *end;
mark_memory (stack_base, end);
return 0;
}
I don't see anything wrong before find_many_sub_blocks is called, there are
just 3 basic blocks at that point, bb3 as entry block successor with freq
1, which has some asan related branches inside of it, but nothing outside,
then bb2
as the function body block with freq 1, which ends in an unconditional jump
that jumps to return_label (in bb4 after note + 2 clobbers), and finally bb4 as
the exit block predecessor with freq 1. I guess the only weird thing is
that the clobbers are bypassed by the jump, maybe that in the end causes
find_many_sub_blocks to create weird frequencies. And bb4 contains again some
conditional jumps and labels related to asan, but again only inside that block.
Without asan use-after-return, the exit block predecessor is just merged with
the preceeding basic block, maybe it has a wrong frequency after
find_many_sub_blocks too, but as it is merged with the body block, tha twrong
frequency never shows up anywhere.
[Bug tree-optimization/53787] Possible IPA-SRA / IPA-CP improvement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53787 --- Comment #17 from Martin Jambor jamborm at gcc dot gnu.org --- Created attachment 32136 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32136action=edit Patch doing ipa-prop function body analysis in dominator order Yuri, this patch should make the requested propagation happen even in the benchmark attached to comment #14. Can you please verify it works for you? Does it speed up anything for you? Thanks.
[Bug c++/60025] Static member of class not found if class name == name of namespace it's defined in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60025 --- Comment #1 from Piotr Pilarczyk ppilar11 at gmail dot com --- Any feedback? Is it in fact a g++ bug?
[Bug c++/60146] [4.8/4.9 Regression] ICE when compiling this code with -fopenmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60146
Volker Reichelt reichelt at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||4.7.0
Keywords||ice-on-valid-code
Last reconfirmed||2014-02-14
CC||reichelt at gcc dot gnu.org
Ever confirmed|0 |1
Summary|Regression: ICE when|[4.8/4.9 Regression] ICE
|compiling this code with|when compiling this code
|-fopenmp|with -fopenmp
Known to fail||4.8.0, 4.9.0
--- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org ---
Confirmed. ICEs since GCC 4.8.0.
Reduced testcase:
==
int foo() { return 0; }
templatetypename T void bar()
{
#pragma omp parallel for
for (T i = foo(); i 8; ++i) {}
}
void baz()
{
barint();
}
==
bug.cc: In instantiation of 'void bar() [with T = int]':
bug.cc:11:12: required from here
bug.cc:6:3: internal compiler error: Segmentation fault
for (T i = foo(); i 8; ++i) {}
^
0xba523f crash_signal
../../gcc/gcc/toplev.c:337
0x733640 contains_struct_check
../../gcc/gcc/tree.h:2822
0x733640 finish_omp_for(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*, tree_node*, tree_node*, tree_node*)
../../gcc/gcc/cp/semantics.c:6434
0x613325 tsubst_expr
../../gcc/gcc/cp/pt.c:13637
0x61250c tsubst_expr
../../gcc/gcc/cp/pt.c:13586
0x61208c tsubst_expr
../../gcc/gcc/cp/pt.c:13424
0x60f2a9 instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:19690
0x64d8c7 instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:19806
0x688bed cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4148
Please submit a full bug report, [etc.]
[Bug c++/60146] [4.8/4.9 Regression] ICE when compiling this code with -fopenmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60146 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.4
[Bug c++/60201] New: Issue with CRTP generation under 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60201
Bug ID: 60201
Summary: Issue with CRTP generation under 4.8.1
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andrew.stern at itg dot com
I created a CRTP (Curiously recurring template pattern) and added non-static
member variables to my base class and that works without issue. But when I add
non-static variables to the subclass instance the initialization and values for
the variables in this class don't get initialized properly and also don't
consistently keep the same values. I checked the size-of the object and it
does seem to contain the correct size that is the Base member variables plus
the Subclasses member variables and the this pointer is consistently the same
value. It's just that when dumping the values to the screen the ones in the
subclass multiple instances of my object are dumping the same values regardless
of the object. I'm guessing that that the computation of the offset in the
object for these variables is being calculated incorrectly. Note that 472
should have been printed and not 0 in the example below.
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-2/root/usr/libexec/gcc/x86_64-redhat-linux/4.8.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/opt/rh/devtoolset-2/root/usr
--mandir=/opt/rh/devtoolset-2/root/usr/share/man
--infodir=/opt/rh/devtoolset-2/root/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
--enable-gnu-unique-object --enable-linker-build-id
--enable-languages=c,c++,fortran,lto --enable-plugin
--with-linker-hash-style=gnu --enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.8.1-20130715/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.1-20130715/obj-x86_64-redhat-linux/cloog-install
--with-mpc=/builddir/build/BUILD/gcc-4.8.1-20130715/obj-x86_64-redhat-linux/mpc-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.1 20130715 (Red Hat 4.8.1-4) (GCC)
Compile flags:
-g;-Wall;-std=c++11;-O0
To execute:
~/crtpbug/crtpbug/Debug/crtpbug
Output of application:
The this pointer is 7fff2124ec70 with a size of 8 and values of 304 and 0
Source code:
#include stdio.h
struct ParamOne {
double val {0.0};
};
struct ParamTwo {
int val {0};
};
templatetypename P, typename Data, typename Other
class Baseclass
{
public:
using subclass_type = P;
using data_type = Data;
using other_type = Other;
bool Method( const Data data);
public:
int m_BaseClassValue { 304 };
};
templatetypename P, typename Data, typename Other using pdata_type = typename
P::data_type;
templatetypename P, typename Data, typename Other using pother_type =
typename P::other_type;
templatetypename P, typename Data, typename Other
bool BaseclassP, Data, Other::Method( const Data data )
{
P Subclass = static_castP( *this );
pother_typeP, Data, Other other;
other.val = 11;
return Subclass.SubclassMethod( data, other );
}
templatetypename Data, typename Other
class Subclass : public BaseclassSubclassData, Other, Data, Other
{
public:
using data_type = Data;
using other_type = Other;
bool SubclassMethod( const Data data, Other other );
public:
int m_SubClassValue { 472 };
};
templatetypename Data, typename Other
bool SubclassData, Other::SubclassMethod( const Data data, Other other )
{
return true;
}
template
bool SubclassParamOne, ParamTwo::SubclassMethod( const ParamOne data,
ParamTwo other )
{
printf( The this pointer is %lx with a size of %ld and values of %d and
%d\n, (long)this, sizeof(*this), m_BaseClassValue, m_SubClassValue );
return true;
}
int main(int argc, char **argv)
{
ParamOne one;
one.val = 5.0;
BaseclassSubclassParamOne, ParamTwo, ParamOne, ParamTwo test;
test.Method(one);
return 0;
}
[Bug c++/60202] New: 128 alignment for vectorT data where T has a member with alignas(128)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60202 Bug ID: 60202 Summary: 128 alignment for vectorT data where T has a member with alignas(128) Product: gcc Version: 4.8.2 URL: http://listengine.tuxfamily.org/lists.tuxfamily.org/ei gen/2014/02/msg00033.html Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ilja.honkonen at helsinki dot fi Target: x86_64-redhat-linux gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper Target: x86_64-redhat-linux 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 --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Säiemalli: posix gcc-versio 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) Command line: g++ -std=c++0x -W -Wall -Wextra -pedantic -O3 testi.cpp -o testi where testi.cpp is http://ideone.com/XpgXyG and is also attached. No compiler output to stdout. Example of program output: Address 0x7fffeb791c80 is 128 bytes aligned. Address 0x7fffeb791d00 is 256 bytes aligned. Address 0xafa010 is 16 bytes aligned. Address 0xafa0a0 is 32 bytes aligned. Address 0xafa1b0 is 16 bytes aligned. Address 0xafa6c0 is 64 bytes aligned. Shouldn't all of the printed addresses be at least 128 byte aligned or compilation should fail?
[Bug c++/60202] 128 alignment for vectorT data where T has a member with alignas(128)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60202 --- Comment #2 from ilja.honkonen at helsinki dot fi --- Created attachment 32138 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32138action=edit saved temp
[Bug c++/60202] 128 alignment for vectorT data where T has a member with alignas(128)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60202 --- Comment #1 from ilja.honkonen at helsinki dot fi --- Created attachment 32137 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32137action=edit source
[Bug target/59794] [4.7/4.8 Regression] i386 backend fails to detect MMX/SSE/AVX ABI changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59794 David Abdurachmanov david.abdurachmanov at gmail dot com changed: What|Removed |Added CC||david.abdurachmanov at gmail dot c ||om --- Comment #13 from David Abdurachmanov david.abdurachmanov at gmail dot com --- Could we get this under -Wno-abi/-Wabi? We have 256-bit vectors [__vector(4) double], but no AVX available/enabled. We understand the affect on ABI compatibility and would like to disable such warnings.
[Bug c++/60202] 128 alignment for vectorT data where T has a member with alignas(128)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60202 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added URL|http://listengine.tuxfamily | |.org/lists.tuxfamily.org/ei | |gen/2014/02/msg00033.html | --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- We don't have a operator new which supports alignas yet. http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2014/02/msg00033.html
[Bug target/60203] New: Support long double/_Decimal128 direct move on power8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60203 Bug ID: 60203 Summary: Support long double/_Decimal128 direct move on power8 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Created attachment 32139 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32139action=edit Bug to show the problem. The direct move support did not include support for moving long double (TFmode) and _Decimal128 (TDmode) between GPRs and VSX registers. The testcase for PR 25972 when compiled for power8 should not move registers to the stack and to the GPRs.
[Bug target/60203] Support long double/_Decimal128 direct move on power8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60203 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-02-14 Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org --- Note, 64-bit direct moves are fairly simple and should be implemented.
[Bug middle-end/60175] ICE on gcc.dg/asan/nosanitize-and-inline.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60175
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org ---
--- gcc/function.c.jj2014-01-06 22:32:17.0 +0100
+++ gcc/function.c2014-02-14 19:05:27.233008179 +0100
@@ -5156,17 +5156,20 @@ expand_function_end (void)
crtl-return_rtx = outgoing;
}
- /* Emit the actual code to clobber return register. */
- {
-rtx seq;
+ /* Emit the actual code to clobber return register. Don't emit
+ it if clobber_after is a barrier, then the previous basic block
+ certainly doesn't fall thru into the exit block. */
+ if (!BARRIER_P (clobber_after))
+{
+ rtx seq;
-start_sequence ();
-clobber_return_register ();
-seq = get_insns ();
-end_sequence ();
+ start_sequence ();
+ clobber_return_register ();
+ seq = get_insns ();
+ end_sequence ();
-emit_insn_after (seq, clobber_after);
- }
+ emit_insn_after (seq, clobber_after);
+}
/* Output the label for the naked return from the function. */
if (naked_return_label)
fixes this for the common case of not falling through into the exit block, if
clobber_after is BARRIER, the clobbers will surely be never reachable and
immediately removed anyway.
Now, even with this patch we generate incorrect frequencies say for -O2
-fsanitize=address on:
int
foo (int i)
{
if (i)
return 4;
int j;
bar (j);
}
I think in that case we either need to stick the clobber stmts before the
return_label into the predecessor basic block, or create a new basic block to
hold just the clobbers and derive the frequency of the block containing the
clobbers from the frequency of the previous basic block.
[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 --- Comment #26 from Jeffrey A. Law law at redhat dot com --- I'd pondered the emit-the-condition twice, one marked as NOTHROW and it may ultimately be the best short term solution. I just don't have enough background on the original change which resulted in this problem to evaluate if other solutions might be viable. FWIW, at one time we did (or considered) a vaguely similar trick to deal with reloads of float point condition codes. IIRC, the target had multiple FP condition code registers, so we wanted to use pseudos and allocate them like any other register. Of course that leads to the potential problem that you can run out and may need to spill them, but the only way to set the hard registers was by doing comparisons, so reloading them after spilling was, umm, nontrivial. Not sure what ever happened with that. FWIW, this potentially affects the m68k, vax, v850, pdp11, h8300, cris, avr and cr16. Of those, I think only the m68k has an FPU, so the impact may be very very small right now.
[Bug c++/59798] [C++11] ICE befriending an inheriting constructor template specialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59798 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-14 CC||reichelt at gcc dot gnu.org Summary|ICE befriending an |[C++11] ICE befriending an |inheriting constructor |inheriting constructor |template specialization |template specialization Ever confirmed|0 |1 Known to fail||4.8.0, 4.9.0 --- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org --- Confirmed. Crashes since GCC 4.8.0 when inheriting constructors were introduced.
[Bug c++/60201] Issue with CRTP generation under 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60201 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- P Subclass = static_castP( *this ); Is this valid as *this at this point is just a Baseclass type (and does not have a Subclass type.
[Bug c++/60201] Issue with CRTP generation under 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60201 --- Comment #2 from Andrew Stern andrew.stern at itg dot com --- Is this valid as *this at this point is just a Baseclass type (and does not have a Subclass type. I believe the code to be valid since the template generates both the Baseclass and Subclass. The Subclass object is really just the same object as the Baseclass and the sizeof operator seems to give the correct values. Note that the code compiles and runs and the correct member functions get called. If you think this is the issue what is the correct method to get the Subclass type. Note the line also is consistent with the code located at: http://eli.thegreenplace.net/2011/05/17/the-curiously-recurring-template-pattern-in-c/ Specifically:const Derived d1 = static_castconst Derived(o1);
[Bug c++/60201] Issue with CRTP generation under 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60201 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Look at the original object: BaseclassSubclassParamOne, ParamTwo, ParamOne, ParamTwo test; test is of class Baseclass. You call Method on it. Method then has a cast from Baseclass to Subclass for *this but *this is only of type Baseclass and not Subclass. So when you call SubclassMethod on the object you just casted, it would really be only a Baseclass and not a Subclass so m_SubClassValue never was initialized and is in fact outside of the object. If we run using valgrind we get: ==10910== Use of uninitialised value of size 8 ==10910==at 0x56167AB: _itoa_word (_itoa.c:195) ==10910==by 0x5619347: vfprintf (vfprintf.c:1616) ==10910==by 0x5621A59: printf (printf.c:35) ==10910==by 0x400740: SubclassParamOne, ParamTwo::SubclassMethod(ParamOne const, ParamTwo) (t.cc:60) ==10910==by 0x4007D6: BaseclassSubclassParamOne, ParamTwo, ParamOne, ParamTwo::Method(ParamOne const) (t.cc:35) ==10910==by 0x400787: main (t.cc:71) If we run using address sanitizer we get: ==11676== ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff3594a8d4 at pc 0x400a6f bp 0x7fff3594a7c0 sp 0x7fff3594a7b8 READ of size 4 at 0x7fff3594a8d4 thread T0 #0 0x400a6e (/home/apinski/a.out+0x400a6e) #1 0x400cdd (/home/apinski/a.out+0x400cdd) #2 0x400bc8 (/home/apinski/a.out+0x400bc8) #3 0x7fe47a7b9c8c (/lib/libc-2.11.3.so+0x1ec8c) #4 0x4008d8 (/home/apinski/a.out+0x4008d8) Address 0x7fff3594a8d4 is located at offset 36 in frame main of T0's stack: This frame has 2 object(s): [32, 36) 'test' [96, 104) 'one' See how test ends at 36 but we are accessing location 36.
[Bug c++/47211] ICE: in cp_build_addr_expr_1, at cp/typeck.c:4866 with -fms-extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47211 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-14 CC||reichelt at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Volker Reichelt reichelt at gcc dot gnu.org --- Confirmed. The non-template version ICEs since GCC 4.6.0 and loops forever with GCC 4.0.0 - 4.5.3. The template version ICEs since GCC 4.4.0 and with GCC 3.4.0 - 4.0.4. It loops forever with GCC 4.1.0 - 4.3.6.
[Bug c++/60201] Issue with CRTP generation under 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60201 --- Comment #4 from Andrew Stern andrew.stern at itg dot com --- Since the examples that I found for CRTP seem to indicate a line very much like this could you perhaps suggest the correct method to get and call the Subclass object from the Baseclass object?
[Bug c++/59004] [4.8 Regression] ICE generated by __func__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59004 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.5.0, 4.6.0, 4.7.0, 4.9.0 Keywords||ice-on-valid-code Last reconfirmed||2014-02-14 CC||reichelt at gcc dot gnu.org Ever confirmed|0 |1 Summary|ICE generated by __func__ |[4.8 Regression] ICE ||generated by __func__ Target Milestone|--- |4.8.4 Known to fail||4.8.0, 4.8.1, 4.8.2 --- Comment #2 from Volker Reichelt reichelt at gcc dot gnu.org --- Confirmed. Still happens on 4.8 branch, but not on trunk.
[Bug rtl-optimization/60155] ICE: in get_pressure_class_and_nregs at gcse.c:3438
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60155 --- Comment #4 from John David Anglin danglin at gcc dot gnu.org --- Created attachment 32140 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32140action=edit Patch The attach patch fixes the ICE but maybe we should always check if the INSN might trap. Also, what about floating point exceptions?
[Bug c++/60201] Issue with CRTP generation under 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60201 --- Comment #5 from Andrew Stern andrew.stern at itg dot com --- It seems that if I change my code From: BaseclassSubclassParamOne, ParamTwo, ParamOne, ParamTwo test; To: SubclassParamOne, ParamTwo test; Then it seems to work. This produces the following output: The this pointer is 7fffddafc360 with a size of 8 and values of 304 and 472
[Bug c++/60201] Issue with CRTP generation under 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60201 --- Comment #6 from Andrew Stern andrew.stern at itg dot com --- Thank you for your help.
[Bug target/60204] New: struct with __m512i is mishandled in function parameter passing and return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60204
Bug ID: 60204
Summary: struct with __m512i is mishandled in function
parameter passing and return
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: kirill.yukhin at intel dot com
[hjl@gnu-6 avx512-1]$ cat x.i
typedef long long __m512i __attribute__ ((__vector_size__ (64),
__may_alias__));
struct m512i
{
__m512i x;
};
typedef long long __m256i __attribute__ ((__vector_size__ (32),
__may_alias__));
struct m256i
{
__m256i x;
};
struct m256i
foo1 (struct m256i x, struct m256i y, struct m256i z)
{
return z;
}
struct m512i
foo2 (struct m512i x, struct m512i y, struct m512i z)
{
return z;
}
[hjl@gnu-6 avx512-1]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -mavx512f -O2 -S x.i
[hjl@gnu-6 avx512-1]$ cat x.s
.filex.i
.section.text.unlikely,ax,@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globlfoo1
.typefoo1, @function
foo1:
.LFB0:
.cfi_startproc
vmovdqa%ymm2, %ymm0
ret
.cfi_endproc
.LFE0:
.sizefoo1, .-foo1
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.section.text.unlikely
.LCOLDB1:
.text
.LHOTB1:
.p2align 4,,15
.globlfoo2
.typefoo2, @function
foo2:
.LFB1:
.cfi_startproc
vmovdqa64136(%rsp), %zmm0
movq%rdi, %rax
vmovdqa64%zmm0, (%rdi)
ret
.cfi_endproc
.LFE1:
.sizefoo2, .-foo2
.section.text.unlikely
.LCOLDE1:
.text
.LHOTE1:
.identGCC: (GNU) 4.9.0 20140214 (experimental)
.section.note.GNU-stack,,@progbits
[hjl@gnu-6 avx512-1]$
I am expecting struct m512i is passed/returned in zmm register per
AVX-512 extension to x86-64 psABI.
[Bug rtl-optimization/60131] [4.9 Regression] RTL check fail in rhs_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60131 --- Comment #5 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Fri Feb 14 20:26:31 2014 New Revision: 207792 URL: http://gcc.gnu.org/viewcvs?rev=207792root=gccview=rev Log: PR rtl-optimization/60131 * ree.c (get_extended_src_reg): New function. (combine_reaching_defs): Use it rather than assuming location of REG. (find_and_remove_re): Verify first operand of extension is a REG before adding the insns to the copy list. PR rtl-optimization/60131 * g++.dg/torture/pr60131.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr60131.C Modified: trunk/gcc/ChangeLog trunk/gcc/ree.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/60131] [4.9 Regression] RTL check fail in rhs_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60131 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law law at redhat dot com --- Fixed by latest trunk commit.
[Bug target/60205] New: No ABU warning for AVX-512
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60205
Bug ID: 60205
Summary: No ABU warning for AVX-512
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: kirill.yukhin at intel dot com
[hjl@gnu-6 avx512-1]$ cat w.i
typedef long long __m512i __attribute__ ((__vector_size__ (64),
__may_alias__));
typedef long long __m256i __attribute__ ((__vector_size__ (32),
__may_alias__));
__m256i
foo1 (__m256i x, __m256i y, __m256i z)
{
return z;
}
__m512i
foo2 (__m512i x, __m512i y, __m512i z)
{
return z;
}
[hjl@gnu-6 avx512-1]$ make w.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -mavx512f -O2 -S w.i
[hjl@gnu-6 avx512-1]$ make clean
rm -f *.s *.o *.i.* *.c.*
[hjl@gnu-6 avx512-1]$ cat w.i
typedef long long __m512i __attribute__ ((__vector_size__ (64),
__may_alias__));
typedef long long __m256i __attribute__ ((__vector_size__ (32),
__may_alias__));
__m256i
foo1 (__m256i x, __m256i y, __m256i z)
{
return z;
}
__m512i
foo2 (__m512i x, __m512i y, __m512i z)
{
return z;
}
[hjl@gnu-6 avx512-1]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -S w.i
w.i: In function ‘foo1’:
w.i:6:1: warning: AVX vector return without AVX enabled changes the ABI
{
^
w.i:5:1: note: The ABI for passing parameters with 32-byte alignment has
changed in GCC 4.6
foo1 (__m256i x, __m256i y, __m256i z)
^
w.i:5:1: warning: AVX vector argument without AVX enabled changes the ABI
[hjl@gnu-6 avx512-1]$
I am expecting similar warnings for AVX-512.
[Bug rtl-optimization/59535] [4.9 regression] -Os code size regressions for Thumb1/Thumb2 with LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Jeffrey A. Law law at redhat dot com --- Should be fixed by Vlad's trunk commit.
[Bug c++/59066] [C++11] 'using' instead of 'typedef' causes a segmentation fault.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59066
Volker Reichelt reichelt at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-02-14
CC||reichelt at gcc dot gnu.org
Summary|C++11, 'using' instead of |[C++11] 'using' instead of
|'typedef' causes a |'typedef' causes a
|segmentation fault. |segmentation fault.
Ever confirmed|0 |1
Known to fail||4.7.0, 4.8.0, 4.9.0
--- Comment #4 from Volker Reichelt reichelt at gcc dot gnu.org ---
Confirmed. Reduced testcase that crashes since GCC 4.7.0 when template
alias (aka 'using') was introduced:
templatetypename T, template typename class U void foo(const UT) {}
templatetypename struct A
{
using B = A;
B bar();
};
void baz()
{
foo(Aint().bar());
}
Stack trace with current 4.8 branch:
bug.cc: In function 'void baz()':
bug.cc:11:22: internal compiler error: Segmentation fault
foo(Aint().bar());
^
0xad469f crash_signal
../../gcc/gcc/toplev.c:332
0xcff5e2 tree_check
../../gcc/gcc/tree.h:3683
0xcff5e2 make_decl_rtl(tree_node*)
../../gcc/gcc/varasm.c:1197
0x7d72f3 rtx_for_function_call
../../gcc/gcc/calls.c:1675
0x7d72f3 expand_call(tree_node*, rtx_def*, int)
../../gcc/gcc/calls.c:2983
0x8aadcd expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
../../gcc/gcc/expr.c:10263
0x7e82fd expand_call_stmt
../../gcc/gcc/cfgexpand.c:2114
0x7e82fd expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:2152
0x7e82fd expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:2304
0x7e9162 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:4138
0x7eacdc gimple_expand_cfg
../../gcc/gcc/cfgexpand.c:4657
Please submit a full bug report, [etc.]
Stack trace with trunk:
cc1plus: internal compiler error: Segmentation fault
0xba523f crash_signal
../../gcc/gcc/toplev.c:337
0x87e004 tree_check
../../gcc/gcc/tree.h:2918
0x87e004 decl_assembler_name_hash
../../gcc/gcc/symtab.c:98
0x87e46f insert_to_assembler_name_hash
../../gcc/gcc/symtab.c:209
0x87e5c1 symtab_initialize_asm_name_hash
../../gcc/gcc/symtab.c:432
0x88cda2 analyze_functions
../../gcc/gcc/cgraphunit.c:1124
0x88e2a5 finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2320
0x689cae cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4448
Please submit a full bug report, [etc.]
[Bug tree-optimization/60206] New: IVOPT has no idea of inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206
Bug ID: 60206
Summary: IVOPT has no idea of inline asm
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wmi at google dot com
CC: rguenth at gcc dot gnu.org, shenhan at google dot com
Host: i386
Target: i386
Created attachment 32141
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32141action=edit
Testcase
This bug is found in google branch but I think the same problem also exists on
trunk (but not exposed).
For the testcase 1.c attached (1.c is extracted from libgcc/soft-fp/divtf3.c),
use trunk compiler gcc-r202164 (Target: x86_64-unknown-linux-gnu) + the patch
r204497 could expose the problem.
The command:
gcc -v -O2 -fno-omit-frame-pointer -fpic -c -S -m32 1.c
The error:
./1.c: In function ‘__divtf3’:
./1.c:64:1194: error: ‘asm’ operand has impossible constraints
The inline asm in error message is as follow:
do {
__asm__ (
sub{l} {%11,%3|%3,%11}\n\t
sbb{l} {%9,%2|%2,%9}\n\t
sbb{l} {%7,%1|%1,%7}\n\t
sbb{l} {%5,%0|%0,%5}
: =r ((USItype) (A_f[3])), =r ((USItype) (A_f[2])), =r ((USItype)
(A_f[1])), =r ((USItype) (A_f[0])) : 0 ((USItype) (B_f[2])), g
((USItype) (A_f[2])), 1 ((USItype) (B_f[1])), g ((USItype) (A_f[1])), 2
((USItype) (B_f[0])), g ((USItype) (A_f[0])), 3 ((USItype) (0)), g
((USItype) (_n_f[_i])));
} while ()
Because -fno-omit-frame-pointer is turned on and the command line uses -fpic,
there are only 5 registers for register allocation.
Before IVOPT,
%0, %1, %2, %3 require 4 registers. The index variable i of _n_f[_i] requires
another register. So 5 registers are used up here.
After IVOPT, MEM reference _n_f[_i] is converted to MEM[base: _874, index:
ivtmp.22_821, offset: 0B]. base and index require 2 registers, Now 6 registers
are required, so LRA cannot find enough registers to allocate.
trunk compiler doesn't expose the problem because of patch r202165. With patch
r202165, IVOPT doesn't change _n_f[_i] in inline asm above. But it just hided
the problem.
Should IVOPT care about the constraints in inline-asm and restrict its
optimization in some case?
[Bug target/60207] New: Wrong TFmode check in construct_container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60207 Bug ID: 60207 Summary: Wrong TFmode check in construct_container Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: hubicka at ucw dot cz, rth at gcc dot gnu.org, ubizjak at gmail dot com r73099: commit e07e720e6332466eef5d5f0ad7687523ddbfc644 Author: hubicka hubicka@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Thu Oct 30 21:01:16 2003 + * real.c (encode_ieee_extended): Initialize whole array. * reg-stack.c (move_for_stack_reg0: Use always XFmode. * i386-modes.def: Change definitions of TFmode and XFmode. * i386.c (classify_argument): Rename TFmodes to XFmodes; add new TFmode co de. (construct_container): Allow constructing of TFmode integer containers. (ix86_return_in_memory): XFmode is not returned in memory. (init_ext_80387_constants): Always use XFmode. (print_operand): Likewise. (ix86_prepare_fp_compare_regs): Likewise. (split_to_parts): Deal with TFmode. (split_long_move): Simplify. (ix86_init_mmx_sse_builtins): Add __float80, __float128. (ix86_memory_move_cost): Do not confuse TFmode. * i386.h (LONG_DOUBLE_TYPE_SIZE): Set to 96. (IS_STACK_MODE): TFmode is not stack mode. (HARD_REGNO_NREGS, CLASS_MAX_NREGS): Deal nicely with XFmode. (VALID_SSE_REG_MODE): Allow TFmode. (VALID_FP_MODE_P): Disallow TFmode. passed TFmode in integer registers: +case TFmode: + classes[0] = X86_64_INTEGER_CLASS; + classes[1] = X86_64_INTEGER_CLASS; + return 2; if (n == 2 class[0] == X86_64_INTEGER_CLASS class[1] == X86_64_INTEGER_CLASS - (mode == CDImode || mode == TImode) + (mode == CDImode || mode == TImode || mode == TFmode) intreg[0] + 1 == intreg[1]) return gen_rtx_REG (mode, intreg[0]); But it was changed later to pass TFmode in SSE register: commit fabb8546e54830051300c70ddcd8a6fce3b7d790 Author: rth rth@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Jul 9 22:35:35 2004 + * config/i386/i386.c (classify_argument): Treat V1xx modes the same as their base modes. CTImode, TCmode, and XCmode must be passed in memory. TFmode (__float128) must be is an SSE/SSEUP pair. V2SImode, V4HImode, and V8QI are class SSE. All sufficiently small remaining vector modes must be passed in one or two integer registers. (ix86_libcall_value): TFmode must be returned in xmm0, XCmode must be returned in memory. (bdesc_2arg, ix86_init_mmx_sse_builtins): __builtin_ia32_pmuludq and __builtin_ia32_pmuludq128 have non-uniform argument and return types and must thus be handled explicitly. * config/i386/i386.md (*movdi_1_rex64): Add cases for moving between MMX and XMM regs. (movv8qi_internal, movv4hi_internal, movv2si_internal, movv2sf_internal): Permit moving between MMX and XMM registers (since MMX areguments and return values are passed in XMM registers). (sse2_umulsidi3): Correct type and mode. But we didn't remove mode == TFmode check in construct_container.
[Bug tree-optimization/60206] IVOPT has no idea of inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I think the real issue __FP_FRAC_SUB_4 needs to be fixed not to use inline-asm but normal C code. The normal C code should be able to produce as good as the inline-asm code now too.
[Bug tree-optimization/60206] IVOPT has no idea of inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206 --- Comment #2 from wmi at google dot com --- This is a way to fix the problem. libgcc/soft-fp/op-4.h has provided a C version of __FP_FRAC_SUB_4, but now it is overrided by the inline asm version in config/i386/32/sfp-machine.h. But the inline asm looks legal right? Isn't it compiler's responsiblity to keep the inline asm constraints always satisfiable?
[Bug web/60208] New: Please highliight that mudflap support is removed in GCC 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60208 Bug ID: 60208 Summary: Please highliight that mudflap support is removed in GCC 4.9 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: rrt at sc3d dot org The wiki page http://gcc.gnu.org/wiki/Mudflap_Pointer_Debugging is immutable: I can't edit it when I'm logged in to the wiki. Hence, please add a prominent notice at the top of the page that support for mudflap has been removed in GCC 4.9: http://gcc.gnu.org/gcc-4.9/changes.html Thanks!
[Bug target/60203] Support long double/_Decimal128 direct move on power8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60203 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org --- Created attachment 32142 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32142action=edit Proposed patch to fix the problem This patch adds direct move support for long double and _Decimal128 on ISA 2.07 64-bit machines.
[Bug c++/60108] [4.7/4.8/4.9 Regression] [C++11] ICE in use_thunk, at cp/method.c:340
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60108
Volker Reichelt reichelt at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||4.4.0, 4.5.0, 4.6.0
Keywords||ice-on-valid-code
Last reconfirmed||2014-02-14
CC||reichelt at gcc dot gnu.org
Ever confirmed|0 |1
Summary|ICE in use_thunk, at|[4.7/4.8/4.9 Regression]
|cp/method.c:340 |[C++11] ICE in use_thunk,
||at cp/method.c:340
Target Milestone|--- |4.7.4
Known to fail||4.7.0
--- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org ---
Confirmed. ICEs since GCC 4.7.0.
Here's a testcase without variadic templates:
templateint struct A
{
virtual ~A();
};
templatetypename struct B : A0, A1
{
~B() = default;
};
struct C : Bbool
{
C() {}
};
[Bug c++/59877] [4.7 Regression] ICE: Error reporting routines re-entered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59877
Volker Reichelt reichelt at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
CC||reichelt at gcc dot gnu.org
Known to work||4.6.0, 4.7.0, 4.7.1, 4.7.2,
||4.8.0, 4.9.0
Target Milestone|--- |4.7.4
Summary|Internal compiler error:|[4.7 Regression] ICE: Error
|Error reporting routines|reporting routines
|re-entered. |re-entered.
Known to fail||4.7.3
--- Comment #2 from Volker Reichelt reichelt at gcc dot gnu.org ---
Here's a shorter testcase:
#include memory
struct A
{
A(int) {}
};
void foo()
{
std::make_sharedA();
}
The bug only appears in GCC 4.7.3.
GCC 4.7.2, 4.8.0, 4.9.0 produce a regular error message.
[Bug tree-optimization/60206] IVOPT has no idea of inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Fri, 14 Feb 2014, pinskia at gcc dot gnu.org wrote: I think the real issue __FP_FRAC_SUB_4 needs to be fixed not to use inline-asm but normal C code. The normal C code should be able to produce as good as the inline-asm code now too. Does GCC do a good job of detecting add-with-carry and subtract-with-borrow patterns (i.e. detecting the comparison that corresponds to the carry flag and its use in a subsequent operation)? (The Clang __builtin_addc* / __builtin_subc* functions might also be a useful addition for this sort of purpose.)
[Bug c++/59877] [4.7 Regression] [c++11] ICE: Error reporting routines re-entered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59877
Volker Reichelt reichelt at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-02-15
Known to work|4.7.0, 4.7.1, 4.7.2 |
Summary|[4.7 Regression] ICE: Error |[4.7 Regression] [c++11]
|reporting routines |ICE: Error reporting
|re-entered. |routines re-entered.
Ever confirmed|0 |1
Known to fail||4.7.0, 4.7.1, 4.7.2
--- Comment #3 from Volker Reichelt reichelt at gcc dot gnu.org ---
Confirmed. Here's a reduced testcase that demonstrates the problem with GCC
4.7.x
(compile with -std=c++11):
=
templatetypename T int* foo(T t)
{
return t;
}
templatetypename struct A
{
static void bar();
templatetypename T static decltype(bar()) baz(T t)
{
foo(t);
}
};
void foo()
{
Aint::baz(0);
}
=
[Bug tree-optimization/60206] IVOPT has no idea of inline asm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206 --- Comment #4 from wmi at google dot com --- On Fri, 14 Feb 2014, pinskia at gcc dot gnu.org wrote: I think the real issue __FP_FRAC_SUB_4 needs to be fixed not to use inline-asm but normal C code. The normal C code should be able to produce as good as the inline-asm code now too. Does GCC do a good job of detecting add-with-carry and subtract-with-borrow patterns (i.e. detecting the comparison that corresponds to the carry flag and its use in a subsequent operation)? I remember at least the expansion of builtin_strlen could generate sub-with-borrow and it works well, so I think rtl passes could handle add-with-carry/subtract-with-borrow.
[Bug c++/58170] [4.7/4.8/4.9 Regression] [c++11] Crash when aliasing a template class that is a member of its template base class.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58170 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.7.0, 4.7.1, 4.7.2 Keywords||ice-on-invalid-code Last reconfirmed||2014-02-15 CC||reichelt at gcc dot gnu.org Ever confirmed|0 |1 Summary|Crash when aliasing a |[4.7/4.8/4.9 Regression] |template class that is a|[c++11] Crash when aliasing |member of its template base |a template class that is a |class. |member of its template base ||class. Target Milestone|--- |4.7.4 Known to fail||4.7.3, 4.8.0, 4.9.0 --- Comment #1 from Volker Reichelt reichelt at gcc dot gnu.org --- Confirmed. ICE started in GCC 4.7.3.
[Bug c++/58170] [4.7/4.8/4.9 Regression] [c++11] Crash when aliasing a template class that is a member of its template base class.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58170 --- Comment #2 from Volker Reichelt reichelt at gcc dot gnu.org --- Stack trace on trunk: bug.cc: In substitution of 'templateclass T, class U, class V using B = A template-parameter-1-1, template-parameter-1-2 ::BV [with T = T; U = char; V = bool]': bug.cc:10:18: required from here bug.cc:6:70: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have template_decl in lookup_template_class_1, at cp/pt.c:7674 template typename T, typename U, typename V using B = AT, U::BV; ^ 0xdbfc54 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/gcc/tree.c:9192 0x5bc4c9 tree_check3(tree_node*, char const*, int, char const*, tree_code, tree_code, tree_code) ../../gcc/gcc/tree.h:2749 0x62520c lookup_template_class_1 ../../gcc/gcc/cp/pt.c:7674 0x62520c lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ../../gcc/gcc/cp/pt.c:7725 0x6296d3 tsubst_aggr_type ../../gcc/gcc/cp/pt.c:10031 0x61ba51 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/pt.c:11436 0x62dbee tsubst_decl ../../gcc/gcc/cp/pt.c:10908 0x61beff tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/pt.c:11357 0x632e4d instantiate_template_1 ../../gcc/gcc/cp/pt.c:15325 0x632e4d instantiate_template(tree_node*, tree_node*, int) ../../gcc/gcc/cp/pt.c:15375 0x61c02d instantiate_alias_template ../../gcc/gcc/cp/pt.c:15405 0x61c02d tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/pt.c:11384 0x62435f lookup_template_class_1 ../../gcc/gcc/cp/pt.c:7499 0x62435f lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ../../gcc/gcc/cp/pt.c:7725 0x72dcc2 finish_template_type(tree_node*, tree_node*, int) ../../gcc/gcc/cp/semantics.c:2953 0x6c2078 cp_parser_template_id ../../gcc/gcc/cp/parser.c:13440 0x6c2398 cp_parser_class_name ../../gcc/gcc/cp/parser.c:19074 0x6b3bc9 cp_parser_qualifying_entity ../../gcc/gcc/cp/parser.c:5524 0x6b3bc9 cp_parser_nested_name_specifier_opt ../../gcc/gcc/cp/parser.c:5249 0x6cba77 cp_parser_simple_type_specifier ../../gcc/gcc/cp/parser.c:14638 Please submit a full bug report, [etc.]
