[Bug c++/82643] lambda capture breaks constexpr-ness of non-static const constexpr member call on non-constexpr value/variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82643 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/89822] New: self mov on x86_64 and not optimized-out sub on ARM/ARM64 in a jump table switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89822
Bug ID: 89822
Summary: self mov on x86_64 and not optimized-out sub on
ARM/ARM64 in a jump table switch
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
Host: x86_64
Target: x86_64/ARM/ARM64
Created attachment 46020
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46020=edit
A reproducer
A simple switch that will be generated as a jump table:
int f1();
int f2();
int f3();
int f4();
int f5();
int foo(int i)
{
switch (i) {
case 1: return f1();
case 2: return f2();
case 3: return f3();
case 4: return f4();
case 5: return f5();
}
__builtin_unreachable();
}
Compiles into (first two rows):
i686:
movl 4(%esp), %eax
jmp *.L4(,%eax,4)
x86_64:
movl %edi, %edi
jmp *.L4(,%rdi,8)
ARM:
sub r0, r0, #1
cmp r0, #16
ARM64:
sub w0, w0, #1
cmp w0, 16
I am not sure why on ARM there is even cmp+bls. https://godbolt.org/z/hi66cD
Possibly a useful info:
GCC x86_64
4.1 mov %edi, %eax
4.4 mov %edi, %edi
4.6 movl %edi, %edi
4.8 bogus jump became jump to ret
8.1 jump to ret removed, but self mov is still there
[Bug rtl-optimization/88347] ICE in begin_move_insn, at sched-ebb.c:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88347 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law --- Fixed on the trunk.
[Bug fortran/89821] New: Get a SIGFPE on a simple test of a kind=real128 variable with -ffpe-trap=invalid switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89821 Bug ID: 89821 Summary: Get a SIGFPE on a simple test of a kind=real128 variable with -ffpe-trap=invalid switch Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Created attachment 46019 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46019=edit test program that fails if -ffpe-trap=invalid is present on kind=real128 test but ok on kind=real32 and kind=real64 tests even with switch on Although there may be IEEE methods that are now preferred with some compilers the simplified code in the attachment shows a method for testing for a NaN value that I believe is standard and has worked with 32-bit and 64-bit REAL variables in more than one programming environment including gfortran(1) with and without the -ffpe-trap=invalid switch on the gfortran compile. The test fails on kind=real128 variables (on Cygwin, at least) with the error signal SIGFPE: Floating-point exception - erroneous arithmetic operation. but the same kind of test works without an error on kind=real32 and kind=real64 variables, as it always has up to this point. I do not think the test is an arithmetic operation and should be allowed even with the -ffpe-trap=invalid switch present, as it does for kind=real32 and kind=real128 floating point variables. Works without any VISIBLE problem without the -ffpe-trap=invalid switch.
[Bug preprocessor/89808] An option to disable warning "#pragma once in main file"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89808 --- Comment #8 from sduguay --- (In reply to Jonathan Wakely from comment #6) > In any case, I agree with confirming this as a bug: all warnings should be > controllable by a -Wxxx option. > > Adding such an option is quite easy, and a good first contribution to GCC. > For an example of adding a new option see https://gcc.gnu.org/r192968 I was going to propose looking into it. I'll try to find some time.
[Bug rtl-optimization/88347] ICE in begin_move_insn, at sched-ebb.c:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88347 --- Comment #5 from Jeffrey A. Law --- Author: law Date: Mon Mar 25 23:33:36 2019 New Revision: 269928 URL: https://gcc.gnu.org/viewcvs?rev=269928=gcc=rev Log: PR rtl-optimization/88347 PR rtl-optimization/88423 * sched-deps.c (sched_analyze_insn): Take into account that for tablejumps the barrier appears after a label and a jump_table_data. * gcc.c-torture/compile/pr88347.c: New test. * gcc.c-torture/compile/pr88423.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr88347.c trunk/gcc/testsuite/gcc.c-torture/compile/pr88423.c Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/88423] [9 Regression] ICE in begin_move_insn, at sched-ebb.c:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88423 --- Comment #8 from Jeffrey A. Law --- Author: law Date: Mon Mar 25 23:33:36 2019 New Revision: 269928 URL: https://gcc.gnu.org/viewcvs?rev=269928=gcc=rev Log: PR rtl-optimization/88347 PR rtl-optimization/88423 * sched-deps.c (sched_analyze_insn): Take into account that for tablejumps the barrier appears after a label and a jump_table_data. * gcc.c-torture/compile/pr88347.c: New test. * gcc.c-torture/compile/pr88423.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr88347.c trunk/gcc/testsuite/gcc.c-torture/compile/pr88423.c Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/70692] No warning when std::function binds a reference to a temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70692 --- Comment #3 from Jonathan Wakely --- This should get addressed more thoroughly by https://wg21.link/p0932
[Bug fortran/85537] Invalid memory reference at runtime when calling subroutine through procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537 Thomas Koenig changed: What|Removed |Added Component|rtl-optimization|fortran Summary|[7/8/9 Regression] Invalid |Invalid memory reference at |memory reference at runtime |runtime when calling |when calling subroutine |subroutine through |through procedure pointer |procedure pointer --- Comment #12 from Thomas Koenig --- (In reply to Thomas Koenig from comment #11) > r237104 fails for me, testing r237008. r237007 also fails, as do earlier versions of the compiler. Not a regression then, but rather a design fault - seems like we need to do some magic to tell the middle end that we could access global variables (i.e. make sure that %r10 contains the right address).
[Bug c/83855] [performance] Improve cse optimization for insn with inout ops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83855
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||segher at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #3 from Segher Boessenkool ---
The internals manual explains this:
Note that @code{match_dup} should not be used to tell the compiler that
a particular register is being used for two operands (example:
@code{add} that adds one register to another; the second register is
both an input operand and the output operand). Use a matching
constraint (@pxref{Simple Constraints}) for those. @code{match_dup} is for the
cases where one
operand is used in two places in the template, such as an instruction
that computes both a quotient and a remainder, where the opcode takes
two input operands but the RTL template has to refer to each of those
twice; once for the quotient pattern and once for the remainder pattern.
[Bug rtl-optimization/85537] [7/8/9 Regression] Invalid memory reference at runtime when calling subroutine through procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85537 --- Comment #11 from Thomas Koenig --- r237104 fails for me, testing r237008.
[Bug c/89812] [9 Regression] incorrect maximum in error: requested alignment ‘536870912’ exceeds maximum 2147483648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89812 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fixed in r269927.
[Bug c/89812] [9 Regression] incorrect maximum in error: requested alignment ‘536870912’ exceeds maximum 2147483648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89812 --- Comment #3 from Martin Sebor --- Author: msebor Date: Mon Mar 25 22:56:40 2019 New Revision: 269927 URL: https://gcc.gnu.org/viewcvs?rev=269927=gcc=rev Log: PR c/89812 - incorrect maximum in error: requested alignment '536870912' exceeds maximum 2147483648 gcc/c-family/ChangeLog: PR c/89812 * c-common.c (check_user_alignment): Rename local. Correct maximum alignment in diagnostic. Avoid assuming argument fits in SHWI, convert it to UHWI when it fits. gcc/testsuite/ChangeLog: PR c/89812 * gcc.dg/attr-aligned-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/attr-aligned-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/89435] [7/8/9 Regression] wrong code with -O1 -march=armv4 -fno-forward-propagate with __builtin_sub_overflow()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89435 --- Comment #7 from Eric Botcazou --- *** Bug 89815 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/89815] [7/8/9 Regression] wrong code with -Og -march=armv4t -fno-tree-ccp -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89815 Eric Botcazou changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Eric Botcazou --- Plain dup. *** This bug has been marked as a duplicate of bug 89435 ***
[Bug debug/86964] [7/8/9 Regression] Too many debug symbols included, especially for extern globals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86964 --- Comment #9 from Jeffrey A. Law --- Author: law Date: Mon Mar 25 21:19:09 2019 New Revision: 269925 URL: https://gcc.gnu.org/viewcvs?rev=269925=gcc=rev Log: PR debug/86964 * dwarf2out.c (premark_used_variables): New function. (prune_unused_types_walk): Do not mark not premarked external variables. (prune_unused_types): Call premark_used_variables. * gcc.dg/debug/dwarf2/pr86964.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr86964.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug c++/79367] ICE with decltype of VLA in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79367 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Summary|ICE on valid C++11 code on |ICE with decltype of VLA in |x86_64-linux-gnu: |lambda |verify_gimple failed| --- Comment #3 from Jason Merrill --- This is not valid C++11 code: b (and thus c) are VLAs, which are not part of any C++ standard. But we should still accept it. G++ currently has trouble with outer VLA types that aren't simple "array of runtime bound" from the cancelled Arrays TS.
[Bug rtl-optimization/89676] [7/8/9 Regression] Redundant moves for long long shift on 32bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89676 --- Comment #9 from Vladimir Makarov --- Author: vmakarov Date: Mon Mar 25 21:14:40 2019 New Revision: 269924 URL: https://gcc.gnu.org/viewcvs?rev=269924=gcc=rev Log: 2019-03-25 Vladimir Makarov PR rtl-optimization/89676 * lra-constraints.c (curr_insn_transform): Do match reload for early clobbers when the match was successful only for different registers. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 70515, which changed state. Bug 70515 Summary: Nested lambdas causing invalid captured pointers on some platforms https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70515 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID
[Bug c++/70515] Nested lambdas causing invalid captured pointers on some platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70515 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |INVALID --- Comment #7 from Jason Merrill --- lambda2 captures lambda1 by reference, and is then copied into func. When their block ends lambda1 no longer exists, so the reference in func is dangling, and so invoking it has undefined behavior.
[Bug c++/87327] [8/9 Regression] Calling member functions on captured constexpr variables "is not a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87327 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/88529] G++ clears the return register on x86_64 when returning an empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88529 --- Comment #4 from Andrew Pinski --- related to PR20408 (but not the same as the patch which Jason attached is different)
[Bug c++/85013] [7/8 Regression] :1:41: internal compiler error: in wide_int_to_tree_1, at tree.c:1567 0x4097e2b wide_int_to_tree_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85013 Paolo Carlini changed: What|Removed |Added Summary|[7/8/9 Regression] |[7/8 Regression] |:1:41: internal |:1:41: internal |compiler error: in |compiler error: in |wide_int_to_tree_1, at |wide_int_to_tree_1, at |tree.c:1567 0x4097e2b |tree.c:1567 0x4097e2b |wide_int_to_tree_1 |wide_int_to_tree_1 --- Comment #4 from Paolo Carlini --- Fixed in trunk so far.
[Bug c++/84661] [7/8 Regression] internal compiler error: Segmentation fault (strip_array_types())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84661 Paolo Carlini changed: What|Removed |Added Summary|[7/8/9 Regression] internal |[7/8 Regression] internal |compiler error: |compiler error: |Segmentation fault |Segmentation fault |(strip_array_types()) |(strip_array_types()) --- Comment #7 from Paolo Carlini --- Fixed in trunk so far.
[Bug c++/84661] [7/8/9 Regression] internal compiler error: Segmentation fault (strip_array_types())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84661 --- Comment #6 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Mar 25 20:43:36 2019 New Revision: 269923 URL: https://gcc.gnu.org/viewcvs?rev=269923=gcc=rev Log: /cp 2019-03-25 Paolo Carlini PR c++/84661 PR c++/85013 * parser.c (cp_parser_binary_expression): Don't call cp_fully_fold to undo the disabling of warnings. /testsuite 2019-03-25 Paolo Carlini PR c++/84661 PR c++/85013 * g++.dg/concepts/pr84661.C: New. * g++.dg/torture/pr85013.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/concepts/pr84661.C trunk/gcc/testsuite/g++.dg/torture/pr85013.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/85013] [7/8/9 Regression] :1:41: internal compiler error: in wide_int_to_tree_1, at tree.c:1567 0x4097e2b wide_int_to_tree_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85013 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Mar 25 20:43:36 2019 New Revision: 269923 URL: https://gcc.gnu.org/viewcvs?rev=269923=gcc=rev Log: /cp 2019-03-25 Paolo Carlini PR c++/84661 PR c++/85013 * parser.c (cp_parser_binary_expression): Don't call cp_fully_fold to undo the disabling of warnings. /testsuite 2019-03-25 Paolo Carlini PR c++/84661 PR c++/85013 * g++.dg/concepts/pr84661.C: New. * g++.dg/torture/pr85013.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/concepts/pr84661.C trunk/gcc/testsuite/g++.dg/torture/pr85013.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug target/88529] G++ clears the return register on x86_64 when returning an empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88529 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-25 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #3 from Andrew Pinski --- There might be another bug that talks about this similar thing. Confirmed.
[Bug middle-end/89820] Returning empty type produces unnecessary instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89820 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 88529. *** This bug has been marked as a duplicate of bug 88529 ***
[Bug target/88529] G++ clears the return register on x86_64 when returning an empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88529 Andrew Pinski changed: What|Removed |Added CC||antoshkka at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 89820 has been marked as a duplicate of this bug. ***
[Bug c++/89820] New: Returning empty type produces unnecessary instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89820
Bug ID: 89820
Summary: Returning empty type produces unnecessary instructions
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the following code
struct my_type_impl {};
my_type_impl foo0() { return {}; }
my_type_impl foo1() { my_type_impl tmp; return tmp; }
For `foo0` and `foo1` GCC generates the following assembly:
xor eax, eax
ret
However xoring the `eax` seems unnecessary and some of the other compilers just
generate the `ret` instruction.
The additional `xor` instruction could significantly increase the code size for
generic C++ programs. For example in Bug 89819 and Bug 89816 each of he 36 jump
table entries has that additional instruction.
[Bug fortran/71861] [7/8/9 Regression] [F03] ICE in write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71861 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from janus at gcc dot gnu.org --- Fixed on trunk and the 7 and 8 branches. Closing.
[Bug c++/86429] [8/9 Regression] lambda capture breaks constexpr-ness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86429
--- Comment #5 from Jason Merrill ---
Reduced:
struct A
{
int i;
constexpr int f(const int&) const { return i; }
};
void g()
{
constexpr A a = { 42 };
[&](auto x) {
constexpr auto y = a.f(x);
}(24);
}
[Bug fortran/71861] [7/8/9 Regression] [F03] ICE in write_symbol(): bad module symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71861 --- Comment #12 from janus at gcc dot gnu.org --- Author: janus Date: Mon Mar 25 19:58:04 2019 New Revision: 269922 URL: https://gcc.gnu.org/viewcvs?rev=269922=gcc=rev Log: fix PR 71861 2019-03-25 Janus Weil PR fortran/71861 * symbol.c (check_conflict): ABSTRACT attribute conflicts with INTRINSIC attribute. 2019-03-25 Janus Weil PR fortran/71861 * gfortran.dg/interface_abstract_5.f90: New test case. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/interface_abstract_5.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/symbol.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug c++/86429] [8/9 Regression] lambda capture breaks constexpr-ness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86429 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/86521] [8 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521 Jason Merrill changed: What|Removed |Added Summary|[8/9 Regression] GCC 8 |[8 Regression] GCC 8 |selects incorrect overload |selects incorrect overload |of ref-qualified conversion |of ref-qualified conversion |operator template |operator template --- Comment #9 from Jason Merrill --- Fixed on trunk so far.
[Bug c++/87480] [8 Regression] SFINAE constructor not matched, only in templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87480 Jason Merrill changed: What|Removed |Added Summary|[8/9 Regression] SFINAE |[8 Regression] SFINAE |constructor not matched,|constructor not matched, |only in templated function |only in templated function --- Comment #6 from Jason Merrill --- Fixed on trunk so far.
[Bug c++/87748] [8 Regression] G++-8 treats SFINAE as error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87748 Jason Merrill changed: What|Removed |Added Summary|[8/9 Regression] G++-8 |[8 Regression] G++-8 treats |treats SFINAE as error |SFINAE as error --- Comment #4 from Jason Merrill --- Fixed on trunk so far.
[Bug c++/87480] [8/9 Regression] SFINAE constructor not matched, only in templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87480 --- Comment #5 from Jason Merrill --- Author: jason Date: Mon Mar 25 18:27:08 2019 New Revision: 269921 URL: https://gcc.gnu.org/viewcvs?rev=269921=gcc=rev Log: PR c++/87748 - substitution failure error with decltype. This issue is similar to PR 87480; in both cases we were doing non-dependent substitution with processing_template_decl set, leading to member access expressions seeming still instantiation-dependent, and therefore decltype not being simplified to its actual type. And as in that PR, the fix is to clear processing_template_decl while substituting a default template argument. * pt.c (most_specialized_partial_spec): Clear processing_template_decl. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae64.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/87748] [8/9 Regression] G++-8 treats SFINAE as error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87748 --- Comment #3 from Jason Merrill --- Author: jason Date: Mon Mar 25 18:27:08 2019 New Revision: 269921 URL: https://gcc.gnu.org/viewcvs?rev=269921=gcc=rev Log: PR c++/87748 - substitution failure error with decltype. This issue is similar to PR 87480; in both cases we were doing non-dependent substitution with processing_template_decl set, leading to member access expressions seeming still instantiation-dependent, and therefore decltype not being simplified to its actual type. And as in that PR, the fix is to clear processing_template_decl while substituting a default template argument. * pt.c (most_specialized_partial_spec): Clear processing_template_decl. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae64.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug preprocessor/89808] An option to disable warning "#pragma once in main file"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89808 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Blocks||44209 --- Comment #7 from Eric Gallager --- (In reply to Jonathan Wakely from comment #6) > In any case, I agree with confirming this as a bug: all warnings should be > controllable by a -Wxxx option. This is bug 44209 > > Adding such an option is quite easy, and a good first contribution to GCC. > For an example of adding a new option see https://gcc.gnu.org/r192968 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 [Bug 44209] [meta-bug] Some warnings are not linked to diagnostics options
[Bug c++/89767] [8 Regression] ICE with tuple and optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89767 Jakub Jelinek changed: What|Removed |Added Summary|[8/9 Regression] ICE with |[8 Regression] ICE with |tuple and optimization |tuple and optimization --- Comment #9 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug other/89817] remove references to type modes from user docs for vector extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89817 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-25 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Gallager --- confirmed
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 --- Comment #10 from Ville Voutilainen --- Assignment can be made to avoid double-visitation, instead of using _M_destructive_move/copy. Other than that, getting it to generate fewer table items needs the idea from the other bug report.
[Bug libstdc++/89819] [9 Regression] std::variant operators regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89819 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #1 from Ville Voutilainen --- The problem with this idea is that it brings back a run-time branch that the visitation got rid of. What we probably need is a different generated table for these functions, a table that uses the same index for both variants or invokes a cookie-function.
[Bug rtl-optimization/89815] [7/8/9 Regression] wrong code with -Og -march=armv4t -fno-tree-ccp -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89815 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-25 CC||ebotcazou at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |7.5 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Also regressed with r242326.
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 --- Comment #9 from Antony Polukhin --- BTW, I think there are some other cases where binary visitation could be simplified to unary (significantly reducing the code size and improving the compile times). I've filled Bug 89819, but looks like assignment and swap could be also optimized.
[Bug libstdc++/89819] New: [9 Regression] std::variant operators regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89819
Bug ID: 89819
Summary: [9 Regression] std::variant operators regressed since
GCC 8.3
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
The following code
#include
struct my_type{};
bool operator==(const my_type&, const my_type&) noexcept;
using V1 = std::variant;
auto test1(const V1& v) { return v == v; }
Was producing a jump table of size 5 on GCC 8.3. GCC 9 produces huge jump
tables with over 30 entries. This leads to ~15 times bigger binaries with GCC 9
and ~25% compilation slowdown. https://godbolt.org/z/yoAIrP
This could be fixed by changing the `_VARIANT_RELATION_FUNCTION_TEMPLATE` from
binary visitation to unary via first checking the `index()` of `__lhs` +
`__rhs` and doing the visitation only if they match (hold the same type).
Pseudo-code:
#define _VARIANT_RELATION_FUNCTION_TEMPLATE(__OP, __NAME) \
template \
constexpr bool operator __OP(const variant<_Types...>& __lhs, \
const variant<_Types...>& __rhs) \
{ \
bool __ret = true; \
if ((__lhs.index() + 1) != (__rhs.index() + 1)) { \
return (__lhs.index() + 1) __OP (__rhs.index() + 1); \
} \
__do_visit([&__ret, &__lhs] \
(auto&& __rhs_mem) mutable \
-> __detail::__variant::__variant_cookie \
{ \
using __Type = remove_reference_t; \
if constexpr (!is_same_v< \
__Type, \
__detail::__variant::__variant_cookie>) \
__ret =
__detail::__variant::__get<__detail::__variant::__index_of_v<__Type,
_Types...>>(__this_mem) __OP __rhs_mem; \
return {}; \
}, __rhs); \
return __ret; \
} \
\
constexpr bool operator __OP(monostate, monostate) noexcept \
{ return 0 __OP 0; }
[Bug c++/89796] Incorrect warning generated with OpenMP atomic capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89796
--- Comment #6 from Arsène Pérard-Gayot ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 46018 [details]
> gcc9-pr89796.patch
>
> Untested fix.
>
> You could have used simpler
> #pragma omp atomic capture
> prev = c++;
> that wouldn't warn (so, if you want a workaround, use that).
Thank you for the workaround. Sadly, I cannot apply it to my problem, because
in my original code, the increment is not one. I need to do something like:
#pragma omp atomic capture
{ prev = counter; counter += K; }
[Bug c++/67343] C++ mangler does not follow ABI for local names in expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67343 Andrew Pinski changed: What|Removed |Added Keywords||ABI, wrong-code See Also||https://github.com/itanium- ||cxx-abi/cxx-abi/issues/38 --- Comment #2 from Andrew Pinski --- Related to the upstream ABI issue: https://github.com/itanium-cxx-abi/cxx-abi/issues/38 related to PR 88413 and PR 89818 .
[Bug c++/89818] possibly invalid name mangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89818 --- Comment #2 from Andrew Pinski --- And related to the upstream ABI issue: https://github.com/itanium-cxx-abi/cxx-abi/issues/38 .
[Bug c++/88413] g++ mangles names involving unresolved names in function argument template parameters differently from the ABI standard.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88413 --- Comment #10 from Andrew Pinski --- related to PR 67343.
[Bug c++/89818] possibly invalid name mangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89818 --- Comment #1 from Andrew Pinski --- related to PR 88413 and PR 67343
[Bug c++/89818] New: possibly invalid name mangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89818 Bug ID: 89818 Summary: possibly invalid name mangling Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- Apologies for the vagueness of this bug. I ran across a pull request that mentions that gcc will sometimes emit an erroneous 'sr' mangling: https://github.com/gimli-rs/cpp_demangle/pull/173 In particular that bug claims that gcc can emit this symbol, which it further claims is invalid: _ZN4base8internal14CheckedSubImplIlEENSt9enable_ifIXsrSt14numeric_limitsIT_E10is_integerEbE4typeES4_S4_PS4_ I don't know whether these claims are accurate, but I figured it would be worth filing, just in case.
[Bug c++/89214] [7/8 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89214 Marek Polacek changed: What|Removed |Added Summary|[7/8/9 Regression] ICE in |[7/8 Regression] ICE in |digest_init_r, at |digest_init_r, at |cp/typeck2.c:1211 with |cp/typeck2.c:1211 with |-std=c++17 |-std=c++17 --- Comment #12 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/89214] [7/8/9 Regression] ICE in digest_init_r, at cp/typeck2.c:1211 with -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89214 --- Comment #11 from Marek Polacek --- Author: mpolacek Date: Mon Mar 25 16:38:48 2019 New Revision: 269919 URL: https://gcc.gnu.org/viewcvs?rev=269919=gcc=rev Log: PR c++/89214 - ICE when initializing aggregates with bases. * typeck2.c (digest_init_r): Warn about object slicing instead of crashing. * g++.dg/cpp1z/aggr-base8.C: New test. * g++.dg/cpp1z/aggr-base9.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1z/aggr-base8.C trunk/gcc/testsuite/g++.dg/cpp1z/aggr-base9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 Ville Voutilainen changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-03-25 Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com Ever confirmed|0 |1
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 --- Comment #8 from Ville Voutilainen --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01200.html
[Bug c++/89705] [7/8 Regression] ICE in convert_like_real, at cp/call.c:7334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89705 Marek Polacek changed: What|Removed |Added Summary|[7/8/9 Regression] ICE in |[7/8 Regression] ICE in |convert_like_real, at |convert_like_real, at |cp/call.c:7334 |cp/call.c:7334 --- Comment #7 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/89705] [7/8/9 Regression] ICE in convert_like_real, at cp/call.c:7334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89705 --- Comment #6 from Marek Polacek --- Author: mpolacek Date: Mon Mar 25 16:10:06 2019 New Revision: 269918 URL: https://gcc.gnu.org/viewcvs?rev=269918=gcc=rev Log: PR c++/89705 - ICE with reference binding with conversion function. * call.c (reference_binding): If the result of the conversion function is a prvalue of non-class type, use the cv-unqualified type. * g++.dg/cpp0x/rv-conv2.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/rv-conv2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/89796] Incorrect warning generated with OpenMP atomic capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89796 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-03-25 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Jakub Jelinek --- Created attachment 46018 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46018=edit gcc9-pr89796.patch Untested fix. You could have used simpler #pragma omp atomic capture prev = c++; that wouldn't warn (so, if you want a workaround, use that).
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 --- Comment #7 from Ville Voutilainen --- Looks good - I'll do a patch shortly.
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816
--- Comment #6 from Antony Polukhin ---
The fix seems pretty trivial: in function `__variant_construct` get the address
of the sorage before entering the `__do_visit` and make it switch only by the
`__rhs`.
Pseudo-code:
template
void __variant_construct(_Tp&& __lhs, _Up&& __rhs)
{
__lhs._M_index = __rhs._M_index;
void* storage = std::addressof(__lhs._M_u);
__do_visit([storage](auto&& __rhs_mem)
-> __detail::__variant::__variant_cookie
{
using _Type = remove_reference_t;
::new (storage)
_Type(std::forward(__rhs_mem));
return {};
}, __variant_cast<_Types...>(std::forward(__rhs)));
}
[Bug other/89817] New: remove references to type modes from user docs for vector extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89817 Bug ID: 89817 Summary: remove references to type modes from user docs for vector extensions Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- The existing user documentation for vector extensions (including the type and variable attributes and not just the Vector Extensions section) is full of references to type modes. This is an internal GCC implementation detail and probably only confuses ordinary users. We need to rewrite this documentation to remove the references and explain the concepts in some other way.
[Bug debug/89529] Wrong debug info generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89529
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-03-25
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
Confirmed. Alex - how do we distinguish before/after sequence point here
when breaking on line 7? Is this a consumer issue? As you can see the
actual breakpoint is on the implicit return, but in final the simple-return
pattern is associated with line 8... (but still covered by the line 7
DEBUG BEGIN_STMT it seems).
b ()
{
[local count: 1073741824]:
[t.c:3:5] # DEBUG BEGIN_STMT
[t.c:3:11] # DEBUG l_1862 => 19071
[t.c:4:5] # DEBUG BEGIN_STMT
[t.c:4:7] a = 0;
[t.c:5:5] # DEBUG BEGIN_STMT
[t.c:7:5] # DEBUG BEGIN_STMT
[t.c:7:5] # DEBUG l_1862 => 19070
[t.c:8:1] return;
(gdb) disassemble
Dump of assembler code for function b:
0x004004b2 <+0>: movl $0x0,0x200b78(%rip)# 0x601034
=> 0x004004bc <+10>:retq
End of assembler dump.
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 --- Comment #5 from Ville Voutilainen --- Correct.
[Bug c++/89700] Warn if move constructor is not generated and not deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89700 --- Comment #6 from Antony Polukhin --- Another way to workaround the warning is to use something like `my_class(my_class&) requires false;`. That's too ugly to use. I'd be fine with closing this issue as a 'won't fix'.
[Bug debug/89791] gcc generates wrong debug information at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89791
Richard Biener changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #2 from Richard Biener ---
Here we have sth looking like a dup of PR89463 but not fixed by its patch.
With
the patch we end up with
main ()
{
[local count: 1073741824]:
[t.c:2:5] # DEBUG BEGIN_STMT
[t.c:2:9] # DEBUG i => 0
[t.c:3:5] # DEBUG BEGIN_STMT
# DEBUG i => NULL
[t.c:5:5] # DEBUG BEGIN_STMT
[t.c:5:5] optimize_me_not ();
[:0:0] return 0;
and in .final:
(note 1 0 3 NOTE_INSN_DELETED)
(note 3 1 20 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 20 3 2 2 NOTE_INSN_PROLOGUE_END)
(note 2 20 27 2 NOTE_INSN_FUNCTION_BEG)
(note 27 2 30 2 t.c:2 NOTE_INSN_BEGIN_STMT)
(note 30 27 28 2 (var_location i (const_int 0 [0])) NOTE_INSN_VAR_LOCATION)
(note 28 30 31 2 t.c:3 NOTE_INSN_BEGIN_STMT)
(note 31 28 29 2 (var_location i (nil)) NOTE_INSN_VAR_LOCATION)
(note 29 31 24 2 t.c:5 NOTE_INSN_BEGIN_STMT)
...
(call_insn:TI 11 24 25 2 (set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:DI ("optimize_me_not") [flags 0x3]
) [0 optimize_me_not S1 A8])
(const_int 0 [0]))) "t.c":5:5 677 {*call_value}
which looks good to me. But then we still get
<2><133>: Abbrev Number: 4 (DW_TAG_variable)
<134> DW_AT_name: i
<136> DW_AT_decl_file : 1
<137> DW_AT_decl_line : 2
<138> DW_AT_decl_column : 9
<139> DW_AT_type: <0x165>
<13d> DW_AT_location: 0x2 (location list)
<141> DW_AT_GNU_locviews: 0x0
0002 v002 v003 views at for:
004003e0 004003e0 (DW_OP_lit0; DW_OP_stack_value)
so we somehow lost the optimized-out association? Or is my consumer
just not behaving? (gdb 8.2)
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 --- Comment #3 from Ville Voutilainen --- The problem here is that the older approach knows that it's always from type X1 to type X1, never from type X4 to X2. The visitation approach generates combinations that we never use.
[Bug debug/89463] debug information for iteractor of an empty loop is gone (at -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89463 --- Comment #9 from Qirun Zhang --- (In reply to Richard Biener from comment #8) > Patch posted here: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01192.html > > Some of your bugs might turn out as duplicates if they are fixed by that > patch. Thanks, Richard. When will the patch be landed? It helps a lot to reduce duplicates.
[Bug debug/89463] debug information for iteractor of an empty loop is gone (at -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89463 --- Comment #10 from rguenther at suse dot de --- On Mon, 25 Mar 2019, qrzhang at gatech dot edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89463 > > --- Comment #9 from Qirun Zhang --- > (In reply to Richard Biener from comment #8) > > Patch posted here: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01192.html > > > > Some of your bugs might turn out as duplicates if they are fixed by that > > patch. > > Thanks, Richard. When will the patch be landed? It helps a lot to reduce > duplicates. I'm waiting for testing/ACK.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #38 from Nickolay Kolchin-Semyonov --- Since this is a long standing problem, maybe this limitation should be mentioned in official documentation?
[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62181
--- Comment #17 from Eric Gallager ---
(In reply to Xi Ruoyao from comment #16)
> (In reply to Jonathan Wakely from comment #15)
> > Was this question ever answered?
> > https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01337.html
>
> Oh that's intentional.
>
> This would make this warning more useful, while most people won't use a
> "char" to address an array or something like. For example, if someone has
> wrote a string-like class but forgot to overload operator+=, this warning
> will detect it when he writes "char c = getchar(); buggy_string t = s + c;".
>
> And for something like
>
> "char *p = s; char x; scanf("%hhd", ); p = p + x;"
>
> 1. In C++ __INT8_TYPE__ is not __CHAR_TYPE__ so there will be no warning.
> He can use "int8_t x;" instead of "char x;".
> 2. He can use p = [x], which is more clear and nobody will think this is
> an append.
>
> I remember I wrote a response, with an option to split this into
> -Wstring-plus-int=1 and -Wstring-plus-int=2. But why it wasn't sent? I
> can't remember.
It was in other branches of the thread:
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01345.html
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01347.html
Again, as I always do when people propose new numeric levels to warning flags,
I'd prefer splitting into new named options instead of adding numeric warning
levels, for individual controllability, and end-user clarity. So in this case,
maybe the final set could be:
-Wstring-plus-int
-Wstring-plus-char (-Wstring-plus-any-char?)
-Wstring-plus-char-literal
[Bug debug/89530] Wrong debug informations for C array generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89530
Richard Biener changed:
What|Removed |Added
Keywords|wrong-debug |
--- Comment #9 from Richard Biener ---
Hmm, there's not really anything "wrong" I think. It is simply we're eliding
static storage initialization and inspecting memory contents from a debugger
is sensitive to dead code removal.
There doesn't seem to be a way to tell a consumer that storage is
"optimized out" when it is in fact still there. Here at -Og we fail
to elide l_1404 completely but manage to prune the initializer
to only cover the read values at [0][7].
Not sure if DCE which does
--- t.c.036t.dse1 2019-03-25 15:37:19.556994432 +0100
+++ t.c.037t.cddce1 2019-03-25 15:37:19.556994432 +0100
@@ -56,10 +56,6 @@
[t.c:7:5] # DEBUG BEGIN_STMT
[t.c:8:5] # DEBUG BEGIN_STMT
[t.c:8:20] MEM[(short unsigned int[3][9] *)_1404 + 8B] = {};
- [t.c:8:20] l_1404[0][0] = 58143;
- [t.c:8:20] l_1404[0][1] = 8;
- [t.c:8:20] l_1404[0][2] = 5;
- [t.c:8:20] l_1404[0][3] = 80;
[t.c:9:5] # DEBUG BEGIN_STMT
[t.c:9:5] goto ; [INV]
could somehow "fix" this.
[Bug debug/89463] debug information for iteractor of an empty loop is gone (at -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89463 --- Comment #8 from Richard Biener --- Patch posted here: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01192.html Some of your bugs might turn out as duplicates if they are fixed by that patch.
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- So started with r269422 ?
[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62181
--- Comment #16 from Xi Ruoyao ---
(In reply to Jonathan Wakely from comment #15)
> Was this question ever answered?
> https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01337.html
Oh that's intentional.
This would make this warning more useful, while most people won't use a "char"
to address an array or something like. For example, if someone has wrote a
string-like class but forgot to overload operator+=, this warning will detect
it when he writes "char c = getchar(); buggy_string t = s + c;".
And for something like
"char *p = s; char x; scanf("%hhd", ); p = p + x;"
1. In C++ __INT8_TYPE__ is not __CHAR_TYPE__ so there will be no warning. He
can use "int8_t x;" instead of "char x;".
2. He can use p = [x], which is more clear and nobody will think this is an
append.
I remember I wrote a response, with an option to split this into
-Wstring-plus-int=1 and -Wstring-plus-int=2. But why it wasn't sent? I can't
remember.
[Bug rtl-optimization/89528] Wrong debug info generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89528 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-03-25 Component|debug |rtl-optimization Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed, this goes wrong on the RTL side somehow. Breakpoint 2, n () at t.c:13 13 optimize_me_not(); (gdb) disassemble Dump of assembler code for function n: 0x004005ce <+0>: push %rbx => 0x004005cf <+1>: mov$0x0,%eax 0x004005d4 <+6>: callq 0x4005cd while we expand from [local count: 1073741824]: # DEBUG BEGIN_STMT _1 = j (1); l_1127_8 = _1 ^ -65536; # DEBUG l_1127 => l_1127_8 # DEBUG BEGIN_STMT optimize_me_not (); not sure how RTL DCE got rid of the call..
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #2 from Ville Voutilainen --- Yes. That codegen looks.. ..bad.
[Bug tree-optimization/89789] [9 Regression] Compile time hog during RPO VN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89789 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon Mar 25 13:53:50 2019 New Revision: 269917 URL: https://gcc.gnu.org/viewcvs?rev=269917=gcc=rev Log: 2019-03-25 Richard Biener PR tree-optimization/89789 * tree-ssa-sccvn.c (set_ssa_val_to): Do not allow lattice changes from non-undefined back to undefined. * gcc.dg/torture/pr89789.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr89789.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/89789] [9 Regression] Compile time hog during RPO VN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89789 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 Jonathan Wakely changed: What|Removed |Added CC||ville at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- Ville, is this due to implementing it via visit?
[Bug libstdc++/89816] [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |9.0
[Bug tree-optimization/89653] Missing vectorization of loop containing std::min/std::max and temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89653 --- Comment #8 from Richard Biener --- (In reply to Moritz Kreutzer from comment #7) > Thanks for taking this up Richard! I just want to check back: Do you need > any assistance with testing or more information from my side? Not at this point - this is an enhancement queued for next stage1 and GCC 10 only, so it has to wait at this moment.
[Bug libstdc++/89816] New: [9 Regression] std::variant move construction regressed since GCC 8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89816
Bug ID: 89816
Summary: [9 Regression] std::variant move construction
regressed since GCC 8.3
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
The following code
#include
struct my_type{
my_type(my_type&&) noexcept;
};
using V1 = std::variant;
V1 test1(V1 v ) { return v; }
Was producing a jump table of size 5 on GCC 8.3. GCC 9 produces huge jump
tables with over 30 entries. This leads to 3 times bigger binaries with GCC 9.
https://godbolt.org/z/SUWL5T
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #37 from Jonathan Wakely --- From PR 89806: Sample code: #pragma GCC diagnostic ignored "-Wdate-time" const char* g_test = "dirty-" __DATE__; When compiling with g++ (g++ -Werror=date-time) this produces: :2:31: error: macro "__DATE__" might prevent reproducible builds [-Werror=date-time] 2 | const char* g_test = "dirty-" __DATE__; | ^~~~ cc1plus: some warnings being treated as errors Compiler returned: 1 But with GCC this compiles without errors (gcc -Werror=date-time).
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Jonathan Wakely changed: What|Removed |Added CC||nbkolchin at gmail dot com --- Comment #36 from Jonathan Wakely --- *** Bug 89806 has been marked as a duplicate of this bug. ***
[Bug c++/89806] Different behaviour for "pragma diagnostic disabled" between gcc and g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89806 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- Yes let's close as a dup, and I'll add this example there. *** This bug has been marked as a duplicate of bug 53431 ***
[Bug c++/62181] [C/C++] Expected new warning: "adding 'char' to a string does not append to the string" [-Wstring-plus-int]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62181 --- Comment #15 from Jonathan Wakely --- Was this question ever answered? https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01337.html
[Bug preprocessor/89808] An option to disable warning "#pragma once in main file"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89808 Jonathan Wakely changed: What|Removed |Added Keywords||easyhack --- Comment #6 from Jonathan Wakely --- In any case, I agree with confirming this as a bug: all warnings should be controllable by a -Wxxx option. Adding such an option is quite easy, and a good first contribution to GCC. For an example of adding a new option see https://gcc.gnu.org/r192968
[Bug tree-optimization/89653] Missing vectorization of loop containing std::min/std::max and temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89653 --- Comment #7 from Moritz Kreutzer --- Thanks for taking this up Richard! I just want to check back: Do you need any assistance with testing or more information from my side?
[Bug preprocessor/89808] An option to disable warning "#pragma once in main file"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89808
--- Comment #5 from Richard Biener ---
(In reply to sduguay from comment #3)
> (In reply to Richard Biener from comment #1)
> > Testcase:
> >
> > #pragma once
> > int main() {}
> >
> > > g++ t.C -S
> > t.C:1:9: warning: #pragma once in main file
> > #pragma once
> > ^~~~
> >
> >
> > you could work around this by wrapping the pragma in a preprocessor
> > conditional
>
> Hi, thanks for adding a minimal test case. I tried:
>
> #if 1
> #pragma once
> #endif
>
> but I'm still getting the warning.
I of course meant
#if !defined(THIS_IS_THE_MAIN_FILE)
#pragma once
#endif
and compile the main file with -DTHIS_IS_THE_MAIN_FILE
[Bug rtl-optimization/89815] New: [7/8/9 Regression] wrong code with -Og -march=armv4t -fno-tree-ccp -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89815
Bug ID: 89815
Summary: [7/8/9 Regression] wrong code with -Og -march=armv4t
-fno-tree-ccp -fno-tree-fre
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: armv7a-hardfloat-linux-gnueabi
Created attachment 46017
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46017=edit
reduced testcase
Output:
$ armv7a-hardfloat-linux-gnueabi-gcc -Og -march=armv4t -fno-tree-ccp
-fno-tree-fre testcase.c -static
$ ./a.out
qemu: uncaught target signal 6 (Aborted) - core dumped
Aborted
Correct value is 0xff, wrong value is 0x. The wrong value seems to be
generated by the instruction:
...
@ testcase.c:10: b = __builtin_sub_overflow (0xff, (u8) - d, );
mvn r4, #0 @ tmp143,
...
$ armv7a-hardfloat-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-269905-checking-yes-rtl-df-extra-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/9.0.1/lto-wrapper
Target: armv7a-hardfloat-linux-gnueabi
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-float=hard --with-fpu=vfpv4
--with-arch=armv7-a --with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=armv7a-hardfloat-linux-gnueabi
--with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld
--with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-269905-checking-yes-rtl-df-extra-armv7a-hardfloat
Thread model: posix
gcc version 9.0.1 20190325 (experimental) (GCC)
The .ira dump has:
...
(insn 55 24 32 2 (set (reg:QI 145 [143])
(const_int -1 [0x])) "testcase.c":10:7 191
{*arm_movqi_insn}
(nil))
...
(insn 58 43 47 2 (set (reg:QI 143)
(reg:QI 145 [143])) "testcase.c":13:1 191 {*arm_movqi_insn}
(expr_list:REG_DEAD (reg:QI 145 [143])
(nil)))
(insn 47 58 48 2 (set (reg/i:SI 0 r0)
(subreg:SI (reg:QI 143) 0)) "testcase.c":13:1 654 {*arm_movsi_vfp}
(expr_list:REG_DEAD (reg:QI 143)
(nil)))
...
And the .reload dump has:
...
(insn 55 24 32 2 (set (reg:QI 4 r4 [143])
(const_int -1 [0x])) "testcase.c":10:7 191
{*arm_movqi_insn}
(nil))
...
(insn 58 43 48 2 (set (reg:QI 0 r0 [143])
(reg:QI 4 r4 [143])) "testcase.c":13:1 191 {*arm_movqi_insn}
(nil))
...
[Bug middle-end/89779] [9 Regression] internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in tree_nop_conversion_p, at tree.c:12798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89779 --- Comment #7 from Richard Biener --- Author: rguenth Date: Mon Mar 25 12:18:38 2019 New Revision: 269914 URL: https://gcc.gnu.org/viewcvs?rev=269914=gcc=rev Log: 2019-03-25 Richard Biener PR tree-optimization/89779 * tree-ssa-loop-ivopts.c (remove_unused_ivs): Return to remove IV defs, delay actual removal. (tree_ssa_iv_optimize_loop): Likewise. Avoid SCEV reset. (tree_ssa_iv_optimize): Remove eliminated IV defs at the very end, properly also reset loop control IV information. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug tree-optimization/89802] [9 Regresssion] ICE: verify_gimple failed (error: dead STMT in EH table)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89802 --- Comment #4 from Richard Biener --- Author: rguenth Date: Mon Mar 25 12:15:59 2019 New Revision: 269913 URL: https://gcc.gnu.org/viewcvs?rev=269913=gcc=rev Log: 2019-03-25 Richard Biener PR tree-optimization/89802 * tree-ssa-math-opts.c (convert_mult_to_fma_1): Properly move EH data to folded stmt. * g++.dg/tree-ssa/pr89802.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr89802.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug tree-optimization/89802] [9 Regresssion] ICE: verify_gimple failed (error: dead STMT in EH table)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89802 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/89802] [9 Regresssion] ICE: verify_gimple failed (error: dead STMT in EH table)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89802 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started to ICE with r260348.
[Bug c++/60702] thread_local initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60702 --- Comment #18 from Jakub Jelinek --- Should be fixed on the trunk now.
[Bug c++/60702] thread_local initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60702 --- Comment #17 from Jakub Jelinek --- Author: jakub Date: Mon Mar 25 11:53:56 2019 New Revision: 269912 URL: https://gcc.gnu.org/viewcvs?rev=269912=gcc=rev Log: PR c++/60702 * g++.dg/tls/thread_local11.C: Remove scan-tree-dump-times directives for _ZTH* calls. * g++.dg/tls/thread_local11a.C: New test. Added: trunk/gcc/testsuite/g++.dg/tls/thread_local11a.C Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/tls/thread_local11.C
[Bug libfortran/79540] [7/8/9 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540 --- Comment #24 from John David Anglin --- Author: danglin Date: Mon Mar 25 11:48:36 2019 New Revision: 269911 URL: https://gcc.gnu.org/viewcvs?rev=269911=gcc=rev Log: PR libgfortran/79540 * io/write_float.def (build_float_string): Don't copy digits when ndigits is negative. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write_float.def
[Bug preprocessor/89808] An option to disable warning "#pragma once in main file"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89808 --- Comment #4 from sduguay --- (In reply to Jakub Jelinek from comment #2) > You haven't explained why do you need to use #pragma once in the main cpp > source file, are you sometimes including it as a header and other times > compiling it as the TU itself? Not to mention that it is best not to use > #pragma once at all anywhere. Yes, in the system I'm working on, there is no "main file", all C++ (xcpp files actually) are small C++ programs that I link with a generated main file. xcpp programs can use other programs (xcpp files) or libs (xhpp files). This is all working pretty well right now, except for that #pragma once warning. It's still under pretty heavy development. You can try it @ https://github.com/binarez/xcpp Thanks
