[Bug target/100865] pass_data_constant_pool_broadcast doesn't work on TImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100865 --- Comment #2 from Hongtao.liu --- > > Also should broadcast from register be used to avoid memory load? I think yes as long as memory load from constant pool.
[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863
--- Comment #1 from Patrick Palka ---
The problem seems to be that default initialization of an unordered_map/set
only default initializes the allocator object rather than value initializing
it. This means the allocator's state doesn't get implicitly zeroed out, which
causes the assert inside test01() to fail. A potential fix is to make
_Hashtable_alloc's default constructor value initialize the allocator object:
--- a/libstdc++-v3/include/bits/hashtable_policy.h
+++ b/libstdc++-v3/include/bits/hashtable_policy.h
@@ -1856,7 +1856,10 @@ namespace __detail
using __buckets_alloc_traits =
std::allocator_traits<__buckets_alloc_type>;
using __buckets_ptr = __node_base_ptr*;
- _Hashtable_alloc() = default;
+ _Hashtable_alloc() noexcept(noexcept(__ebo_node_alloc()))
+ : __ebo_node_alloc()
+ { }
+
_Hashtable_alloc(const _Hashtable_alloc&) = default;
_Hashtable_alloc(_Hashtable_alloc&&) = default;
[Bug target/100865] pass_data_constant_pool_broadcast doesn't work on TImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100865
--- Comment #1 from Hongtao.liu ---
(insn 6 5 9 2 (set (reg:V1TI 84)
(mem/u/c:V1TI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S16 A128]))
"test.c":5:3 1474 {movv1ti_internal}
(expr_list:REG_EQUAL (const_vector:V1TI [
(const_wide_int 0xc0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c)
])
For V1TImode, we don't know vec_duplicate of what, it could be (subreg:V1TI
(vec_duplicate:v4si (si)) 0) or (subreg:V1TI (vec_duplicate:v8hi (hi)) 0) or
(subreg:V1TI (vec_duplicate:v16qi (qi)) 0)
[Bug tree-optimization/100864] (a&!b) | b is not opimized to a | b for comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100864
--- Comment #2 from Andrew Pinski ---
I have a patch,
(for bitop (bit_and bit_ior)
rbitop (bit_ior bit_and)
/* Similar but for comparisons which have been inverted already,
Note it is hard to similulate inverted tcc_comparison due to NaNs
so a double for loop is needed and then compare the inverse code
with the result of invert_tree_comparison is needed. */
(for cmp (tcc_comparison)
(for icmp (tcc_comparison)
(simplify
(bitop:c (rbitop:c (icmp @0 @1) @2) (cmp@3 @0 @1))
(with { enum tree_code ic = invert_tree_comparison
(cmp, HONOR_NANS (@0)); }
(if (ic == icmp)
(bitop @3 @2)))
It is more complex than I had liked but it does solve the issue. There is no
way really of simplifying the pattern either, just because of the way match.pd
works :(
[Bug target/100865] New: pass_data_constant_pool_broadcast doesn't work on TImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100865
Bug ID: 100865
Summary: pass_data_constant_pool_broadcast doesn't work on
TImode
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
Target Milestone: ---
Target: x86-64
[hjl@gnu-cfl-2 gcc]$ cat /tmp/y.c
extern char *dst;
void
foo (void)
{
__builtin_memset (dst, 12, 16);
}
[hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S -O2 -march=skylake-avx512 /tmp/y.c
[hjl@gnu-cfl-2 gcc]$ cat y.s
.file "y.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movqdst(%rip), %rax
vmovdqa .LC0(%rip), %xmm0
vmovdqu %xmm0, (%rax)
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.section.rodata.cst16,"aM",@progbits,16
.align 16
.LC0:
.quad 868082074056920076
.quad 868082074056920076
.ident "GCC: (GNU) 12.0.0 20210602 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 gcc]$
Also should broadcast from register be used to avoid memory load?
[Bug tree-optimization/100864] (a&!b) | b is not opimized to a | b for comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100864 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Last reconfirmed||2021-06-02 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Summary|(a&!b) | b is not opimized |(a&!b) | b is not opimized |to a | b for conditionals |to a | b for comparisons --- Comment #1 from Andrew Pinski --- The pattern which matches this when this is not a comparison: (for bitop (bit_and bit_ior) rbitop (bit_ior bit_and) /* (x | y) & x -> x */ /* (x & y) | x -> x */ (simplify (bitop:c (rbitop:c @0 @1) @0) @0) /* (~x | y) & x -> x & y */ /* (~x & y) | x -> x | y */ (simplify (bitop:c (rbitop:c (bit_not @0) @1) @0) (bitop @0 @1))) We should be able to add something similar for tcc_comparison/inverted_tcc_comparison_with_nans too.
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 Alan Modra changed: What|Removed |Added Target|powerpc |powerpc64le CC||amodra at gmail dot com --- Comment #4 from Alan Modra --- The disassembly says this is powerpc64le. Possibly interesting fact: the offsets used above the stack frame are 400, 432, 440, which all correspond to the parameter save area. I don't see any reason that DGEBAL should have a parameter save area though since all parameters can be passed in regs.
[Bug tree-optimization/96923] Failure to optimize a select-related bool pattern to or+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923 Andrew Pinski changed: What|Removed |Added Depends on||100864 --- Comment #6 from Andrew Pinski --- This depends on PR 100864 if I don't want to write out the 4 patterns. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100864 [Bug 100864] (a&!b) | b is not opimized to a | b for conditionals
[Bug tree-optimization/100864] New: (a&!b) | b is not opimized to a | b for conditionals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100864
Bug ID: 100864
Summary: (a&!b) | b is not opimized to a | b for conditionals
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
_Bool f(int a, int b, _Bool e)
{
_Bool c = (a > b);
_Bool d = !c;
return (e & d) | c;
}
--- CUT
We get currently:
c_5 = a_3(D) > b_4(D);
_2 = a_3(D) <= b_4(D);
_1 = _2 & e_7(D);
_6 = _1 | c_5;
But this should be optimized to just:
c_5 = a_3(D) <= b_4(D);
_6 = e_7(D) | c_5;
I noticed this while fixing PR 96923.
[Bug tree-optimization/96923] Failure to optimize a select-related bool pattern to or+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > Created attachment 50905 [details] > Patch which is in testing (needs testcases) > > As I said for the case in this PR, it needs > https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571616.html too. > > If you change !b to b; that is "!a ? b : 0", this patch will optimize it. > The other patch is needed to allow to move !b out of the conditional. This patch has one bug in it where we need a convert added. BUT then we run into a different missed optimization issue. _51 = p2_22 <= prephitmp_122; _44 = (logical(kind=4)) _51; _37 = p2_22 > prephitmp_122; _49 = (logical(kind=4)) _37; _38 = _49 & found_p_63; _46 = _38 | _44; This is really just: _51 = p2_22 <= prephitmp_122; _44 = (logical(kind=4)) _51; _46 = found_p_63| _44; That is we don't optimize: (a & ~b) | b into a | b if ~b has been converted already. The other thing I noticed is the cast should not be really needed but nothing removes it; I will look at that later. Note I could rewrite the pattern to do the simplification of the constants manually but I want to try to avoid that.
[Bug other/44032] internals documentation is not legally safe to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44032 Eric Gallager changed: What|Removed |Added CC||ams at gnu dot org --- Comment #10 from Eric Gallager --- Does the update on copyright assignment policy affect this at all? https://gcc.gnu.org/pipermail/gcc/2021-June/236182.html My reading of this email seems to imply that it does: https://gcc.gnu.org/pipermail/gcc/2021-June/236214.html
[Bug c++/100809] PPC: __int128 divide/modulo does not use P10 instructions vdivsq/vdivuq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809
--- Comment #4 from Michael Meissner ---
Note, in looking at Carl's patch, it is only for adding the built-ins. I don't
believe it adds direct support for {,u}divti3 and {,u}moddti3 to implement
these for normal __int128 variables.
[Bug c++/100809] PPC: __int128 divide/modulo does not use P10 instructions vdivsq/vdivuq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809 Michael Meissner changed: What|Removed |Added Last reconfirmed||2021-06-01 Status|UNCONFIRMED |NEW CC||carll at gcc dot gnu.org, ||meissner at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Michael Meissner --- Carl Love submitted a patch for this on April 26th.
[Bug tree-optimization/59660] We fail to optimize common boolean checks pre-inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59660
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Last reconfirmed|2014-01-07 00:00:00 |2021-6-1
--- Comment #12 from Andrew Pinski ---
(In reply to Jan Hubicka from comment #4)
> > Not all testcases can be handled at gimplification time IIRC. Which
> > means "testcases welcome" first, so we can look at them individually.
>
> The GCC one I saw was equivalent of:
> #include
> bool
> m_is_less_than_n (int n, int m)
> {
>return (n==m || m_is_less_than_n (n-1,m));
> }
First we cannot optimize this into a loop until tailc rather than in either
tailr1 or tailr2.
In tailr1, we have:
_2 = m_is_less_than_n (_1, m_7(D));
if (_2 != 0)
goto ; [INV]
else
goto ; [INV]
:
:
# iftmp.0_3 = PHI <1(6), 0(3), 1(2)>
_12 = (_Bool) iftmp.0_3;
While in tailr2, we have:
_18 = m_is_less_than_n (_17, m_6(D));
_4 = (int) _18;
[local count: 1073741825]:
# iftmp.0_3 = PHI <_4(6), 1(3), 1(2), 1(4), 1(5)>
_8 = (_Bool) iftmp.0_3;
It is not until PRE where we remove the casts (to/from int).
[Bug middle-end/100861] False positive -Wmismatched-new-delete with destroying operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100861
--- Comment #3 from Martin Sebor ---
The virtual dtor forces an out-of-line call to the Grommet dtor which then
calls ::operator delete(), so the warning has nothing to complain about. It
sees this code (compile with -fdump-tree-optimized=/dev/stdout):
int main ()
{
void * _3;
[local count: 1073741824]:
_3 = operator new (16);
MEM[(struct Widget *)_3].Kind = 0;
MEM[(struct Grommet *)_3].D.2504._vptr.Widget = [(void
*)&_ZTV7Grommet + 16B];
Grommet::~Grommet (_3);
return 0;
}
whereas with the original test case it sees:
int main ()
{
struct destroying_delete_t D.2584;
void * _3;
[local count: 1073741824]:
_3 = operator new (4);
Widget::operator delete (_3, D.2584); <<< warning here
return 0;
}
[Bug tree-optimization/67731] Combine of OR'ed bitfields should use bit-test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67731 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from Andrew Pinski --- Mine, this is bit-field lowering related. I am hoping to get the bit-field lowering into GCC 12.
[Bug middle-end/100861] False positive -Wmismatched-new-delete with destroying operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100861
--- Comment #2 from Joseph C. Sible ---
Wait, if it's just checking whether the calls to operator new and operator
delete match up, then why does adding "virtual ~Widget() {}" make the warning
go away?
[Bug tree-optimization/96923] Failure to optimize a select-related bool pattern to or+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923 --- Comment #4 from Andrew Pinski --- Created attachment 50905 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50905=edit Patch which is in testing (needs testcases) As I said for the case in this PR, it needs https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571616.html too. If you change !b to b; that is "!a ? b : 0", this patch will optimize it. The other patch is needed to allow to move !b out of the conditional.
[Bug middle-end/100861] False positive -Wmismatched-new-delete with destroying operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100861
Martin Sebor changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Component|c++ |middle-end
Last reconfirmed||2021-06-01
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Blocks||100406
--- Comment #1 from Martin Sebor ---
The warning doesn't do anything special with destroying operator delete or any
other kinds of the operators (other than scalar vs array). It triggers for
this test case because it sees the result of ::operator new() being passed to
Widget::operator delete (Widget*). If Widget::operator delete() is inlined
(e.g., declared with attribute always_inline) the warning goes away just as
long as the operator doesn't pass the pointer to the wrong overload of delete.
Alternatively, if Widget defines a non-inline member operator new() that also
prevents the warning because calls to both operators match.
With that, I'm not sure that suppressing the warning for a destroying operator
delete() would be a good solution. It seems to me that the right fix is to
solve the broader problem where one of the operators is inlined and the other
isn't (similar to pr100485, except with the definitions of both operators
available in the same translation unit).
Until/unless a solution is developed I would suggest to either define the
destroying operator delete inline and have it call an out-of-line function to
do the work (as shown below) or to force the inlining of the destroying delete.
struct Widget {
const WidgetKind Kind : 4;
unsigned OtherThings : 28;
Widget(WidgetKind k) : Kind(k) {}
void operator delete(Widget *widget, std::destroying_delete_t) {
destroy_delete (widget);
}
static __attribute__ ((noinline)) void destroy_delete (Widget *);
};
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100406
[Bug 100406] bogus/missing -Wmismatched-new-delete
[Bug c/100854] TS 18661-3 and backwards-incompatible setting of __FLT_EVAL_METHOD__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100854 --- Comment #1 from joseph at codesourcery dot com --- On Tue, 1 Jun 2021, acoplan at gcc dot gnu.org via Gcc-bugs wrote: > This could be considered a bug in TS 18661-3 which stipulates that > __FLT_EVAL_METHOD__ take backwards-incompatible values. Either way, it seems TS 18661-3 only talks about FLT_EVAL_METHOD, not __FLT_EVAL_METHOD__. GCC's then uses __FLT_EVAL_METHOD__, __FLT_EVAL_METHOD_TS_18661_3__ and __STDC_WANT_IEC_60559_TYPES_EXT__ to determine the value of FLT_EVAL_METHOD, taking account of any -fpermitted-flt-eval-methods option (or other options implying it) passed.
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 --- Comment #3 from Segher Boessenkool --- Hi Alexander, You do not say what the actual target you used is? powerpc-linux, powerpc64-linux, powerpc64le-linux, something else entirely?
[Bug tree-optimization/96923] Failure to optimize a select-related bool pattern to or+not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96923 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-06-01 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Mine, I have a patch which implements this. It needs https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571616.html first. I will be posting this once I write some testcases and do a bootstrap/test cycle.
[Bug tree-optimization/97690] (cond ? 2 : 0) is not optimized to int(cond) << 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97690 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.0 --- Comment #7 from Andrew Pinski --- Fixed for GCC 11. GCC 12 moves the simplifications to match.pd too. So closing.
[Bug testsuite/100750] new test case gcc.target/powerpc/rop-5.c fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by William Schmidt : https://gcc.gnu.org/g:3d75b5cd9a362172838825c7083a3afa2403735a commit r11-8496-g3d75b5cd9a362172838825c7083a3afa2403735a Author: Bill Schmidt Date: Tue Jun 1 15:47:22 2021 -0500 PR100750: Require ELFv2 ABI for ROP test 2021-06-01 Bill Schmidt gcc/testsuite/ PR testsuite/100750 * gcc.target/powerpc/rop-5.c: Require ELFv2 ABI.
[Bug testsuite/100750] new test case gcc.target/powerpc/rop-5.c fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750 --- Comment #4 from Bill Schmidt --- I cannot reproduce failures for powerpc64le on P10 LE.
[Bug libstdc++/100863] New: 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863
Bug ID: 100863
Summary: 23_containers/unordered_{map,set}/allocator/default_in
it.cc still fail at runtime even after r12-1153
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
These two tests still fail at runtime even after the r12-1153 fix for PR65816.
The tests fail at runtime when compiled with Clang.
[Bug middle-end/100685] #pragma GCC push_options ineffective for optimize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100685
--- Comment #4 from Martin Sebor ---
Thanks. I belatedly realized that the test case didn't reproduce the problem I
was seeing. The one below demonstrates that the -O1 option does override the
-O2 set earlier. Sorry for the noise!
$ cat pr100685.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout
pr100685.c
#pragma GCC optimize ("2")
int f (void)
{
char s[] = "abc";
return __builtin_strlen (s); // folded to 3 (good)
}
#pragma GCC push_options
#pragma GCC optimize ("1")
int g (void)
{
char s[] = "abc";
return __builtin_strlen (s); // not folded and shouldn't be
}
;; Function f (f, funcdef_no=0, decl_uid=1943, cgraph_uid=1, symbol_order=0)
__attribute__((optimize ("2")))
int f ()
{
[local count: 1073741824]:
return 3;
}
;; Function g (g, funcdef_no=1, decl_uid=1947, cgraph_uid=2, symbol_order=1)
__attribute__((optimize ("2", "1")))
int g ()
{
char s[4];
long unsigned int _1;
int _4;
[local count: 1073741824]:
s = "abc";
_1 = __builtin_strlen ();
_4 = (int) _1;
s ={v} {CLOBBER};
return _4;
}
[Bug c++/65816] Constructor delegation does not perform zero-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816 --- Comment #8 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ac0bc21bd634a334ba8f323c39a11f01dfdc2aae commit r12-1153-gac0bc21bd634a334ba8f323c39a11f01dfdc2aae Author: Patrick Palka Date: Tue Jun 1 12:23:49 2021 -0400 c++: value-init vs zero-init in expand_aggr_init_1 [PR65816] In the case of value-initializing an object of class type T, [dcl.init.general]/8 says: - if T has either no default constructor ([class.default.ctor]) or a default constructor that is user-provided or deleted, then the object is default-initialized; - otherwise, the object is zero-initialized and ... if T has a non-trivial default constructor, the object is default-initialized; But when determining whether to first zero-initialize the object, expand_aggr_init_1 incorrectly considers the user-providedness of _all_ constructors rather than only that of the _default_ constructors. This causes us to skip the zero-initialization step when the class type has a defaulted default constructor alongside a user-defined constructor. It seems the predicate type_has_non_user_provided_default_constructor accurately captures the above rule for when to first perform a zero-initialization during value-initialization, so this patch adjusts expand_aggr_init_1 to use this predicate instead. PR c++/65816 gcc/cp/ChangeLog: * init.c (expand_aggr_init_1): Check type_has_non_user_provided_default_constructor instead of type_has_user_provided_constructor. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-delegating3.C: New test. * g++.dg/cpp0x/dc10.C: New test. * g++.dg/cpp0x/initlist-base4.C: New test. * g++.dg/cpp2a/constexpr-init22.C: New test. libstdc++-v3/ChangeLog: * testsuite/23_containers/deque/allocator/default_init.cc, testsuite/23_containers/forward_list/allocator/default_init.cc, testsuite/23_containers/list/allocator/default_init.cc, testsuite/23_containers/map/allocator/default_init.cc, testsuite/23_containers/set/allocator/default_init.cc, testsuite/23_containers/vector/allocator/default_init.cc, testsuite/23_containers/vector/bool/allocator/default_init.cc: Remove xfail.
[Bug c++/100862] New: using enum member access fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100862
Bug ID: 100862
Summary: using enum member access fail
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eligorkadaf at gmail dot com
Target Milestone: ---
The following code must compile according to C++20 standard. However, gcc fails
to compile it
enum class fruit { orange, apple };
struct Working {
using enum fruit;
};
struct Broken {
using enum fruit;
private:
};
int main() {
Working::orange;
Broken::orange;
}
Link to godbolt(I don't have gcc-11 installed): https://godbolt.org/z/srYj3sMno
Link to C++-draft clause: http://eel.is/c++draft/namespace.udecl#16
[Bug c++/100861] New: False positive -Wmismatched-new-delete with destroying operator delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100861
Bug ID: 100861
Summary: False positive -Wmismatched-new-delete with destroying
operator delete
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: josephcsible at gmail dot com
Target Milestone: ---
Currently, code like "Base *b = new Derived; delete b;" gives a
-Wmismatched-new-delete warning, unless Base has a virtual destructor. One of
the use cases for C++20's destroying operator delete is to make this safe
without needing a virtual destructor, so this warning should be suppressed if
Base has a destroying operator delete. Here's a modified version of the code at
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0722r1.html that will
unnecessarily cause this warning (compile with -std=c++20 -Wall):
#include
enum class WidgetKind {
Grommet,
Wingnut
};
struct Widget {
const WidgetKind Kind : 4;
unsigned OtherThings : 28;
Widget(WidgetKind k) : Kind(k) {}
void operator delete(Widget *, std::destroying_delete_t);
};
struct Grommet : Widget {
Grommet() : Widget(WidgetKind::Grommet) {}
};
struct Wingnut : Widget {
Wingnut() : Widget(WidgetKind::Wingnut) {}
};
void Widget::operator delete(Widget *widget, std::destroying_delete_t) {
switch (widget->Kind) {
case WidgetKind::Grommet:
static_cast(widget)->~Grommet();
::operator delete(widget, sizeof(Grommet));
return;
case WidgetKind::Wingnut:
static_cast(widget)->~Wingnut();
::operator delete(widget, sizeof(Wingnut));
return;
}
}
int main() {
Widget *widget = new Grommet;
delete widget;
}
[Bug c++/100847] M1 chip: many functions not declared in "std" or "::"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100847
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WORKSFORME
--- Comment #2 from Andrew Pinski ---
I was able to compile and test GCC myself with the following options:
apinski@Andrews-Mac-mini ~ % ~/upstream-gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/Users/apinski/upstream-gcc/bin/gcc
COLLECT_LTO_WRAPPER=/Users/apinski/upstream-gcc/libexec/gcc/aarch64-apple-darwin20.4.0/11.0.1/lto-wrapper
Target: aarch64-apple-darwin20.4.0
Configured with: /Users/apinski/src/upstream-gcc-macosx/gcc/configure
--prefix=/Users/apinski/upstream-gcc
--with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210417 (experimental) (GCC)
apinski@Andrews-Mac-mini ~ % ~/upstream-gcc/bin/g++ t.c
apinski@Andrews-Mac-mini ~ % ./a.out
Hello World.
apinski@Andrews-Mac-mini ~ % cat t.c
#include
int main(void)
{
std::cout << "Hello World.\n";
}
[Bug c++/100797] [10/11 Regression] using declaration causing virtual call with wrongly adjusted this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100797 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|10.4|9.4 --- Comment #10 from Jason Merrill --- Fixed for 9.4/10.4/11.2/12.
[Bug fortran/86115] move_alloc for class(*) containing value of type character(len=*) looses data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86115 --- Comment #3 from anlauf at gcc dot gnu.org --- Looking at the dump tree, it appears that the _vptr component is properly copied, but the _len component is not. But this one is needed for unlimited polymorphics.
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 Peter Bergner changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-06-01 --- Comment #2 from Peter Bergner --- (In reply to Alexander Grund from comment #1) > Confirmed to also break with GCC 7.3, 8.2, 8.3 but works with 6.3, 6.4, 6.5 The failure with GCC 7 and later coincides with the PPC port starting to default to LRA instead of reload. If I look at the debug dumps compiling dgebal.f, the 440 offset to the stack is created by an LRA spill. No problem there that I can see. The problem seems to come later when we generate the prologue/epilogue and we only update the stack pointer by the smaller 368 byte offset. Either LRA isn't telling us it needs that extra stack space or the ppc backend didn't notice. I'll keep digging.
[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 --- Comment #18 from Andrew Pinski --- (In reply to CVS Commits from comment #17) Note this is the only start of the patches, this is not fully fixed, it is being worked on in a series of patches rather than one big one.
[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 --- Comment #17 from CVS Commits --- The master branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:9f55df63154a39d67ef5b24def7044bf87300831 commit r12-1152-g9f55df63154a39d67ef5b24def7044bf87300831 Author: Andrew Pinski Date: Tue Jun 1 01:05:09 2021 + Replace conditional_replacement with match and simplify This is the first of series of patches to simplify phi-opt to use match and simplify in many cases. This simplification will more things to optimize. This is what Richard requested in https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571197.html and I think it is the right thing to do too. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog: PR tree-optimization/25290 * tree-ssa-phiopt.c (match_simplify_replacement): New function. (tree_ssa_phiopt_worker): Use match_simplify_replacement. (two_value_replacement): Change the comment about conditional_replacement. (conditional_replacement): Delete.
[Bug fortran/100860] class(*) type is (character(*)) produces a segmentation fault when run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100860 --- Comment #2 from Dominique d'Humieres --- WORKSFORME from GCC7 up to trunk.
[Bug tree-optimization/95481] Failure to optimize infinite recursion for empty struct types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95481 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 --- Comment #5 from Andrew Pinski --- Fixed.
[Bug tree-optimization/95481] Failure to optimize infinite recursion for empty struct types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95481 --- Comment #4 from CVS Commits --- The master branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:ea418485c700494c3efdc282854c5f5a08702416 commit r12-1151-gea418485c700494c3efdc282854c5f5a08702416 Author: Andrew Pinski Date: Mon May 31 00:17:22 2021 + Fix PR 95481: tail call fails with empty struct types The problem here is we don't have an assignment type any more for empty structs as they were removed during gimplifcation. This adds a special case where the assignment var does not exist and the return decl is empty typed. OK? Tested on aarch64-linux-gnu with no regressions. Thanks, Andrew Pinski changes since v1: v2: Use is_empty_type instead of zero-sized type. gcc/ChangeLog: PR tree-optimization/95481 * tree-tailcall.c (find_tail_calls): Handle empty typed return decls. gcc/testsuite/ChangeLog: PR tree-optimization/95481 * gcc.dg/tree-ssa/tailcall-10.c: New test. * gcc.dg/tree-ssa/tailcall-11.c: New test. * gcc.dg/tree-ssa/tailcall-12.c: New test. * gcc.dg/tree-ssa/tailcall-13.c: New test. * gcc.dg/tree-ssa/tailrecursion-8.c: New test.
[Bug fortran/86115] move_alloc for class(*) containing value of type character(len=*) looses data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86115 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Keywords||wrong-code Last reconfirmed|2018-06-13 00:00:00 |2021-6-1 --- Comment #2 from anlauf at gcc dot gnu.org --- Adding print *, 'string length: ', len (z) in subroutine p prints string length 0.
[Bug fortran/100860] class(*) type is (character(*)) produces a segmentation fault when run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100860 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-06-01 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Possibly related to pr100551, which was fixed after the 11.1 release. I do not see the issue with the current mainline or 11-branch version. Can you please check?
[Bug fortran/100860] New: class(*) type is (character(*)) produces a segmentation fault when run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100860 Bug ID: 100860 Summary: class(*) type is (character(*)) produces a segmentation fault when run Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: thomas.robinson at noaa dot gov Target Milestone: --- When a string is passed as an argument to a subroutine where the argument is `class(*)`, there is a seg fault when the type is selected. Other types seem to be working. Previous versions of gfortran have no problem compiling and running this simple program. I think the code is correct. It seems to be gcc 11 that has an issue. Here is some test code: module ctest contains subroutine sub (carg, slen) class(*), intent (in) :: carg integer, optional, intent (in) :: slen select type (carg) type is (character(*)) if (.not.present(slen)) then write (6,*) "This is an error dealing with a string" else write (6,*) "string length is ",slen write (6,*) "String is ",carg(1:slen) endif type is (integer) write (6,*) "Integer type is ", carg type is (real) write (6,*) "Real type is ", carg class default write (6,*) "Not the right type" end select end subroutine sub end module ctest program test use ctest character (len=10) :: c10 character (len=:), allocatable :: sall integer :: i=100 real :: r = 999.9 logical :: l = .true. call sub (r) call sub (i) call sub (l) c10="12345" allocate(character (len=i) :: sall) sall = "87654321" ! write (6,*) "c10=",trim(c10),"::LEN=",len_trim(c10) ! call sub(trim(c10), len_trim(c10)) write (6,*) "sall=",trim(sall),"::LEN=",len_trim(sall) call sub(trim(sall),len_trim(sall)) end program test Here is the output Real type is999.900024 Integer type is 100 Not the right type sall=87654321::LEN= 8 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. I tried with heap and stack strings, and both fail (you can see I have the first one commented out). Please let me know if there's any more information you need.
[Bug c++/65816] Constructor delegation does not perform zero-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug fortran/100855] pow run time gfortran vs ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855 --- Comment #2 from anlauf at gcc dot gnu.org --- If you do not care about correct rounding, you can replace sum = sum + (i ** (0.05 + n)) by sum = sum + exp (log (real(i)) * (0.05 + n)) I think __builtin_powf and powf do care. I do not know if there is a gcc flag that replaces __builtin_powf by the combination of __builtin_expf / __builtin_logf which would also allow for (better) vectorization. (I know of a compiler for hardware which offers this).
[Bug c++/91859] Using destroying delete should not clobber stores to the object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91859 Jason Merrill changed: What|Removed |Added Target Milestone|--- |11.2 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jason Merrill --- Fixed for 11.2/12.
[Bug target/99725] arm: ICE in dwarf2out_frame_debug_adjust_cfa with -mcmse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99725 Alex Coplan changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Alex Coplan --- GCC 9 lacks armv8.1-m.main support (which the bug requires), so this is fixed everywhere.
[Bug target/99725] arm: ICE in dwarf2out_frame_debug_adjust_cfa with -mcmse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99725 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Alex Coplan : https://gcc.gnu.org/g:1cbde1725cac9ae53b892449c847f28f977f3a9b commit r10-9877-g1cbde1725cac9ae53b892449c847f28f977f3a9b Author: Alex Coplan Date: Tue May 11 13:11:09 2021 +0100 arm: Avoid emitting bogus CFA adjusts for CMSE nonsecure calls [PR99725] The PR shows us attaching REG_CFA_ADJUST_CFA notes to stack pointer adjustments emitted in cmse_nonsecure_call_inline_register_clear (when -march=armv8.1-m.main). However, the stack pointer is not guaranteed to be the CFA reg. If we're at -O0 or we have -fno-omit-frame-pointer, then the frame pointer will be used as the CFA reg, and these notes on the sp adjustments will lead to ICEs in dwarf2out_frame_debug_adjust_cfa. This patch avoids emitting these notes if the current function has a frame pointer. gcc/ChangeLog: PR target/99725 * config/arm/arm.c (cmse_nonsecure_call_inline_register_clear): Avoid emitting CFA adjusts on the sp if we have the fp. gcc/testsuite/ChangeLog: PR target/99725 * gcc.target/arm/cmse/pr99725.c: New test. (cherry picked from commit 2ac1f0eb3887335b7a7e845812956fa436e72a91)
[Bug testsuite/100750] new test case gcc.target/powerpc/rop-5.c fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750 --- Comment #3 from Bill Schmidt --- Fixed the BE problem. Will look into the GCC11 report.
[Bug fortran/100855] pow run time gfortran vs ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Last reconfirmed||2021-06-01 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- This is not a gfortran bug. Adding code to use exp() and log(), I compiled the modified code: s0 = s0 + i**(0.05 + n) s1 = s1 + exp(0.05 + n) s2 = s2 + log(0.05 + n) with the -fdump-tree-optimized option. Looking at the dumped info, one finds the three lines _107 = __builtin_powf (_103, _106); _109 = __builtin_expf (_105); _111 = __builtin_logf (_105); If I compile the code with "-S -O3" and look at the assembly code I see callpowf callexpf calllogf which are math functions contained in your system's libm. So, this is an issue with your libm not gfortran. I'll let someone else judge whether the bug should be closed with INVALID or WONTFIX.
[Bug c++/100850] [coroutine] Wrong addresses of variables captured by reference into lambda co-routines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100850 --- Comment #3 from Vlad --- My bad. It's actually a UB. The lambda lifetime is just over by the moment of resumption of the co-routine.
[Bug testsuite/100750] new test case gcc.target/powerpc/rop-5.c fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100750 --- Comment #2 from CVS Commits --- The master branch has been updated by William Schmidt : https://gcc.gnu.org/g:250cf86735fc9e088cc2309c520adb655790eb99 commit r12-1147-g250cf86735fc9e088cc2309c520adb655790eb99 Author: Bill Schmidt Date: Tue Jun 1 11:08:53 2021 -0500 PR100750: Require ELFv2 ABI for ROP test 2021-06-01 Bill Schmidt gcc/testsuite/ PR testsuite/100750 * gcc.target/powerpc/rop-5.c: Require ELFv2 ABI.
[Bug libstdc++/100833] ranges::advance should return n when i == bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100833 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d8326291695c0f13124c232ddf4fd34e3310e649 commit r12-1146-gd8326291695c0f13124c232ddf4fd34e3310e649 Author: Jonathan Wakely Date: Tue Jun 1 16:02:45 2021 +0100 libstdc++: Fix return value of std::ranges::advance [PR 100833] The three-argument form of ranges::advance is supposed to return the difference between the second argument and the distance the iterator was advanced. When a non-random-access iterator is not advanced (because it already equals the sentinel) we were returning 0 rather than n - 0. libstdc++-v3/ChangeLog: PR libstdc++/100833 * include/bits/ranges_base.h (ranges::advance(iter, n, sentinel)): Fix return value for no-op case. * testsuite/24_iterators/range_operations/advance.cc: Test return values of three-argument overload.
[Bug c++/95719] [10/11 Regression] ICE in lookup_vfn_in_binfo at gcc/cp/class.c:2459 since r11-954-g0ddb93ce77374004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95719 --- Comment #14 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:1027e8c8837d9d4933946f2888d85deef2cf850b commit r10-9876-g1027e8c8837d9d4933946f2888d85deef2cf850b Author: Jason Merrill Date: Thu May 27 23:54:52 2021 -0400 c++: 'this' adjustment for devirtualized call My patch for 95719 made us do a better job of finding the actual virtual function we want to call, but didn't update the 'this' pointer adjustment to match. This backport also incorporates a bit of the r11-1638 reorganization. PR c++/100797 PR c++/95719 gcc/cp/ChangeLog: * call.c (build_over_call): Adjust base_binfo in resolves_to_fixed_type_p case. gcc/testsuite/ChangeLog: * g++.dg/inherit/virtual15.C: New test. * g++.dg/inherit/virtual15a.C: New test.
[Bug c++/100797] [10/11 Regression] using declaration causing virtual call with wrongly adjusted this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100797 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:1027e8c8837d9d4933946f2888d85deef2cf850b commit r10-9876-g1027e8c8837d9d4933946f2888d85deef2cf850b Author: Jason Merrill Date: Thu May 27 23:54:52 2021 -0400 c++: 'this' adjustment for devirtualized call My patch for 95719 made us do a better job of finding the actual virtual function we want to call, but didn't update the 'this' pointer adjustment to match. This backport also incorporates a bit of the r11-1638 reorganization. PR c++/100797 PR c++/95719 gcc/cp/ChangeLog: * call.c (build_over_call): Adjust base_binfo in resolves_to_fixed_type_p case. gcc/testsuite/ChangeLog: * g++.dg/inherit/virtual15.C: New test. * g++.dg/inherit/virtual15a.C: New test.
[Bug c++/91859] Using destroying delete should not clobber stores to the object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91859 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ee3edeb01eca1cc8d7ebe777b4adb333f0c1118a commit r11-8495-gee3edeb01eca1cc8d7ebe777b4adb333f0c1118a Author: Jason Merrill Date: Fri May 28 17:05:23 2021 -0400 c++: no clobber for C++20 destroying delete [PR91859] Before C++20 added destroying operator delete, by the time we called operator delete for a pointer, the object would already be gone. But that isn't true for destroying delete. Since the optimizers' assumptions about operator delete are based on either DECL_IS_REPLACEABLE_OPERATOR (which already is not set) or CALL_FROM_NEW_OR_DELETE_P, let's avoid setting the latter flag in this case. PR c++/91859 gcc/ChangeLog: * tree.h (CALL_FROM_NEW_OR_DELETE_P): Adjust comment. gcc/cp/ChangeLog: * call.c (build_op_delete_call): Don't set CALL_FROM_NEW_OR_DELETE_P for destroying delete. * init.c (build_delete): Don't clobber before destroying delete. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/destroying-delete5.C: New test.
[Bug c++/95719] [10/11 Regression] ICE in lookup_vfn_in_binfo at gcc/cp/class.c:2459 since r11-954-g0ddb93ce77374004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95719 --- Comment #13 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:7c61ce59421547194647a847263b2b9065a26e03 commit r11-8494-g7c61ce59421547194647a847263b2b9065a26e03 Author: Jason Merrill Date: Thu May 27 23:54:52 2021 -0400 c++: 'this' adjustment for devirtualized call My patch for 95719 made us do a better job of finding the actual virtual function we want to call, but didn't update the 'this' pointer adjustment to match. PR c++/100797 PR c++/95719 gcc/cp/ChangeLog: * call.c (build_over_call): Adjust base_binfo in resolves_to_fixed_type_p case. gcc/testsuite/ChangeLog: * g++.dg/inherit/virtual15.C: New test.
[Bug c++/100797] [10/11 Regression] using declaration causing virtual call with wrongly adjusted this pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100797 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:7c61ce59421547194647a847263b2b9065a26e03 commit r11-8494-g7c61ce59421547194647a847263b2b9065a26e03 Author: Jason Merrill Date: Thu May 27 23:54:52 2021 -0400 c++: 'this' adjustment for devirtualized call My patch for 95719 made us do a better job of finding the actual virtual function we want to call, but didn't update the 'this' pointer adjustment to match. PR c++/100797 PR c++/95719 gcc/cp/ChangeLog: * call.c (build_over_call): Adjust base_binfo in resolves_to_fixed_type_p case. gcc/testsuite/ChangeLog: * g++.dg/inherit/virtual15.C: New test.
[Bug c++/91859] Using destroying delete should not clobber stores to the object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91859 --- Comment #7 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:cf2b7020ee8e9745ede527b0a3b2e0ffbafd492b commit r12-1145-gcf2b7020ee8e9745ede527b0a3b2e0ffbafd492b Author: Jason Merrill Date: Fri May 28 17:05:23 2021 -0400 c++: no clobber for C++20 destroying delete [PR91859] Before C++20 added destroying operator delete, by the time we called operator delete for a pointer, the object would already be gone. But that isn't true for destroying delete. Since the optimizers' assumptions about operator delete are based on either DECL_IS_REPLACEABLE_OPERATOR (which already is not set) or CALL_FROM_NEW_OR_DELETE_P, let's avoid setting the latter flag in this case. PR c++/91859 gcc/ChangeLog: * tree.h (CALL_FROM_NEW_OR_DELETE_P): Adjust comment. gcc/cp/ChangeLog: * call.c (build_op_delete_call): Don't set CALL_FROM_NEW_OR_DELETE_P for destroying delete. * init.c (build_delete): Don't clobber before destroying delete. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/destroying-delete5.C: New test.
[Bug fortran/59202] Erroneous argument aliasing with defined assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59202 Vladimir Fuka changed: What|Removed |Added CC||vladimir.fuka at gmail dot com --- Comment #2 from Vladimir Fuka --- Behaviour still present in GCC 11.
[Bug c++/94492] no way to silence -Wdeprecated-copy for aggregates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94492 --- Comment #1 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:620cd7861e1266991c9c2a82e1e2d5f4d723ec88 commit r12-1144-g620cd7861e1266991c9c2a82e1e2d5f4d723ec88 Author: Jason Merrill Date: Tue Apr 27 17:13:39 2021 -0400 c++: -Wdeprecated-copy and #pragma diagnostic [PR94492] -Wdeprecated-copy was depending only on the state of the warning at the point where we call the function, making it hard to use #pragma diagnostic to suppress the warning for a particular implicitly declared function. But checking whether the warning is enabled at the location of the implicit declaration turned out to be a bit complicated; option_enabled only tests whether it was enabled at the start of compilation, the actual test only existed in the middle of diagnostic_report_diagnostic. So this patch factors it out and adds a new warning_enabled function to diagnostic.h. gcc/ChangeLog: PR c++/94492 * diagnostic.h (warning_enabled_at): Declare. * diagnostic.c (diagnostic_enabled): Factor out from... (diagnostic_report_diagnostic): ...here. (warning_enabled_at): New. gcc/cp/ChangeLog: PR c++/94492 * decl2.c (cp_warn_deprecated_use): Check warning_enabled_at. gcc/testsuite/ChangeLog: PR c++/94492 * g++.dg/cpp0x/depr-copy4.C: New test.
[Bug c++/100859] New: ICE in tsubst_omp_clauses, at cp/pt.c:17520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100859
Bug ID: 100859
Summary: ICE in tsubst_omp_clauses, at cp/pt.c:17520
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-12.0.0-alpha20210530 snapshot (g:a0a7adeea31918deefb053a9a15257af94aecfaf)
ICEs when compiling the following testcase, reduced from
test/OpenMP/task_ast_print.cpp from the clang 12.0.0 test suite, w/ -fopenmp:
struct S1 {
S1 () {}
};
template
class S7 {
protected:
T c[10];
public:
S7 () {
#pragma omp task affinity (iterator (i = 0 : 10 : 1): c[i])
for (int k = 0; k < 1; ++k)
;
}
};
struct S8 : public S7 {
S8 () : S7 () {}
};
% g++-12.0.0 -fopenmp -c jhbrjcts.cpp
jhbrjcts.cpp: In instantiation of 'S7::S7() [with T = S1]':
jhbrjcts.cpp:19:19: required from here
jhbrjcts.cpp:12:9: internal compiler error: in tsubst_omp_clauses, at
cp/pt.c:17520
12 | #pragma omp task affinity (iterator (i = 0 : 10 : 1): c[i])
| ^~~
0x6b8a81 tsubst_omp_clauses
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210530/work/gcc-12-20210530/gcc/cp/pt.c:17520
0xab7392 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210530/work/gcc-12-20210530/gcc/cp/pt.c:18720
0xab726e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210530/work/gcc-12-20210530/gcc/cp/pt.c:18507
0xab7eb2 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210530/work/gcc-12-20210530/gcc/cp/pt.c:18142
0xab7eb2 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210530/work/gcc-12-20210530/gcc/cp/pt.c:18156
0xab726e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210530/work/gcc-12-20210530/gcc/cp/pt.c:18507
0xabd308 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210530/work/gcc-12-20210530/gcc/cp/pt.c:18142
0xabd308 instantiate_body
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210530/work/gcc-12-20210530/gcc/cp/pt.c:25843
0xabe502 instantiate_decl(tree_node*, bool, bool)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210530/work/gcc-12-20210530/gcc/cp/pt.c:26137
0xae36ab instantiate_pending_templates(int)
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210530/work/gcc-12-20210530/gcc/cp/pt.c:26216
0x9a4d7b c_parse_final_cleanups()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210530/work/gcc-12-20210530/gcc/cp/decl2.c:4966
[Bug tree-optimization/100858] New: Simple common code hoisting is not performed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100858
Bug ID: 100858
Summary: Simple common code hoisting is not performed
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
void bar();
int foo(bool f)
{
if (f) {
bar();
return 1;
}
else {
bar();
return 2;
}
}
; GCC
foo(bool):
sub rsp, 8
testdil, dil
je .L2
callbar()
mov eax, 1
add rsp, 8
ret
.L2:
callbar()
mov eax, 2
add rsp, 8
ret
; Clang
foo(bool):
pushrbx
mov ebx, edi
callbar()
mov eax, 2
sub eax, ebx
pop rbx
ret
https://godbolt.org/z/j9eKG1dds
[Bug tree-optimization/100857] New: Simple common code sinking is not performed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100857
Bug ID: 100857
Summary: Simple common code sinking is not performed
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
void bar(int);
void foo(bool f)
{
if (f) {
bar(1);
}
else {
bar(2);
}
}
; GCC
foo(bool):
testdil, dil
je .L2
mov edi, 1
jmp bar(int)
.L2:
mov edi, 2
jmp bar(int)
; Clang
foo(bool):
mov eax, 2
sub eax, edi
mov edi, eax
jmp bar(int)
https://godbolt.org/z/4oEPY4ncb
[Bug libstdc++/100833] ranges::advance should return n when i == bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100833 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.4 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-06-01 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug tree-optimization/100787] [12 Regression] Bootstrap failure caused by r12-1077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100787 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Aldy Hernandez --- Fixed in trunk by: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571597.html
[Bug c++/100809] PPC: __int128 divide/modulo does not use P10 instructions vdivsq/vdivuq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100809 --- Comment #2 from Bill Schmidt --- I believe this work is pending, but the patches are still under review.
[Bug c++/67593] Partial specialization: "Template argument involves template parameters"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67593 Patrick Palka changed: What|Removed |Added CC||pubby.8 at gmail dot com --- Comment #4 from Patrick Palka --- *** Bug 51155 has been marked as a duplicate of this bug. ***
[Bug c++/51155] Incorrect sizeof and sizeof... behavior in template partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51155 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Target Milestone|--- |12.0 Resolution|--- |DUPLICATE --- Comment #3 from Patrick Palka --- GCC 12 now handles all these testcases correctly after r12-1093, which implements CWG 1315. *** This bug has been marked as a duplicate of bug 67593 ***
[Bug middle-end/100685] #pragma GCC push_options ineffective for optimize options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100685
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|ASSIGNED|RESOLVED
--- Comment #3 from Martin Liška ---
(In reply to Martin Sebor from comment #0)
> The #pragma GCC push_options in the program below should prevent the folding
> of the strlen() call in g() but doesn't. This has changed in GCC 11 (GCC 10
> behaves as expected). The dump shows that the optimize attribute has both
> optimization options, -O1 as well as -O2. That also seems unexpected but it
> has not changed between 10 and 11.
There's a change that caused that:
r11-6922-gefc9ccbfd0ca4da6(27 Jan 2021 10:08)(ja...@redhat.com): [took: 0.596s]
result: FAILED (1)
varpool: Restore GENERIC TREE_READONLY automatic var optimization [PR7260]
In 4.8 and earlier we used to fold the following to 0 during GENERIC folding,
but we don't do that anymore because ctor_for_folding etc. has been turned into
a
GIMPLE centric API, but as the testcase shows, it is invoked even during
GENERIC folding and there the automatic vars still should have meaningful
initializers. I've verified that the C++ FE drops TREE_READONLY on
automatic vars with const qualified types if they require non-constant
(runtime) initialization.
2021-01-27 Jakub Jelinek
PR tree-optimization/97260
* varpool.c: Include tree-pass.h.
(ctor_for_folding): In GENERIC return DECL_INITIAL for TREE_READONLY
non-TREE_SIDE_EFFECTS automatic variables.
* gcc.dg/tree-ssa/pr97260.c: New test.
So the code snippet is optimized out even with -O1. So you should use:
#pragma GCC optimize ("0")
[Bug target/100841] xtensa-linux: dwarf2cfi.c:291:12: error: comparison of integer expressions of different signedness: 'const unsigned int' and 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100841 --- Comment #2 from Jan-Benedict Glaw --- (In reply to Jakub Jelinek from comment #1) > Guess following could fix it > --- gcc/config/xtensa/xtensa.h.jj 2021-01-04 10:25:45.570157539 +0100 > +++ gcc/config/xtensa/xtensa.h2021-06-01 10:39:19.848827041 +0200 [...] It does, though uncovers the next signedness fun: [all 2021-06-01 14:06:13] /usr/lib/gcc-snapshot/bin/g++ -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o function.o -MT function.o -MMD -MP -MF ./.deps/function.TPo ../../gcc/gcc/function.c [all 2021-06-01 14:06:14] ../../gcc/gcc/function.c: In function 'void gen_call_used_regs_seq(rtx_insn*, unsigned int)': [all 2021-06-01 14:06:14] ../../gcc/gcc/function.c:5897:63: error: comparison of unsigned expression in '< 0' is always false [-Werror=type-limits] [all 2021-06-01 14:06:14] 5897 | if (crtl->uses_only_leaf_regs && LEAF_REG_REMAP (regno) < 0) [all 2021-06-01 14:06:22] cc1plus: all warnings being treated as errors [all 2021-06-01 14:06:22] make[1]: *** [Makefile:1141: function.o] Error 1 [all 2021-06-01 14:06:22] make[1]: Leaving directory '/var/lib/laminar/run/gcc-xtensa-linux/4/toolchain-build/gcc' [all 2021-06-01 14:06:22] make: *** [Makefile:4414: all-gcc] Error 2
[Bug other/100826] Add that "-fgcse-after-reload" is enabled at "-O3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100826 --- Comment #5 from Martin Liška --- (In reply to Firas Khalil Khana from comment #4) > Glad I could help. Thanks for your time and effort! You're welcome. We thank you for reporting that!
[Bug target/100643] [11/12 Regression] ICE in ix86_mangle_function_version_assembler_name, at config/i386/i386-features.c:2809 since r11-7693-g1c7bec8bfbc5457c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100643
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0 |1
Last reconfirmed||2021-06-01
CC||jason at gcc dot gnu.org
--- Comment #2 from Martin Liška ---
Slightly clean up test-case:
$ cat pr100643.c
int foo()
{
int foo(void) __attribute__((target("avx")));
int foo(void) __attribute__((target("default")));
return 123;
}
$ g++ pr100643.c -c
pr100643.c:7:1: internal compiler error: in
ix86_mangle_function_version_assembler_name, at
config/i386/i386-features.c:2809
7 | }
| ^
0x8b6dba ix86_mangle_function_version_assembler_name
/home/marxin/Programming/gcc/gcc/config/i386/i386-features.c:2809
0x8b6dba ix86_mangle_decl_assembler_name(tree_node*, tree_node*)
/home/marxin/Programming/gcc/gcc/config/i386/i386-features.c:2839
0xa671bf get_mangled_id
/home/marxin/Programming/gcc/gcc/cp/mangle.c:4041
0xa671bf mangle_decl(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/mangle.c:4078
0x147028c decl_assembler_name(tree_node*)
/home/marxin/Programming/gcc/gcc/tree.c:711
0x14ca040 notice_global_symbol(tree_node*)
/home/marxin/Programming/gcc/gcc/varasm.c:1801
0xd18798 cgraph_node::finalize_function(tree_node*, bool)
/home/marxin/Programming/gcc/gcc/cgraphunit.c:453
0xb9241e expand_or_defer_fn(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/semantics.c:4681
0xb0b138 cp_parser_function_definition_after_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:30157
0xb0c59d cp_parser_function_definition_from_specifiers_and_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:30060
0xb0c59d cp_parser_init_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.c:21706
0xae711c cp_parser_simple_declaration
/home/marxin/Programming/gcc/gcc/cp/parser.c:14487
0xb15be4 cp_parser_declaration
/home/marxin/Programming/gcc/gcc/cp/parser.c:14184
0xb1675c cp_parser_toplevel_declaration
/home/marxin/Programming/gcc/gcc/cp/parser.c:14213
0xb1675c cp_parser_translation_unit
/home/marxin/Programming/gcc/gcc/cp/parser.c:4942
0xb1675c c_parse_file()
/home/marxin/Programming/gcc/gcc/cp/parser.c:45508
0xc4b2d9 c_common_parse_file()
/home/marxin/Programming/gcc/gcc/c-family/c-opts.c:1219
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug other/100826] Add that "-fgcse-after-reload" is enabled at "-O3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100826 --- Comment #4 from Firas Khalil Khana --- Glad I could help. Thanks for your time and effort!
[Bug fortran/42954] [9/10/11/12 regression] TARGET_*_CPP_BUILTINS issues with gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954 --- Comment #35 from Bill Long --- A lot of users have moved to the 10.X series of compilers, and the adventurous ones to 11.X. Will the fixes also appear in those compilers?
[Bug c++/100825] function signature constraints are not a part of mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100825
--- Comment #6 from vopl at bk dot ru ---
(In reply to Jonathan Wakely from comment #5)
> Yes, I realise that, but I think that is the same rule that means you can't
> change the result of overload resolution for a given call,
But I have a precedent:
void foo(char) {}
void useFirst()
{
foo(0); // "void foo(char)" used, no "void foo(int)" visible at now
}
void foo(int) {} // introduce second function
void useSecond()
{
foo(0); // "void foo(int)" selected as more suitable
}
> which is why the
> second definition gets emitted using the same symbol name as the first.
[defns.signature.templ] states that trailing require-clause is a part of
function signature, so these are two different functions:
template void foo() {}
template void foo() requires true {}
Since the signature is the basis for name mangling - different names are
expected for different functions..
> If the constrained overload is declared before the first call to foo()
> then there is no error.
Aha, in such situation there is an only call, no second one, so, no second
symbol and no conflicts.
Thanks.
[Bug target/100856] Arm: Multilib mapping is missing for CDE arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100856 SRINATH PARVATHANENI changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-06-01 Ever confirmed|0 |1 Target||arm-none-eabi
[Bug target/100856] New: Arm: Multilib mapping is missing for CDE arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100856
Bug ID: 100856
Summary: Arm: Multilib mapping is missing for CDE arguments.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sripar01 at gcc dot gnu.org
Target Milestone: ---
For the +cdecp extensions, properly multilib linking is missing in
arm-none-eabi.
$ arm-none-eabi-gcc -march=armv8.1-m.main+mve.fp+cdecp0+cdecp1+cdecp2
-mfloat-abi=hard -fomit-frame-pointer -mfpu=auto --print-multi-dir
.
$ cat xx.c
#include "arm_cde.h"
int main()
{
return 0;
}
$ arm-none-eabi-gcc -march=armv8.1-m.main+mve.fp+cdecp0+cdecp1+cdecp2
-mfloat-abi=hard
/media/sripar01/2tb_work/CDE/src/gcc/gcc/testsuite/gcc.target/arm/acle/xx.c
--specs=rdimon.specs
/media/sripar01/2tb_work/Bug_fixing/build-arm-none-eabi/install/lib/gcc/arm-none-eabi/12.0.0/../../../../arm-none-eabi/bin/ld:
error: /tmp/ccUBPNX2.o uses VFP register arguments, a.out does not
/media/sripar01/2tb_work/Bug_fixing/build-arm-none-eabi/install/lib/gcc/arm-none-eabi/12.0.0/../../../../arm-none-eabi/bin/ld:
error: /tmp/ccUBPNX2.o: conflicting CPU architectures 2/21
/media/sripar01/2tb_work/Bug_fixing/build-arm-none-eabi/install/lib/gcc/arm-none-eabi/12.0.0/../../../../arm-none-eabi/bin/ld:
failed to merge target specific data of file /tmp/ccUBPNX2.o
collect2: error: ld returned 1 exit status
$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/media/sripar01/2tb_work/Bug_fixing/build-arm-none-eabi/install/libexec/gcc/arm-none-eabi/12.0.0/lto-wrapper
Target: arm-none-eabi
Configured with: /media/sripar01/2tb_work/Bug_fixing/src/gcc/configure
--target=arm-none-eabi
--prefix=/media/sripar01/2tb_work/Bug_fixing/build-arm-none-eabi/install//
--with-gmp=/media/sripar01/2tb_work/Bug_fixing/build-arm-none-eabi/host-tools
--with-mpfr=/media/sripar01/2tb_work/Bug_fixing/build-arm-none-eabi/host-tools
--with-mpc=/media/sripar01/2tb_work/Bug_fixing/build-arm-none-eabi/host-tools
--with-isl=/media/sripar01/2tb_work/Bug_fixing/build-arm-none-eabi/host-tools
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=yes --enable-languages=c,c++,fortran --with-newlib
--with-multilib-list=rmprofile --with-pkgversion=unknown
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210520 (experimental) (unknown)
[Bug target/100758] __builtin_cpu_supports does not (always) detect "sse2"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100758 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Martin Liška --- Closing as wontfix.
[Bug other/100759] [12 regression] ICE for g++.dg/torture/pr81360.C after r12-1039 at gcc/options-save.c:13626
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100759 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Martin Liška --- Should be fixed now.
[Bug other/100759] [12 regression] ICE for g++.dg/torture/pr81360.C after r12-1039 at gcc/options-save.c:13626
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100759 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:b195d84561a5c31108c7bbbd7c5b63fe3cebe35f commit r12-1142-gb195d84561a5c31108c7bbbd7c5b63fe3cebe35f Author: Martin Liska Date: Tue Jun 1 10:41:04 2021 +0200 Fix sanity checking of global_options. gcc/c-family/ChangeLog: PR other/100759 * c-attribs.c (handle_optimize_attribute): Limit sanity check to a situation where we are not in processing of an optimize pragma. * c-pragma.c (handle_pragma_pop_options): Restore target options.
[Bug rtl-optimization/87871] [9/10/11/12 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #68 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #67)
> According to gcc-testresults, we still see:
> FAIL: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump pro_and_epilogue
> "Performing shrink-wrapping"
> FAIL: gcc.target/arm/addr-modes-float.c scan-assembler vst3.8\t{d[02468],
> d[02468], d[02468]}, \\[r[0-9]+\\]!
>
> but gcc.target/arm/armv8_2-fp16-move-1.c seems to PASS now.
OK, I think the best thing to do then is to create separate bugs for each
testcase that fails and to link them to this one (treating this one as
essentially a meta bug).
[Bug rtl-optimization/87871] [9/10/11/12 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #67 from Christophe Lyon ---
According to gcc-testresults, we still see:
FAIL: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump pro_and_epilogue "Performing
shrink-wrapping"
FAIL: gcc.target/arm/addr-modes-float.c scan-assembler vst3.8\t{d[02468],
d[02468], d[02468]}, \\[r[0-9]+\\]!
but gcc.target/arm/armv8_2-fp16-move-1.c seems to PASS now.
[Bug driver/69471] "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 --- Comment #19 from wavexx at thregr dot org --- I don't follow gcc development too closely. I expected this bug to be closed when the relevant patch was applied automatically, but I could test if this still apllied. Which gcc release is sufficient to test with all the patches applied? Is gcc 10.2.1 enough?
[Bug fortran/100855] New: pow run time gfortran vs ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855
Bug ID: 100855
Summary: pow run time gfortran vs ifort
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: nadavhalahmi560 at gmail dot com
Target Milestone: ---
I wrote the code below:
```
program power
implicit none
real :: sum, n, q
integer :: i, j
integer :: limit
real :: start, finish
sum = 0d0
limit = 1
n = 2.0
q = 0.5
call CPU_TIME(start)
do j=1,limit
do i=1, limit
n = n*q
sum = sum + (i ** (0.05 + n))
end do
end do
call CPU_TIME(finish)
print *, sum
print '("Time = ",f6.3," seconds.")',finish-start
end program power
```
and compiled it using:
ifort pow.f90 -O3 -no-vec -o intel.out
gfortran pow.f90 -O3 -fno-tree-vectorize -o gnu.out
When I run `./intel.out` I get the following output:
3.3554432E+07
Time = 1.615 seconds.
When I run `./gnu.out` I get the following output:
33554432.0
Time = 7.817 seconds.
Therefore, gfortran is much slower than ifort. I get similar behavior for `log`
and `exp` functions.
gfortran -v:
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/software/x86_64/3.10.0/gcc/11.1.0/libexec/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/software/x86_64/3.10.0/gcc/11.1.0
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.1.0 (GCC)
ifort -v:
ifort version 19.1.3.304
[Bug libstdc++/99453] libstdc++*-gdb.py installation depends on library naming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99453 --- Comment #16 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:9f7bc160b4a0f27dce248d1226e3ae7104b0e67b commit r12-1141-g9f7bc160b4a0f27dce248d1226e3ae7104b0e67b Author: Jonathan Wakely Date: Tue Jun 1 11:00:16 2021 +0100 libstdc++: Fix installation of python hooks [PR 99453] When no shared library is installed, the new code to determine the name of the -gdb.py file yields an empty string. Use the name of the static library in that case. libstdc++-v3/ChangeLog: PR libstdc++/99453 * python/Makefile.am: Use archive name for printer hook if no dynamic library name is available. * python/Makefile.in: Regenerate.
[Bug other/100826] Add that "-fgcse-after-reload" is enabled at "-O3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100826 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Martin Liška --- Fixed.
[Bug other/100826] Add that "-fgcse-after-reload" is enabled at "-O3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100826 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:fdbd0cb73af527f0630f0cbb26edb8584f593fea commit r12-1140-gfdbd0cb73af527f0630f0cbb26edb8584f593fea Author: Martin Liska Date: Tue Jun 1 14:17:39 2021 +0200 docs: Mention that -fgcse-after-reload is enabled with -O3. gcc/ChangeLog: PR other/100826 * doc/invoke.texi: Mention that -fgcse-after-reload is enabled with -O3.
[Bug fortran/96012] [9/10/11/12 Regression] ICE in fold_convert_loc, at fold-const.c:2558
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96012 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from Dominique d'Humieres --- > This PR appears to remain an 8-only regression, as the testcases in comment#0 > do compile now. GCC8 is closed, so closing.
[Bug c++/71283] Inconsistent location for C++ warning options in the manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71283 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.5 |---
[Bug driver/69471] "-march=native" unintentionally breaks further -march/-mtune flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471 --- Comment #18 from Manuel López-Ibáñez --- (In reply to wavexx from comment #17) > I wish this would be given a nudge, considering the patch. This has been > pushed to new releases since 2016 :( I see several patches have been committed already. Is there any patch pending? What are the remaining issues?
[Bug inline-asm/100785] [9/10/11/12 Regression] ICE: in expand_asm_stmt with "m" and bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100785 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Jakub Jelinek --- Created attachment 50904 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50904=edit gcc12-pr100785.patch Untested fix.
[Bug c++/85004] ambiguous diagnostic: passing ‘const S’ as ‘this’ argument discards qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85004 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.5 |---
[Bug c++/100825] function signature constraints are not a part of mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100825 --- Comment #5 from Jonathan Wakely --- Yes, I realise that, but I think that is the same rule that means you can't change the result of overload resolution for a given call, which is why the second definition gets emitted using the same symbol name as the first. If the constrained overload is declared before the first call to foo() then there is no error.
[Bug rtl-optimization/87871] [9/10/11/12 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871 Richard Earnshaw changed: What|Removed |Added Status|NEW |WAITING --- Comment #66 from Richard Earnshaw --- Is this still an issue? I propose to close now unless specific cases can be identified and reported here.
[Bug target/84467] Choosing between Integer and NEON for 64-bit operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84467 Richard Earnshaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Earnshaw --- This was ultimately addressed by deciding not to use neon at all for 64-bit operations. Too many cases lead to very poor performance and with better optimization on the general regs expansions (which is only possible if a hard choice is made early) we generally end up with better code overall.
[Bug target/95650] aarch64: Missed optimization storing addition of two shorts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95650 --- Comment #6 from Richard Earnshaw --- AArch32 is able to produce the optimal sequence because the ABI specifies caller widening of parameters. For safety reasons AArch64 takes the opposite approach and requires the callee to narrow arguments. Sadly, because this isn't handled at the gimple level, it has to be detected during RTL optimization. Yes, the optimization is sound because the bits above bit 16 in the input values cannot affect the lower bits in the result of an addition. It's also likely that the expanders cannot see enough of what is going on to transform this efficiently either.
[Bug c/100854] New: TS 18661-3 and backwards-incompatible setting of __FLT_EVAL_METHOD__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100854
Bug ID: 100854
Summary: TS 18661-3 and backwards-incompatible setting of
__FLT_EVAL_METHOD__
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
GCC implements TS 18661-3. On arm and aarch64, this means that an -march string
that includes fp16 results in GCC defining __FLT_EVAL_METHOD__ to 16.
This is backwards-incompatible with libraries conforming to C99 which interpret
values other than 0, 1, or 2 as implementation defined. See newlib's use of
__FLT_EVAL_METHOD__ in math.h:
https://sourceware.org/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/include/math.h;h=ba1a8a17ef4368eabb7a0d116f50b6a7d34546ce;hb=HEAD#l144
On AArch64, we define three variants of __FLT_EVAL_METHOD__:
$ aarch64-linux-gnu-gcc -xc /dev/null -E -dM | grep FLT_EVAL
#define __FLT_EVAL_METHOD__ 0
#define __FLT_EVAL_METHOD_TS_18661_3__ 0
#define __FLT_EVAL_METHOD_C99__ 0
Adding fp16 to the -march, we see that all three of these macros take the value
16:
$ aarch64-linux-gnu-gcc -march=armv8.2-a+fp16 -xc /dev/null -E -dM | grep
FLT_EVAL
#define __FLT_EVAL_METHOD__ 16
#define __FLT_EVAL_METHOD_TS_18661_3__ 16
#define __FLT_EVAL_METHOD_C99__ 16
This is a little surprising. Based on the name of __FLT_EVAL_METHOD_C99__, you
might expect it to only take values defined by C99.
Forcing -std=c99, we see that __FLT_EVAL_METHOD__ itself takes a C99-conforming
value, but the others do not:
$ aarch64-linux-gnu-gcc -march=armv8.2-a+fp16 -std=c99 -xc /dev/null -E -dM |
grep FLT_EVAL
#define __FLT_EVAL_METHOD__ 0
#define __FLT_EVAL_METHOD_TS_18661_3__ 16
#define __FLT_EVAL_METHOD_C99__ 16
It seems that the behaviour of __FLT_EVAL_METHOD_C99__ is the exact opposite of
what the name suggests.
Notably the __FLT_EVAL_METHOD_C99__ macro is AArch64-specific. It isn't
implemented on the arm port:
$ ./arm-eabi-gcc -xc /dev/null -E -dM -march=armv8-a+simd | grep FLT_EVAL
#define __FLT_EVAL_METHOD__ 0
#define __FLT_EVAL_METHOD_TS_18661_3__ 0
$ ./arm-eabi-gcc -xc /dev/null -E -dM -march=armv8.2-a+fp16 | grep FLT_EVAL
#define __FLT_EVAL_METHOD__ 16
#define __FLT_EVAL_METHOD_TS_18661_3__ 16
$ ./arm-eabi-gcc -xc /dev/null -E -dM -march=armv8.2-a+fp16 -std=c99 | grep
FLT_EVAL
#define __FLT_EVAL_METHOD__ 0
#define __FLT_EVAL_METHOD_TS_18661_3__ 16
It would be useful if GCC provided a portable pre-defined __FLT_EVAL_METHOD__
variant that was guaranteed to only take values defined by C99/C11. As it
stands, GCC with -march=armv8.2-a+fp16 (or any -mcpu/-march that implies fp16)
on arm and aarch64 fails to compile any file that includes newlib's math.h.
This could be considered a bug in TS 18661-3 which stipulates that
__FLT_EVAL_METHOD__ take backwards-incompatible values. Either way, it seems
that GCC should provide a way to recover a conforming __FLT_EVAL_METHOD__
without forcing the user to compile everything in a strict standards-conforming
mode (-std=c{99,11}).
At a minimum, the __FLT_EVAL_METHOD_C99__ builtin macro should probably be
removed from the AArch64 backend as its current behaviour is entirely
unhelpful.
Ideally, GCC would define a new macro (portable across all architectures
implementing fp16) which is guaranteed to only take values defined by C99/C11.
[Bug c++/100853] internal compiler error: in cp_tree_equal, at cp/tree.c:4148
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100853 --- Comment #1 from Ilya Leoshkevich --- Created attachment 50903 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50903=edit repro
[Bug c++/100853] New: internal compiler error: in cp_tree_equal, at cp/tree.c:4148
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100853
Bug ID: 100853
Summary: internal compiler error: in cp_tree_equal, at
cp/tree.c:4148
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iii at linux dot ibm.com
Target Milestone: ---
$ cat cp-tree-equal.cpp
typedef struct a *b;
template struct c
{ d({
b *e; __typeof (*({
__typeof *e f;
f})).g const f (({ __typeof (*({
int h;
f} )).g const f (
$ gcc/cc1plus -fno-PIE -g -O2 -fno-checking -gtoggle -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables cp-tree-equal.cpp
...
cp-tree-equal.cpp:8:37: internal compiler error: in cp_tree_equal, at
cp/tree.c:4148
8 | f} )).g const f (
| ^
0x7062e9 cp_tree_equal(tree_node*, tree_node*)
../../gcc/cp/tree.c:4148
0xbd1d3e cp_tree_equal(tree_node*, tree_node*)
../../gcc/cp/tree.c:4138
0xbd1d3e cp_tree_equal(tree_node*, tree_node*)
../../gcc/cp/tree.c:4138
0xbd1d3e cp_tree_equal(tree_node*, tree_node*)
../../gcc/cp/tree.c:4138
0xbd1d3e cp_tree_equal(tree_node*, tree_node*)
../../gcc/cp/tree.c:4138
0xbdc784 structural_comptypes
../../gcc/cp/typeck.c:1491
0xae2ffc check_local_shadow
../../gcc/cp/name-lookup.c:3264
0xae2ffc do_pushdecl
../../gcc/cp/name-lookup.c:3773
0xae39b4 pushdecl(tree_node*, bool)
../../gcc/cp/name-lookup.c:3852
0xa3995e start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/cp/decl.c:5591
0xb2dd61 cp_parser_init_declarator
../../gcc/cp/parser.c:21802
0xb093cd cp_parser_simple_declaration
../../gcc/cp/parser.c:14487
0xb0b0a9 cp_parser_declaration_statement
../../gcc/cp/parser.c:13622
0xb0bc0b cp_parser_statement
../../gcc/cp/parser.c:11848
0xb0ce0e cp_parser_statement_seq_opt
../../gcc/cp/parser.c:12215
0xb0cee8 cp_parser_compound_statement
../../gcc/cp/parser.c:12164
0xb10473 cp_parser_statement_expr
../../gcc/cp/parser.c:5142
0xb10473 cp_parser_primary_expression
../../gcc/cp/parser.c:5549
0xb11b80 cp_parser_postfix_expression
../../gcc/cp/parser.c:7528
0xb243af cp_parser_unary_expression
../../gcc/cp/parser.c:8849
Found when reducing a testcase for another problem.
[Bug middle-end/100278] IBM Z: Segmentation fault when building valgrind with -march=z14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100278 Ilya Leoshkevich changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Ilya Leoshkevich --- Fixed, thanks!
