[Bug middle-end/57370] [4.9 Regression] compile time hog in reassoc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- I killed the compilation after 15h...
[Bug c++/57384] New: can't expand a parameter pack into a list of function types or function pointer types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57384
Bug ID: 57384
Summary: can't expand a parameter pack into a list of function
types or function pointer types
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
I believe all of the following 4 test cases should pass:
templatetypename ...Ts
struct list
{};
templatetypename ...Ts
struct S
{
using type1 = void(int...(Ts));// fails
using type2 = listint...(Ts);// fails
using type3 = void(int(*...)(Ts)); // fails
using type4 = listint(*...)(Ts); // works with 4.7, fails with 4.8
};
Currently (i.e. with gcc-4.8), 1-4 all fail. With gcc-4.7, (4) worked. I'm
compiling with -std=gnu++11
[Bug rtl-optimization/57381] [4.8/4.9 Regression] array of volatile pointers hangs gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57381 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-05-23 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.8.1 Summary|array of volatile pointers |[4.8/4.9 Regression] array |hangs gcc |of volatile pointers hangs ||gcc Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Mine. Hangs in 0x00caeac6 in visit_use (use=0x76e3eee8) at /space/rguenther/src/svn/trunk/gcc/tree-ssa-sccvn.c:3469 3469changed = visit_reference_op_store (lhs, rhs1, stmt);
[Bug rtl-optimization/57381] [4.8/4.9 Regression] array of volatile pointers hangs gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57381 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- The usual a.b.c with volatile fields do not compare equal thing ... Value numbering l_61$0$0$0_6 stmt = l_61$0$0$0_6 = MEM[(volatile int *[5][2][2] *)*.LC0]; RHS MEM[(volatile int *[5][2][2] *)*.LC0] simplified to s.f2.f0 has constants 1 Setting value number of l_61$0$0$0_6 to s.f2.f0 (changed) and s.f2.f0 never comparing equal because we unshare it in every iteration. Which is because operand_equal_p compares the FIELD_DECLs of COMPONENT_REFs after clearing OEP_CONSTANT_ADDRESS_OF but those have TREE_SIDE_EFFECTS set as well and we hit /* If ARG0 and ARG1 are the same SAVE_EXPR, they are necessarily equal. We don't care about side effects in that case because the SAVE_EXPR takes care of that for us. In all other cases, two expressions are equal if they have no side effects. If we have two identical expressions with side effects that should be treated the same due to the only side effects being identical SAVE_EXPR's, that will be detected in the recursive calls below. If we are taking an invariant address of two identical objects they are necessarily equal as well. */ if (arg0 == arg1 ! (flags OEP_ONLY_CONST) (TREE_CODE (arg0) == SAVE_EXPR || (flags OEP_CONSTANT_ADDRESS_OF) || (! TREE_SIDE_EFFECTS (arg0) ! TREE_SIDE_EFFECTS (arg1 return 1;
[Bug target/53854] ICE in find_constant_pool_ref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53854 --- Comment #6 from Dan Horák dan at danny dot cz --- FYI the error is still present in gcc version 4.8.0 20130412 (Red Hat 4.8.0-2) (GCC) Target: s390-redhat-linux
[Bug tree-optimization/57380] [4.7/4.8/4.9 Regression] GCC 4.9.0 will not vectorize std::max and similar functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57380 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-05-23 Known to work||4.5.4 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.7.4 Summary|GCC 4.9.0 will not |[4.7/4.8/4.9 Regression] |vectorize std::max and |GCC 4.9.0 will not |similar functions |vectorize std::max and ||similar functions Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- For some reason phiprop doesn't work here. I'll investigate, but I guess it is because the addresses are not constant but depend on the loop IV: bb 3: _3 = b.data[i_2]; _4 = a.data[i_2]; _10 = MEM[(const int )a].data[i_2]; _11 = MEM[(const int )b].data[i_2]; if (_10 _11) goto bb 5; else goto bb 4; bb 4: bb 5: # iftmp.0_12 = PHI _3(3), _4(4) bb 6: _6 = *iftmp.0_12;
[Bug target/57379] [4.9 Regression]: Segfault in invalidate_any_buried_refs (x=0x0) at ../../gcc-svn/trunk/gcc/gcse.c:3850
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57379 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c++/57378] gnu multiversioning gives assembler error: foo.resolver is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57378 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-23 CC||tmsriram at google dot com Version|unknown |4.8.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug c++/57384] can't expand a parameter pack into a list of function types or function pointer types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57384 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Eric Niebler from comment #0) I believe all of the following 4 test cases should pass: I'll leave it to someone else to rule on that, they make my head hurt ;) I will note that this works: using type2 = listint(Ts)...; and this works: using type4 = listint(*)(Ts)...; And of course all these work: templateclass X using F = int(X); using type1 = void(FTs...); using type2 = listFTs...; templateclass X using Fp = int(*)(X); using type3 = void(FpTs...); using type4 = listFpTs...;
[Bug tree-optimization/57380] [4.7/4.8/4.9 Regression] GCC 4.9.0 will not vectorize std::max and similar functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57380 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- There was a deliberate change to require at least one invariant address or a re-use of a previous load. 2010-07-08 Richard Guenther rguent...@suse.de + PR tree-optimization/44831 + * tree-ssa-phiprop.c (phiprop_insert_phi): Properly build + a MEM_REF preserving TBAA info of the original dereference. + Dereference the original pointer if the address is not + invariant. + (propagate_with_phi): Fixup type checks wrt MEM_REFs. Require + at least one invariant address that we are going to dereference. I have a fix.
[Bug rtl-optimization/57344] [4.7 Regression] wrong code with pragma pack(1) and -O1 on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57344 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.1, 4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] wrong code |wrong code with pragma |with pragma pack(1) and -O1 |pack(1) and -O1 on x86 |on x86 Known to fail|4.9.0 | --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu May 23 09:17:34 2013 New Revision: 199238 URL: http://gcc.gnu.org/viewcvs?rev=199238root=gccview=rev Log: PR middle-end/57344 * expmed.c (store_split_bit_field): If op0 is a REG or SUBREG of a REG, don't lower unit. Handle unit not being always BITS_PER_WORD. * gcc.c-torture/execute/pr57344-1.c: New test. * gcc.c-torture/execute/pr57344-2.c: New test. * gcc.c-torture/execute/pr57344-3.c: New test. * gcc.c-torture/execute/pr57344-4.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr57344-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57344-2.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57344-3.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57344-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c trunk/gcc/testsuite/ChangeLog Author: jakub Date: Thu May 23 09:18:57 2013 New Revision: 199239 URL: http://gcc.gnu.org/viewcvs?rev=199239root=gccview=rev Log: PR middle-end/57344 * expmed.c (store_split_bit_field): If op0 is a REG or SUBREG of a REG, don't lower unit. Handle unit not being always BITS_PER_WORD. * gcc.c-torture/execute/pr57344-1.c: New test. * gcc.c-torture/execute/pr57344-2.c: New test. * gcc.c-torture/execute/pr57344-3.c: New test. * gcc.c-torture/execute/pr57344-4.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr57344-1.c branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr57344-2.c branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr57344-3.c branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr57344-4.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/expmed.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog Fixed for 4.8/4.9+ so far.
[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #2 from Rainer Orth ro at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #1) I solved the infinite loop problem on plugin enabled setups with http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00847.html Are you still seeing the infinite loop? My last bootstrap with gld was at rev 199009, i.e. before that patch went in. New ones are currently running (as/ld though, thus it will take a bit to verify that the failures with gld are gone). That gas/gld bootstrap has now completed and the failures are indeed gone. Thanks. Rainer
[Bug target/57341] [4.8/4.9 Regression] wrong code on x86_64-linux at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57341 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu May 23 08:37:24 2013 New Revision: 199237 URL: http://gcc.gnu.org/viewcvs?rev=199237root=gccview=rev Log: 2013-05-23 Richard Biener rguent...@suse.de PR rtl-optimization/57341 * ira.c (validate_equiv_mem_from_store): Use anti_dependence instead of true_dependence. * gcc.dg/torture/pr57341.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr57341.c Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/57381] [4.8 Regression] array of volatile pointers hangs gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57381 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Target Milestone|4.8.1 |4.8.2 Summary|[4.8/4.9 Regression] array |[4.8 Regression] array of |of volatile pointers hangs |volatile pointers hangs gcc |gcc | Known to fail||4.8.1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu May 23 10:08:33 2013 New Revision: 199240 URL: http://gcc.gnu.org/viewcvs?rev=199240root=gccview=rev Log: 2013-05-23 Richard Biener rguent...@suse.de PR middle-end/57381 * fold-const.c (operand_equal_p): Compare FIELD_DECLs with OEP_CONSTANT_ADDRESS_OF retained. * gcc.dg/torture/pr57381.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr57381.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug target/57341] [4.8/4.9 Regression] wrong code on x86_64-linux at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57341 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu May 23 10:36:55 2013 New Revision: 199242 URL: http://gcc.gnu.org/viewcvs?rev=199242root=gccview=rev Log: 2013-05-23 Richard Biener rguent...@suse.de PR rtl-optimization/57341 * ira.c (validate_equiv_mem_from_store): Use anti_dependence instead of true_dependence. * gcc.dg/torture/pr57341.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr57341.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/ira.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/57287] GCC 4.9.0 fails to build GDB on Ubuntu 12.04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287 --- Comment #4 from hmb muhammad_bilal at mentor dot com --- I am attaching the all preprocessed source code of GDB here is the link https://www.dropbox.com/s/ldml34p3lov867w/gcc-bug.zip
[Bug middle-end/57287] GCC 4.9.0 fails to build GDB on Ubuntu 12.04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed with -O2 -Wall.
[Bug middle-end/57287] GCC 4.9.0 fails to build GDB on Ubuntu 12.04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 30172 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30172action=edit preprocessed source
[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366 --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org --- Thanks. Obviously RTL world translates through the weakrefs w/o LTO but not with LTO. I will look into it.
[Bug tree-optimization/57385] New: [tree-ssa] Possible segfault in fully_constant_vn_reference_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57385
Bug ID: 57385
Summary: [tree-ssa] Possible segfault in
fully_constant_vn_reference_p
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aivchenk at gmail dot com
CC: aivchenk at gmail dot com
The following code crashes android ndk gcc-4.6 on 64 bit windows with segfault
on at least -O1:
int c;
void foo(int f)
{
int wbi=-1;
c = (f ? 012346:01345:6008)[wbi];
}
However, potentially it can appear on trunk as well: the reason for this is
that in fully_constant_vn_reference_p we have a bound violation:
1303| if (arg0-opcode == STRING_CST
1304|(TYPE_MODE (op-type)
1305| == TYPE_MODE (TREE_TYPE (TREE_TYPE (arg0-op0
1306|GET_MODE_CLASS (TYPE_MODE (op-type)) == MODE_INT
1307|GET_MODE_SIZE (TYPE_MODE (op-type)) == 1
1308|compare_tree_int (op-op0, TREE_STRING_LENGTH (arg0-op0))
0)
1309| return build_int_cst_type (op-type,
1310+ (TREE_STRING_POINTER (arg0-op0)
1311| [TREE_INT_CST_LOW (op-op0)]));
here the TREE_INT_CST_LOW (op-op0) is 0x (wbi from the code snippet
above and int_cst.low is unsigned). but here:
1308|compare_tree_int (op-op0, TREE_STRING_LENGTH (arg0-op0))
0)
compare_tree_int thinks that op-op0 equals to -1 and so the check for bound
violation passes.
I think we need to add another check that op-op0 is not less than zero here.
[Bug tree-optimization/57385] [tree-ssa] Possible segfault in fully_constant_vn_reference_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57385 --- Comment #1 from Alexander Ivchenko aivchenk at gmail dot com --- Following fix could solve the problem: diff --git a/gcc-4.6/gcc/tree-ssa-sccvn.c b/gcc-4.6/gcc/tree-ssa-sccvn.c index eb88969..704a86c 100644 --- a/gcc-4.6/gcc/tree-ssa-sccvn.c +++ b/gcc-4.6/gcc/tree-ssa-sccvn.c @@ -1115,6 +1115,7 @@ fully_constant_vn_reference_p (vn_reference_t ref) == TYPE_MODE (TREE_TYPE (TREE_TYPE (arg0-op0 GET_MODE_CLASS (TYPE_MODE (op-type)) == MODE_INT GET_MODE_SIZE (TYPE_MODE (op-type)) == 1 + tree_int_cst_sgn (op-op0) = 0 compare_tree_int (op-op0, TREE_STRING_LENGTH (arg0-op0)) 0) return build_int_cst_type (op-type, (TREE_STRING_POINTER (arg0-op0)
[Bug tree-optimization/57380] [4.7/4.8 Regression] GCC 4.9.0 will not vectorize std::max and similar functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57380 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] GCC |GCC 4.9.0 will not |4.9.0 will not vectorize |vectorize std::max and |std::max and similar |similar functions |functions Known to fail|4.9.0 |4.8.1 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu May 23 12:23:59 2013 New Revision: 199246 URL: http://gcc.gnu.org/viewcvs?rev=199246root=gccview=rev Log: 2013-05-23 Richard Biener rguent...@suse.de PR tree-optimization/57380 * tree-ssa-phiprop.c (propagate_with_phi): Do not require at least one invariant or re-used load. * passes.c (init_optimization_passes): Move pass_phiprop before pass_forwprop. * g++.dg/tree-ssa/pr57380.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr57380.C Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-phiprop.c
[Bug tree-optimization/57385] [tree-ssa] Possible segfault in fully_constant_vn_reference_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57385 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- True. Please post to gcc-patches and do a bootstrap/test with it.
[Bug tree-optimization/57385] [tree-ssa] Possible segfault in fully_constant_vn_reference_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57385 --- Comment #3 from Alexander Ivchenko aivchenk at gmail dot com --- Testing is in progress, will send to gcc-patches rigth after that.
[Bug target/56446] Generate one fewer relocation when calling a checked weakref function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56446 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org --- default_binds_local_p should do the job, but it doesn't follow the aliases. With LTO the weakref target can be brought local and then the weakref can be translated to normal static alias, but we don't do this at the moment. I am in progress of making my mind on when this is valid. Honza
[Bug libstdc++/57386] New: ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 Bug ID: 57386 Summary: ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: stigge at antcom dot de Created attachment 30173 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30173action=edit debug file from ICE ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn Hi, on powerpc SPE (e500v2) native compiling of gcc 4.8.0 (on current Debian sid), I get: libtool: compile: /home/ernie/gcc-4.8-4.8.0/build/./gcc/xgcc -shared-libgcc -B/home/ernie/gcc-4.8-4.8.0/build/./gcc -nostdinc++ -L/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/src -L/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/src/.libs -B/usr/powerpc-linux-gnuspe/bin/ -B/usr/powerpc-linux-gnuspe/lib/ -isystem /usr/powerpc-linux-gnuspe/include -isystem /usr/powerpc-linux-gnuspe/sys-include -isystem /home/ernie/gcc-4.8-4.8.0/build/sys-include -I/home/ernie/gcc-4.8-4.8.0/src/libstdc++-v3/../libgcc -I/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/include/powerpc-linux-gnuspe -I/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/include -I/home/ernie/gcc-4.8-4.8.0/src/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=hash_tr1.lo -gdwarf-4 -g3 -O0 -c ../../../../../../src/libstdc++-v3/src/c++98/hash_tr1.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o hash_tr1.o /bin/bash ../../../libtool --tag CXX --tag disable-shared --mode=compile /home/ernie/gcc-4.8-4.8.0/build/./gcc/xgcc -shared-libgcc -B/home/ernie/gcc-4.8-4.8.0/build/./gcc -nostdinc++ -L/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/src -L/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/src/.libs -B/usr/powerpc-linux-gnuspe/bin/ -B/usr/powerpc-linux-gnuspe/lib/ -isystem /usr/powerpc-linux-gnuspe/include -isystem /usr/powerpc-linux-gnuspe/sys-include -isystem /home/ernie/gcc-4.8-4.8.0/build/sys-include -I/home/ernie/gcc-4.8-4.8.0/src/libstdc++-v3/../libgcc -I/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/include/powerpc-linux-gnuspe -I/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/include -I/home/ernie/gcc-4.8-4.8.0/src/libstdc++-v3/libsupc++ -prefer-pic -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=hashtable_tr1.lo -gdwarf-4 -g3 -O0 -c -o hashtable_tr1.lo ../../../../../../src/libstdc++-v3/src/c++98/hashtable_tr1.cc libtool: compile: /home/ernie/gcc-4.8-4.8.0/build/./gcc/xgcc -shared-libgcc -B/home/ernie/gcc-4.8-4.8.0/build/./gcc -nostdinc++ -L/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/src -L/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/src/.libs -B/usr/powerpc-linux-gnuspe/bin/ -B/usr/powerpc-linux-gnuspe/lib/ -isystem /usr/powerpc-linux-gnuspe/include -isystem /usr/powerpc-linux-gnuspe/sys-include -isystem /home/ernie/gcc-4.8-4.8.0/build/sys-include -I/home/ernie/gcc-4.8-4.8.0/src/libstdc++-v3/../libgcc -I/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/include/powerpc-linux-gnuspe -I/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/include -I/home/ernie/gcc-4.8-4.8.0/src/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=hashtable_tr1.lo -gdwarf-4 -g3 -O0 -c ../../../../../../src/libstdc++-v3/src/c++98/hashtable_tr1.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o hashtable_tr1.o /bin/bash ../../../libtool --tag CXX --tag disable-shared --mode=compile /home/ernie/gcc-4.8-4.8.0/build/./gcc/xgcc -shared-libgcc -B/home/ernie/gcc-4.8-4.8.0/build/./gcc -nostdinc++ -L/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/src -L/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/src/.libs -B/usr/powerpc-linux-gnuspe/bin/ -B/usr/powerpc-linux-gnuspe/lib/ -isystem /usr/powerpc-linux-gnuspe/include -isystem /usr/powerpc-linux-gnuspe/sys-include -isystem /home/ernie/gcc-4.8-4.8.0/build/sys-include -I/home/ernie/gcc-4.8-4.8.0/src/libstdc++-v3/../libgcc -I/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/include/powerpc-linux-gnuspe -I/home/ernie/gcc-4.8-4.8.0/build/powerpc-linux-gnuspe/libstdc++-v3/include -I/home/ernie/gcc-4.8-4.8.0/src/libstdc++-v3/libsupc++ -prefer-pic -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
--- Comment #9 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
the following patch sets IDENTIFIER_TRANSPARENT_ALIAS correctly from lto-symtab
(correct fix should do the same for variable aliases, too). Now the testcase
compiles for
me on Linux with weakref disabled. Does it work for you?
I can not bootstrap with the weakref disabling hack because of some
transational memory issue, but I think it is independent.
Honza
Index: lto-symtab.c
===
--- lto-symtab.c(revision 199251)
+++ lto-symtab.c(working copy)
@@ -623,6 +623,15 @@ lto_symtab_merge_cgraph_nodes (void)
if ((cnode-thunk.thunk_p || cnode-alias)
cnode-thunk.alias DECL_P (cnode-thunk.alias))
cnode-thunk.alias = lto_symtab_prevailing_decl (cnode-thunk.alias);
+#ifndef ASM_OUTPUT_WEAKREF
+ if (lookup_attribute (weakref, DECL_ATTRIBUTES (cnode-symbol.decl)))
+{
+ IDENTIFIER_TRANSPARENT_ALIAS (DECL_ASSEMBLER_NAME (cnode-symbol.decl))
= 1;
+ TREE_CHAIN (DECL_ASSEMBLER_NAME (cnode-symbol.decl))
+ = (DECL_P (cnode-thunk.alias) ? DECL_ASSEMBLER_NAME
(cnode-thunk.alias)
+ : cnode-thunk.alias);
+}
+#endif
cnode-symbol.aux = NULL;
}
FOR_EACH_VARIABLE (vnode)
[Bug middle-end/57347] [4.8/4.9 Regression] wrong code for bitfield on x86_64-linux at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57347 --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Thu May 23 13:20:41 2013 New Revision: 199252 URL: http://gcc.gnu.org/viewcvs?rev=199252root=gccview=rev Log: 2013-05-22 Martin Jambor mjam...@suse.cz PR middle-end/57347 * tree.h (contains_bitfld_component_ref_p): Declare. * tree-sra.c (contains_bitfld_comp_ref_p): Move... * tree.c (contains_bitfld_component_ref_p): ...here. Adjust its caller. * ipa-prop.c (determine_known_aggregate_parts): Check that LHS does not access a bit-field. Assert all final offsets are byte-aligned. testsuite/ * gcc.dg/ipa/pr57347.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ipa/pr57347.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c trunk/gcc/tree.c trunk/gcc/tree.h
[Bug middle-end/57347] [4.8/4.9 Regression] wrong code for bitfield on x86_64-linux at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57347 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Thu May 23 13:25:23 2013 New Revision: 199253 URL: http://gcc.gnu.org/viewcvs?rev=199253root=gccview=rev Log: 2013-05-23 Martin Jambor mjam...@suse.cz PR middle-end/57347 * tree.h (contains_bitfld_component_ref_p): Declare. * tree-sra.c (contains_bitfld_comp_ref_p): Move... * tree.c (contains_bitfld_component_ref_p): ...here. Adjust its caller. * ipa-prop.c (determine_known_aggregate_parts): Check that LHS does not access a bit-field. Assert all final offsets are byte-aligned. testsuite/ * gcc.dg/ipa/pr57347.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/ipa/pr57347.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/ipa-prop.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-sra.c branches/gcc-4_8-branch/gcc/tree.c branches/gcc-4_8-branch/gcc/tree.h
[Bug c++/57387] New: Passing parameter pack to emplace stl function cause compilation bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57387 Bug ID: 57387 Summary: Passing parameter pack to emplace stl function cause compilation bug Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: avraammauridis at gmail dot com Created attachment 30174 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30174action=edit bug output g++ -std=c++0x stlstudy.cc ‘ Internal compiler error: Error reporting routines re-entered. Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions. Preprocessed source stored into /tmp/cc7q32tE.out file, please attach this to your bugreport.
[Bug middle-end/57287] GCC 4.9.0 fails to build GDB on Ubuntu 12.04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||xinliangli at gmail dot com --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- tree-ssa-uninit.c somehow fails to properly handle abnormal edges. Index: tree-ssa-uninit.c === --- tree-ssa-uninit.c (revision 199249) +++ tree-ssa-uninit.c (working copy) @@ -1919,7 +1919,8 @@ find_uninit_use (gimple phi, unsigned un } worklist-safe_push (use_stmt); - pointer_set_insert (possibly_undefined_names, phi_result); + if (!SSA_NAME_OCCURS_IN_ABNORMAL_PHI (phi_result)) + pointer_set_insert (possibly_undefined_names, phi_result); } } fixes the issue but that doesn't look the very best place to fix it and it doesn't look fully correct. It should be enough to not consider values flowing across abnormal edges - but that's already done (but somehow not in a complete manner). I'm trying to reduce the testcase to get a better idea what is going wrong here.
[Bug libstdc++/57386] ICE: hash-long-double-tr1-aux.cc:54:7: error: unrecognizable insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57386 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||powerpc-spe Status|UNCONFIRMED |WAITING Last reconfirmed||2013-05-23 Host||powerpc-spe Ever confirmed|0 |1 Build||powerpc-spe --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Can you check gcc 4.8.1 RC1?
[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #16 from chrbr at gcc dot gnu.org --- Fixed on trunk #199261.
[Bug c++/57387] Passing parameter pack to emplace stl function cause compilation bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57387 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Seems to be fixed for 4.8 already.
[Bug middle-end/57287] GCC 4.9.0 fails to build GDB on Ubuntu 12.04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 30175 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30175action=edit somewhat reduced testcase Autoreduced on level 0.
[Bug middle-end/57287] GCC 4.9.0 fails to build GDB on Ubuntu 12.04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 30176 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30176action=edit more reduced
[Bug c++/57388] New: [C++11] ICE when function types with ref-qualifiers meet other function types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57388
Bug ID: 57388
Summary: [C++11] ICE when function types with ref-qualifiers
meet other function types
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
While attempting to upgrade std::function for functions with ref-qualifiers I
found that the following code gives an ICE for gcc 4.9.0 20130519
(experimental). The compiler flags are:
-std=c++11 -Wall -pedantic
//--
templateclass struct A
{
static constexpr bool value = false;
};
templateclass Res, class... Args
struct ARes(Args...)
{
static constexpr bool value = true;
};
templateclass Res, class... Args
struct ARes(Args...) const
{
static constexpr bool value = true;
};
templateclass Res, class... Args
struct ARes(Args...) const
{
static constexpr bool value = true;
};
static_assert(Avoid()::value, Ouch);
static_assert(Avoid() const ::value, ); // #1
static_assert(Avoid() const ::value, ); // #2
//--
The error being (at line #1 or if this is commented on line #2):
main.cpp|25|internal compiler error: canonical types differ for identical
types void() const and void() const
The conditions seem to depend on type ordering. The ICE doesn't occur, when the
last three lines are inverted to
static_assert(Avoid() const ::value, );
static_assert(Avoid() const ::value, );
static_assert(Avoid()::value, Ouch);
or if typedefs are introduces for functions with ref-qualifiers up-front such
as in the following replacement of the last three lines:
typedef void FClref() const ;
static_assert(Avoid()::value, Ouch);
static_assert(Avoid() const ::value, );
static_assert(Avoid() const ::value, );
Interestingly the following variant
typedef void FClref() const ;
static_assert(Avoid()::value, Ouch);
static_assert(Avoid() const ::value, ); // #1
static_assert(Avoid() const ::value, );
still ICEs for #1 (but the previous one didn't ICE on the last line)
[Bug c++/57384] can't expand a parameter pack into a list of function types or function pointer types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57384 --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com --- I have the impression that this *could* be related to http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1488 This is unchecked yet, because I'm leaving my place here.
[Bug c++/57388] [C++11] ICE when function types with ref-qualifiers meet other function types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57388 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Let's add Jason in CC.
[Bug c++/57319] [4.8 Regression]: bogus defaulted move assignment for ... calls a non-trivial move assignment operator for virtual base ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57319 --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- Thanks for the fix. Confirmed for both the reduced test case, and the original source. Can this be back-ported to 4.8 branch?
[Bug libstdc++/54354] TODO extended iomanip manipulators std::get_time and std::put_time (C++11, section 27.7.5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54354 Daniel Morilha dmorilha at gmail dot com changed: What|Removed |Added CC||dmorilha at gmail dot com --- Comment #3 from Daniel Morilha dmorilha at gmail dot com --- any update on that? is there any workaround? I am trying to parse from ISO 8601 date/time format to C++11 time_points and relied on std::get_time to do the parsing work. Any ideas on how to accomplish that by other means? Thanks
[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace with ms_abi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146 Ben Woodard woodard at redhat dot com changed: What|Removed |Added Attachment #30127|0 |1 is obsolete|| --- Comment #9 from Ben Woodard woodard at redhat dot com --- Created attachment 30177 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30177action=edit updated patch that includes __builtin_expect
[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace with ms_abi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146 --- Comment #10 from Richard Henderson rth at gcc dot gnu.org --- (In reply to Ben Woodard from comment #9) Created attachment 30177 [details] updated patch that includes __builtin_expect The patch in #8 is better, and indeed has a bug fix relative to this in that the condition should be = DWARF_FRAME_REGISTERS. Note that the array size is DWARF_FRAME_REGISTERS + 1.
[Bug c++/57388] [C++11] ICE when function types with ref-qualifiers meet other function types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57388 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-05-23 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/57317] [4.8/4.9 Regression] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57317 --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- (In reply to Jason Merrill from comment #2) Fixed the false positive for 4.8.1. Did you mean fixed on trunk ? On trunk I see 2013-05-20 Jason Merrill ja...@redhat.com PR c++/57317 * decl2.c (determine_visibility): Use PRIMARY_TEMPLATE_P to decide whether a template has its own args. but nothing on 4_8-branch. Can this be back-ported to 4.8? Thanks,
[Bug c++/57375] gnu multiversioning selects different version depending on link order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57375 Sriraman Tallam tmsriram at google dot com changed: What|Removed |Added CC||davidxl at google dot com --- Comment #2 from Sriraman Tallam tmsriram at google dot com --- IMO, This is working as expected. You define corei7 only in mv12-aux1.cc, so the compilation of mv12.C and mv12-aux.cc do not see the corei7 version. The version resolver function that is generated is a comdat function, and there are 2 copies generated for the 2 source files with a call to foo, mv12.C and mv12-aux1.cc. However, one of the copies is different, that generated when compiling mv12-aux1.cc because it has the extra corei7 version. So, depending on the link order whichever comdat copy gets kept either calls the corei7 version or not. Usually, the linker keeps the first comdat copy seen so if you put mv12-aux1.cc ahead of mv12.C, the corei7 version will be called and the reverse will not call it. The fix is in the source. Either make every source file see the corei7 version or hide it from all. The linker can be made to complain that the comdats differ if it could be taught about version resolvers. This may be more involved.
[Bug middle-end/57366] gcc.dg/lto/attr-weakref-1 FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #9 from Jan Hubicka hubicka at ucw dot cz --- Hi, the following patch sets IDENTIFIER_TRANSPARENT_ALIAS correctly from lto-symtab (correct fix should do the same for variable aliases, too). Now the testcase compiles for me on Linux with weakref disabled. Does it work for you? It does and is a considerable improvement: it fixes -FAIL: g++.dg/lto/20091219 cp_lto_20091219_0.o-cp_lto_20091219_0.o link, -O3 -fl to (internal compiler error) -UNRESOLVED: g++.dg/lto/20091219 cp_lto_20091219_0.o-cp_lto_20091219_0.o execute -O3 -flto i.e. PR lto/47333 and several of the failures from this PR, but not all of them: UNRESOLVED: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakr ef-1_2.o execute -O2 -flto -flto-partition=none FAIL: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2 .o link, -O0 -flto -flto-partition=1to1 (internal compiler error) UNRESOLVED: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakr ef-1_2.o execute -O0 -flto -flto-partition=1to1 -FAIL: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2 .o link, -O2 -flto -flto-partition=1to1 -UNRESOLVED: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakr ef-1_2.o execute -O2 -flto -flto-partition=1to1 -FAIL: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2 .o link, -O0 -flto -UNRESOLVED: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakr ef-1_2.o execute -O0 -flto -FAIL: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2 .o link, -O2 -flto -UNRESOLVED: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakr ef-1_2.o execute -O2 -flto i.e. those failures remain: FAIL: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto -flto-partition=none UNRESOLVED: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o execute -O0 -flto -flto-partition=none FAIL: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O2 -flto -flto-partition=none UNRESOLVED: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o execute -O2 -flto -flto-partition=none FAIL: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o link, -O0 -flto -flto-partition=1to1 (internal compiler error) UNRESOLVED: gcc.dg/lto/attr-weakref-1 c_lto_attr-weakref-1_0.o-c_lto_attr-weakref-1_2.o execute -O0 -flto -flto-partition=1to1 Btw., the patch has a few formatting issues: indentation and line length. Thanks. Rainer
[Bug libstdc++/54354] TODO extended iomanip manipulators std::get_time and std::put_time (C++11, section 27.7.5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54354 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- We are trying to break the ABI for 4.9
[Bug c++/57375] gnu multiversioning selects different version depending on link order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57375 --- Comment #3 from davidxl at google dot com --- (In reply to Sriraman Tallam from comment #2) IMO, This is working as expected. You define corei7 only in mv12-aux1.cc, so the compilation of mv12.C and mv12-aux.cc do not see the corei7 version. The version resolver function that is generated is a comdat function, and there are 2 copies generated for the 2 source files with a call to foo, mv12.C and mv12-aux1.cc. However, one of the copies is different, that generated when compiling mv12-aux1.cc because it has the extra corei7 version. So, depending on the link order whichever comdat copy gets kept either calls the corei7 version or not. Usually, the linker keeps the first comdat copy seen so if you put mv12-aux1.cc ahead of mv12.C, the corei7 version will be called and the reverse will not call it. The fix is in the source. Either make every source file see the corei7 version or hide it from all. The linker can be made to complain that the comdats differ if it could be taught about version resolvers. This may be more involved. There is no need to conditionally declare/define corei7 version in one file only -- the additional time cost is very small. David
[Bug c++/57248] string parameter to constexpr functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57248 --- Comment #2 from Sumant Tambe sutambe at yahoo dot com --- I'm a bit confused. Is the program illformed or supposed to compile but does not.
[Bug c++/57378] gnu multiversioning gives assembler error: foo.resolver is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57378 Sriraman Tallam tmsriram at google dot com changed: What|Removed |Added CC||davidxl at google dot com --- Comment #2 from Sriraman Tallam tmsriram at google dot com --- First, what is happening here is the first call to foo is only seeing 2 versions and the second call to foo is seeing the 3rd corei7 version. Was this intentional? When the dispatcher/resovler decl is created, the cgraph nodes of all versions are mapped to this decl. However, the new version decl (corei7 version) is created later, after the first call, and hence it is not mapped to the dispatcher function decl that was previously generated. Hence the second call re-generates it. There are a couple of issues here. Should the first call to foo () even get access to the corei7 version which is not visible? If the corei7 version should not be visible to the first call I must create 2 resolvers, one for the first call and the other for the second call. This gets complicated and I want to leave this for future enhancement. Currently, what is supported is that all calls must see all the versions that will be created. I can create a patch to generate an appropriate error here so that this is made clear.
[Bug c++/57378] gnu multiversioning gives assembler error: foo.resolver is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57378 --- Comment #3 from davidxl at google dot com --- Can the resolver node be updated? or a new dispatcher/resolver is created? The user code looks fine to me, which exposes the implementation limitation. David (In reply to Sriraman Tallam from comment #2) First, what is happening here is the first call to foo is only seeing 2 versions and the second call to foo is seeing the 3rd corei7 version. Was this intentional? When the dispatcher/resovler decl is created, the cgraph nodes of all versions are mapped to this decl. However, the new version decl (corei7 version) is created later, after the first call, and hence it is not mapped to the dispatcher function decl that was previously generated. Hence the second call re-generates it. There are a couple of issues here. Should the first call to foo () even get access to the corei7 version which is not visible? If the corei7 version should not be visible to the first call I must create 2 resolvers, one for the first call and the other for the second call. This gets complicated and I want to leave this for future enhancement. Currently, what is supported is that all calls must see all the versions that will be created. I can create a patch to generate an appropriate error here so that this is made clear.
[Bug rtl-optimization/57359] wrong code for union access at -O3 on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359 --- Comment #3 from Dara Hazeghi dhazeghi at yahoo dot com --- My apologies for the invalid report and thank you for the clear explanation. I've been using frama-c to check validity of the testcases, but clearly in this case it's not sufficient.
[Bug debug/57389] New: ICE in dbx_reg_number, at dwarf2out.c:10507 on powerpc-spe target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57389 Bug ID: 57389 Summary: ICE in dbx_reg_number, at dwarf2out.c:10507 on powerpc-spe target Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: rmansfield at qnx dot com Target: powerpc-e500v2-linux-gnuspe spe targets are failing to build libgcc. $ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: powerpc-e500v2-linux-gnuspe Configured with: ../configure --target=powerpc-e500v2-linux-gnuspe --prefix=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe --with-sysroot=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnuspe/sys-root --disable-multilib --with-cpu=8548 --with-tune=8548 --with-gmp=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe --with-mpfr=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe --enable-__cxa_atexit --with-local-prefix=/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnuspe/sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99 --enable-long-long --enable-target-optspace --enable-e500_double --with-long-double-128 target_alias=powerpc-e500v2-linux-gnuspe --enable-languages=c,c++,lto Thread model: posix gcc version 4.9.0 20130523 (experimental) [trunk revision 199267] (GCC) /home/ryan/gnu/gcc/trunk/spe-build/./gcc/xgcc -B/home/ryan/gnu/gcc/trunk/spe-build/./gcc/ -B/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnuspe/bin/ -B/home/ryan/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnuspe/lib/ -isystem /home/ryan/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnuspe/include -isystem /home/ryan/x-tools/powerpc-e500v2-linux-gnuspe/powerpc-e500v2-linux-gnuspe/sys-include -g -Os -O2 -g -Os -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -mlong-double-128 -mno-minimal-toc -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include -I../../../libgcc/../libdecnumber/dpd -I../../../libgcc/../libdecnumber -DHAVE_CC_TLS -o _powidf2.o -MT _powidf2.o -MD -MP -MF _powidf2.dep -DL_powidf2 -c ../../../libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS ../../../libgcc/libgcc2.c: In function '__powidf2': ../../../libgcc/libgcc2.c:1777:1: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 } ^ 0x64377e dbx_reg_number ../../gcc/dwarf2out.c:10507 0x64377e dbx_reg_number ../../gcc/dwarf2out.c:10503 0x66b447 multiple_reg_loc_descriptor ../../gcc/dwarf2out.c:10664 0x66b447 reg_loc_descriptor ../../gcc/dwarf2out.c:10578 0x66eb43 loc_descriptor ../../gcc/dwarf2out.c:12951 0x66ee46 loc_descriptor ../../gcc/dwarf2out.c:12983 0x66f3b5 dw_loc_list_1 ../../gcc/dwarf2out.c:13256 0x66b86b dw_loc_list ../../gcc/dwarf2out.c:13512 0x66b86b loc_list_from_tree ../../gcc/dwarf2out.c:13897 0x670de9 add_location_or_const_value_attribute ../../gcc/dwarf2out.c:15391 0x670de9 add_location_or_const_value_attribute ../../gcc/dwarf2out.c:15333 0x671261 gen_formal_parameter_die ../../gcc/dwarf2out.c:17190 0x65f694 gen_decl_die ../../gcc/dwarf2out.c:20191 0x65cb9b gen_subprogram_die ../../gcc/dwarf2out.c:18063 0x65f634 gen_decl_die ../../gcc/dwarf2out.c:20102 0x660688 dwarf2out_function_decl ../../gcc/dwarf2out.c:20492 0x6c1dc4 rest_of_handle_final ../../gcc/final.c:4393 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/57388] [C++11] ICE when function types with ref-qualifiers meet other function types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57388 --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Daniel Krügler from comment #0) While attempting to upgrade std::function for functions with ref-qualifiers [..] Oops, I meant std::is_function of-course.
[Bug libstdc++/54354] TODO extended iomanip manipulators std::get_time and std::put_time (C++11, section 27.7.5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54354 --- Comment #5 from Daniel Morilha dmorilha at gmail dot com --- I just realized I can use operating system functionality to achieve the same goal. Please ignore my question and thanks for the quick follow up. Looking forward to gcc 4.9.0
[Bug c++/57319] [4.8 Regression]: bogus defaulted move assignment for ... calls a non-trivial move assignment operator for virtual base ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57319 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Paul Pluzhnikov from comment #3) Can this be back-ported to 4.8 branch? After 4.8.1, I think.
[Bug c++/57248] string parameter to constexpr functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57248
--- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com ---
The code looks valid to me. I think that Paolo just wanted to point out that
the library implementation does not cause this. I agree with him and can
confirm that the code is also rejected when emulating the library such as in
the following way:
templatebool, class
struct enable_if{};
templateclass T
struct enable_iftrue, T{ typedef T type; };
templateclass T1, class T2
struct tuple
{
T1 t1;
T2 t2;
};
templateunsigned I, class T1, class T2
constexpr
typename enable_ifI == 0, T1::type
get(tupleT1, T2 t) { return t.t1; }
templateunsigned I, class T1, class T2
constexpr
typename enable_ifI == 1, T1::type
get(tupleT1, T2 t) { return t.t2; }
templateclass T1, class T2
constexpr tupleT1, T2 make_tuple(T1 t1, T2 t2)
{
return tupleT1, T2{t1, t2};
}
Same error here.
[Bug rtl-optimization/57359] wrong code for union access at -O3 on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- NP, and thanks a lot for the bugreports, they are very much appreciated.
[Bug c++/57319] [4.8 Regression]: bogus defaulted move assignment for ... calls a non-trivial move assignment operator for virtual base ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57319 Richard Smith richard-gccbugzilla at metafoo dot co.uk changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #5 from Richard Smith richard-gccbugzilla at metafoo dot co.uk --- (In reply to Jason Merrill from comment #1) (In reply to Paul Pluzhnikov from comment #0) However, this particular case *isn't* the problematic case, because (a) this sample code should not trigger the definition of C's move assignment operator, and True, the warning is given at declaration time; it would be possible to move the warning to when the move assignment is used, but that might mean design errors don't get caught until later. OK, that makes sense. However, delaying the check until the operator= is lazily declared does not fully achieve this goal. Could the check be performed at the end of the definition of class C (rather than, presumably, when looking for a virtual C::operator= for D::operator= to override)? (b) there is only one inheritance path from C to B, so it won't be move-assigned multiple times, and True, the warning is given at the point of first virtual derivation rather than when it appears in a diamond-shaped hierarchy. But the purpose of virtual derivation is to support diamond-shaped hierarchies, so again it seems appropriate to warn sooner rather than later. OK. The class which brings together the diamond may provide a move assignment operator which does not blindly call the move assignment operators on the base classes, so this can still have some false positives even if every virtual base is involved in diamond inheritance.
[Bug c++/57317] [4.8/4.9 Regression] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57317 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Paul Pluzhnikov from comment #3) but nothing on 4_8-branch. Look again; it's commit 199104 on gcc-4_8-branch.
[Bug c++/57317] [4.8/4.9 Regression] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57317 --- Comment #5 from Paul Pluzhnikov ppluzhnikov at google dot com --- (In reply to Jason Merrill from comment #4) Look again; it's commit 199104 on gcc-4_8-branch. I can see it now. Thanks for the fix!
[Bug c++/57384] can't expand a parameter pack into a list of function types or function pointer types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57384
--- Comment #3 from Eric Niebler eric.niebler at gmail dot com ---
Interesting. I filed a similar bug against clang
(http://llvm.org/bugs/show_bug.cgi?id=16118), where Richard Smith seems to feel
the test cases should be:
templatetypename ...Ts
struct list
{};
templatetypename ...Ts
struct S
{
using type1 = void(int...(Ts));// (1) fails
using type2 = listint(Ts)...;// (2) works
using type3 = void(int(*...)(Ts)); // (3) fails
using type4 = listint(*)(Ts)...; // (4) works
};
This strikes me as ludicrously inconsistent. I think we need guidance from the
committee here. I was basing my bug report(s) on the example in 8.3.5/13 (which
shows:
templatetypename... T void f(T (* ...t)(int, int));
The suggestion that the pack expansion syntax differs depending on the context
in which the expansion occurs is, um, unsatisfactory.
[Bug middle-end/57286] [4.9 regression] infinite recursion in fold-const.c:10037
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57286 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Marc Glisse glisse at gcc dot gnu.org --- .
[Bug middle-end/56934] ICE folding a COND_EXPR involving vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56934 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Known to fail|4.9.0 | --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- Fixed on trunk.
[Bug c++/57248] string parameter to constexpr functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57248
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
Thanks Daniel. In fact - I should have attached some code - nothing about
tuple co matters, you can remove it completely and replace std::get with,
say,
template int N
constexpr int get() { return 1; }
[Bug c++/37140] type inherited from base class not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks a lot!
[Bug c++/57390] New: Fixed point types on AVR are not available in C++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57390 Bug ID: 57390 Summary: Fixed point types on AVR are not available in C++ mode Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ambrop7 at gmail dot com As of version 4.8, GCC supports fixed point types for the AVR target. See: http://gcc.gnu.org/wiki/avr-gcc#Fixed-Point_Support However, this is only available in C and not in C++. Please enable fixed point for C++ too. It may have to be hidden behind an option to not break existing C++ code though.
[Bug c++/57390] Fixed point types on AVR are not available in C++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57390 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- There is no way to enable it for C++ because the extension has not been designed to how it would interact with templates and such. See the thread at http://gcc.gnu.org/ml/gcc/2011-11/msg00124.html for more info.
[Bug c++/57390] Fixed point types on AVR are not available in C++ mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57390 --- Comment #2 from Ambroz Bizjak ambrop7 at gmail dot com --- I've been reading the discussion there, but I don't see any interaction problems with templates. Most of it is just useless arguing about whether fixed point types can be implemented externally with templates. The support in the GCC code is already there, what is the real obstacle to enabling that in C++?
