[Bug lto/64374] [5 Regression] LTO ICE in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64374 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- I see another issue. When we stream in OPTIMIZATION_NODE/TARGET_OPTIONS_NODE, we don't use build_optimization_node/build_target_option_node and thus we don't merge identical nodes by hashing them together in between different streamed in TUs (or does it happen somehow else)? If it doesn't happen, then it unnecessarily slows down lto1, because it needs to reinitialize the backend more often and switch in between different target options even when they are effectively the same. Though, of course, if we'd hash them together, we'd need to call some target hook to resync the streamed in options with the global state before hashing them together, because they can't be changed while they are in the hash table.
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888
--- Comment #31 from Jakub Jelinek jakub at gcc dot gnu.org ---
Any progress on this?
If not, I'm considering doing:
--- libsanitizer/asan/asan_globals.cc.jj2014-11-14 00:10:34.0 +0100
+++ libsanitizer/asan/asan_globals.cc2015-02-20 11:43:33.179177767 +0100
@@ -148,7 +148,9 @@ static void RegisterGlobal(const Global
CHECK(AddrIsInMem(g-beg));
CHECK(AddrIsAlignedByGranularity(g-beg));
CHECK(AddrIsAlignedByGranularity(g-size_with_redzone));
- if (flags()-detect_odr_violation) {
+ // This ODR violation detection is fundamentally incompatible with
+ // how GCC registers globals. Disable as useless until rewritten upstream.
+ if (0 flags()-detect_odr_violation) {
// Try detecting ODR (One Definition Rule) violation, i.e. the situation
// where two globals with the same name are defined in different modules.
if (__asan_region_is_poisoned(g-beg, g-size_with_redzone)) {
for now.
[Bug rtl-optimization/64081] [5 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- Any progress on this?
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888 --- Comment #32 from Yury Gribov y.gribov at samsung dot com --- Or (probably less intrusive) add detect_odr_violation=0 to ASAN_OPTIONS config/bootstrap-asan.mk.
[Bug target/64452] [4.8/4.9/5.0 Regression] ICE in avr-gcc when passing struct member to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64452 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Fri Feb 20 11:15:56 2015 New Revision: 220849 URL: https://gcc.gnu.org/viewcvs?rev=220849root=gccview=rev Log: gcc/ Backport from 2015-02-20 trunk r220847. PR target/64452 * config/avr/avr.md (pushhi_insn): New insn. (pushmode1): Push virtual regs in one chunk using pushhi1_insn. gcc/testsuite/ Backport from 2015-02-20 trunk r220847. PR target/64452 * gcc.target/avr/torture/pr64452.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/avr/torture/pr64452.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/avr/avr.md branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/64969] generic functions do not work with placeholder return types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64969 Harald van Dijk harald at gigawatt dot nl changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #3 from Harald van Dijk harald at gigawatt dot nl --- This happens because auto is encoded as a template parameter that is one level deeper than the currently deepest real template parameter. In other words, auto f() is encoded as template-param-1-1 f(), and template typename T auto f() is encoded as template typename T template-param-2-1 f(). Given auto f1(auto x), when the first auto is parsed, it becomes template-param-1-1 f1(auto x). When the second auto is parsed, and the function implicitly becomes a template, it looks like template typename auto template-param-1-1 f1(template-param-1-1 x) where the first template-param-1-1 should be template-param-2-1. Instead of fixing up existing references to auto when a function is implicitly made a template, how about encoding auto as a template argument with a level of zero, and adding a tf_auto flag for tsubst to specify that auto is to be replaced? If that flag is specified, fix up the zero by changing it to (processing_template_decl+1), if that flag is not specified, leave auto alone. All that seems to be needed aside from that, in a quick test, is making reduce_template_parm_level aware of them, making it leave a level of zero at zero. The cases in this bug pass, and manually running tests on gcc/testsuite/g++.dg/cpp1y/auto* doesn't show problems either. I'll do some more extensive testing, and also run the full test suite.
[Bug middle-end/64491] [5 Regression] incorrect warning: loop exit may only be reached after undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491 --- Comment #10 from Andrew Stubbs ams at gcc dot gnu.org --- I'm trying to look at this problem, but so far all my builds are failing. Probably I have some local cruft. In the meantime, the workaround is to use -Wno-aggressive-loop-optimizations, I think.
[Bug target/64347] constructor priorities are not supported in avr-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64347 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org --- constructor priority is same as init priority, cf. PR60588. *** This bug has been marked as a duplicate of bug 60588 ***
[Bug target/60588] AVR target does not support init_priority attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60588 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 CC||gjl at gcc dot gnu.org
[Bug target/60588] AVR target does not support init_priority attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60588 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added CC||cameron at tacklind dot com --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org --- *** Bug 64347 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/64081] [5 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #15 from Igor Zamyatin izamyatin at gmail dot com --- Got an access to AIX machine, planning to look at it next week
[Bug target/64452] [4.8/4.9/5.0 Regression] ICE in avr-gcc when passing struct member to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64452 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Fri Feb 20 10:30:24 2015 New Revision: 220847 URL: https://gcc.gnu.org/viewcvs?rev=220847root=gccview=rev Log: gcc/ PR target/64452 * config/avr/avr.md (pushhi_insn): New insn. (pushmode1): Push virtual regs in one chunk using pushhi1_insn. gcc/testsuite/ PR target/64452 * gcc.target/avr/torture/pr64452.c: New test. Added: trunk/gcc/testsuite/gcc.target/avr/torture/pr64452.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/65131] Integer overflow in .size() for std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131 --- Comment #7 from Francois Fayard fayard at insideloop dot io --- I agree. Thanks for your comments.
[Bug target/63892] [5 Regression] gcc.dg/sibcall-3.c fails on darwin with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63892 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 34815 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34815action=edit gcc5-pr63892.patch This untested patch fixes the issue too, though if the #c4 patch could be made to work, it might be perhaps unnecessary because we would never try to add thunks in between local functions. Or is there any case where it would make sense to add them rather than redirect callers?
[Bug target/64452] [4.8/4.9/5.0 Regression] ICE in avr-gcc when passing struct member to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64452 --- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org --- Author: gjl Date: Fri Feb 20 10:46:05 2015 New Revision: 220848 URL: https://gcc.gnu.org/viewcvs?rev=220848root=gccview=rev Log: gcc/ Backport from 2015-02-20 trunk r220847. PR target/64452 * config/avr/avr.md (pushhi_insn): New insn. (pushmode1): Push virtual regs in one chunk using pushhi1_insn. gcc/testsuite/ Backport from 2015-02-20 trunk r220847. PR target/64452 * gcc.target/avr/torture/pr64452.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/avr/torture/pr64452.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/avr/avr.md branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/64452] [4.8/4.9 Regression] ICE in avr-gcc when passing struct member to varargs function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64452 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.5, 4.9.3 Resolution|--- |FIXED Target Milestone|--- |4.9.3 Summary|[4.8/4.9/5.0 Regression]|[4.8/4.9 Regression] ICE in |ICE in avr-gcc when passing |avr-gcc when passing struct |struct member to varargs|member to varargs function |function| --- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org --- Fixed in 4.8.5 and 4.9.3+
[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63888 --- Comment #33 from Jakub Jelinek jakub at gcc dot gnu.org --- That is not sufficient. The bug affects all programs, not just gcc when bootstrapping it.
[Bug rtl-optimization/64158] [5 Regression] FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 global deletions = (2|3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64158 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||macro at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Is this a regression though? I see the FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 global deletions = (2|3) even with gcc 4.7.x, 4.8.x, 4.9.x on ppc64. There was an attempt to avoid running this test on ppc64-linux: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00299.html r213657 and r213677 but clearly that is not working well. Don't have a ppc64 box readily available now, so can't quickly analyze what's going on though. I see: Executing on host: /builddir/build/BUILD/gcc-5.0.0-20150217/obj-ppc64-redhat-linux/gcc/xgcc -B/builddir/build/BUILD/gcc-5.0.0-20150217/obj-ppc64-redhat-linux/gcc/ -fno-diagnostics-show-caret -fdiagnostics-color=never -c -o powerpc_elfv216903.o powerpc_elfv216903.c(timeout = 300) spawn -ignore SIGHUP /builddir/build/BUILD/gcc-5.0.0-20150217/obj-ppc64-redhat-linux/gcc/xgcc -B/builddir/build/BUILD/gcc-5.0.0-20150217/obj-ppc64-redhat-linux/gcc/ -fno-diagnostics-show-caret -fdiagnostics-color=never -c -o powerpc_elfv216903.o powerpc_elfv216903.c powerpc_elfv216903.c:3:7: error: #error not ELF v2 ABI compiler exited with status 1 output is: powerpc_elfv216903.c:3:7: error: #error not ELF v2 ABI ... Executing on host: /builddir/build/BUILD/gcc-5.0.0-20150217/obj-ppc64-redhat-linux/gcc/xgcc -B/builddir/build/BUILD/gcc-5.0.0-20150217/obj-ppc64-redhat-linux/gcc/ /builddir/build/BUILD/gcc-5.0.0-20150217/gcc/testsuite/gcc.dg/pr44194-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fdump-rtl-dse1 -fdump-rtl-final -ffat-lto-objects -ffat-lto-objects -S -o pr44194-1.s (timeout = 300) spawn -ignore SIGHUP /builddir/build/BUILD/gcc-5.0.0-20150217/obj-ppc64-redhat-linux/gcc/xgcc -B/builddir/build/BUILD/gcc-5.0.0-20150217/obj-ppc64-redhat-linux/gcc/ /builddir/build/BUILD/gcc-5.0.0-20150217/gcc/testsuite/gcc.dg/pr44194-1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fdump-rtl-dse1 -fdump-rtl-final -ffat-lto-objects -ffat-lto-objects -S -o pr44194-1.s PASS: gcc.dg/pr44194-1.c (test for excess errors) FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 global deletions = (2|3) PASS: gcc.dg/pr44194-1.c scan-rtl-dump-not final insn[: ][^\n]*set \\(mem(?![^\n]*scratch) in the gcc.log from our rpm build, so I'd expect that powerpc_elfv2 is 0 and therefore the pr44194-1.c test should be skipped as unsupported.
[Bug c/65088] Does GCC has load/store widening phase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65088 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- See bug 23684.
[Bug target/63892] [5 Regression] gcc.dg/sibcall-3.c fails on darwin with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63892
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
So, during ICF we don't create alias because
sem_item::target_supports_symbol_aliases_p () tells us not to.
But I really don't see a reason why we couldn't try to redirect_callers in this
case, both original and alias are local functions without address taken.
There is another case that worries me - if the above mentioned function returns
false, we set create_thunk even for stdarg_p functions.
So, I think we should do something like:
--- gcc/ipa-icf.c.jj2015-02-19 12:52:33.0 +0100
+++ gcc/ipa-icf.c2015-02-20 10:06:04.532637240 +0100
@@ -651,7 +651,9 @@ sem_function::merge (sem_item *alias_ite
section (or we risk link failures when section is discarded). */
if ((original_address_matters
alias_address_matters)
- || original_discardable)
+ || original_discardable
+ || DECL_COMDAT_GROUP (alias-decl)
+ || !sem_item::target_supports_symbol_aliases_p ())
{
create_thunk = !stdarg_p (TREE_TYPE (alias-decl));
create_alias = false;
@@ -659,6 +661,7 @@ sem_function::merge (sem_item *alias_ite
the extra thunk wrapper for direct calls. */
redirect_callers
= (!original_discardable
+!DECL_COMDAT_GROUP (alias-decl)
alias-get_availability () AVAIL_INTERPOSABLE
original-get_availability () AVAIL_INTERPOSABLE
!alias-instrumented_version);
@@ -670,13 +673,6 @@ sem_function::merge (sem_item *alias_ite
redirect_callers = false;
}
- if (create_alias (DECL_COMDAT_GROUP (alias-decl)
- || !sem_item::target_supports_symbol_aliases_p ()))
-{
- create_alias = false;
- create_thunk = true;
-}
-
/* We want thunk to always jump to the local function body
unless the body is comdat and may be optimized out. */
if ((create_thunk || redirect_callers)
Unfortunately this ICEs on the testcase in question, when we reach:
725 /* The alias function is removed if symbol address
726 does not matter. */
727 if (!alias_address_matters)
728alias-remove ();
because in
1645void
1646sem_item_optimizer::remove_symtab_node (symtab_node *node)
1647{
1648 gcc_assert (!m_classes.elements());
1649
1650 m_removed_items_set.add (node);
1651}
called during the alias-remove ()
m_classes.elements() is 3. I'm not familiar with that code, Martin/Honza, can
you please have a look?
And, another thing, not analyzed fully, is that when we create a thunk to the
local calling convention function and the thunk isn't visible either, the
question is why it doesn't use the same calling convention (i.e. local again).
Last thing, I believe we should change the testcase anyway, either use
-fno-ipa-icf or add say some volatile int v; v++;
into one of the functions, so that sibcall-3.c tests what it originally meant
to test. With ICF it can be turned into a tail recursion test, while clearly
originally it was meant to be a tail call test.
We can certainly copy the current testcase into a new one...
[Bug libstdc++/64135] Allocator base classes should use reserved names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64135 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-20 Ever confirmed|0 |1
[Bug c++/62116] Allowing redeclaration of global variable x using ::x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62116 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-20 Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- Confirmed then. Thanks, Richard.
[Bug libstdc++/65131] Integer overflow in .size() for std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc/2011-08/msg00221.html
[Bug c++/65132] New: diagnostics: missing: bitfield member cannot have an in-class initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65132
Bug ID: 65132
Summary: diagnostics: missing: bitfield member cannot have an
in-class initializer
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
class C { bool x:1=false; };
g++ (GCC) 5.0.0 20150219 (experimental):
field.C:1:20: error: an assignment cannot appear in a constant-expression
clang-3.5.0-6.fc21.x86_64:
field.C:1:19: error: bitfield member cannot have an in-class initializer
I had no idea what GCC errors on until I asked clang.
[Bug go/65134] New: gccgo ignores the attribute constructor in a subdirectory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134 Bug ID: 65134 Summary: gccgo ignores the attribute constructor in a subdirectory Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: e29253 at jp dot ibm.com CC: cmang at google dot com Created attachment 34813 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34813action=edit Example to reproduce the constructor problem Gccgo ignores a C-function with the constructor attribute in a subdirectory. In the attached example, gc executes a C-function init() in sub.go before a Go function main(), but gccgo does not: ~/example$ export GOPATH=$(pwd) ~/example$ /usr/local/go/bin/go version go version go1.4.2 linux/amd64 ~/example$ /usr/local/go/bin/go run src/main/main.go Hello from constructor Hello from main ~/example$ export LD_LIBRARY_PATH=/usr/local/gccgo/lib64:$LD_LIBRARY_PATH ~/example$ /usr/local/gccgo/bin/go version go version gccgo (GCC) 5.0.0 20150115 (experimental) linux/amd64 ~/example$ /usr/local/gccgo/bin/go run src/main/main.go Hello from main ~/example$ It seems this difference is due to that gccgo cannot detect a function with the constructor attribute in an archived objects created in a subdirectory. Is there any workaround to avoid this problem?
[Bug libstdc++/65131] Integer overflow in .size() for std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- And you can't actually allocate 2^64 bytes of memory on x86_64 either. In practice this doesn't really matter, noone uses max_size() this way.
[Bug libstdc++/65131] Integer overflow in .size() for std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- The ABI says for all 32bit ABIs you cannot allocate more than half of the address space.
[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||x86_64-*-*
Status|WAITING |NEW
Known to work||4.7.4
--- Comment #9 from Richard Biener rguenth at gcc dot gnu.org ---
Hmm, I still see 2GB of memory - just checked with ulimit -v 200 where 4.7
succeeds but 4.8, 4.9 and 5 (r220758).
Thus, re-confirmed. Without var-tracking GCC 5 tops out at ~400MB.
I don't get the following note:
b.ii: In function ‘bool {anonymous}::test03()’:
b.ii:84991:1: note: variable tracking size limit exceeded with
-fvar-tracking-assignments, retrying without
did you use some patched GCC with lower limits?
[Bug c/45779] pointer difference error/ptrdiff_t representability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45779 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc/2011-08/msg00221.html
[Bug libstdc++/65131] Integer overflow in .size() for std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131 --- Comment #3 from Francois Fayard fayard at insideloop dot io --- Thanks for the info. It would be nice to reflect that in max_size().
[Bug c++/65133] New: [C++11] Result type deduction proceeds even though argument deduction fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65133
Bug ID: 65133
Summary: [C++11] Result type deduction proceeds even though
argument deduction fails
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mbianco at cscs dot ch
GCC 4.8.0 to 4.9.0 fails in employing SFINAE to find the proper implementation
when infinite template recursion is hit. ICPC (15) and CLANG++ (3.7) compile
and run the code correctly.
#STANDALONE SOURCE
#include iostream
#include type_traits
template int I
struct count
{
using type = typename countI-1::type;
};
template
struct count0
{
using type = void;
};
template int I
auto foo(typename std::enable_if(I=0)::type * = nullptr) - typename
countI::type
/* Substituting countI::type with void would make the code to compile.*/
{
std::cout I=0 std::endl;
}
// Specialization #2
template int I
void foo(typename std::enable_if(I0)::type * = nullptr)
{
std::cout I0 std::endl;
}
int main() {
foo2(); // This Works fine
foo-1(); // This should go the specialization #2 but GCC fails since it
goes into counting down 900 times without resolution
return 0;
}
### COMPILER INVOCATION:
g++ -std=c++11 -c main.cpp
### EXPECTED OUTPUT:
Successful compile.
### ACTUAL OUTPUT:
main.cpp:7:43: error: template instantiation depth exceeds maximum of 900 (use
-ftemplate-depth= to increase the maximum) instantiating ‘struct count-900’
using type = typename countI-1::type;
^
main.cpp:7:43: recursively required from ‘struct count-2’
main.cpp:7:43: required from ‘struct count-1’
main.cpp:18:6: required by substitution of ‘templateint I typename
countI::type foo(typename std::enable_if(I = 0)::type*) [with int I = -1]’
main.cpp:35:13: required from here
main.cpp:7:43: error: invalid use of incomplete type ‘struct count-900’
main.cpp:5:8: error: declaration of ‘struct count-900’
struct count
^
### g++ -v OUTPUT:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/apps/dom/gcc/4.9.0/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/apps/dom/gcc/4.9.0
--enable-languages=c,c++,fortran --with-mpfr=/apps/dom/gnu/mpfr/3.1.2
--with-mpc=/apps/dom/gnu/mpc/1.0.2 --with-gmp=/apps/dom/gnu/gmp/5.1.3
--with-isl=/apps/dom/gnu/isl/0.12.2 --with-cloog=/apps/dom/gnu/cloog/0.18.1
Thread model: posix
gcc version 4.9.0 (GCC)
[Bug libstdc++/65131] Integer overflow in .size() for std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- It seems like a waste of time. The internals of the standard library are not the right place to dissuade people from their mistaken beliefs. Simply trying to allocate such an array should be evidence enough.
[Bug sanitizer/63958] [5 Regression] bootstrap failure in the sanitizer libs on sparc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63958 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- The r216224 change apparently applies cleanly to the current sources, does it fix all the sparc*-linux build issues? My SPARC box is long time dead...
[Bug testsuite/65126] [5 Regresion] additional_sources not defined anymore during dg-final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65126 --- Comment #4 from vries at gcc dot gnu.org --- (In reply to Maxim Kuvyrkov from comment #3) Hi Tom, I can't reproduce this. I'm trying make check-gcc RUNTESTFLAGS=vect.exp on a native x86_64 bootstrap. What is required to trigger this? Hi Maxim, vect.exp=vect-simd-clone-10.c should trigger this. Running vect-simd-clone-10.c produces the leftover vect-simd-clone-10a.c.126t.vect. But if vect-simd-clone-10a.c is run afterwards, then vect-simd-clone-10a.c.126t.vect is first overwritten, and then cleaned up. So whether the file is still there after the test run depends on whether 10a is run after 10 in the same testdirectory. Reproduced it with a fresh build from r220825: ... $ make -k -j5 check RUNTESTFLAGS=vect.exp=vect-simd-clone-10.c --target_board=unix ... $ ls lean/build/gcc/testsuite/gcc* lean/build/gcc/testsuite/gcc: gcc.log gcc.log.sep gcc.sum gcc.sum.sep site.exp lean/build/gcc/testsuite/gcc1: gcc.log.sep gcc.sum.sep site.exp vect-simd-clone-10a.c.126t.vect lean/build/gcc/testsuite/gcc2: gcc.log.sep gcc.sum.sep site.exp lean/build/gcc/testsuite/gcc3: gcc.log.sep gcc.sum.sep site.exp ...
[Bug libstdc++/65131] Integer overflow in .size() for std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131 --- Comment #5 from Francois Fayard fayard at insideloop dot io --- They are so many people out there who claim that using an unsigned integer (std::size_t) as an array index was a good choice because you can allocate larger arrays than with the signed integer of the same size (std::ptrdiff_t) that it would be nice to show them they can't :-) max_size() is not clearly defined, but I still think it would be nice to put it in max_size() as a documentation.
[Bug c++/65127] [5 Regression] internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'addr_expr' in parsing_nsdmi, at cp/parser.c:18311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65127
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-02-20
CC||mpolacek at gcc dot gnu.org
Target Milestone|--- |5.0
Summary|internal compiler error:|[5 Regression] internal
|tree check: expected tree |compiler error: tree check:
|that contains 'decl |expected tree that contains
|minimal' structure, have|'decl minimal' structure,
|'addr_expr' in |have 'addr_expr' in
|parsing_nsdmi, at |parsing_nsdmi, at
|cp/parser.c:18311 |cp/parser.c:18311
Ever confirmed|0 |1
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
Started with r216750.
Note that we ICE even on
templateint sz void make_item()
{
static int i{100};
struct
{
int id{i++};
} item;
}
int main()
{
make_item0();
}
which is accepted by 4.9 and clang.
[Bug rtl-optimization/65135] New: Performance regression in pic mode after r220674.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65135 Bug ID: 65135 Summary: Performance regression in pic mode after r220674. Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ysrumyan at gmail dot com We noticed 10% regression on one important benchmark using for testing x86 32-bit platforms. This regression can be reproduced on attached test-case: one more fill is present in innermost loop after r220674. One possible decision is spillong live phisical registers not referenced in (innermost) loops (GOT-register in out test-case) in loop preheader with subsequent restore it in loop post header. Note that regression can be seen only in pic mode for 32-bit x86 platform.
[Bug testsuite/65126] [5 Regresion] additional_sources not defined anymore during dg-final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65126 Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org changed: What|Removed |Added CC||mkuvyrkov at gcc dot gnu.org --- Comment #5 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org --- The problem here is that gcc_target_compile (and, probably, other *_target_compile procs) clears out additional_sources as soon as it is done. I don't immediately know how to fix this properly. A quick fix may be to delay clearing out additional_sources till a later point. More generally, from what I see GCC's testsuite doesn't have coordinated maintenance of its global state (additional_* and other variables, see gcc-dg.exp). It would be a nice cleanup to have PUSH and POP operations for global state that could used to 1. clearing of state for next test -- the POP to a reference clean state would be done once all parts of the test would finish, thus removing the need to clear out additional_sources after compilation (== midway through running the test). 2. saving / restoring of state for target-supports checks.
[Bug tree-optimization/65136] New: VRP inserts unnecessary constant copy in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65136
Bug ID: 65136
Summary: VRP inserts unnecessary constant copy in the loop
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: izamyatin at gmail dot com
For the following piece of code
int foo (unsigned int cc)
{
while ( cc 16 )
{
cc = (cc 0x) + (cc 16);
}
return cc == 1;
}
at o2 we have
movl%edi, %eax
shrl$16, %eax
testl %eax, %eax
je .L2
.p2align 4,,10
.p2align 3
.L3:
movzwl %di, %edi
addl%eax, %edi
movl$1, %eax
movl%edi, %edx
shrl$16, %edx
testl %edx, %edx
jne .L3
while with -fno-tree-vrp
jmp .L8
.p2align 4,,10
.p2align 3
.L3:
movzwl %di, %edi
addl%eax, %edi
.L8:
movl%edi, %eax
shrl$16, %eax
testl %eax, %eax
jne .L3
vrp changes loop in a following way
bb 4:
# cc_12 = PHI cc_2(D)(3), cc_5(4)
# _13 = PHI _11(3), 1(4)
_4 = cc_12 65535;
cc_5 = _13 + _4;
_3 = cc_5 16;
if (_3 != 0)
goto bb 4;
else
goto bb 5;
resulted in constant copy to be inserted.
[Bug rtl-optimization/65135] Performance regression in pic mode after r220674.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65135 --- Comment #1 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 34814 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34814action=edit test-case to reproduce Need to compile with -O2 -m32 -fPIE -pie options.
[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028 --- Comment #58 from Markus Trippelsdorf trippels at gcc dot gnu.org --- The Firefox issue from comment #49 is fixed.
[Bug target/63892] [5 Regression] gcc.dg/sibcall-3.c fails on darwin with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63892 --- Comment #6 from Martin Liška marxin at gcc dot gnu.org --- Created attachment 34817 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34817action=edit Fixed IPA ICF hooks Hello Jakub. Your patch in #c4 is correct, assert is caused due to wrong placement of unregister hooks. Please see the patch, I tested on my x86_64-linux-pc machine (where I return false in target_supports_symbol_aliases_p) and it works me. Thanks, Martin
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 --- Comment #23 from uros at gcc dot gnu.org --- Author: uros Date: Fri Feb 20 12:04:21 2015 New Revision: 220854 URL: https://gcc.gnu.org/viewcvs?rev=220854root=gccview=rev Log: Backport from mainline 2015-01-22 Wei Mi w...@google.com PR rtl-optimization/64557 * dse.c (record_store): Call get_addr for mem_addr. (check_mem_read_rtx): Likewise. Backport from mainline 2014-10-20 Uros Bizjak ubiz...@gmail.com * varasm.c (const_alias_set): Remove. (init_varasm_once): Remove initialization of const_alias_set. (build_constant_desc): Do not set alias set to const_alias_set. Backport from mainline 2014-10-14 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/63475 * alias.c (true_dependence_1): Always use get_addr to extract true address operands from x_addr and mem_addr. Use extracted address operands to check for references with alignment ANDs. Use extracted address operands with find_base_term and base_alias_check. For noncanonicalized operands call canon_rtx with extracted address operand. (write_dependence_1): Ditto. (may_alias_p): Ditto. Remove unused calls to canon_rtx. Backport from mainline 2014-10-10 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/63483 * alias.c (true_dependence_1): Do not exit early for MEM_READONLY_P references when alignment ANDs are involved. (write_dependence_p): Ditto. (may_alias_p): Ditto. Backport from mainline 2013-03-26 Richard Biener rguent...@suse.de * alias.c (find_base_term): Avoid redundant and not used recursion. (base_alias_check): Get the initial base term from the caller. (true_dependence_1): Compute and pass base terms to base_alias_check. (write_dependence_p): Likewise. (may_alias_p): Likewise. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/alias.c branches/gcc-4_8-branch/gcc/dse.c branches/gcc-4_8-branch/gcc/varasm.c
[Bug rtl-optimization/64557] get_addr in true_dependence_1 cannot handle VALUE inside an expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557 --- Comment #5 from uros at gcc dot gnu.org --- Author: uros Date: Fri Feb 20 12:04:21 2015 New Revision: 220854 URL: https://gcc.gnu.org/viewcvs?rev=220854root=gccview=rev Log: Backport from mainline 2015-01-22 Wei Mi w...@google.com PR rtl-optimization/64557 * dse.c (record_store): Call get_addr for mem_addr. (check_mem_read_rtx): Likewise. Backport from mainline 2014-10-20 Uros Bizjak ubiz...@gmail.com * varasm.c (const_alias_set): Remove. (init_varasm_once): Remove initialization of const_alias_set. (build_constant_desc): Do not set alias set to const_alias_set. Backport from mainline 2014-10-14 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/63475 * alias.c (true_dependence_1): Always use get_addr to extract true address operands from x_addr and mem_addr. Use extracted address operands to check for references with alignment ANDs. Use extracted address operands with find_base_term and base_alias_check. For noncanonicalized operands call canon_rtx with extracted address operand. (write_dependence_1): Ditto. (may_alias_p): Ditto. Remove unused calls to canon_rtx. Backport from mainline 2014-10-10 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/63483 * alias.c (true_dependence_1): Do not exit early for MEM_READONLY_P references when alignment ANDs are involved. (write_dependence_p): Ditto. (may_alias_p): Ditto. Backport from mainline 2013-03-26 Richard Biener rguent...@suse.de * alias.c (find_base_term): Avoid redundant and not used recursion. (base_alias_check): Get the initial base term from the caller. (true_dependence_1): Compute and pass base terms to base_alias_check. (write_dependence_p): Likewise. (may_alias_p): Likewise. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/alias.c branches/gcc-4_8-branch/gcc/dse.c branches/gcc-4_8-branch/gcc/varasm.c
[Bug rtl-optimization/65135] [5 Regression] Performance regression in pic mode after r220674.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65135 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization CC||rth at gcc dot gnu.org Target Milestone|--- |5.0 Summary|Performance regression in |[5 Regression] Performance |pic mode after r220674. |regression in pic mode ||after r220674.
[Bug tree-optimization/65136] [5 Regression] VRP inserts unnecessary constant copy in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65136 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.2 Target Milestone|--- |5.0 Summary|VRP inserts unnecessary |[5 Regression] VRP inserts |constant copy in the loop |unnecessary constant copy ||in the loop --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- This is a regression from GCC 4.9.
[Bug go/65134] gccgo ignores the attribute constructor in a subdirectory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65134
--- Comment #1 from Ian Lance Taylor ian at airs dot com ---
It's pretty ugly, but a workaround is to drop something like this into sub.go:
var AlwaysFalse bool
func init() {
if AlwaysFalse {
C.init()
}
}
The idea is to force in something that refers to the function that the compiler
and linker aren't smart enough to discard.
[Bug tree-optimization/65136] VRP inserts unnecessary constant copy in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65136 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-02-20 Version|unknown |5.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- The issue is that VRP constant-propagates into the latch edge PHI argument which makes it unable to coalesce across the latch edge. It is also very hard to undo this equivalence. I have a patch.
[Bug target/63892] [5 Regression] gcc.dg/sibcall-3.c fails on darwin with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63892 --- Comment #9 from Martin Liška marxin at gcc dot gnu.org --- Thanks for cooperation, I'm going to bootstrap and run regression tests on x86_64-linux-pc and I'm going to clone these tests too. Martin
[Bug rtl-optimization/64557] get_addr in true_dependence_1 cannot handle VALUE inside an expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.5 --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- Fixed everywhere.
[Bug target/63892] [5 Regression] gcc.dg/sibcall-3.c fails on darwin with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63892 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Thanks, looks reasonable. That will hopefully render my #c5 patch undeeded. Can you please bootstrap/regtest it on x86_64-linux (well, I can do that too now). Don't have access to darwin nor time to test it there, so will leave that to others.
[Bug tree-optimization/65136] [5 Regression] VRP inserts unnecessary constant copy in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65136 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||uros at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- After the patch the assembly difference between 4.9 and 5 is --- t.s.good2015-02-20 13:26:52.337186388 +0100 +++ t.s 2015-02-20 13:26:56.769235529 +0100 @@ -21,7 +21,7 @@ testl %eax, %eax jne .L3 xorl%eax, %eax - cmpw$-1, %di + cmpl$65535, %edi sete%al ret .cfi_endproc not sure why we prefer the bigger encoding now.
[Bug target/63892] [5 Regression] gcc.dg/sibcall-3.c fails on darwin with -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63892
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 34818
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34818action=edit
V499
And let's copy and adjust the sibcall-{3,4}.c testcases so that they aren't ICF
optimized, so that we also test what we originally meant to.
[Bug rtl-optimization/65135] [5 Regression] Performance regression in pic mode after r220674.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65135 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-02-20 Ever confirmed|0 |1 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Yuri Rumyantsev from comment #1) Created attachment 34814 [details] test-case to reproduce Need to compile with -O2 -m32 -fPIE -pie options. Please provide your assembly code.
[Bug rtl-optimization/65135] [5 Regression] Performance regression in pic mode after r220674.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65135 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- The assembly code generates by r220674 is much shorter: bar: call__x86.get_pc_thunk.ax addl$_GLOBAL_OFFSET_TABLE_, %eax movlFPtr@GOTOFF(%eax), %edx movlinc@GOTOFF(%eax), %ecx leal(%edx,%ecx,4), %ecx cmpl%ecx, FEOF@GOTOFF(%eax) movl4(%esp), %ecx cmovbF@GOTOFF(%eax), %edx movl%ecx, (%edx) movlinc@GOTOFF(%eax), %ecx leal(%edx,%ecx,4), %edx movl%edx, FPtr@GOTOFF(%eax) ret vs bar: call__x86.get_pc_thunk.dx addl$_GLOBAL_OFFSET_TABLE_, %edx pushl%edi pushl%esi movlFPtr@GOT(%edx), %ecx pushl%ebx movlinc@GOT(%edx), %ebx movlFEOF@GOT(%edx), %edi movl(%ecx), %eax movl(%ebx), %esi leal(%eax,%esi,4), %esi cmpl%esi, (%edi) jnb.L2 movlF@GOT(%edx), %eax movl(%eax), %eax .L2: movl16(%esp), %edx movl%edx, (%eax) movl(%ebx), %edx leal(%eax,%edx,4), %eax movl%eax, (%ecx) popl%ebx popl%esi popl%edi ret .sizebar, .-bar Why doesn't it improve performance? Why does it hurt performance instead?
[Bug libstdc++/65122] std::vector doesn't honor element alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Benoit Jacob from comment #11) (In reply to Richard Biener from comment #10) But ::operator new(std::size_t) could always return memory aligned for the most over-aligned type? Thus our default new implementation could use posix_memalign (..., MIN (size, BIGGEST_ALIGNMENT), size)? The problem is there are lots of use cases for really high alignment: AVX brings uses of 32-byte alignment, and cache lines are typically = 64 byte aligned. So alignas has to support at least 64 or 128 byte alignment to support cache friendly code, and even without that, it would have to support at least 32 byte alignment for AVX vectorized code. Making all allocations that large would lead to substantial allocator slop. For example, jemalloc has a quantum of 8 or 16 byte depending on whether the arch is 32 or 64 bit, so increasing it to 32, 64 or 128 byte would be a big difference. Though does it really matter in practice? Tiny allocations would not suffer because of the MIN (align, size), so the worst-case is max-align + 1 allocations. Btw, you could as well try MIN (align, size -size), thus assume that the allocation size is N * alignof (). If the user provides its own ::new then he is on its own, of course I agree that's how I would like things to be. Unfortunately, the spec quote in comment 4, the storage is obtained by calling ::operator new(std::size_t), goes in the opposite direction, by requiring allocators to use the type-blind ::new , thereby losing useful type information such as the type's alignment. That's why I think that this is the spec's weak spot that might be questioned. but you're the expert, not me :) (and doing that and using posix_memalign in it would be a workaround for this issue?!). That could be a good compromise for many applications, that either don't care about minimizing memory usage, or don't do many tiny allocations. Unfortunately, my context here is a library (Eigen), so we can't make this decision for all our users.
[Bug testsuite/64158] [5 Regression] FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 global deletions = (2|3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64158
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 34816
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34816action=edit
gcc5-pr64158.patch
Untested fix. Seem tcl is picky about the {}s, doesn't want cond1 cond2
cond3, but instead { { cond1 cond2 } cond3 }. That is one of the pairs,
why is the second one needed is beyond my current understanding.
Tested just by replacing the various ! sometarget cases with ! x86_64-*-* and
checking whether they indeed made the test unsupported on my x86_64-linux.
s390, hppa and alpha replacement worked expectedly, for the powerpc case it was
enough to add one {} pair, for nvptx I had to add another one.
[Bug rtl-optimization/63475] Postreload CSE propagates aliased memory operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63475 --- Comment #9 from uros at gcc dot gnu.org --- Author: uros Date: Fri Feb 20 12:04:21 2015 New Revision: 220854 URL: https://gcc.gnu.org/viewcvs?rev=220854root=gccview=rev Log: Backport from mainline 2015-01-22 Wei Mi w...@google.com PR rtl-optimization/64557 * dse.c (record_store): Call get_addr for mem_addr. (check_mem_read_rtx): Likewise. Backport from mainline 2014-10-20 Uros Bizjak ubiz...@gmail.com * varasm.c (const_alias_set): Remove. (init_varasm_once): Remove initialization of const_alias_set. (build_constant_desc): Do not set alias set to const_alias_set. Backport from mainline 2014-10-14 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/63475 * alias.c (true_dependence_1): Always use get_addr to extract true address operands from x_addr and mem_addr. Use extracted address operands to check for references with alignment ANDs. Use extracted address operands with find_base_term and base_alias_check. For noncanonicalized operands call canon_rtx with extracted address operand. (write_dependence_1): Ditto. (may_alias_p): Ditto. Remove unused calls to canon_rtx. Backport from mainline 2014-10-10 Uros Bizjak ubiz...@gmail.com PR rtl-optimization/63483 * alias.c (true_dependence_1): Do not exit early for MEM_READONLY_P references when alignment ANDs are involved. (write_dependence_p): Ditto. (may_alias_p): Ditto. Backport from mainline 2013-03-26 Richard Biener rguent...@suse.de * alias.c (find_base_term): Avoid redundant and not used recursion. (base_alias_check): Get the initial base term from the caller. (true_dependence_1): Compute and pass base terms to base_alias_check. (write_dependence_p): Likewise. (may_alias_p): Likewise. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/alias.c branches/gcc-4_8-branch/gcc/dse.c branches/gcc-4_8-branch/gcc/varasm.c
[Bug testsuite/64158] [5 Regression] FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 global deletions = (2|3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64158 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org --- It's a restriction of the selector expression parser.
[Bug c++/65132] diagnostics: missing: bitfield member cannot have an in-class initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65132 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-20 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Confirmed. Probably it is just a matter of calling cp_parser_constant_expression with the right parameters to not emit errors, then checking after it returns that it indeed parsed a constant-expression and give appropriate errors otherwise.
[Bug c++/65132] diagnostics: missing: bitfield member cannot have an in-class initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65132 --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #1) Probably it is just a matter of calling cp_parser_constant_expression with the right parameters to not emit errors, then checking after it returns that it indeed parsed a constant-expression and give appropriate errors otherwise. Which is what the C++ parser needs to do in general to avoid the terribly user-unfriendly expected...before diagnostics, particularly the infamous 'expected primary-expression before...' PR39858. We really need at lot more people working on the C++ parser...
[Bug libstdc++/65122] std::vector doesn't honor element alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122 --- Comment #11 from Benoit Jacob jacob.benoit.1 at gmail dot com --- (In reply to Richard Biener from comment #10) But ::operator new(std::size_t) could always return memory aligned for the most over-aligned type? Thus our default new implementation could use posix_memalign (..., MIN (size, BIGGEST_ALIGNMENT), size)? The problem is there are lots of use cases for really high alignment: AVX brings uses of 32-byte alignment, and cache lines are typically = 64 byte aligned. So alignas has to support at least 64 or 128 byte alignment to support cache friendly code, and even without that, it would have to support at least 32 byte alignment for AVX vectorized code. Making all allocations that large would lead to substantial allocator slop. For example, jemalloc has a quantum of 8 or 16 byte depending on whether the arch is 32 or 64 bit, so increasing it to 32, 64 or 128 byte would be a big difference. If the user provides its own ::new then he is on its own, of course I agree that's how I would like things to be. Unfortunately, the spec quote in comment 4, the storage is obtained by calling ::operator new(std::size_t), goes in the opposite direction, by requiring allocators to use the type-blind ::new , thereby losing useful type information such as the type's alignment. That's why I think that this is the spec's weak spot that might be questioned. but you're the expert, not me :) (and doing that and using posix_memalign in it would be a workaround for this issue?!). That could be a good compromise for many applications, that either don't care about minimizing memory usage, or don't do many tiny allocations. Unfortunately, my context here is a library (Eigen), so we can't make this decision for all our users.
[Bug libstdc++/65131] Integer overflow in .size() for std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65131 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Andrew Pinski from comment #1) The ABI says for all 32bit ABIs you cannot allocate more than half of the address space. X32 can allocate more than 2GB via malloc and ILP32 on ARM64 may also be able to.
[Bug c++/65137] New: wrong line for missing semicolon after expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65137
Bug ID: 65137
Summary: wrong line for missing semicolon after expression
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: manu at gcc dot gnu.org
int foo(int a)
{
a++
return 0;
}
gcc:
test.c:4:3: error: expected ‘;’ before ‘return’
return 0;
^
clang:
test.c:3:6: error: expected ';' after expression
a++
^
;
[Bug middle-end/65082] Wasted cycles when using a register based varible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65082
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Target|AVR-GCC |avr
Priority|P3 |P5
Status|UNCONFIRMED |WAITING
Last reconfirmed||2015-02-20
Ever confirmed|0 |1
--- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org ---
This cannot be reproduced with
register unsigned r4 asm (r4);
extern unsigned x;
void f (void)
{
r4 += x;
}
and compiled with
$ avr-gcc prog.c -S -Os
Neither with 4.8 nor 4.9 nor 5.0: In all cases, the generated code is:
f:
lds r24,x
lds r25,x+1
add r4,r24
adc r5,r25
ret
(In reply to NickParker from comment #0)
c code:
-
register uint16_t phaseAccPh asm (r4);
uint16_t phaseAccFr;
phaseAccPh += phaseAccFr;
This is not C code that can be compiled. Please read the bug reporting
instructions again.
https://gcc.gnu.org/bugs/#report
[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028
--- Comment #59 from Martin Jambor jamborm at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #36)
We end up with algnment unkonwn instead of a. (did not managed to reproduce
the wrong alignment here). What about the following:
It is certainly better than what I had there before, except that
unless I read it wrong, I think there are two bugs:
Index: ipa-cp.c
===
--- ipa-cp.c (revision 220789)
+++ ipa-cp.c (working copy)
@@ -1409,6 +1409,60 @@ propagate_context_accross_jump_function
return ret;
}
+/* Decrease alignment info DEST to be at most CUR. */
+
+static bool
+decrease_alignment (ipa_alignment *dest, ipa_alignment cur)
+{
+ bool changed = false;
+
+ if (!cur.known)
+return false;
I really think this should be return set_alignment_to_bottom (dest);
If some known alignment has been already propagated to DEST along a
different edge and now along the current edge an unknown alignment is
coming in, then the result value of the lattice must be BOTTOM and not
the previous alignment this code leaves in place.
+ if (!dest-known)
+{
+ *dest = cur;
+ return true;
+}
+ if (dest-align == cur.align
+ dest-misalign == cur.misalign)
+return false;
+
+ if (dest-align cur.align)
+{
+ dest-align = cur.align;
+ if (cur.align)
+ dest-misalign
+ = dest-misalign % cur.align;
+ changed = true;
+}
+ if (dest-align (dest-misalign != (cur.misalign % dest-align)))
+{
+ int diff = abs (dest-misalign
+ - (cur.misalign % dest-align));
+ dest-align = MIN (dest-align, (unsigned)diff - diff);
+ if (dest-align)
+ dest-misalign
+ = dest-misalign % dest-align;
+ changed = true;
+}
+ return changed;
+}
+
+/* Increase alignment info DEST to be at least CUR. */
+
+static bool
+increase_alignment (ipa_alignment *dest, ipa_alignment cur)
+{
+ if (!dest-known)
+return false;
I think this condition always exits. DEST is caller's CUR which was
read from jfunc-alignment which is always going to be unknown for
PASS_THROUGH and ANCESTOR jump functions at the moment. Perhaps you
meant if (!cur.known) ?
+ if (!cur.known || dest-align cur.align)
+{
again here, I think you meant !des-.known.
Apart from that, this is clearly an improvement, thanks.
[Bug rtl-optimization/65135] [5 Regression] Performance regression in pic mode after r220674.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65135 --- Comment #4 from Yuri Rumyantsev ysrumyan at gmail dot com --- This patch improves performance of almost all benchmarks in pic-mode for 32-bit target, but we have the only huge degradation on benchmark from eembc1.1 suite. I mentioned that the innermost loop has one more fill. before r220674 .L8: testl%esi, %esi jne.L11 movl16(%esp), %eax movl(%eax,%edx), %eax cmpl$-1, %eax je.L13 .L43: movl4(%esp), %edi leal0(,%eax,4), %edx movl%ecx, %ebx addl%edx, %edi cmpl$101, %ecx je.L41 leal1(%ebx), %ecx movl8(%esp), %ebp cmpl(%edi), %ebp jne.L8 after r220674 .L6: movl4(%esp), %ebx -- redundant fill testl%ebx, %ebx jne.L9 movl20(%esp), %eax movl(%eax,%edx), %eax cmpl$-1, %eax je.L11 .L42: movl8(%esp), %edi leal0(,%eax,4), %edx movl%ecx, %ebx addl%edx, %edi cmpl$101, %ecx je.L40 leal1(%ebx), %ecx movl12(%esp), %esi cmpl(%edi), %esi jne.L6 The issue is that before the fix GOT-register is not considered for allocation it to physical register.
[Bug sanitizer/65112] [5 Regression] -fsanitized=thread Fortran program crashes at startup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65112 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Can't reproduce, works just fine here.
[Bug target/65139] New: Improve register allocation for aarch64_*_sisd_or_intmode3 patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65139 Bug ID: 65139 Summary: Improve register allocation for aarch64_*_sisd_or_intmode3 patterns Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: mkuvyrkov at gcc dot gnu.org Following discussion in http://thread.gmane.org/gmane.comp.gcc.patches/336162 , review usage of early clobber in aarch64_lshr_sisd_or_int_≤mode3, aarch64_ashr_sisd_or_int_≤mode3, and, maybe, other patterns. Convert them to use (match_scratch) and compare quality of generated code between the two approaches. In theory, (match_scratch) should give more freedom to RA, but this requires double-checking.
[Bug libstdc++/65122] std::vector doesn't honor element alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122 --- Comment #13 from Benoit Jacob jacob.benoit.1 at gmail dot com --- (In reply to Richard Biener from comment #12) (In reply to Benoit Jacob from comment #11) (In reply to Richard Biener from comment #10) But ::operator new(std::size_t) could always return memory aligned for the most over-aligned type? Thus our default new implementation could use posix_memalign (..., MIN (size, BIGGEST_ALIGNMENT), size)? The problem is there are lots of use cases for really high alignment: AVX brings uses of 32-byte alignment, and cache lines are typically = 64 byte aligned. So alignas has to support at least 64 or 128 byte alignment to support cache friendly code, and even without that, it would have to support at least 32 byte alignment for AVX vectorized code. Making all allocations that large would lead to substantial allocator slop. For example, jemalloc has a quantum of 8 or 16 byte depending on whether the arch is 32 or 64 bit, so increasing it to 32, 64 or 128 byte would be a big difference. Though does it really matter in practice? Tiny allocations would not suffer because of the MIN (align, size), so the worst-case is max-align + 1 allocations. Btw, you could as well try MIN (align, size -size), thus assume that the allocation size is N * alignof (). Oh, I was missing the MIN (size, BIGGEST_ALIGNMENT) part of your proposal. So you're right, that nicely takes care of tiny allocations. Correct also on MIN (align, size -size) (though I have to trust your bit wizardry here) so that neatly exploits the low bits of the size parameter to infer the alignof --- sounds very good to me!
[Bug libstdc++/65122] std::vector doesn't honor element alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122
--- Comment #14 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Benoit Jacob from comment #13)
(In reply to Richard Biener from comment #12)
(In reply to Benoit Jacob from comment #11)
(In reply to Richard Biener from comment #10)
But ::operator new(std::size_t) could always return memory aligned for
the
most over-aligned type? Thus our default new implementation could use
posix_memalign (..., MIN (size, BIGGEST_ALIGNMENT), size)?
The problem is there are lots of use cases for really high alignment: AVX
brings uses of 32-byte alignment, and cache lines are typically = 64 byte
aligned. So alignas has to support at least 64 or 128 byte alignment to
support cache friendly code, and even without that, it would have to
support
at least 32 byte alignment for AVX vectorized code.
Making all allocations that large would lead to substantial allocator
slop.
For example, jemalloc has a quantum of 8 or 16 byte depending on whether
the
arch is 32 or 64 bit, so increasing it to 32, 64 or 128 byte would be a
big
difference.
Though does it really matter in practice? Tiny allocations would not suffer
because of the MIN (align, size), so the worst-case is max-align + 1
allocations. Btw, you could as well try MIN (align, size -size),
thus assume that the allocation size is N * alignof ().
Oh, I was missing the MIN (size, BIGGEST_ALIGNMENT) part of your proposal.
So you're right, that nicely takes care of tiny allocations. Correct also on
MIN (align, size -size) (though I have to trust your bit wizardry here)
so that neatly exploits the low bits of the size parameter to infer the
alignof --- sounds very good to me!
That trick of course requires you to not optimize your allocations manually
to omit tail padding in aggregates (or manually compute allocation sizes).
Or use
struct { avx512vector x; char c; } __attribute__((packed,aligned(64)));
which has alignment 64 and size 65... (of course arrays of such objects
are ill-defined)
[Bug libstdc++/65122] std::vector doesn't honor element alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65122 --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org --- Oh, and I wonder if there is an aligned realloc (though C++ doesn't define sth like realloc and thus std::vector can't optimize the copy when reallocating?!). But for a C program using posix_memalign or any other such facility means realloc is out of the question as well.
[Bug c++/65127] [5 Regression] internal compiler error: tree check: expected tree that contains 'decl minimal' structure, have 'addr_expr' in parsing_nsdmi, at cp/parser.c:18311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65127
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
So it seems current_class_ptr is no longer just NULL or a PARM_DECL, but can be
also ADDR_EXPR of a PLACEHOLDER_EXPR. Dunno if the right fix is
just
bool
parsing_nsdmi (void)
{
/* We recognize NSDMI context by the context-less 'this' pointer set up
by the function above. */
- if (current_class_ptr DECL_CONTEXT (current_class_ptr) == NULL_TREE)
+ if (current_class_ptr
+TREE_CODE (current_class_ptr) == PARM_DECL
+DECL_CONTEXT (current_class_ptr) == NULL_TREE)
return true;
return false;
}
or something different.
[Bug target/65138] New: [5 Regression] testsuite ICEs on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65138
Bug ID: 65138
Summary: [5 Regression] testsuite ICEs on powerpc64le
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
Build: powerpc64le-unknown-linux-gnu
Running the testsuite on the new gcc2-2-power8.osuosl.org powerpc64le machine
shows:
FAIL: gcc.c-torture/execute/20050604-1.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none (internal compiler error)
FAIL: gcc.c-torture/execute/20050604-1.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (internal compiler error)
FAIL: gcc.c-torture/execute/20060420-1.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none (internal compiler error)
FAIL: gcc.c-torture/execute/20060420-1.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (internal compiler error)
FAIL: c-c++-common/torture/vector-compare-1.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none (internal compiler error)
FAIL: c-c++-common/torture/vector-compare-1.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (internal compiler error)
FAIL: gcc.dg/torture/pr45678-1.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none (internal compiler error)
FAIL: gcc.dg/torture/pr45678-2.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none (internal compiler error)
FAIL: c-c++-common/torture/vector-compare-1.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none (internal compiler error)
FAIL: c-c++-common/torture/vector-compare-1.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects (internal compiler error)
These all have the same backtrace:
c-c++-common/torture/vector-compare-1.c: In function ‘main’:
c-c++-common/torture/vector-compare-1.c:108:8: internal compiler error: in
convert_move, at expr.c:315
f0 = (vector (4, float)){(float)argc, 1., 2., 10.};
^
0x1030bf03 convert_move(rtx_def*, rtx_def*, int)
../../gcc/gcc/expr.c:315
0x103130a7 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, tree_node*)
../../gcc/gcc/expr.c:5459
0x1031b5e7 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:5154
0x101cb33f expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3385
0x101cb33f expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3481
0x101d2dd7 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5470
0x101d5387 execute
../../gcc/gcc/cfgexpand.c:6088
Please submit a full bug report,
FAIL: gcc.dg/torture/vector-1.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none (internal compiler error)
FAIL: gcc.dg/torture/vector-2.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none (internal compiler error)
These two have a different backtrace:
gcc.dg/torture/vector-2.c:15:16: internal compiler error: in
expand_expr_real_1, at expr.c:9666
((int*)t)[0] = a;
^
0x103087c3 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:9666
0x1031b8c3 expand_expr
../../gcc/gcc/expr.h:254
0x1031b8c3 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/gcc/expr.c:4851
0x101cb33f expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3385
0x101cb33f expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3481
0x101d2dd7 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5470
0x101d5387 execute
../../gcc/gcc/cfgexpand.c:6088
Please submit a full bug report,
with preprocessed source if appropriate
[Bug ipa/65028] [5 Regression] 450.soplex in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65028 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #60 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #57) Martin, I just tested firefox with -march=native -flto -O3 and it still segfaults for me at movaps, so it seems that there is still some issue with the code :( (it happens with or withtout the propagation patch I posted) Please have a look at my comments of the patch. If that still does not help, open a new bug and I will have a look. This PR has had more than it's fair share of comments already :-)
[Bug target/65139] Improve register allocation for aarch64_*_sisd_or_intmode3 patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65139 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-20 CC||ktkachov at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Thanks for opening this, I was about to open this myself. I guess this should be done for GCC 6
[Bug target/65138] [5 Regression] testsuite ICEs on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65138 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Only with -flto? huh.
[Bug libstdc++/64695] [5 Regression] FAIL: libstdc++-prettyprinters/cxx11.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64695 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Fri Feb 20 14:40:00 2015 New Revision: 220871 URL: https://gcc.gnu.org/viewcvs?rev=220871root=gccview=rev Log: PR libstdc++/64695 * python/libstdcxx/v6/printers.py (StdTuplePrinter): Handle new tuple layout. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
[Bug libstdc++/64695] [5 Regression] FAIL: libstdc++-prettyprinters/cxx11.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64695 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed. There are still some odd printer FAILs on ppc64 but they're unrelated: FAIL: libstdc++-prettyprinters/libfundts.cc print ab Python Exception type 'exceptions.RuntimeError' Cannot locate object file for block.: ^M skipping: Python Exception type 'exceptions.RuntimeError' Cannot locate object file for block.: ^M Python Exception type 'exceptions.RuntimeError' Cannot locate object file for block.: ^M skipping: Python Exception type 'exceptions.RuntimeError' Cannot locate object file for block.: ^M
[Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org --- Is this fixed at r220682 ?
[Bug rtl-optimization/65135] [5 Regression] Performance regression in pic mode after r220674.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65135 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|WAITING |NEW CC||vmakarov at redhat dot com --- Comment #5 from H.J. Lu hjl.tools at gmail dot com --- After r220674, we have movlz1.1821@GOTOFF(%ebp), %eax ... movl%eax, %esi ... movl%esi, 4(%esp) ... .L6: movl4(%esp), %ebx testl%ebx, %ebx jne.L9 movl20(%esp), %eax movl(%eax,%edx), %eax cmpl$-1, %eax je.L11 .L42: movl8(%esp), %edi leal0(,%eax,4), %edx movl%ecx, %ebx addl%edx, %edi cmpl$101, %ecx je.L40 movl12(%esp), %esi cmpl(%edi), %esi leal1(%ebx), %ecx jne.L6 vs movlz1.1821@GOTOFF(%ebx), %esi ... .L8: testl%esi, %esi jne.L11 movl16(%esp), %eax movl(%eax,%edx), %eax cmpl$-1, %eax je.L13 .L43: movl4(%esp), %edi leal0(,%eax,4), %edx movl%ecx, %ebx addl%edx, %edi cmpl$101, %ecx je.L41 movl8(%esp), %ebp cmpl(%edi), %ebp leal1(%ebx), %ecx jne.L8 RA puts GOT into %ebp and won't use it for this loop.
[Bug c++/65147] alignment of std::atomic object is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65147 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Fri, 20 Feb 2015, alexey.lapshin at oracle dot com wrote: According to the documentation - https://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy alignment of atomic object should match it`s size. Alignment in the test case below does not match with documentation. Not in itself a bug to fail to follow preliminary plans. *But*: This behavior also differs from gcc. Gcc aligns 8-bytes objects to 8-bytes. Differences between C and C++ atomics might be a bug - there may be intent for them to be ABI-compatible (although that didn't get implemented), unlike other aspects of the early plans you point to where intent changed over the course of implementation.
[Bug rtl-optimization/64317] [5 Regression] Ineffective allocation of PIC base register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64317 --- Comment #14 from Jeffrey A. Law law at redhat dot com --- Just trying to help out where I can. It's similar to the round robin use of reload regs we've had in reload for a while. THe idea was to hopefully have reloaded values lying around in a useful place more often to improve inheritance.
[Bug bootstrap/65150] New: bootstrap failure at r220878 on x86_64 darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150 Bug ID: 65150 Summary: bootstrap failure at r220878 on x86_64 darwin Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: howarth at bromo dot med.uc.edu Current gcc trunk at r220878 fails to bootstrap on x86_64-apple-darwin14 with the error... /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/xg++ -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc5.0/x86_64-apple-darwin14.3.0/bin/ -nostdinc++ -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/src/.libs -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/libsupc++/.libs -I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/include/x86_64-apple-darwin14.3.0 -I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/include -I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5-20150220/libstdc++-v3/libsupc++ -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.3.0/libstdc++-v3/libsupc++/.libs -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -Wl,-no_pie -o build/genmatch \ build/genmatch.o ../libcpp/libcpp.a ../libiberty/libiberty.a build/errors.o build/vec.o build/hash-table.o .././libiberty/libiberty.a -lintl -L/sw/lib -liconv Undefined symbols for architecture x86_64: std::type_info::__is_pointer_p() const, referenced from: vtable for __cxxabiv1::__si_class_type_info in libstdc++.a(si_class_type_info.o) vtable for __cxxabiv1::__class_type_info in libstdc++.a(class_type_info.o) vtable for std::type_info in libstdc++.a(tinfo.o) ld: symbol(s) not found for architecture x86_64 collect2: error: ld returned 1 exit status Makefile:2606: recipe for target 'build/genmatch' failed make[3]: *** [build/genmatch] Error 1 make[3]: Leaving directory '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc' Makefile:4408: recipe for target 'all-stage2-gcc' failed make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir' Makefile:20723: recipe for target 'stage2-bubble' failed make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir' Makefile:20918: recipe for target 'bootstrap' failed make: *** [bootstrap] Error 2
[Bug c++/65149] unaligned atomic object causes Bus Error on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65149 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Related to PR 62259 -- maybe even a dup.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 --- Comment #27 from Harald Anlauf anlauf at gmx dot de --- (In reply to Jerry DeLisle from comment #26) Created attachment 34819 [details] Updated full patch. Revised to fix error shown in Comment #22 The new patch does indeed fix the error in comment #22, and it also works for me (e.g. for the original issue). Thanks, Harald
[Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #11) Is this fixed at r220682 ? I think we can close this yes, as long as it's ok to have newline as isblank.
[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315
Aldy Hernandez aldyh at gcc dot gnu.org changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
||rth at gcc dot gnu.org
--- Comment #14 from Aldy Hernandez aldyh at gcc dot gnu.org ---
I'm not very familiar with the var tracking code, but one thing I see odd here
is a ton of similar var_location notes attached to each instruction (well, not
each instruction, but a lot of the instructions are affected while generating
code for test01, test02, test03, test04, etc).
I see an instruction like this:
(insn:TI 52195 52199 83288 6386 (set (mem/c:DI (plus:DI (reg/f:DI 6 bp)
(const_int -25880 [0x9ae8])) [125 %sfp+-25864 S8
A64])
(reg:DI 0 ax)) 89 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 0 ax)
(nil)))
(jump_insn 83288 52195 83289 6386 (set (pc)
(label_ref 34659)) 653 {jump}
(nil)
- 34659)
Followed by over 1000 var_location notes:
(note 11489581 83289 11489582 (var_location this(0x7fffe7223360) (plus:DI
(reg/f:DI 6 bp)
(const_int -21808 [0xaad0]))) NOTE_INSN_VAR_LOCATION)
(note 11489582 11489581 11489583 (var_location this(0x7fffe8d7dc60) (plus:DI
(reg/f:DI 6 bp)
(const_int -25200 [0x9d90]))) NOTE_INSN_VAR_LOCATION)
(note 11489583 11489582 11489584 (var_location this(0x7fffe72236c0) (plus:DI
(reg/f:DI 6 bp)
(const_int -21856 [0xaaa0]))) NOTE_INSN_VAR_LOCATION)
(note 11489584 11489583 11489585 (var_location this(0x7fffe7223bd0) (plus:DI
(reg/f:DI 6 bp)
(const_int -6576 [0xe650]))) NOTE_INSN_VAR_LOCATION)
(note 11489585 11489584 11489586 (var_location this(0x7fffe7223cf0) (plus:DI
(reg/f:DI 6 bp)
(const_int -21872 [0xaa90]))) NOTE_INSN_VAR_LOCATION)
(note 11489586 11489585 11489587 (var_location this(0x7fffe941e090) (plus:DI
(reg/f:DI 6 bp)
(const_int -25136 [0x9dd0]))) NOTE_INSN_VAR_LOCATION)
etc
etc etc
.
Notice all of them are the this pointer, but I have hacked the RTL dumping
code to also print the address of the DECL to show that every this is
actually a different instance.
This looks suspect. Anyone have a clue, otherwise I'm going to continue
banging my head against a wall here?
[Bug c/65145] size of atomic object is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65145 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Joseph S. Myers jsm28 at gcc dot gnu.org --- Not a bug; there is no intent to increase object size with _Atomic.
[Bug fortran/65141] ISO_10646 constant parameters convert kind when used with substring references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65141 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-20 CC||jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Confirmed and the problem is in the front end side.
[Bug libstdc++/64467] [5 Regression] 28_regex/traits/char/isctype.cc and wchar_t/isctype.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org --- In the POSIX (i.e. C) locale it should only be space and tab, but implementing that when the target only has 8-bits for the ctype mask and doesn't have a blank class is very difficult. For other locales it's OK for newline to be in the blank class.
[Bug c/65145] size of atomic object is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65145 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Fri, 20 Feb 2015, alexey.lapshin at oracle dot com wrote: The size of atomic object does not match with documentation - https://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy specifically : That's not documentation. It's an early description of intent that does not correspond to what was actually implemented (note the future tense in the words you quote, and the last edited date a year before I added _Atomic support to trunk based on Andrew's work). In general, old wiki pages are left around as they may help understand archived development discussions.
[Bug target/65109] [5 Regression] r220674 causes FAIL: gcc.target/powerpc/ppc64-abi-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65109 --- Comment #10 from Martin Sebor msebor at gcc dot gnu.org --- Created attachment 34821 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34821action=edit Patch to make the test less subject to register clobbering. FWIW, I agree with Richard that the test is overly fragile. I have attached another patch that attempts to make the test more reliable by splitting up each test function into two, one that does nothing but save the volatile registers (thus reducing the risk of them getting clobbered by other code), and another that then verifies their values.
[Bug c/65146] alignment of _Atomic structure member is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146 --- Comment #2 from Alexey Lapshin alexey.lapshin at oracle dot com --- if alignment of atomic object less then it`s size then it could not be lock-free on x86 32. If that object would split across cache lines then the operation would not be atomic. At the same time compiler reports for this 8-bytes size object: __atomic_always_lock_free(sizeof(obj2.ao), obj2.ao) TRUE atomic_is_lock_free( obj2.ao ) TRUE so it looks like lock-free atomic operation on this 4-bytes aligned data object could fail to be atomic.
[Bug bootstrap/65150] bootstrap failure at r220878 on x86_64 darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65150 --- Comment #1 from howarth at bromo dot med.uc.edu --- Failed for bootstrap using... ../gcc-5-20150220/configure --prefix=/sw --prefix=/sw/lib/gcc5.0 --mandir=/sw/share/man --infodir=/sw/lib/gcc5.0/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-5.0
[Bug c/65146] alignment of _Atomic structure member is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65146 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Fri, 20 Feb 2015, alexey.lapshin at oracle dot com wrote: Alignment of single _Atomic object match with documentation : https://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy . That's not documentation. Implementation differences from early plans are not a bug. Differences in alignment are only bugs if they mean atomic operations *fail to be atomic*.
[Bug c/65145] size of atomic object is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65145 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Fri, 20 Feb 2015, alexey.lapshin at oracle dot com wrote: Hi Joseph, Could you help me with a link to the correct description of atomic ABI, which in fact used by gcc/g++, please ? I don't believe it's documented, but I think the general rule for C is: if a type's size is 1, 2, 4, 8, 16, its alignment is increased by _Atomic to that of the atomic integer type of that size, which is the same as that of the non-atomic integer type unless increased by TARGET_ATOMIC_ALIGN_FOR_MODE; the size is never increased by _Atomic, and alignment of types not of those sizes is unchanged. If the code differs, likely the code should take precedence over that description. (But of course if a type is under-aligned for the instructions used to operate on it, there's a bug, whether in the alignment or in the instruction choice.)
[Bug target/65109] [5 Regression] r220674 causes FAIL: gcc.target/powerpc/ppc64-abi-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65109 --- Comment #11 from Jeffrey A. Law law at redhat dot com --- Martin, Looks good to me. Can you write a quick ChangeLog for the patch, then post it to gcc-patc...@gcc.gnu.org Something like
[Bug c/65145] size of atomic object is not correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65145 --- Comment #2 from Alexey Lapshin alexey.lapshin at oracle dot com --- Hi Joseph, Could you help me with a link to the correct description of atomic ABI, which in fact used by gcc/g++, please ? Thank you, Alexey.
[Bug target/65109] [5 Regression] r220674 causes FAIL: gcc.target/powerpc/ppc64-abi-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65109 --- Comment #12 from Jeffrey A. Law law at redhat dot com --- Martin, Looks good to me. Can you write a quick ChangeLog for the patch, then post it to gcc-patc...@gcc.gnu.org Something like PR target/65109 * gcc.target/powerpc/ppc64-abi-1.c: Split test functions into two parts. One to save registers, the other to verify the registers have the right values. Save register state into static data rather than on the stack.
