[Bug ipa/58313] New: [4.9 Regression] kdelibs build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58313
Bug ID: 58313
Summary: [4.9 Regression] kdelibs build failure
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at trippelsdorf dot de
Building kdelibs-4.11.1 fails when linking kdecore:
...
CMakeFiles/kdecore.dir/network/k3socketdevice.o:k3socketdevice.cpp:function
_ZN8KNetwork13KSocketDeviceC2EPKNS_11KSocketBaseEP7QObject: error: undefined
reference to '_ZN8KNe
twork17KActiveSocketBaseC2EPPKvP7QObject'
CMakeFiles/kdecore.dir/network/k3socketdevice.o:k3socketdevice.cpp:function
_ZN8KNetwork13KSocketDeviceC2EPKNS_11KSocketBaseEP7QObject: error: undefined
reference to '_ZN8KNe
twork18KPassiveSocketBaseC2EPPKv'
CMakeFiles/kdecore.dir/network/k3socketdevice.o:k3socketdevice.cpp:function
_ZN8KNetwork13KSocketDeviceC1EPKNS_11KSocketBaseEP7QObject: error: undefined
reference to '_ZN8KNe
twork17KActiveSocketBaseC2EPPKvP7QObject'
CMakeFiles/kdecore.dir/network/k3socketdevice.o:k3socketdevice.cpp:function
_ZN8KNetwork13KSocketDeviceC1EPKNS_11KSocketBaseEP7QObject: error: undefined
reference to '_ZN8KNe
twork18KPassiveSocketBaseC2EPPKv'
...
I've reduced this issue to:
markus@x4 tmp % cat test.ii
namespace KNetwork {
class A {};
class KPassiveSocketBase : virtual A {
public:
KPassiveSocketBase();
};
class B : KPassiveSocketBase {
B();
};
}
using namespace KNetwork;
B::B() {}
markus@x4 tmp % g++ -c -O2 test.ii
markus@x4 tmp % nm test.o | grep _ZN8KNetwork18KPassiveSocketBaseC2EPPKv
U _ZN8KNetwork18KPassiveSocketBaseC2EPPKv
markus@x4 tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.1/g++ -c -O2 test.ii
markus@x4 tmp % nm test.o | grep _ZN8KNetwork18KPassiveSocketBaseC2EPPKv
markus@x4 tmp %
[Bug ipa/58313] [4.9 Regression] kdelibs build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58313 --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de --- markus@x4 tmp % g++ c -O2 test.ii markus@x4 tmp % nm test.o|grep _ZN8KNetwork18KPassiveSocketBase U _ZN8KNetwork18KPassiveSocketBaseC2EPPKv markus@x4 tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/4.8.1/g++ -Wall -c -O2 test.ii markus@x4 tmp % nm test.o|grep _ZN8KNetwork18KPassiveSocketBase U _ZN8KNetwork18KPassiveSocketBaseC2Ev markus@x4 tmp % c++filt _ZN8KNetwork18KPassiveSocketBaseC2EPPKv KNetwork::KPassiveSocketBase::KPassiveSocketBase(void const**) markus@x4 tmp % c++filt _ZN8KNetwork18KPassiveSocketBaseC2Ev KNetwork::KPassiveSocketBase::KPassiveSocketBase()
[Bug rtl-optimization/58210] 400.perlbench fails with ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58210 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- Dup of PR 58137 ? There is a discussion on gcc-patches between Bernd Edlinger and Richard Biener about how to fix it.
[Bug fortran/44489] Transfer with boz constant can confuse - add documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44489 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-04 Ever confirmed|0 |1 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- I think the code in comment #0 is invalid (see also pr54072) per: C4102 (R463) A boz-literal-constant shall appear only as a data-stmt-constant in a DATA statement, or where explicitly allowed in subclause 13.7 as an actual argument of an intrinsic procedure. 13.7.168 TRANSFER (SOURCE, MOLD [, SIZE]) ... MOLD shall be a scalar or array of any type. If it is a variable, it need not be defined. BOZ is not explicitly allowed here. Note that compiling the code in comment#0 with -Wall gives the following warnings pr44489.f90:9.20: print *, transfer(ii8,z'1000') 1 Warning: Intrinsic TRANSFER at (1) has partly undefined result: source size 4 result size 16 pr44489.f90:10.20: print *, transfer(ii8,z'1000') 1 Warning: Intrinsic TRANSFER at (1) has partly undefined result: source size 4 result size 16 (size 8 for 32 bit mode).
[Bug ipa/58313] [4.9 Regression] kdelibs build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58313 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-04 CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Caused by r201251.
[Bug fortran/47191] Misleading error message if part-ref starts with DATA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47191 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-04 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 202232.
[Bug bootstrap/56750] [4.8/4.9 Regression] static -lstdc++ logic bleeds into all subdirs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56750 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|static -lstdc++ logic |[4.8/4.9 Regression] static |bleeds into all subdirs |-lstdc++ logic bleeds into ||all subdirs
[Bug rtl-optimization/58210] 400.perlbench fails with ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58210 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-09-04 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Please provide preprocessed source and compiler flags and the architecture that fails.
[Bug tree-optimization/58311] [4.9 Regression] ICE: SIGSEGV in hash_table::find_slot_with_hash() with -fdevirtualize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58311 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.9.0
[Bug c++/58308] Segmentation fault: internal compiler error: in make_decl_rtl, at varasm.c:1147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58308 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid, ||ice-on-invalid-code Known to fail||4.7.3, 4.8.0 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- t.C: In function 'int main()': t.C:6:26: error: use of local variable with automatic storage from containing function int *p = x; ^ t.C:3:11: note: 'int x' declared here int x = 666; ^
[Bug c++/58305] Deprecation warning for class not raised when not assigning to a variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58305 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Sep 4 08:57:26 2013 New Revision: 202242 URL: http://gcc.gnu.org/viewcvs?rev=202242root=gccview=rev Log: /cp 2013-09-03 Paolo Carlini paolo.carl...@oracle.com PR c++/58305 * typeck2.c (build_functional_cast): Maybe warn_deprecated_use. /testsuite 2013-09-03 Paolo Carlini paolo.carl...@oracle.com PR c++/58305 * g++.dg/warn/deprecated-8.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/deprecated-8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/58305] Deprecation warning for class not raised when not assigning to a variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58305 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug rtl-optimization/58210] 400.perlbench fails with ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58210 --- Comment #3 from GGanesh Ganesh.Gopalasubramanian at amd dot com --- (In reply to Richard Biener from comment #2) Please provide preprocessed source and compiler flags and the architecture that fails. Its for 400.perlbench (Spec 1.2) with options -Ofast -march=bdver2
[Bug c++/58305] Deprecation warning for class not raised when not assigning to a variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58305 --- Comment #7 from Johannes Wienke languitar at semipol dot de --- Thanks!
[Bug c/58314] New: SH4 error: 'asm' operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58314 Bug ID: 58314 Summary: SH4 error: 'asm' operand requires impossible reload Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chrbr at gcc dot gnu.org Created attachment 30746 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30746action=edit Reproduce Reproduced in -Os with - sh4-linux-gcc 4.8.1 (sh-superh-elf-gcc surprisingly OK) - sh-superh-elf-gcc 4.9 sh-superh-elf-gcc -Os bug_asm.c bug_asm.c: In function 'xfs_attr_leaf_remove': bug_asm.c:206:2: error: 'asm' operand requires impossible reload __asm__( ^ See similar reports : #10396, #13515, #48496. Does not look similar as still not fixed and pertained to older versions.
[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #27 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Martin Jambor from comment #22)
Created attachment 30732 [details]
Another attempt at a fix
I simply moved the decision whether to go the misalignp path or not a
bit down in the function, below the address adjustments done for
non-NULL offset, strict volatile bit fields etc. and ran the
testsuite, expecting some fallout. But there was none the patch even
survives a bootstrap on x86_64-linux. I'm hesitant to call it the
fix, I'd like to have a second look at it after the weekend but if
someone wants to test meanwhile, such input would be highly welcome.
Martin, this patch is wrong:
consider this test example:
/* PR middle-end/57748 */
/* { dg-do run } */
#include stdlib.h
extern void abort (void);
typedef long long V
__attribute__ ((vector_size (2 * sizeof (long long)), may_alias));
typedef double V1
__attribute__ ((vector_size (1 * sizeof (double)), may_alias));
typedef struct S { V a; V1 b[0]; } P __attribute__((aligned (1)));
struct __attribute__((packed)) T { char c; P s; };
void __attribute__((noinline, noclone))
check (struct T *t)
{
if (t-s.b[0][0] != 3)
abort ();
}
int __attribute__((noinline, noclone))
get_i (void)
{
return 0;
}
void __attribute__((noinline, noclone))
foo (P *p)
{
V1 a = { 3 };
int i = get_i();
p-b[i] = a;
}
int
main ()
{
struct T *t = (struct T *) malloc (128);
foo (t-s);
check (t);
return 0;
}
this example is designed to go thru the
if (bitsize != GET_MODE_BITSIZE (mode)) path.
Because the struct mode is derived from V but the bitsize
is from V1, only half of V.
the resulting code from this patch accesses out of bounds:
foo:
.LFB9:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq%rdi, %rbx
subq$16, %rsp
.cfi_def_cfa_offset 32
callget_i
cltq
movq.LC1(%rip), %xmm1
addq$2, %rax
movdqu (%rbx,%rax,8), %xmm0
psrldq $8, %xmm0
punpcklqdq %xmm0, %xmm1
movdqu %xmm1, (%rbx,%rax,8)
addq$16, %rsp
.cfi_def_cfa_offset 16
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
while my latest patch (which meanwhile was boot-straped without regressions)
generates this:
foo:
.LFB9:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq%rdi, %rbx
callget_i
movsd .LC0(%rip), %xmm0
cltq
movsd %xmm0, 16(%rbx,%rax,8)
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #28 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Richard Biener from comment #19)
Barking up wrong trees. Hacky fix looks like:
Index: gcc/expr.c
===
--- gcc/expr.c (revision 202043)
+++ gcc/expr.c (working copy)
@@ -4753,6 +4753,9 @@ expand_assignment (tree to, tree from, b
{
enum machine_mode address_mode;
rtx offset_rtx;
+ rtx saved_to_rtx = to_rtx;
+ if (misalignp)
+ to_rtx = mem;
if (!MEM_P (to_rtx))
{
@@ -4785,6 +4788,11 @@ expand_assignment (tree to, tree from, b
to_rtx = offset_address (to_rtx, offset_rtx,
highest_pow2_factor_for_target (to,
offset));
+ if (misalignp)
+ {
+ mem = to_rtx;
+ to_rtx = saved_to_rtx;
+ }
}
/* No action is needed if the target is not a memory and the field
this patch generates wrong code too:
foo:
.LFB9:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq%rdi, %rbx
subq$16, %rsp
.cfi_def_cfa_offset 32
callget_i
movdqu (%rbx), %xmm0
cltq
movq.LC1(%rip), %xmm1
psrldq $8, %xmm0
punpcklqdq %xmm0, %xmm1
movdqu %xmm1, 16(%rbx,%rax,8)
addq$16, %rsp
.cfi_def_cfa_offset 16
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
loads *s into xmm0, modifies low part,
writes back at s-b[0] and s-b[1].
[Bug middle-end/57748] [4.7/4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Summary|[4.8/4.9 Regression] ICE|[4.7/4.8/4.9 Regression] |when expanding assignment |ICE when expanding |to unaligned zero-sized |assignment to unaligned |array |zero-sized array --- Comment #30 from Richard Biener rguenth at gcc dot gnu.org --- At least the wrong-code issue is latent on the 4.7 branch.
[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #29 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #28)
(In reply to Richard Biener from comment #19)
Barking up wrong trees. Hacky fix looks like:
Index: gcc/expr.c
===
--- gcc/expr.c (revision 202043)
+++ gcc/expr.c (working copy)
@@ -4753,6 +4753,9 @@ expand_assignment (tree to, tree from, b
{
enum machine_mode address_mode;
rtx offset_rtx;
+ rtx saved_to_rtx = to_rtx;
+ if (misalignp)
+ to_rtx = mem;
if (!MEM_P (to_rtx))
{
@@ -4785,6 +4788,11 @@ expand_assignment (tree to, tree from, b
to_rtx = offset_address (to_rtx, offset_rtx,
highest_pow2_factor_for_target (to,
offset));
+ if (misalignp)
+ {
+ mem = to_rtx;
+ to_rtx = saved_to_rtx;
+ }
}
/* No action is needed if the target is not a memory and the field
this patch generates wrong code too:
foo:
.LFB9:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq%rdi, %rbx
subq$16, %rsp
.cfi_def_cfa_offset 32
callget_i
movdqu (%rbx), %xmm0
cltq
movq.LC1(%rip), %xmm1
psrldq $8, %xmm0
punpcklqdq %xmm0, %xmm1
movdqu %xmm1, 16(%rbx,%rax,8)
addq$16, %rsp
.cfi_def_cfa_offset 16
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
loads *s into xmm0, modifies low part,
writes back at s-b[0] and s-b[1].
This bug is latent because we use the mode of the base object to query
for movmisalign_optab (and use it). It highlights the issue I raised
in my last comment.
So, new, completely untested patch:
Index: gcc/expr.c
===
--- gcc/expr.c (revision 202240)
+++ gcc/expr.c (working copy)
@@ -4646,10 +4646,12 @@ expand_assignment (tree to, tree from, b
/* Handle misaligned stores. */
mode = TYPE_MODE (TREE_TYPE (to));
- if ((TREE_CODE (to) == MEM_REF
- || TREE_CODE (to) == TARGET_MEM_REF)
- mode != BLKmode
- !mem_ref_refers_to_non_mem_p (to)
+ if (mode != BLKmode
+ (DECL_P (to)
+ || handled_component_p (to)
+ || ((TREE_CODE (to) == MEM_REF
+ || TREE_CODE (to) == TARGET_MEM_REF)
+ !mem_ref_refers_to_non_mem_p (to)))
((align = get_object_alignment (to))
GET_MODE_ALIGNMENT (mode))
(((icode = optab_handler (movmisalign_optab, mode))
@@ -4696,7 +4698,6 @@ expand_assignment (tree to, tree from, b
int unsignedp;
int volatilep = 0;
tree tem;
- bool misalignp;
rtx mem = NULL_RTX;
push_temp_slots ();
@@ -4707,40 +4708,7 @@ expand_assignment (tree to, tree from, b
DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
get_bit_range (bitregion_start, bitregion_end, to, bitpos, offset);
- /* If we are going to use store_bit_field and extract_bit_field,
-make sure to_rtx will be safe for multiple use. */
- mode = TYPE_MODE (TREE_TYPE (tem));
- if (TREE_CODE (tem) == MEM_REF
- mode != BLKmode
- ((align = get_object_alignment (tem))
- GET_MODE_ALIGNMENT (mode))
- ((icode = optab_handler (movmisalign_optab, mode))
- != CODE_FOR_nothing))
- {
- struct expand_operand ops[2];
-
- misalignp = true;
- to_rtx = gen_reg_rtx (mode);
- mem = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
-
- /* If the misaligned store doesn't overwrite all bits, perform
-rmw cycle on MEM. */
- if (bitsize != GET_MODE_BITSIZE (mode))
- {
- create_input_operand (ops[0], to_rtx, mode);
- create_fixed_operand (ops[1], mem);
- /* The movmisalignmode pattern cannot fail, else the assignment
-would silently be omitted. */
- expand_insn (icode, 2, ops);
-
- mem = copy_rtx (mem);
- }
- }
- else
- {
- misalignp = false;
- to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
- }
+ to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
/* If the bitfield is volatile, we want to access it in the
field's mode, not the
[Bug middle-end/57748] [4.7/4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
--- Comment #31 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Richard Biener from comment #29)
(In reply to Bernd Edlinger from comment #28)
(In reply to Richard Biener from comment #19)
Barking up wrong trees. Hacky fix looks like:
Index: gcc/expr.c
===
--- gcc/expr.c (revision 202043)
+++ gcc/expr.c (working copy)
@@ -4753,6 +4753,9 @@ expand_assignment (tree to, tree from, b
{
enum machine_mode address_mode;
rtx offset_rtx;
+ rtx saved_to_rtx = to_rtx;
+ if (misalignp)
+ to_rtx = mem;
if (!MEM_P (to_rtx))
{
@@ -4785,6 +4788,11 @@ expand_assignment (tree to, tree from, b
to_rtx = offset_address (to_rtx, offset_rtx,
highest_pow2_factor_for_target (to,
offset));
+ if (misalignp)
+ {
+ mem = to_rtx;
+ to_rtx = saved_to_rtx;
+ }
}
/* No action is needed if the target is not a memory and the field
this patch generates wrong code too:
foo:
.LFB9:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq%rdi, %rbx
subq$16, %rsp
.cfi_def_cfa_offset 32
callget_i
movdqu (%rbx), %xmm0
cltq
movq.LC1(%rip), %xmm1
psrldq $8, %xmm0
punpcklqdq %xmm0, %xmm1
movdqu %xmm1, 16(%rbx,%rax,8)
addq$16, %rsp
.cfi_def_cfa_offset 16
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
loads *s into xmm0, modifies low part,
writes back at s-b[0] and s-b[1].
This bug is latent because we use the mode of the base object to query
for movmisalign_optab (and use it). It highlights the issue I raised
in my last comment.
So, new, completely untested patch:
Index: gcc/expr.c
===
--- gcc/expr.c (revision 202240)
+++ gcc/expr.c (working copy)
@@ -4646,10 +4646,12 @@ expand_assignment (tree to, tree from, b
/* Handle misaligned stores. */
mode = TYPE_MODE (TREE_TYPE (to));
- if ((TREE_CODE (to) == MEM_REF
- || TREE_CODE (to) == TARGET_MEM_REF)
- mode != BLKmode
- !mem_ref_refers_to_non_mem_p (to)
+ if (mode != BLKmode
+ (DECL_P (to)
+ || handled_component_p (to)
+ || ((TREE_CODE (to) == MEM_REF
+ || TREE_CODE (to) == TARGET_MEM_REF)
+ !mem_ref_refers_to_non_mem_p (to)))
((align = get_object_alignment (to))
GET_MODE_ALIGNMENT (mode))
(((icode = optab_handler (movmisalign_optab, mode))
@@ -4696,7 +4698,6 @@ expand_assignment (tree to, tree from, b
int unsignedp;
int volatilep = 0;
tree tem;
- bool misalignp;
rtx mem = NULL_RTX;
push_temp_slots ();
@@ -4707,40 +4708,7 @@ expand_assignment (tree to, tree from, b
DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
get_bit_range (bitregion_start, bitregion_end, to, bitpos,
offset);
- /* If we are going to use store_bit_field and extract_bit_field,
-make sure to_rtx will be safe for multiple use. */
- mode = TYPE_MODE (TREE_TYPE (tem));
- if (TREE_CODE (tem) == MEM_REF
- mode != BLKmode
- ((align = get_object_alignment (tem))
- GET_MODE_ALIGNMENT (mode))
- ((icode = optab_handler (movmisalign_optab, mode))
- != CODE_FOR_nothing))
- {
- struct expand_operand ops[2];
-
- misalignp = true;
- to_rtx = gen_reg_rtx (mode);
- mem = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
-
- /* If the misaligned store doesn't overwrite all bits, perform
-rmw cycle on MEM. */
- if (bitsize != GET_MODE_BITSIZE (mode))
- {
- create_input_operand (ops[0], to_rtx, mode);
- create_fixed_operand (ops[1], mem);
- /* The movmisalignmode pattern cannot fail, else the
assignment
-would silently be omitted. */
- expand_insn (icode, 2, ops);
-
- mem = copy_rtx (mem);
- }
- }
- else
- {
- misalignp = false;
- to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
- }
+ to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
/* If the bitfield is volatile, we want to access it in the
field's mode, not the computed mode.
@@ -4879,17 +4847,6 @@ expand_assignment
[Bug libgcj/55637] FAIL: sourcelocation output - source compiled test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637 Mark Wielaard mark at gcc dot gnu.org changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #6 from Mark Wielaard mark at gcc dot gnu.org --- Does the .log file give any more hints? Or could someone that sees the test failing run it by hand and show the output?
[Bug libgcj/55637] FAIL: sourcelocation output - source compiled test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637 --- Comment #7 from Matthias Klose doko at gcc dot gnu.org --- it prints -1 -1 -1
[Bug libgcj/55637] FAIL: sourcelocation output - source compiled test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637 --- Comment #8 from Mark Wielaard mark at gcc dot gnu.org --- What happens when you run it by hand? $ gij -cp ./libjava/testsuite/libjava.lang/sourcelocation.jar sourcelocation 10 13 15 -1 indicates something went wrong, which is indeed not very helpful.
[Bug ipa/58313] [4.9 Regression] kdelibs build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58313 --- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de --- Probably dup of Bug 58201.
[Bug c++/58201] [4.9 Regression] Undefined reference to `B::B(void const**)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58201 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot de --- Comment #6 from Markus Trippelsdorf markus at trippelsdorf dot de --- *** Bug 58313 has been marked as a duplicate of this bug. ***
[Bug ipa/58313] [4.9 Regression] kdelibs build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58313 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de --- dup *** This bug has been marked as a duplicate of bug 58201 ***
[Bug libgcj/55637] FAIL: sourcelocation output - source compiled test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637 --- Comment #9 from Mark Wielaard mark at gcc dot gnu.org --- I assume this is some weirdness in the testsuite. It does indeed fail for me in a make check, but seems to work just fine when ran by hand.
[Bug libgcj/55637] FAIL: sourcelocation output - source compiled test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637 --- Comment #10 from Mark Wielaard mark at gcc dot gnu.org --- O wait, it is more complicated than that. My by hand tests were using the interpreter. But there are multiple sourcelocation tests: PASS: sourcelocation compilation from source PASS: sourcelocation execution - source compiled test FAIL: sourcelocation output - source compiled test PASS: sourcelocation -findirect-dispatch compilation from source PASS: sourcelocation -findirect-dispatch execution - source compiled test FAIL: sourcelocation -findirect-dispatch output - source compiled test PASS: sourcelocation -O3 compilation from source PASS: sourcelocation -O3 execution - source compiled test FAIL: sourcelocation -O3 output - source compiled test PASS: sourcelocation -O3 -findirect-dispatch compilation from source PASS: sourcelocation -O3 -findirect-dispatch execution - source compiled test PASS: sourcelocation -O3 -findirect-dispatch output - source compiled test So sometimes the output does PASS.
[Bug libgcj/55637] FAIL: sourcelocation output - source compiled test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637 --- Comment #11 from Mark Wielaard mark at gcc dot gnu.org --- It seems somewhat related to the binutils version. The results form comment #10 are with binutils-2.20.51.0.2-5.36.el6.x86_64 If I build and put current binutils trunk on the path the results change (for the worse): PASS: sourcelocation compilation from source PASS: sourcelocation execution - source compiled test FAIL: sourcelocation output - source compiled test PASS: sourcelocation -findirect-dispatch compilation from source PASS: sourcelocation -findirect-dispatch execution - source compiled test FAIL: sourcelocation -findirect-dispatch output - source compiled test PASS: sourcelocation -O3 compilation from source PASS: sourcelocation -O3 execution - source compiled test FAIL: sourcelocation -O3 output - source compiled test PASS: sourcelocation -O3 -findirect-dispatch compilation from source PASS: sourcelocation -O3 -findirect-dispatch execution - source compiled test FAIL: sourcelocation -O3 -findirect-dispatch output - source compiled test Now all output tests fail... hohum.
[Bug c++/58076] internal compiler error: tree check: expected tree that contains ‘decl common’ structure, have ‘identifier_node’ in get_narrower, at tree.c:8500
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58076 --- Comment #3 from chenpoyang young.cpy at gmail dot com --- Before I see an error when compiling gcc, now forgotten...- -
[Bug lto/53808] Undefined symbol when building a library with lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53808 --- Comment #4 from Rafael Avila de Espindola rafael.espindola at gmail dot com --- The equivalent clang bug (llvm.org/pr13124) just got fixed by avoiding the devirtualization in this case. Not sure how similar the issues are internally, but I summarized what I found in clang in: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130902/087810.html
[Bug debug/58315] [4.8/4.9 Regression] Excessive memory use with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 30747 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30747action=edit testcase
[Bug debug/58315] [4.8/4.9 Regression] Excessive memory use with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.2
[Bug debug/58315] New: [4.8/4.9 Regression] Excessive memory use with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315 Bug ID: 58315 Summary: [4.8/4.9 Regression] Excessive memory use with -g Product: gcc Version: 4.8.1 Status: UNCONFIRMED Keywords: memory-hog Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Compiling the PPL testsuite, specifically MIP_Problem/mipproblem1.cc, with -O2 -g makes GCC use nearly 6GB of memory (followed by GAS needing 6.5GB of memory to assemble the result). Dropping -g results in instant gratification.
[Bug debug/58315] [4.8/4.9 Regression] Excessive memory use with -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Unsurprisingly the culprit is var-tracking. Disabling it gets memory use down to 250MB.
[Bug c++/58304] gcc dev branch compilation Failed at libstdc++-v3 (used gcc 4.7.3 to compile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58304 --- Comment #3 from Harsha harsha.patankar at gmail dot com --- I'm compiling Revision: 202247 using gcc 4.7.3. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@202247 138bc75d-0d04-0410-961f-82ee72b054a4 And my OS is Ubuntu 64-bit Linux DESK 3.8.0-29-generic #42-Ubuntu SMP Tue Aug 13 19:40:39 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[Bug c++/58304] gcc dev branch compilation Failed at libstdc++-v3 (used gcc 4.7.3 to compile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58304 --- Comment #4 from Harsha harsha.patankar at gmail dot com --- Created attachment 30748 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30748action=edit config.log attached
[Bug c++/58201] [4.9 Regression] Undefined reference to `B::B(void const**)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58201 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org --- OK, the destructor is used as: _ZN1BD2EPPKv/21 (B::~B()) @0x7f56014ecd10 Type: function Visibility: external public References: Referring: Availability: not_available Function flags: Called by: _ZN1C2C2D2Ev/4 (1.00 per call) (can throw external) _ZN1C2C2D1Ev/5 (1.00 per call) Calls: _ZN1C2C2D2Ev/4 (C::C2::~C2()) @0x7f56014d2d10 Type: function definition analyzed Visibility: public Aux: @0x7f56014d2e40 References: __gxx_personality_v0/18 (addr) Referring: Function flags: body Called by: Calls: A::~A()/20 (1.00 per call) void operator delete(void*)/22 (1.00 per call) A::~A()/20 (1.00 per call) B::~B()/21 (1.00 per call) Now with older GCC we do not output _ZN1C2C2D2Ev Older GCC gets: C::C2::~C2()/4 @0x7f15ce0c6360 (asm: _ZN1C2C2D2Ev) analyzed needed reachable body finalized called by: calls: A::~A()/16 (1.00 per call) void operator delete(void*)/14 (1.00 per call) A::~A()/16 (1.00 per call) (can throw external) B::~B()/15 (1.00 per call) References: fn:built-in/17 (addr) Refering this function: B::~B()/15 @0x7f15ce0d4000 (asm: _ZN1BD2Ev) availability:not_available called by: C::C2::~C2()/4 (1.00 per call) (can throw external) virtual C::C2::~C2()/5 (1.00 per call) calls: References: Refering this function: So it calls B::~B() instead of B::~B(void const**) The extra const** parameter is however passed in both I am not really sure how this difference happens...
[Bug c++/58201] [4.9 Regression] Undefined reference to `B::B(void const**)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58201 --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org --- Created attachment 30749 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30749action=edit Proposed fix.
[Bug bootstrap/58186] LTO profiledbootstrap fails in stage feedback for fortran/frontend-passes.c with edge ... has no corresponding call_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58186 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org --- This ought to be fixed now. Does it still reproduce to you?
[Bug c++/58201] [4.9 Regression] Undefined reference to `B::B(void const**)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58201 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- In C++ destructors don't have parameters, so the question is where the bogusly mangled name comes from. Is that coming from the implicit this argument that is somehow used again in the mangling (though that would be the class *const, wouldn't it)?
[Bug middle-end/58125] [4.9 Regression] ICE: in operator[], at vec.h:827 with -fno-inline-small-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58125 --- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org --- OK, the testcase no longer reproduces, but the dump seems clear. We introduced new aliases but did not resize the summary vector, because we do not need info for these. Then we attempt to free it and ICE. I am testing Index: ipa-inline-analysis.c === --- ipa-inline-analysis.c (revision 202199) +++ ipa-inline-analysis.c (working copy) @@ -4019,7 +4019,8 @@ if (!inline_edge_summary_vec.exists ()) return; FOR_EACH_DEFINED_FUNCTION (node) -reset_inline_summary (node); +if (!node-symbol.alias) + reset_inline_summary (node); if (function_insertion_hook_holder) cgraph_remove_function_insertion_hook (function_insertion_hook_holder); function_insertion_hook_holder = NULL; and will commit it along with the PR if that passes.
[Bug c++/58316] error: call of overloaded ‘foo(long long unsigned int, long long unsigned int)’ is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58316 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Integer conversions are not ranked by size. The call is ambiguous, G++ is correct. Intel and clang agree.
[Bug c++/58316] New: error: call of overloaded ‘foo(long long unsigned int, long long unsigned int)’ is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58316
Bug ID: 58316
Summary: error: call of overloaded ‘foo(long long unsigned int,
long long unsigned int)’ is ambiguous
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pluto at agmk dot net
$ cat t.cpp
#if !defined( __GNUC__) !defined( __x86_64__)
#error testcase requires LLP64 arch
#endif
typedef unsigned long u64_t1;
void foo( u64_t1, u64_t1 );
void foo( unsigned, unsigned );
void bar()
{
foo( 0xull, 0xull );
}
$ g++ -Wall t.cpp -c -m64
t.cpp: In function ‘void bar()’:
t.cpp:12:52: error: call of overloaded ‘foo(long long unsigned int, long long
unsigned int)’ is ambiguous
foo( 0xull, 0xull );
^
t.cpp:12:52: note: candidates are:
t.cpp:7:6: note: void foo(u64_t1, u64_t1)
void foo( u64_t1, u64_t1 );
^
t.cpp:8:6: note: void foo(unsigned int, unsigned int)
void foo( unsigned, unsigned );
^
the 'unsigned long' and 'unsigned long long' have the same size
on the x86-64(llp64) target, so where's the ambiguity?
[Bug lto/57776] [4.9 Regression] FAIL: gcc.dg/lto/pr56297 c_lto_pr56297_0.o-c_lto_pr56297_1.o link, -flto -fno-common (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57776 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed now.
[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Jan Hubicka hubicka at gcc dot gnu.org --- Closing thus.
[Bug lto/58084] [4.9 Regression] FAIL: gcc.dg/torture/pr8081.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58084 --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org --- The patch to fix this is issue is proposed at http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00078.html If a type is refered to by two functions it is by definition not local. But as it references a local entity it is local. Note that you seem to have put the type local for RESULT_DECL but still have the global type used for the function type that hangs off the function decl. That type also refers to the PARM_DECLs which are local, too now AFAIK. While it was discussed in more generality the thread of http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00058.html , I will just add my understanding to this particular problem here. The type of RESULT_DECL was always local by tree_indexable predicate, since it is variable sized and it reffers to local variable of the outer function in its DECL_SIZE. The fact that RESULT_DECL was in global stream did not solve it. The effect was that RESULT_DECL pushed another copy of the type into global stream referring another copy of the local variable from global stream that will never get unified with the real local variable in the local stream. We do not ICE because we compare types for equality between returned value and returned type. Still the types are ill formed - we have three copies of the type after streaming in (one global and one for each of the functions) and three copies of the local variable (breaking one declaration rule). We happen to survive because we do not need the bad ones. If we had another use of the type besides the returning we would get the same problem even with global RESULT_DECL. One can not write a testcase as for some reason assignment of variable sized types is forbidden, while returning is allowed. The other ICE in thunks should be fixed by http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00078.html
[Bug tree-optimization/58011] GCC segfaults at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58011 --- Comment #2 from eraman at gcc dot gnu.org --- Author: eraman Date: Wed Sep 4 17:48:15 2013 New Revision: 202262 URL: http://gcc.gnu.org/viewcvs?rev=202262root=gccview=rev Log: 2013-09-04 Easwaran Raman era...@google.com PR middle-end/57370 PR tree-optimization/58011 * tree-ssa-reassoc.c (get_stmt_uid_with_default): New function, (build_and_add_sum): Use it. (appears_later_in_bb): Simplify code. gcc/testsuite/ChangeLog: 2013-09-04 Easwaran Raman era...@google.com PR middle-end/57370 PR tree-optimization/58011 * gfortran.dg/reassoc_12.f90: New testcase. * gcc.dg/tree-ssa/reassoc-31.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-31.c trunk/gcc/testsuite/gfortran.dg/reassoc_12.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug tree-optimization/57370] [4.9 Regression] compiler hangs in reassoc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370 --- Comment #10 from eraman at gcc dot gnu.org --- Author: eraman Date: Wed Sep 4 17:48:15 2013 New Revision: 202262 URL: http://gcc.gnu.org/viewcvs?rev=202262root=gccview=rev Log: 2013-09-04 Easwaran Raman era...@google.com PR middle-end/57370 PR tree-optimization/58011 * tree-ssa-reassoc.c (get_stmt_uid_with_default): New function, (build_and_add_sum): Use it. (appears_later_in_bb): Simplify code. gcc/testsuite/ChangeLog: 2013-09-04 Easwaran Raman era...@google.com PR middle-end/57370 PR tree-optimization/58011 * gfortran.dg/reassoc_12.f90: New testcase. * gcc.dg/tree-ssa/reassoc-31.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-31.c trunk/gcc/testsuite/gfortran.dg/reassoc_12.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug middle-end/58096] [4.9 Regression] gcc.dg/tree-ssa/attr-alias.c fails with r201439
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58096 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Pat Haugen pthaugen at gcc dot gnu.org --- (In reply to Hans-Peter Nilsson from comment #6) This is fixed for cris-elf in (201978:202144] apparently r202111 as also obvious from the message at gcc-patches. It's probably fixed everywhere. Can Pat the reporter or Jan the fixer please verify and close if so? Confirmed this is no longer failing on trunk, closing.
[Bug c++/58316] error: call of overloaded ‘foo(long long unsigned int, long long unsigned int)’ is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58316 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Closing.
[Bug bootstrap/58304] gcc dev branch compilation Failed at libstdc++-v3 (used gcc 4.7.3 to compile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58304 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- You should really figure out what's so special about your setup/system, because we have so many reports of successful builds, just look at gcc-testresults.
[Bug c++/24926] gcc ignores access level violation for anonymous structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24926 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Sep 4 23:52:48 2013 New Revision: 202266 URL: http://gcc.gnu.org/viewcvs?rev=202266root=gccview=rev Log: /cp 2013-09-04 Paolo Carlini paolo.carl...@oracle.com PR c++/24926 * class.c (finish_struct_anon_r): New. (finish_struct_anon): Use it. /testsuite 2013-09-04 Paolo Carlini paolo.carl...@oracle.com PR c++/24926 * g++.dg/parse/access11.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/access11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug c++/24926] gcc ignores access level violation for anonymous structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24926 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug c++/58317] New: Calling a method while preparing to call the constructor should be illegal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58317
Bug ID: 58317
Summary: Calling a method while preparing to call the
constructor should be illegal
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oleg at smolsky dot net
struct Thing {
Thing(int);
int f();
};
void test() {
Thing instance(instance.f());
}
The aforementioned code is idiotic and should not compile. Yet it does with gcc
4.8:
/bin/x86_64-unknown-linux-g++ -Wall -c bug.cc
[Bug tree-optimization/58318] New: very slow compilation on x86_64-linux with -O3 and -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58318
Bug ID: 58318
Summary: very slow compilation on x86_64-linux with -O3 and -g
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code takes much longer to compile with both -O3 and -g on using
the current gcc trunk on x86_64-linux (in both 32-bit and 64-bit modes).
4.8 is considerably faster than the trunk, while 4.6 and 4.7 are much slower.
For reference, I also included the times for clang and icc.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130904 (experimental) [trunk revision 202240] (GCC)
$
$
$ time gcc-trunk -O3 reduced.c
0.06user 0.00system 0:00.23elapsed 30%CPU (0avgtext+0avgdata 51792maxresident)k
0inputs+32outputs (0major+7258minor)pagefaults 0swaps
$
$
$ time gcc-trunk -O3 -g reduced.c
11.70user 0.68system 0:18.93elapsed 65%CPU (0avgtext+0avgdata
1133520maxresident)k
0inputs+64outputs (0major+297028minor)pagefaults 0swaps
$
$
$ time gcc-4.8 -O3 -g reduced.c
0.89user 0.12system 0:01.54elapsed 65%CPU (0avgtext+0avgdata
487552maxresident)k
0inputs+64outputs (0major+50913minor)pagefaults 0swaps
$
$
$ time gcc-4.7 -O3 -g reduced.c
84.09user 0.10system 1:57.58elapsed 71%CPU (0avgtext+0avgdata
580944maxresident)k
0inputs+64outputs (0major+41887minor)pagefaults 0swaps
$
$
$ time gcc-4.6 -O3 -g reduced.c
83.83user 0.16system 2:00.92elapsed 69%CPU (0avgtext+0avgdata
558864maxresident)k
0inputs+64outputs (0major+40733minor)pagefaults 0swaps
$
$
$ time clang-trunk -O3 -g reduced.c
0.02user 0.00system 0:00.09elapsed 34%CPU (0avgtext+0avgdata 52064maxresident)k
0inputs+40outputs (0major+6282minor)pagefaults 0swaps
$
$
$ time icc -O3 -g reduced.c
0.26user 2.39system 0:04.07elapsed 65%CPU (0avgtext+0avgdata 84000maxresident)k
1424inputs+184outputs (14major+16463minor)pagefaults 0swaps
$
$
-
int a, b, c, d;
int *foo (int *r, short s, short t)
{
return c;
}
short bar (int p)
{
int t = 0;
for (a = 0; a 8; a++)
for (b = 0; b 8; b++)
for (p = 0; p 8; p++)
for (d = 0; d 8; d++)
foo (t, p, d);
bar (0);
return 0;
}
int main ()
{
return 0;
}
