[Bug c++/77547] designated initializer reports a sorry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77547 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 55606. *** This bug has been marked as a duplicate of bug 55606 ***
[Bug c++/55606] sorry, unimplemented: non-trivial designated initializers not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55606 Andrew Pinski changed: What|Removed |Added CC||su at cs dot ucdavis.edu --- Comment #10 from Andrew Pinski --- *** Bug 77547 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/77541] [7 Regression] wrong code with 512bit vectors of int128 @ -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77541 --- Comment #2 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #1) > This is RA failure, where reload tries to fix up: To be clear, it is LRA pass, not reload.
[Bug c++/77548] ICE on invalid C++ code with overloaded functions: in instantiate_type, at cp/class.c:8270
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77548 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-10 CC||marxin at gcc dot gnu.org Target Milestone|--- |5.5 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug c++/77549] [7 Regression] ICE on invalid C++ code that references undeclared variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77549 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code Last reconfirmed||2016-9-10 CC||dmalcolm at gcc dot gnu.org, ||marxin at gcc dot gnu.org Target Milestone|--- |7.0 Summary|ICE on invalid C++ code |[7 Regression] ICE on |that references undeclared |invalid C++ code that |variable|references undeclared ||variable --- Comment #1 from Martin Liška --- Confirmed, started with r238538.
[Bug c++/77549] [7 Regression] ICE on invalid C++ code that references undeclared variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77549 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug c++/77545] [7 Regression] ICE on valid C++11 code: in potential_constant_expression_1, at cp/constexpr.c:5480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77545 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-10 CC||jason at redhat dot com, ||marxin at gcc dot gnu.org Summary|ICE on valid C++11 code: in |[7 Regression] ICE on valid |potential_constant_expressi |C++11 code: in |on_1, at|potential_constant_expressi |cp/constexpr.c:5480 |on_1, at ||cp/constexpr.c:5480 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r238559.
[Bug tree-optimization/77544] [Regression 6/7] segfault at -O0 - infinite loop in simplification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77544 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code CC||marxin at gcc dot gnu.org Target Milestone|--- |6.3 --- Comment #2 from Martin Liška --- The code snippet causes stack overflow as we periodically try to fold PLUS_EXPR: (unsigned int) (d + c) and ~(unsigned int) (302806 >> 0) to MINUS_EXPR: (unsigned int) (d + c) + (unsigned int) -(302806 >> 0) and 1 and so forth, there's part of back-trace: #1584 0x00d52f3a in fold_build2_stat_loc (loc=2147483652, code=PLUS_EXPR, type=0x76a02540, op0=0x767efd98, op1=0x769fac18) at ../../gcc/fold-const.c:12287 #1585 0x016a9ea5 in generic_simplify_MINUS_EXPR (loc=2147483652, code=MINUS_EXPR, type=0x76a02540, op0=0x767efd98, op1=0x769facc0) at generic-match.c:12390 #1586 0x016ebbaa in generic_simplify (loc=2147483652, code=MINUS_EXPR, type=0x76a02540, op0=0x767efd98, op1=0x769facc0) at generic-match.c:31237 #1587 0x00d42d9e in fold_binary_loc (loc=2147483652, code=MINUS_EXPR, type=0x76a02540, op0=0x767efd98, op1=0x769facc0) at ../../gcc/fold-const.c:9159 #1588 0x00d52f3a in fold_build2_stat_loc (loc=2147483652, code=MINUS_EXPR, type=0x76a02540, op0=0x767efd98, op1=0x769facc0) at ../../gcc/fold-const.c:12287 #1589 0x00d2083e in associate_trees (loc=2147483652, t1=0x767efd98, t2=0x769facc0, code=MINUS_EXPR, type=0x76a02540) at ../../gcc/fold-const.c:913 #1590 0x00d45f53 in fold_binary_loc (loc=2147483652, code=PLUS_EXPR, type=0x76a02540, op0=0x767f25e0, op1=0x767f2620) at ../../gcc/fold-const.c:9679 #1591 0x00d52f3a in fold_build2_stat_loc (loc=2147483652, code=PLUS_EXPR, type=0x76a02540, op0=0x767f25e0, op1=0x767f2620) at ../../gcc/fold-const.c:12287 #1592 0x00d2083e in associate_trees (loc=2147483652, t1=0x767f25e0, t2=0x767f2620, code=PLUS_EXPR, type=0x76a02540) at ../../gcc/fold-const.c:913 #1593 0x00d46049 in fold_binary_loc (loc=2147483652, code=PLUS_EXPR, type=0x76a02540, op0=0x767efd70, op1=0x769fac18) at ../../gcc/fold-const.c:9695 #1594 0x00d52f3a in fold_build2_stat_loc (loc=2147483652, code=PLUS_EXPR, type=0x76a02540, op0=0x767efd70, op1=0x769fac18) at ../../gcc/fold-const.c:12287 #1595 0x016a9ea5 in generic_simplify_MINUS_EXPR (loc=2147483652, code=MINUS_EXPR, type=0x76a02540, op0=0x767efd70, op1=0x769facc0) at generic-match.c:12390 #1596 0x016ebbaa in generic_simplify (loc=2147483652, code=MINUS_EXPR, type=0x76a02540, op0=0x767efd70, op1=0x769facc0) at generic-match.c:31237
[Bug c++/77522] ICE on invalid code C++14 code: in tsubst_decl, at cp/pt.c:12447
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77522 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-10 CC||marxin at gcc dot gnu.org Target Milestone|--- |5.5 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug tree-optimization/77544] [Regression 6/7] segfault at -O0 - infinite loop in simplification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77544 --- Comment #3 from Marc Glisse --- 302806 >> 0 should have been folded first, so we are apparently calling fold on unfolded operands somewhere?
[Bug c++/77550] New: std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550
Bug ID: 77550
Summary: std::deque with -O3 has infinite std::distance
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dan.cooke89 at gmail dot com
Target Milestone: ---
The following program, compiled with -O3, never returns:
#include
#include
#include
#include
#include
struct Foo
{
std::string bar, s = "";
char a = '\0';
};
int main()
{
const std::deque foos(14, {""});
const std::string test {};
const auto p = [test] (const auto& foo) { return foo.bar == test; };
using boost::make_filter_iterator;
const auto begin = make_filter_iterator(p, std::cbegin(foos),
std::cend(foos));
const auto end = make_filter_iterator(p, std::cend(foos),
std::cend(foos));
std::cout << std::distance(begin, end) << std::endl;
}
Observations:
- GCC with optimisations -O2 or less returns as expected.
- Clang (3.8) returns the correct answer with any optimisation level.
- Changing std::deque to std::vector or std::list results in expected
behaviour.
- The 14 is critical; anything less and the problem disappears.
- The sizeof(Foo) is important; removing s or a makes the problem go away.
- Capturing test by reference, or just comparing to a constant expression
(e.g. foo.bar == " ") results in normal behaviour.
- There are no compiler warnings (with -Wall -Wextra -pedantic).
- Valgrind reports no errors.
- Use fsanitize=undefined and the problem goes away.
From: http://stackoverflow.com/q/39424753/2970186
[Bug tree-optimization/77550] [5/6 Regression] std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-10 CC||trippels at gcc dot gnu.org Component|c++ |tree-optimization Summary|std::deque with -O3 has |[5/6 Regression] std::deque |infinite std::distance |with -O3 has infinite ||std::distance Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- -fno-tree-slp-vectorize "fixes" the issue.
[Bug tree-optimization/77550] [5/6 Regression] std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550 --- Comment #2 from Markus Trippelsdorf --- Created attachment 39596 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39596&action=edit unreduced testcase
[Bug tree-optimization/77550] [5/6 Regression] std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550 --- Comment #3 from Daniel Cooke --- -fno-strict-aliasing also resolves.
[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550 Jonathan Wakely changed: What|Removed |Added Severity|critical|normal
[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550 --- Comment #4 from Daniel Cooke --- @Jonathan Wakely: Why do you not consider this critical?
[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550 --- Comment #5 from Markus Trippelsdorf --- (In reply to Daniel Cooke from comment #4) > @Jonathan Wakely: Why do you not consider this critical? We don't use this field. So normal is just the default.
[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550 --- Comment #6 from Jonathan Wakely --- And if we did use it, it would be the severity as determined by the GCC project, not according to the bug reporter. Bug reporters tend to consider their own bugs of higher importance than everyone else's bugs :)
[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550 --- Comment #7 from Markus Trippelsdorf --- Well, the best solution would be to simply disable the field for users. This what other bugzillas do.
[Bug c++/68476] microblaze: compilation of btSoftBody.cpp doesn't terminate with optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68476
Arnout Vandecappelle changed:
What|Removed |Added
CC||arnout at mind dot be
Version|5.2.1 |6.2.0
--- Comment #3 from Arnout Vandecappelle ---
I just tried again with gcc 6.2 and the problem persists.
I've simplified the code to a minimal reproduction - it's so simple that it's
not worth attaching:
void foo (void* ptr);
struct Node
{
int m_v[16];
int m_leaf;
};
void setVolumeMass()
{
extern struct Node* m_n[4];
extern struct Node* m_nodes;
int *ranks;
int j;
for(j=0;j<4;++j)
{
ranks[(int)(m_n[j]-m_nodes)]=1;
}
foo ((void*)( ranks ));
}
Removing one line from the code above makes it pass.
The last file that is generated when run with -da is now
btSoftBody.i.281r.vartrack. It looks to me like it's much larger than it should
be. I'll attach it, as well as the preceding btSoftBody.i.280r.alignments. When
a line is removed from the code above, the compilation continues with
btSoftBody.i.282r.mach.
[Bug c++/68476] microblaze: compilation of btSoftBody.cpp doesn't terminate with optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68476 Arnout Vandecappelle changed: What|Removed |Added Attachment #36813|0 |1 is obsolete|| --- Comment #4 from Arnout Vandecappelle --- Created attachment 39597 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39597&action=edit Simplified code
[Bug c++/68476] microblaze: compilation of btSoftBody.cpp doesn't terminate with optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68476 --- Comment #5 from Arnout Vandecappelle --- Created attachment 39598 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39598&action=edit 280r.alignments intermediate output
[Bug c++/68476] microblaze: compilation of btSoftBody.cpp doesn't terminate with optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68476 --- Comment #6 from Arnout Vandecappelle --- Created attachment 39599 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39599&action=edit 281r.vartrack intermediate output
[Bug c++/68476] microblaze: compilation of btSoftBody.cpp doesn't terminate with optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68476 --- Comment #7 from Arnout Vandecappelle --- By the way, the reason I'm coming back to this after more than a year is that we're now encountering the same problem (compilation that doesn't terminate for microblaze) with ffmpeg.
[Bug web/77551] New: Please disable the "Importance:" field for normal users of bugzilla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77551 Bug ID: 77551 Summary: Please disable the "Importance:" field for normal users of bugzilla Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: LpSolit at netscape dot net Target Milestone: --- Currently every user has the ability to edit the "Importance:" field and many of them use this ability to change the field to "Critical" or some other value. Since the only P1-P5 is normally used and set only by the release managers, please disable the field for normal users. Thanks.
[Bug tree-optimization/77550] [6/7 Regression] std::deque with -O3 has infinite std::distance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550 --- Comment #8 from Markus Trippelsdorf --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77551
[Bug c/71602] [6/7 regression] ICE on __builtin_va_arg in build_va_arg, at c-family/c-common.c:5810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71602 --- Comment #16 from Tom de Vries --- Author: vries Date: Sat Sep 10 14:38:56 2016 New Revision: 240072 URL: https://gcc.gnu.org/viewcvs?rev=240072&root=gcc&view=rev Log: Make canonical_va_list_type more strict 2016-09-10 Tom de Vries PR C/71602 * builtins.c (std_canonical_va_list_type): Strictly return non-null for va_list type only. * config/i386/i386.c (ix86_canonical_va_list_type): Same. * gimplify.c (gimplify_va_arg_expr): Handle &va_list. * c-common.c (build_va_arg): Handle more strict targetm.canonical_va_list_type. Replace first argument type error with assert. * c-c++-common/va-arg-va-list-type.c: New test. Added: trunk/gcc/testsuite/c-c++-common/va-arg-va-list-type.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/config/i386/i386.c trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/77507] gfortran rejects keyworded calls to procedures from intrinsic modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77507 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Sep 10 14:45:46 2016 New Revision: 240073 URL: https://gcc.gnu.org/viewcvs?rev=240073&root=gcc&view=rev Log: 2016-09-10 Steven G. Kargl PR fortran/77507 * gfortran.dg/c_assoc_2.f03: Update for r240050 * gfortran.dg/c_assoc_4.f90: Ditto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_assoc_2.f03 trunk/gcc/testsuite/gfortran.dg/c_assoc_4.f90
[Bug c/77490] bit-not (~) on boolean should be warned about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77490 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Mine.
[Bug c++/77431] warn for having the same code in if-else branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77431 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-09-10 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Mine. Any ideas for the name?
[Bug c/64279] Warning missing for "(cond) ? A : A" / if(cond) expr1; else expr1; // same expression in if and else branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64279 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-09-10 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Mine. 77431 is actually a dup.
[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479 DB changed: What|Removed |Added CC||db0451 at gmail dot com --- Comment #5 from DB --- Sorry to wake the dead, but I'm wondering whether anyone has ever considered adding an opt-out for this diagnostic, or whether there's any other way to issue the following hint to g++: > "Believe me: you will only ever get one of these values, so don't worry about > it" Of course a malicious and/or absent-minded caller could pass in a value that the switch doesn't handle and invoke UB, but what about codebases that don't let in such callers? Should they have to artificially add a default/return/abort/whatever just to keep their build log readable? Interestingly, Clang is silent if you handle all your enum (including non-class) cases (and if you don't, says "control **may** reach end of non-void function [-Wreturn-type]") - which, yeah, seems nice initially - but arguably is a worse default, due to the aforementioned malicious caller and what Jonathan explained. So, I feel GCC could do one better by - quite rightly! - defaulting to warning about such callers - but, crucially, allowing the warning to be disabled by competent ones (willing to take the blame if they pass a duff value later) Anyway, just some idle thoughts and questions. I understand the current reasoning and don't disagree with the default, but think there's a potential gain here too.
[Bug c/64279] Warning missing for "(cond) ? A : A" / if(cond) expr1; else expr1; // same expression in if and else branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64279 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #2 from Bernd Edlinger --- Yes. I had also thought in the same direction for the Wint-in-bool-context... It may be good not to warn here, if both branches are in fact different macros that expand to the same expressions, say, they may depend on configure options, and are trivial on one target only.
[Bug web/77319] [bugzilla] bugzilla behaves erratically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77319 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed now.
[Bug plugins/69928] incorrect reference to gcc-plugin.h in plugin documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69928
--- Comment #1 from Andrew Pinski ---
It is installed at:
./lib/gcc/${target_triplet}/${version}/plugin/include/gcc-plugin.h
[Bug plugins/69928] incorrect reference to gcc-plugin.h in plugin documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69928 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-10 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Oh, yes events were moved over to plugin.def but the difference here is small. THough the events have changed it seemed.
[Bug rtl-optimization/77289] [7 Regression] ICE in extract_constrain_insn, at recog.c:2212 on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77289 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #8 from Bernd Edlinger --- Created attachment 39600 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39600&action=edit untested patch for the aarch64 fallout
[Bug tree-optimization/77552] New: FAIL: gcc.dg/tree-ssa/slsr-8.c scan-tree-dump-times optimized " w?\\* " 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77552 Bug ID: 77552 Summary: FAIL: gcc.dg/tree-ssa/slsr-8.c scan-tree-dump-times optimized " w?\\* " 7 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Created attachment 39601 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39601&action=edit Tree dump spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gc c/gcc/testsuite/gcc.dg/tree-ssa/slsr-8.c -fno-diagnostics-show-caret -fdiagnosti cs-color=never -O3 -fdump-tree-optimized -S -o slsr-8.s PASS: gcc.dg/tree-ssa/slsr-8.c (test for excess errors) FAIL: gcc.dg/tree-ssa/slsr-8.c scan-tree-dump-times optimized " w?\\* " 7
[Bug debug/77553] New: [6/7 Regression] wrong code with post-increment operator in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77553
Bug ID: 77553
Summary: [6/7 Regression] wrong code with post-increment
operator in constexpr
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
From
http://stackoverflow.com/questions/39427567/gcc-bug-in-decrement-array-access-in-constexpr
markus@x4 tmp % cat const.ii
constexpr void bar(int *b) {
int i = 0;
b[i++] = 1; // GCC failure here.
}
constexpr int foo() {
int tmp[] = {0};
bar(tmp);
return tmp[0];
}
constexpr int cexprI = foo();
int main() {
static_assert(cexprI, "");
if (!foo())
__builtin_abort();
}
markus@x4 tmp % g++ -O2 const.ii
const.ii: In function ‘int main()’:
const.ii:16:3: error: static assertion failed
static_assert(cexprI, "");
^
(With the static_assert commented out:)
markus@x4 tmp % g++ -O2 const.ii
markus@x4 tmp % ./a.out
[1]25850 abort ./a.out
[Bug c++/77542] __attribute__((warn_unused_result)) ignored on function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77542 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-09-10 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Do you have a full example which shows the issue? In your case does ReturnValue have a copy constructor? If so this is a dup of bug 38172. Note C++17 defines [[nodiscard]] which should be used here instead really but it is only implemented in GCC 7.
[Bug fortran/77532] ICE in check_dtio_interface1, at fortran/interface.c:4622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77532 --- Comment #3 from Jerry DeLisle --- Author: jvdelisle Date: Sat Sep 10 21:16:45 2016 New Revision: 240074 URL: https://gcc.gnu.org/viewcvs?rev=240074&root=gcc&view=rev Log: 2016-09-10 Paul Thomas Steven G. Kargl PR fortran/77532 ^ interface.c (check_dtio_arg_TKR_intent): Return after error. (check_dtio_interface1): Remove asserts, test for NULL and return if found. gfortran.dg/dtio_11.f90: new test. Added: trunk/gcc/testsuite/gfortran.dg/dtio_11.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/77546] [5 to 6 regression] C++ software renderer performance drop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77546 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-09-10 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Can you attach the preprocessed source?
[Bug middle-end/77546] [5 to 6 regression] C++ software renderer performance drop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77546 --- Comment #2 from Andrew Pinski --- Looks like an inlining difference: bl 418118 So please supply the preprocessed source which instantiates: unsigned int IlluminatePixel >(FatPointPhongAndSoftShadowed const &, TriangleCarrier const&, Scene const&, SDL_Surface*)
[Bug c++/77554] New: ICE on valid C++11 code with variadic template function: tree check: expected class ‘expression’, have ‘type’ (integer_type) in tree_operand_check, at tree.h:3524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77554
Bug ID: 77554
Summary: ICE on valid C++11 code with variadic template
function: tree check: expected class ‘expression’,
have ‘type’ (integer_type) in tree_operand_check, at
tree.h:3524
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The code is accepted by both Clang and MSVC.
It crashes all versions 4.8.x and later, and seems to be a regression from
4.7.x. However, 4.8.x to 6.2.x have a different crash log from the trunk.
$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160910 (experimental) [trunk revision 240069] (GCC)
$
$ clang++-3.8 -c -std=c++11 small.cpp
$
$ g++-trunk -c small.cpp
small.cpp: In substitution of ‘template int f(X...)
[with T = ]’:
small.cpp:3:29: required from here
small.cpp:3:29: internal compiler error: tree check: expected class
‘expression’, have ‘type’ (integer_type) in tree_operand_check, at tree.h:3524
int a = f (X < int, int > ());
^
0x1087d57 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-source-trunk/gcc/tree.c:9793
0x5df6b1 expr_check
../../gcc-source-trunk/gcc/tree.h:3195
0x5df6b1 tree_operand_check
../../gcc-source-trunk/gcc/tree.h:3524
0x70e0df tree_operand_check
../../gcc-source-trunk/gcc/tree.h:3140
0x70e0df unify_pack_expansion
../../gcc-source-trunk/gcc/cp/pt.c:19291
0x711578 unify
../../gcc-source-trunk/gcc/cp/pt.c:20089
0x7102ea unify
../../gcc-source-trunk/gcc/cp/pt.c:19985
0x710e46 unify
../../gcc-source-trunk/gcc/cp/pt.c:20081
0x5dfbd6 try_class_unification
../../gcc-source-trunk/gcc/cp/pt.c:19085
0x7100bf unify
../../gcc-source-trunk/gcc/cp/pt.c:20119
0x70c55d unify_one_argument
../../gcc-source-trunk/gcc/cp/pt.c:18412
0x70d674 unify_pack_expansion
../../gcc-source-trunk/gcc/cp/pt.c:19323
0x70f0d9 type_unification_real
../../gcc-source-trunk/gcc/cp/pt.c:18506
0x71cd24 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc-source-trunk/gcc/cp/pt.c:17931
0x67af4b add_template_candidate_real
../../gcc-source-trunk/gcc/cp/call.c:3119
0x67bc7c add_template_candidate
../../gcc-source-trunk/gcc/cp/call.c:3197
0x67bc7c add_candidates
../../gcc-source-trunk/gcc/cp/call.c:5396
0x67e3e9 perform_overload_resolution
../../gcc-source-trunk/gcc/cp/call.c:4066
0x6808de build_new_function_call(tree_node*, vec**, bool, int)
../../gcc-source-trunk/gcc/cp/call.c:4143
0x8241f0 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc-source-trunk/gcc/cp/semantics.c:2440
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.
$
-
template < typename ... > struct X {};
template < typename ... T > int f (X < T, T ... > ...);
int a = f (X < int, int > ());
[Bug middle-end/77546] [6 regression] C++ software renderer performance drop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77546 --- Comment #3 from PeteVine --- Created attachment 39602 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39602&action=edit Screen.cc preprocessed
[Bug c++/77553] [6/7 Regression] wrong code with post-increment operator in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77553 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-09-10 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |6.3 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- The bug is that for POINTER_PLUS_EXPR we do: case POINTER_PLUS_EXPR: r = cxx_eval_pointer_plus_expression (ctx, t, lval, non_constant_p, overflow_p); if (r) break; /* fall through */ ... r = cxx_eval_binary_expression (ctx, t, lval, non_constant_p, overflow_p); break; where both cxx_eval_pointer_plus_expression and cxx_eval_binary_expression calls cxx_eval_constant_expression on both operands of the POINTER_PLUS_EXPR. That unfortunately means if the first one returns NULL_TREE, the side-effects in the two subexpressions happen multiple times. So, either we should remove cxx_eval_pointer_plus_expression and fold what it does into cxx_eval_binary_expression, or cxx_eval_pointer_plus_expression should copy what cxx_eval_binary_expression does, or add some helper function which will be called only after both operands are processed through cxx_eval_constant_expression.
[Bug c++/77555] New: unused inline function in-function static variable accessed from outside leads to linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77555 Bug ID: 77555 Summary: unused inline function in-function static variable accessed from outside leads to linker error Product: gcc Version: 6.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marmoo1024 at gmail dot com Target Milestone: --- Created attachment 39603 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39603&action=edit examples showing the behavior. Two part problem, Part one Unused inline functions can cause static variables to be instantiated by constexpr variable taking the address of the static variable. The attached test.cpp shows it working. === Part two === In-function static variables can be made visible outside, through templates, and this causes a linker error. Not a compilation error. test2.cpp:(.text._ZZN9someclass6unusedEvEN6getter3getEv[_ZZN9someclass6unusedEvEN6getter3getEv]+0x7): undefined reference to `someclass::unused()::function_static' The error happens with g++ 4.8.5, 5.3.0, 6.1.1, with -std=c++11, -std=c++14, -std=c++1z. clang++-3.5 crashes, 3.8 and 3.9 compiles and objdump shows that the in-function static variables are instantiated but the function is not emitted (since it's implicitly inline). Any static variable that's not used is not instantiated. The attached test2.cpp shows this. Naturally the behavior doesn't change if the class is instantiated, and is not affected by optimization, which I believe in gcc has extra control flow analysis. The only difference to the error with optimization is that with O1 or above the unused reference is from _GLOBAL__sub_I_main. IMHO, gcc should follow the example of clang and instantiate static variables if they're referenced. Definitely not a linker error, I don't know if part one is required by the standard, but it seems plausible either way. If so, the compiler should detect the use of such static variables and emit them.
[Bug c++/77431] warn for having the same code in if-else branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77431 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #2 from Eric Gallager --- (In reply to Marek Polacek from comment #1) > Mine. Any ideas for the name? -Wduplicated-cond-body? Enabled by -Wduplicated-cond. -Wduplicated-branches? -Wredundant-branch?
[Bug c++/53479] Control flow analysis reports warnings in switch over an enum class even if all possible values have their branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53479 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #6 from Eric Gallager --- This should probably depend on the -fstrict-enums flag, as that controls whether enums can have any value or just those values that are enumerated.
[Bug c++/77556] New: ICE on invalid C++ code with non-constant non-type template argument: in convert_nontype_argument, at cp/pt.c:6416
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77556
Bug ID: 77556
Summary: ICE on invalid C++ code with non-constant non-type
template argument: in convert_nontype_argument, at
cp/pt.c:6416
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
It also affects 6.x and is a regression from 5.x.
$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160910 (experimental) [trunk revision 240069] (GCC)
$
$ g++-trunk -c small.cpp
small.cpp: In function ‘void f()’:
small.cpp:5:40: internal compiler error: in convert_nontype_argument, at
cp/pt.c:6416
L1: L2: A < (long) &&L2 - (long) &&L1 > a;
^
0x6f1717 convert_nontype_argument
../../gcc-source-trunk/gcc/cp/pt.c:6416
0x6f8323 convert_template_argument
../../gcc-source-trunk/gcc/cp/pt.c:7285
0x7039f3 coerce_template_parms
../../gcc-source-trunk/gcc/cp/pt.c:7747
0x70592a lookup_template_class_1
../../gcc-source-trunk/gcc/cp/pt.c:8320
0x70592a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc-source-trunk/gcc/cp/pt.c:8663
0x8238bd finish_template_type(tree_node*, tree_node*, int)
../../gcc-source-trunk/gcc/cp/semantics.c:3140
0x7ab894 cp_parser_template_id
../../gcc-source-trunk/gcc/cp/parser.c:15049
0x7abb3a cp_parser_class_name
../../gcc-source-trunk/gcc/cp/parser.c:21354
0x79d1ed cp_parser_qualifying_entity
../../gcc-source-trunk/gcc/cp/parser.c:6278
0x79d1ed cp_parser_nested_name_specifier_opt
../../gcc-source-trunk/gcc/cp/parser.c:5962
0x79b32d cp_parser_simple_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:16372
0x798891 cp_parser_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:16049
0x7ac253 cp_parser_decl_specifier_seq
../../gcc-source-trunk/gcc/cp/parser.c:12889
0x7b94a1 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12416
0x7b9921 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12363
0x7ba378 cp_parser_declaration_statement
../../gcc-source-trunk/gcc/cp/parser.c:11975
0x7b6d0b cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:10581
0x7b783c cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:10859
0x7b792f cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:10813
0x7b7adf cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:20832
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.
$
---
template < int > struct A {};
void f ()
{
L1: L2: A < (long) &&L2 - (long) &&L1 > a;
}
[Bug c++/77555] unused inline function in-function static variable accessed from outside leads to linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77555
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-09-11
CC||trippels at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf ---
% cat test2.ii
extern "C" void printf(...);
struct A {
A(int, char *p2) { printf(p2); }
};
template struct B { static A static_var; };
template
A B::static_var{0, GETTER::get()};
struct C {
void unused() {
static char function_static;
struct D {
static char *get() { return &function_static; }
};
auto addr = B<0, D>::static_var;
}
};
int main() {}
% clang++ -flto -O2 test2.ii
% clang++ -O2 test2.ii
% icpc -O2 test2.ii
% g++ -O2 test2.ii
/tmp/ccskrvWq.o:test2.ii:function _GLOBAL__sub_I_main: error: undefined
reference to 'C::unused()::function_static'
collect2: error: ld returned 1 exit status
(with -flto we get an ICE:)
% g++ -flto -O2 test2.ii
test2.ii:17:13: internal compiler error: in get_partitioning_class, at
symtab.c:1850
int main() {}
^
0x98fdd1 symtab_node::get_partitioning_class()
../../gcc/gcc/symtab.c:1850
0xc4ddb7 lto_output_varpool_node
../../gcc/gcc/lto-cgraph.c:614
0xc4ddb7 output_symtab()
../../gcc/gcc/lto-cgraph.c:1024
0xc60ba9 lto_output()
../../gcc/gcc/lto-streamer-out.c:2395
0xccb4ee write_lto
../../gcc/gcc/passes.c:2455
0xccefce ipa_write_summaries_1
../../gcc/gcc/passes.c:2519
0xccefce ipa_write_summaries()
../../gcc/gcc/passes.c:2579
0x9a8020 ipa_passes
../../gcc/gcc/cgraphunit.c:2330
0x9a8020 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2424
0x9aa8a1 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2557
0x9aa8a1 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2583
Please submit a full bug report,
