[Bug tree-optimization/96135] [9/10/11 regression] bswap not detected by bswap pass, unexpected results between optimization levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96135 --- Comment #3 from Richard Biener --- See also PR96573
[Bug tree-optimization/96573] [10/11 Regression] Regression in optimization on x86-64 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96573 --- Comment #3 from Richard Biener --- See also PR96135
[Bug libstdc++/99846] New: [11 regression] std::variant comparison operator error for recursive type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99846
Bug ID: 99846
Summary: [11 regression] std::variant comparison operator error
for recursive type
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: nilsgladitz at gmail dot com
Target Milestone: ---
Created attachment 50491
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50491=edit
Test case source code
The attached source is a test case I reduced from a JSON like library that uses
std::variant to store alternate value types.
This still builds with GCC 10.2.0 but fails in 11.0.1 (g65374af219f) with:
/opt/gcc/git-snapshot/include/c++/11.0.1/compare: In substitution of
‘template requires (three_way_comparable<_Types,
std::partial_ordering> && ...) constexpr
std::common_comparison_category_t...> std::operator<=>(const std::variant<_Types ...>&, const
std::variant<_Types ...>&) [with _Types = {std::__cxx11::list >}]’:
/opt/gcc/git-snapshot/include/c++/11.0.1/compare:893:10: required by
substitution of ‘template constexpr auto
std::__detail::_Synth3way::operator()(const _Tp&, const _Up&) const requires
requires{{std::__detail::_Synth3way::operator()::__t <
std::__detail::_Synth3way::operator()::__u} -> decltype(auto) [requires
std::__detail::__boolean_testable<,
>];{std::__detail::_Synth3way::operator()::__u <
std::__detail::_Synth3way::operator()::__t} -> decltype(auto) [requires
std::__detail::__boolean_testable<, >];} [with _Tp = Value; _Up =
Value]’
/opt/gcc/git-snapshot/include/c++/11.0.1/compare:914:34: required by
substitution of ‘template using __synth3way_t = decltype
(std::__detail::__synth3way(declval<_Tp&>(), declval<_Up&>())) [with _Tp =
Value; _Up = Value]’
/opt/gcc/git-snapshot/include/c++/11.0.1/bits/stl_list.h:2030:5: required by
substitution of ‘template
std::__detail::__synth3way_t<_T1> std::operator<=>(const
std::__cxx11::list<_Tp, _Alloc>&, const std::__cxx11::list<_Tp, _Alloc>&) [with
_Tp = Value; _Alloc = std::allocator]’
/opt/gcc/git-snapshot/include/c++/11.0.1/concepts:306:10: required by
substitution of ‘template requires
(three_way_comparable<_Types, std::partial_ordering> && ...) constexpr
std::common_comparison_category_t...> std::operator<=>(const std::variant<_Types ...>&, const
std::variant<_Types ...>&) [with _Types = {std::__cxx11::list >}]’
test.cpp:16:16: required from here
/opt/gcc/git-snapshot/include/c++/11.0.1/variant:1218:5: required by the
constraints of ‘template requires
(three_way_comparable<_Types, std::partial_ordering> && ...) constexpr
std::common_comparison_category_t...> std::operator<=>(const std::variant<_Types ...>&, const
std::variant<_Types ...>&)’
cc1plus: error: satisfaction of atomic constraint
‘(three_way_comparable<_Types, std::partial_ordering> && ...) [with _Types =
{_Types ...}]’ depends on itself
/opt/gcc/git-snapshot/include/c++/11.0.1/compare: In substitution of
‘template requires (three_way_comparable<_Types,
std::partial_ordering> && ...) constexpr
std::common_comparison_category_t...> std::operator<=>(const std::variant<_Types ...>&, const
std::variant<_Types ...>&) [with _Types = {std::__cxx11::list >}]’:
/opt/gcc/git-snapshot/include/c++/11.0.1/compare:894:10: required by
substitution of ‘template constexpr auto
std::__detail::_Synth3way::operator()(const _Tp&, const _Up&) const requires
requires{{std::__detail::_Synth3way::operator()::__t <
std::__detail::_Synth3way::operator()::__u} -> decltype(auto) [requires
std::__detail::__boolean_testable<,
>];{std::__detail::_Synth3way::operator()::__u <
std::__detail::_Synth3way::operator()::__t} -> decltype(auto) [requires
std::__detail::__boolean_testable<, >];} [with _Tp = Value; _Up =
Value]’
/opt/gcc/git-snapshot/include/c++/11.0.1/compare:914:34: required by
substitution of ‘template using __synth3way_t = decltype
(std::__detail::__synth3way(declval<_Tp&>(), declval<_Up&>())) [with _Tp =
Value; _Up = Value]’
/opt/gcc/git-snapshot/include/c++/11.0.1/bits/stl_list.h:2030:5: required by
substitution of ‘template
std::__detail::__synth3way_t<_T1> std::operator<=>(const
std::__cxx11::list<_Tp, _Alloc>&, const std::__cxx11::list<_Tp, _Alloc>&) [with
_Tp = Value; _Alloc = std::allocator]’
/opt/gcc/git-snapshot/include/c++/11.0.1/concepts:306:10: required by
substitution of ‘template requires
(three_way_comparable<_Types, std::partial_ordering> && ...) constexpr
std::common_comparison_category_t...> std::operator<=>(const std::variant<_Types ...>&, const
std::variant<_Types ...>&) [with _Types = {std::__cxx11::list >}]’
test.cpp:16:16: required from here
/opt/gcc/git-snapshot/include/c++/11.0.1/variant:1218:5: required by the
constraints of ‘template requires
(three_way_comparable<_Types, std::partial_ordering> && ...) constexpr
std::common_comparison_category_t...> std::operator<=>(const
[Bug libstdc++/99846] [11 regression] std::variant comparison operator error for recursive type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99846 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Keywords||rejects-valid Known to work||10.2.0
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #59 from Jakub Jelinek --- The non-noisy workaround applied.
[Bug c++/99833] [8/9/10/11 Regression] structured binding + if init + generic lambda = internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99833 Richard Biener changed: What|Removed |Added Priority|P3 |P2 --- Comment #4 from Richard Biener --- (In reply to Marek Polacek from comment #2) > Started with r11-372. So may be a P1 :(. But you show GCC 8 has the same issue ...
[Bug ipa/99835] missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99835 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org Component|tree-optimization |ipa Last reconfirmed||2021-03-31 Keywords||missed-optimization Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Version|unknown |11.0 --- Comment #1 from Richard Biener --- At -O3 the unused 'c' remains. Likely different (recursive?) inlining makes us process a cgraph cycle in different order and thus fail to elide the output of 'c' (it's output first at -O3). Fixing that would need processing cgraph SCCs with an extra IPA phase in main optimization so we get a chance to do extra node removal (maybe order the cycles so that functions we can elide - aka static ones - are processed last).
[Bug ipa/99835] missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99835 --- Comment #4 from Jan Hubicka --- > But inside a SCC the order is arbitrary anyway. Note I'd only re-order SCCs > and keep the postordering the same otherwise. We compile leaf functions first to be able to propagated to their callers. In order to be able to optimize out functions in case call was optimized out, we would need to compile in reverse order than we do now... Honza
[Bug target/99037] Invalid representation of vector zero in aarch64-simd.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99037 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:1a92899b08e61d503a2897f2f66b064eb84706bc commit r10-9628-g1a92899b08e61d503a2897f2f66b064eb84706bc Author: Kyrylo Tkachov Date: Mon Mar 29 11:52:24 2021 +0100 aarch64: PR target/99037 Fix RTL represntation in move_lo_quad patterns This patch fixes the RTL representation of the move_lo_quad patterns to use aarch64_simd_or_scalar_imm_zero for the zero part rather than a vec_duplicate of zero or a const_int 0. The expander that generates them is also adjusted so that we use and match the correct const_vector forms throughout. Co-Authored-By: Jakub Jelinek gcc/ChangeLog: PR target/99037 * config/aarch64/aarch64-simd.md (move_lo_quad_internal_): Use aarch64_simd_or_scalar_imm_zero to match zeroes. Remove pattern matching const_int 0. (move_lo_quad_internal_be_): Likewise. (move_lo_quad_): Update for the above. * config/aarch64/iterators.md (VQ_2E): Delete. gcc/testsuite/ChangeLog: PR target/99808 * gcc.target/aarch64/pr99808.c: New test.
[Bug target/99808] [8/9/10/11 Regression] ICE in as_a, at machmode.h:365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99808 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:1a92899b08e61d503a2897f2f66b064eb84706bc commit r10-9628-g1a92899b08e61d503a2897f2f66b064eb84706bc Author: Kyrylo Tkachov Date: Mon Mar 29 11:52:24 2021 +0100 aarch64: PR target/99037 Fix RTL represntation in move_lo_quad patterns This patch fixes the RTL representation of the move_lo_quad patterns to use aarch64_simd_or_scalar_imm_zero for the zero part rather than a vec_duplicate of zero or a const_int 0. The expander that generates them is also adjusted so that we use and match the correct const_vector forms throughout. Co-Authored-By: Jakub Jelinek gcc/ChangeLog: PR target/99037 * config/aarch64/aarch64-simd.md (move_lo_quad_internal_): Use aarch64_simd_or_scalar_imm_zero to match zeroes. Remove pattern matching const_int 0. (move_lo_quad_internal_be_): Likewise. (move_lo_quad_): Update for the above. * config/aarch64/iterators.md (VQ_2E): Delete. gcc/testsuite/ChangeLog: PR target/99808 * gcc.target/aarch64/pr99808.c: New test.
[Bug target/99808] [8/9/10/11 Regression] ICE in as_a, at machmode.h:365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99808 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:c611209a3422d2a2dc10bc804986db9bfb80a62e commit r10-9629-gc611209a3422d2a2dc10bc804986db9bfb80a62e Author: Kyrylo Tkachov Date: Tue Mar 30 14:07:50 2021 +0100 aarch64: Fix gcc.target/aarch64/pr99808.c for ILP32 Fix test for -mabi=ilp32 gcc/testsuite/ChangeLog: PR target/99808 * gcc.target/aarch64/pr99808.c: Use ULL constant suffix. (cherry picked from commit 41d57b2a97c44ae7b0a5b01ae703a8f0d0495238)
[Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
(In reply to Richard Biener from comment #1)
> allocbuf(uint32_t nelems) {
> return new(std::nothrow) T[static_cast(nelems)];
> }
>
> expands to
>
> < = TARGET_EXPR nelems> <= 1152921504606846975 ? (size_t) ((SAVE_EXPR <(sizetype) nelems> +
> 1) * 8) : (size_t) __cxa_throw_bad_array_new_length ()>;, TARGET_EXPR
> , (const struct
> nothrow_t &) )>;;, *(sizetype *) NON_LVALUE_EXPR =
> SAVE_EXPR <(sizetype) nelems>;, try
> {
> ...
>
> which calls MyType::operator new[] and then stores 'nelems' at the beginning
> of the allocated storage for some reason (ABI?).
Yes
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#array-cookies
(not just ABI but also for the reason the ABI talks about).
>
> That makes using new[] (std::nothrow) "unsafe" to call it seems?
I guess for the nothrow versions we should wrap that nelems store into a
COND_EXPR based on whether operator new returned non-NULL.
[Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
--- Comment #3 from Richard Biener ---
The interesting thing is that doing
#include
struct X
{
~X(){}
};
int main(int argc, char **argv)
{
X *p = new (std::nothrow) X[argc];
}
properly conditionalizes this store:
TARGET_EXPR , (const struct
nothrow_t &) )>;;, (struct X *) D.6173 != 0B ? *(sizetype *)
NON_LVALUE_EXPR = SAVE_EXPR <(sizetype) argc>;, (struct X *) (D.6173 +
8); : (struct X *) D.6173;)
so something in the wrapping triggers the error.
[Bug testsuite/97680] [12 Regression] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 Summary|[11 Regression] new test|[12 Regression] new test |case|case |c-c++-common/zero-scratch-r |c-c++-common/zero-scratch-r |egs-10.c in r11-4578 has|egs-10.c in r11-4578 has |excess errors |excess errors Target Milestone|11.0|12.0 --- Comment #15 from Jakub Jelinek --- Testsuite adjusted. Changing it into a GCC 12 regression because support for the feature on many of the architectures is missing.
[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4
[Bug target/97701] [10 Regression] aarch64: ICE in extract_constrain_insn since r10-4447-g095f78c6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97701 --- Comment #15 from Alex Coplan --- So fixed everywhere?
[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 Matthias Klose changed: What|Removed |Added Status|WAITING |NEW
[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 --- Comment #23 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 > > --- Comment #21 from Matthias Klose --- > building with trunk 20210330 using these parameters didn't succeed: > > make[1]: Entering directory '/packages/tmp/guymager-0.8.12' > g++ -c -pipe -g -O2 -ffile-prefix-map=/packages/tmp/guymager-0.8.12=. > -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat > -Werror=format-security --param ggc-min-expand=0 ggc-min-heapsize=0 ^^^ missing --param here (which may be my mistake in earlier comment, sorry for htat) Honza
[Bug target/98119] [10/11 Regression] SVE: Wrong code with -O1 -ftree-vectorize -msve-vector-bits=512 -mtune=thunderx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98119 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:1393938e4c7dab9306cdce5a73d93b242fc246ec commit r11-7927-g1393938e4c7dab9306cdce5a73d93b242fc246ec Author: Richard Sandiford Date: Wed Mar 31 11:26:06 2021 +0100 aarch64: Fix target alignment for SVE [PR98119] The vectoriser supports peeling for alignment using predication: we move back to the previous aligned boundary and make the skipped elements inactive in the first loop iteration. As it happens, the costs for existing CPUs give an equal cost to aligned and unaligned accesses, so this feature is rarely used. However, the PR shows that when the feature was forced on, we were still trying to align to a full-vector boundary even when using partial vectors. gcc/ PR target/98119 * config/aarch64/aarch64.c (aarch64_vectorize_preferred_vector_alignment): Query the size of the provided SVE vector; do not assume that all SVE vectors have the same size. gcc/testsuite/ PR target/98119 * gcc.target/aarch64/sve/pr98119.c: New test.
[Bug rtl-optimization/96264] [10 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 --- Comment #18 from Richard Biener --- Please somebody do it quick then (not omitting necessary testing, of course).
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
--- Comment #6 from Richard Biener ---
(In reply to Jan Hubicka from comment #5)
> > Btw, one solution would be to drop __always_inline__ after always-inline
> > inlining
> > and thus make it reliably not present for IPA inlining.
> Removing it would make you to lose those errors, but we can ignore it
> for late inlining if we decide we do not really care about always
> inlining indirect calls (that are not reliably inlined by early
> inliner).
>
> But I tried that at some point and broke kernel.
>
> Note that we could also use syntactic aliase and consider two decls
> unmergeable if they differ by always_inline attribute. That should make
> it to behave consistently...
Yeah, and then maybe diagnose this "ODR violation". Still
__attribute__((__always_inline__)) void *memcpy();
void *foo = memcpy;
should be ill-formed (but yeah, maybe this ship has sailed...).
Now, I do wonder why during cgraph merging we prefer the non-definition
declaration ... the code "works fine" if it's not memcpy but memcpyx
(and thus not __builtin_memcpy but also memcpyx).
I also wonder if we can get a better reduction of the kernel problem
due to all the diagnostics I get:
1.i:1:42: warning: 'always_inline' function might not be inlinable
[-Wattribute]
1 | __attribute__((__always_inline__)) void *memcpy();
| ^~
3.i:5:1: warning: conflicting types for built-in function 'memcpy'; expected
'void *(void *, const void *, long unsigned int)'
[-Wbuiltin-declaration-mismatch]
5 | memcpy(void *dest, void *src, long len) {
| ^~
1.i:1:42: warning: type of 'memcpy' does not match original declaration
[-Wlto-type-mismatch]
1 | __attribute__((__always_inline__)) void *memcpy();
| ^
...
[Bug c++/99831] [10/11 Regression] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831 Richard Biener changed: What|Removed |Added Summary|ICE: in reshape_init, at|[10/11 Regression] ICE: in |cp/decl.c:6720 |reshape_init, at ||cp/decl.c:6720 Target Milestone|--- |10.3 Priority|P3 |P2
[Bug ipa/99834] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99834 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-03-31 Version|unknown |11.0 CC||hubicka at gcc dot gnu.org Keywords||missed-optimization Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Similar to the other bug - when 'main' is named 'bar' then we optimize it OK at -O3, the difference being again loop header copying not applied in "cold" context but inlining is. Not sure if we want to call this a bug, but then the inconsistency is odd.
[Bug c++/99843] Making a function a friend of a class will hide function constructor priority if has constructor(n) attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99843
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-03-31
Known to fail||11.0, 7.5.0
Keywords||wrong-code
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Biener ---
Probably an issue with merging the declarations
friend void Init105(void);
and
void Init105(void) __attribute__((constructor(105)));
Smaller testcase:
//void Init105(void) __attribute__((constructor(105))); -- fixes it
class Foo
{
friend void Init105(void);
};
void Init105(void) __attribute__((constructor(105)));
void Init105(void)
{
}
[Bug ipa/99835] missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99835 --- Comment #2 from Jan Hubicka --- > At -O3 the unused 'c' remains. Likely different (recursive?) inlining makes > us > process a cgraph cycle in different order and thus fail to elide the output > of 'c' (it's output first at -O3). > > Fixing that would need processing cgraph SCCs with an extra IPA phase in main > optimization so we get a chance to do extra node removal (maybe order > the cycles so that functions we can elide - aka static ones - are processed > last). That would tamper with optimizations that propagate from callee to caller during late optimization, like IPA register allocation, stack alignment propagation or late pure/const discovery. Honza
Re: [Bug ipa/99835] missed optimization for dead code elimination at -O3 (vs. -O1)
> At -O3 the unused 'c' remains. Likely different (recursive?) inlining makes > us > process a cgraph cycle in different order and thus fail to elide the output > of 'c' (it's output first at -O3). > > Fixing that would need processing cgraph SCCs with an extra IPA phase in main > optimization so we get a chance to do extra node removal (maybe order > the cycles so that functions we can elide - aka static ones - are processed > last). That would tamper with optimizations that propagate from callee to caller during late optimization, like IPA register allocation, stack alignment propagation or late pure/const discovery. Honza
[Bug target/99813] [11 Regression] SVE: Invalid assembly at -O3 (multiplier out of range in incb instruction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99813 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 --- Comment #22 from Matthias Klose --- this is a compiler configured with --enable-default--pie
[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 --- Comment #25 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 > > --- Comment #23 from Jan Hubicka --- > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 > > > > --- Comment #21 from Matthias Klose --- > > building with trunk 20210330 using these parameters didn't succeed: > > > > make[1]: Entering directory '/packages/tmp/guymager-0.8.12' > > g++ -c -pipe -g -O2 -ffile-prefix-map=/packages/tmp/guymager-0.8.12=. > > -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat ^^^ this is interesting differnce, I will give it a try. It did not occured to me you are using fat lto objects (which is not very good idea in general since nm/ranlib/ar gets confused by it) Honza > > -Werror=format-security --param ggc-min-expand=0 ggc-min-heapsize=0 >^^^ missing --param here > (which may be my mistake in earlier comment, sorry for htat) > > Honza > > -- > You are receiving this mail because: > You are the assignee for the bug. > You are on the CC list for the bug.
[Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2021-03-31
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Biener ---
allocbuf(uint32_t nelems) {
return new(std::nothrow) T[static_cast(nelems)];
}
expands to
< = TARGET_EXPR <= 1152921504606846975 ? (size_t) ((SAVE_EXPR <(sizetype) nelems> + 1)
* 8) : (size_t) __cxa_throw_bad_array_new_length ()>;, TARGET_EXPR , (const struct nothrow_t &)
)>;;, *(sizetype *) NON_LVALUE_EXPR = SAVE_EXPR <(sizetype)
nelems>;, try
{
...
which calls MyType::operator new[] and then stores 'nelems' at the beginning
of the allocated storage for some reason (ABI?).
That makes using new[] (std::nothrow) "unsafe" to call it seems?
[Bug target/99836] aarch64: -fpatchable-function-entry=N[,0] should place .cfi_startproc before NOPs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99836 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Earnshaw --- Dup *** This bug has been marked as a duplicate of bug 98776 ***
[Bug debug/98776] DW_AT_low_pc is inconsistent with function entry address, when enabling -fpatchable-function-entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98776 Richard Earnshaw changed: What|Removed |Added CC||i at maskray dot me --- Comment #1 from Richard Earnshaw --- *** Bug 99836 has been marked as a duplicate of this bug. ***
[Bug bootstrap/98860] [11 Regression] bootstrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #58 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a49a96f681bf13c6e77644d4507e867f00f93fe6 commit r11-7923-ga49a96f681bf13c6e77644d4507e867f00f93fe6 Author: Jakub Jelinek Date: Wed Mar 31 09:11:29 2021 +0200 i386, debug: Default to -gdwarf-4 on Windows targets with broken ld.bfd [PR98860] As mentioned in the PR, before the https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba6eb62ff0ea9843a018cfd7cd06777bd66ae0a0 fix from March 1st, PECOFF ld.bfd didn't know about .debug_loclists, .debug_rnglists and other debug sections new in DWARF 5. Unfortunately, unlike for ELF linkers, that means the sections were placed in wrong ordering with wrong VMA/LMA, so the resulting executables are apparently unusable. As that is pretty new change, newer than 2.35.2 or 2.36 binutils releases, the following patch adds a workaround that turns -gdwarf-4 by default instead of -gdwarf-5 if a broken linker is found at configure time. Users can still explicitly play with -gdwarf-5 and either use a non-broken linker or use custom linker scripts for the broken one, but at least by default it should work. 2021-03-31 Jakub Jelinek PR bootstrap/98860 * configure.ac (HAVE_LD_BROKEN_PE_DWARF5): New AC_DEFINE if PECOFF linker doesn't support DWARF sections new in DWARF5. * config/i386/i386-options.c (ix86_option_override_internal): Default to dwarf_version 4 if HAVE_LD_BROKEN_PE_DWARF5 for TARGET_PECOFF targets. * config.in: Regenerated. * configure: Regenerated.
[Bug ipa/99835] missed optimization for dead code elimination at -O3 (vs. -O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99835 --- Comment #3 from Richard Biener --- (In reply to Jan Hubicka from comment #2) > > At -O3 the unused 'c' remains. Likely different (recursive?) inlining > > makes us > > process a cgraph cycle in different order and thus fail to elide the output > > of 'c' (it's output first at -O3). > > > > Fixing that would need processing cgraph SCCs with an extra IPA phase in > > main > > optimization so we get a chance to do extra node removal (maybe order > > the cycles so that functions we can elide - aka static ones - are processed > > last). > That would tamper with optimizations that propagate from callee to > caller during late optimization, like IPA register allocation, stack > alignment propagation or late pure/const discovery. But inside a SCC the order is arbitrary anyway. Note I'd only re-order SCCs and keep the postordering the same otherwise. > Honza
[Bug target/99813] [11 Regression] SVE: Invalid assembly at -O3 (multiplier out of range in incb instruction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99813 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c001c194a2f73fb32461b597e91a35f9bbcf4414 commit r11-7924-gc001c194a2f73fb32461b597e91a35f9bbcf4414 Author: Jakub Jelinek Date: Wed Mar 31 10:46:01 2021 +0200 aarch64: Fix up *add3_poly_1 [PR99813] As mentioned in the PR, Uai constraint stands for aarch64_sve_scalar_inc_dec_immediate while Uav for aarch64_sve_addvl_addpl_immediate. Both *add3_aarch64 and *add3_poly_1 patterns use * return aarch64_output_sve_scalar_inc_dec (operands[2]); * return aarch64_output_sve_addvl_addpl (operands[2]); in that order, but the former with Uai,Uav order, while the latter with Uav,Uai instead. This patch swaps the constraints so that they match the output. Co-authored-by: Richard Sandiford 2021-03-31 Jakub Jelinek Richard Sandiford PR target/99813 * config/aarch64/aarch64.md (*add3_poly_1): Swap Uai and Uav constraints on operands[2] and similarly 0 and rk constraints on operands[1] corresponding to that. * g++.target/aarch64/sve/pr99813.C: New test.
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
--- Comment #8 from Martin Liška ---
All right, I vanished the test-case:
$ cat 1.i
inline __attribute__((__always_inline__)) __attribute__((gnu_inline)) void *
memcpy();
void *apply_relocate_add_write = memcpy;
$ touch 2.s
$ cat 3.i
enum { false, true } * __memcpy();
_Bool kasan_check_range();
void *memcpy(void *dest, void *src, long len) {
if (kasan_check_range(len, false, 0) || kasan_check_range(len, true, 0))
return __memcpy(dest, src, len);
}
long LZ4_decompress_generic_dst_restSize;
char LZ4_decompress_generic_dst_lowPrefix;
void LZ4_decompress_generic_dst() {
__builtin_memcpy(LZ4_decompress_generic_dst,
_decompress_generic_dst_lowPrefix,
LZ4_decompress_generic_dst_restSize);
}
$ gcc 1.i -c -flto && gcc 3.i -c -flto -Os -fno-builtin && gcc -r [13].o 2.s
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
warning: incremental linking of LTO and non-LTO objects; using
-flinker-output=nolto-rel which will bypass whole program optimization
3.i: In function ‘LZ4_decompress_generic_dst’:
1.i:2:1: error: inlining failed in call to ‘always_inline’ ‘memcpy’: --param
max-inline-insns-auto limit reached
2 | memcpy();
| ^
3.i:11:3: note: called from here
11 | __builtin_memcpy(LZ4_decompress_generic_dst,
| ^
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug tree-optimization/96974] [10/11 Regression] ICE in vect_get_vector_types_for_stmt compiling for SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974 --- Comment #13 from ktkachov at gcc dot gnu.org --- Fixed now?
[Bug target/99648] [11 regression] gcc.dg/torture/pr71522.c fails starting with r11-165 for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99648
--- Comment #5 from Richard Biener ---
(In reply to seurer from comment #4)
> Which RTL do you want to see?
So with a cross .expand shows we expand from
MEM [(char * {ref-all})] = 4702111234474983680;
MEM [(char * {ref-all})] = MEM [(char
* {ref-all})];
_1 = __builtin_strcmp (, "AAA");
if (_1 != 0)
doing
;; MEM [(char * {ref-all})] = 4702111234474983680;
(insn 5 4 6 (set (reg:SI 121)
(high:SI (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])))
"pr71522.c":20:3 -1
(nil))
(insn 6 5 7 (set (reg/f:SI 120)
(lo_sum:SI (reg:SI 121)
(symbol_ref:SI ("*.LANCHOR0") [flags 0x182]))) "pr71522.c":20:3 -1
(expr_list:REG_EQUAL (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
(nil)))
(insn 7 6 0 (set (reg/v:DF 118 [ d ])
(mem/u/c:DF (reg/f:SI 120) [0 S8 A64])) "pr71522.c":20:3 -1
(expr_list:REG_EQUAL (const_double:DF 2.26163450980389118194580078125e+6
[0x0.8a0a0a0a0a08p+22])
(nil)))
;; MEM [(char * {ref-all})] = MEM
[(char * {ref-all})];
(insn 8 7 0 (set (mem/c:DI (reg/f:SI 112 virtual-stack-vars) [0 MEM [(char * {ref-all})]+0 S8 A64])
(subreg:DI (reg/v:DF 118 [ d ]) 0)) "pr71522.c":21:3 -1
(nil))
that looks OK, but then the assembly I get is
main:
.LFB0:
stwu 1,-32(1)
.LCFI0:
mflr 0
stw 0,36(1)
.LCFI1:
lis 9,.LANCHOR0@ha
la 4,.LANCHOR0@l(9)
lwz 10,0(4)
lwz 11,4(4)
stw 10,8(1)
stw 11,12(1)
addi 4,4,8
addi 3,1,8
bl strcmp
so no signs of 'lfd'.
How do you configure? What subtarget do you use? Problematic in the above
IL might be the reg-equal note.
[Bug c++/99845] New: gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Bug ID: 99845
Summary: gcc8: Overloaded operator new[](size_t, const
std::nothrow_t&) is seg faulting when the allocation
fails
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: keith.halligan at microfocus dot com
Target Milestone: ---
Created attachment 50490
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50490=edit
Disassembly of the crash
In our code we're facing a crash on gcc (c++) 8. The example program below
demonstrates the crash. The crash seems to come from some incorrect machine
instructions that follow calling operator new[](). The issue occurs when a
new(nothrow) fails to allocate a block of memory, and the 0/null value is then
dereferenced, on the other hand if the allocation succeeds, the memory address
is valid and can be sucessfully dereferenced.
The example code uses a few levels of "operator new[]() - std::nothrow_t
version" before we finally call out to the c++ runtime version of operator
new(size_t, const std::nothrow_t&).
==
// File: new_crash.cpp
#include
#include
#include
class MemAlloc {
public:
MemAlloc() {}
void* operator new[](size_t sz, const std::nothrow_t& nt) {
return ::operator new(sz, nt);
}
};
template
class VarArray : public MemAlloc
{
public:
VarArray() {}
~VarArray(){}
static T*
allocbuf(uint32_t nelems) {
return new(std::nothrow) T[static_cast(nelems)];
}
void* operator new[](size_t sz, const std::nothrow_t& nt) {
return MemAlloc::operator new[](sz, nt);
}
};
class MyType {
public:
void* operator new[](size_t sz, const std::nothrow_t& nt) {
return MemAlloc::operator new[](sz, nt);
}
uint32_t m_id;
VarArray m_int_seq;
};
class MyTypeList : private VarArray
{
public:
using VarArray::allocbuf;
using VarArray::operator new[];
};
int main()
{
const uint32_t max_uint32t = std::numeric_limits::max();
MyType *type_list = MyTypeList::allocbuf(max_uint32t);
if (type_list) {
delete[] type_list;
}
return 0;
}
==
Compiled via: g++ -o m64 -O2 new_crash new_crash.cpp
Disassembly (attached) generated via: objdump -M X86-64 -M att -d -C
--no-show-raw-insn new_crash > new_crash.dis
at -O2 level:
00400650 :
400650: sub$0x8,%rsp
400654: mov$0x600dd8,%esi
400659: movabs $0x8,%rdi
400663: callq 400640
400668: mov$0x,%edx
40066d: mov%rdx,(%rax)
Dereferening $rax leads to seg fault as it contains
a zero value
at -O0 level:
004008dd ::allocbuf(unsigned int)>:
4008dd: push %rbp
4008de: mov%rsp,%rbp
4008e1: push %r13
4008e3: push %r12
4008e5: push %rbx
4008e6: sub$0x18,%rsp
4008ea: mov%edi,-0x24(%rbp)
4008ed: mov-0x24(%rbp),%ebx
4008f0: movabs $0xfff,%rax
4008fa: cmp%rax,%rbx
4008fd: ja 40092c ::allocbuf(unsigned int)+0x4f>
4008ff: lea0x1(%rbx),%rax
400903: shl$0x3,%rax
400907: mov$0x600dd8,%esi
40090c: mov%rax,%rdi
40090f: callq 400878
400914: mov%rax,%r12
400917: mov%rbx,(%r12)
Dereferening $r12, which has a zero value which
originated in $rax
--
Compilation (verbose):
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,lto --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-shared --enable-threads=posix --enable-checking=release
--enable-multilib --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-gcc-major-version-only
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--disable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 8.3.1 20191121 (Red Hat 8.3.1-5) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-m64' '-O2' '-o' 'new_crash'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/8/cc1plus -E -quiet -v -D_GNU_SOURCE
new_crash.cpp -m64 -mtune=generic -march=x86-64 -O2 -fpch-preprocess -o
new_crash.ii
ignoring
[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 --- Comment #21 from Matthias Klose --- building with trunk 20210330 using these parameters didn't succeed: make[1]: Entering directory '/packages/tmp/guymager-0.8.12' g++ -c -pipe -g -O2 -ffile-prefix-map=/packages/tmp/guymager-0.8.12=. -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security --param ggc-min-expand=0 ggc-min-heapsize=0 -fmessage-length=0 -fno-strict-aliasing -flto -g -ffile-prefix-map=/packages/tmp/guymager-0.8.12=. -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security --param ggc-min-expand=0 --param ggc-min-heapsize=0 -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -ggdb -std=gnu++1y -Wall -Wextra -D_REENTRANT -fPIC -DSPLASH_DIR='"/usr/share/guymager"' -DLANGUAGE_DIR='"/usr/share/guymager"' -DLANGUAGE_DIR_QT='"/usr/share/qt5/translations"' -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_DBUS_LIB -DQT_CORE_LIB -I. -I/usr/include/libguytools2 -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtDBus -I/usr/include/x86_64-linux-gnu/qt5/QtCore -Imoc -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ -o aaff.o aaff.cpp g++: warning: ggc-min-heapsize=0: linker input file unused because linking not done g++: error: ggc-min-heapsize=0: linker input file not found: No such file or directory make[1]: *** [Makefile:897: aaff.o] Error 1
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 96974, which changed state. Bug 96974 Summary: [10/11 Regression] ICE in vect_get_vector_types_for_stmt compiling for SVE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/96974] [10/11 Regression] ICE in vect_get_vector_types_for_stmt compiling for SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Richard Biener --- Fixed.
[Bug c++/99790] [8/9 Regression] internal compiler error: in expand_expr_real_2 since r7-3811
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99790 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED Summary|[8/9/10 Regression] |[8/9 Regression] internal |internal compiler error: in |compiler error: in |expand_expr_real_2 since|expand_expr_real_2 since |r7-3811 |r7-3811 --- Comment #8 from Jakub Jelinek --- Fixed for 10.3 too.
[Bug c/99588] variable set but not used warning on static _Atomic assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99588 --- Comment #8 from Jakub Jelinek --- Fixed for 10.3 too.
[Bug c++/99705] [10 Regression] ICE in expand_expr_real_1 since r10-3661
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99705 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed for 10.3 too.
[Bug rtl-optimization/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99830 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
--- Comment #9 from rguenther at suse dot de ---
On Wed, 31 Mar 2021, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
>
> --- Comment #8 from Martin Liška ---
> All right, I vanished the test-case:
>
> $ cat 1.i
> inline __attribute__((__always_inline__)) __attribute__((gnu_inline)) void *
> memcpy();
> void *apply_relocate_add_write = memcpy;
>
> $ touch 2.s
> $ cat 3.i
> enum { false, true } * __memcpy();
?? obviously bad reduction.
> _Bool kasan_check_range();
> void *memcpy(void *dest, void *src, long len) {
> if (kasan_check_range(len, false, 0) || kasan_check_range(len, true, 0))
> return __memcpy(dest, src, len);
> }
>
> long LZ4_decompress_generic_dst_restSize;
> char LZ4_decompress_generic_dst_lowPrefix;
> void LZ4_decompress_generic_dst() {
> __builtin_memcpy(LZ4_decompress_generic_dst,
>_decompress_generic_dst_lowPrefix,
>LZ4_decompress_generic_dst_restSize);
I wonder if this use of __builtin_memcpy intends to not use the
kernels always-inline memcpy but GCCs own inline expansion?
This obviously doesn't work, not with LTO at least.
It looks like with kasan enabled (and memcpy "wrapped") the
memcpy declaration should _not_ have the always-inline (since
the implementation is no longer always-inline). That would be
a fix on the kernel side, but I'd also diagnose any such
always-inline "mismatch" we get to at WPA.
[Bug rtl-optimization/98601] [8/9/10/11 Regression] aarch64: ICE in rtx_addr_can_trap_p_1, at rtlanal.c:467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98601
Alex Coplan changed:
What|Removed |Added
Summary|aarch64: ICE in |[8/9/10/11 Regression]
|rtx_addr_can_trap_p_1, at |aarch64: ICE in
|rtlanal.c:467 |rtx_addr_can_trap_p_1, at
||rtlanal.c:467
Target|aarch64 |arm aarch64
--- Comment #1 from Alex Coplan ---
ICEs started with GCC 8. GCC 7 accepts the code with a warning (warning:
dereferencing 'void *' pointer).
Clearly we should fix the ICE, but I'm wondering whether this code is actually
valid?
clang rejects it with "error: dereference of pointer to incomplete type 'void'"
x86-64 GCC rejects it with:
:3:3: error: invalid use of void expression
3 | asm("" : "=Q"(*b));
| ^~~
:3:3: error: invalid lvalue in 'asm' output 0
We also hit the same ICE with this testcase on AArch32, FWIW.
[Bug testsuite/97680] [11 Regression] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680
--- Comment #14 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0989e99470c2a6797bacf6d04888bc9a46a632a8
commit r11-7922-g0989e99470c2a6797bacf6d04888bc9a46a632a8
Author: Jakub Jelinek
Date: Wed Mar 31 08:55:38 2021 +0200
testsuite: Disable zero-scratch-regs-{8, 9, 10, 11}.c on all but ...
[PR97680]
Seems the target hook is only defined on
config/i386/i386.c:#undef TARGET_ZERO_CALL_USED_REGS
config/i386/i386.c:#define TARGET_ZERO_CALL_USED_REGS
ix86_zero_call_used_regs
config/sparc/sparc.c:#undef TARGET_ZERO_CALL_USED_REGS
config/sparc/sparc.c:#define TARGET_ZERO_CALL_USED_REGS
sparc_zero_call_used_regs
but apparently many of the tests actually succeed on various targets that
don't define those hooks. E.g. I haven't seen them to fail on aarch64,
on arm only the -10.c fails, on powerpc*/s390* all {8,9,10,11} fail (plus
5 is skipped on power*-aix*).
On ia64 according to testresults {6,7,8,9,10,11} fail, some with ICEs.
On mipsel according to testresults {9,10,11} fail, some with ICEs.
On nvptx at least 1-9 succeed, 10-11 don't know, don't have assert.h
around.
I've kept {5,6,7} with aix,ia64,ia64 skipped because those seems like
outliers, it works pretty much everywhere but on those.
The rest have known good targets.
2021-03-31 Jakub Jelinek
PR testsuite/97680
* c-c++-common/zero-scratch-regs-6.c: Skip on ia64.
* c-c++-common/zero-scratch-regs-7.c: Likewise.
* c-c++-common/zero-scratch-regs-8.c: Change from dg-skip-if of
selected unsupported triplets to all targets but selected triplets
of supported targets.
* c-c++-common/zero-scratch-regs-9.c: Likewise.
* c-c++-common/zero-scratch-regs-10.c: Likewise.
* c-c++-common/zero-scratch-regs-11.c: Likewise.
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
--- Comment #7 from Jan Hubicka ---
> Yeah, and then maybe diagnose this "ODR violation". Still
I think we do have this kinds of divergence (like glibcs
fortification), so I am not sure we want to warn by default.
>
> __attribute__((__always_inline__)) void *memcpy();
> void *foo = memcpy;
>
> should be ill-formed (but yeah, maybe this ship has sailed...).
Yep. We took wrong move calling alwys_inline always_inline at the time
it really meant disregard_inline_limits (that is correclty named
internally) and then giving it the semantics of really always inlining.
>
> Now, I do wonder why during cgraph merging we prefer the non-definition
> declaration ... the code "works fine" if it's not memcpy but memcpyx
> (and thus not __builtin_memcpy but also memcpyx).
Hmm, we follow resolution file here and linker doesn't know about the
attributes. I guess disabling merging here is something to do
(it was alwyas on my TODO list but not very high). We eventualy ought
to also support keeping multiple inline bodies for different decls we
decide to not merge that is bit harder to get right.
>
> I also wonder if we can get a better reduction of the kernel problem
> due to all the diagnostics I get:
>
> 1.i:1:42: warning: 'always_inline' function might not be inlinable
> [-Wattribute]
> 1 | __attribute__((__always_inline__)) void *memcpy();
> | ^~
> 3.i:5:1: warning: conflicting types for built-in function 'memcpy'; expected
> 'void *(void *, const void *, long unsigned int)'
> [-Wbuiltin-declaration-mismatch]
> 5 | memcpy(void *dest, void *src, long len) {
> | ^~
> 1.i:1:42: warning: type of 'memcpy' does not match original declaration
> [-Wlto-type-mismatch]
> 1 | __attribute__((__always_inline__)) void *memcpy();
> | ^
Hmm these warnings come from different places but indeed it is bit too
much :)
Honza
[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 --- Comment #24 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:d7145b4bb6c8729a1e782373cb6256c06ed60465 commit r11-7926-gd7145b4bb6c8729a1e782373cb6256c06ed60465 Author: Jan Hubicka Date: Wed Mar 31 11:35:29 2021 +0200 Small refactoring of cgraph_node::release_body PR lto/99447 * cgraph.c (cgraph_node::release_body): Remove all callers and references. * cgraphclones.c (cgraph_node::materialize_clone): Do not do it here. * cgraphunit.c (cgraph_node::expand): And here.
[Bug target/95842] arch_names_table and processor_alias_table should be combined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95842 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:a42a5600c5917541481c3de29a95c1cb169edc6b commit r10-9630-ga42a5600c5917541481c3de29a95c1cb169edc6b Author: H.J. Lu Date: Tue Jun 23 12:49:32 2020 -0700 x86: Fold arch_names_table into processor_alias_table In i386-builtins.c, arch_names_table is used to to map architecture name string to internal model. A switch statement is used to map internal processor name to architecture name string and internal priority. model and priority are added to processor_alias_table so that a single entry contains architecture name string, internal processor name, internal model and internal priority. 6 entries are appended for i386-builtins.c, which have special architecture name strings: amd, amdfam10h, amdfam15h, amdfam17h, shanghai and istanbul, and pta_size is adjusted to exclude them. Entries which are not used by i386-builtins.c have internal model 0. P_PROC_DYNAMIC is added to internal priority to make entries with dynamic architecture name string or priority. PR target/95842 * common/config/i386/i386-common.c (processor_alias_table): Add processor model and priority to each entry. (pta_size): Updated with -6. (num_arch_names): New. * common/config/i386/i386-cpuinfo.h: New file. * config/i386/i386-builtins.c (feature_priority): Removed. (processor_model): Likewise. (_arch_names_table): Likewise. (arch_names_table): Likewise. (_isa_names_table): Replace P_ZERO with P_NONE. (get_builtin_code_for_version): Replace P_ZERO with P_NONE. Use processor_alias_table. (fold_builtin_cpu): Replace arch_names_table with processor_alias_table. * config/i386/i386.h: Include "common/config/i386/i386-cpuinfo.h". (pta): Add model and priority. (num_arch_names): New. (cherry picked from commit 3fb2c2f4d0a43b96e9e4907db952e57a5cbe61ef)
[Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98798 --- Comment #4 from Jonathan Wakely --- Maybe related to Bug 98798 comment 4, where G++ fails to store a cookie when required to. If not related, it's probably worth fixing them together.
[Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #7 from Jonathan Wakely ---
(In reply to Keith Halligan from comment #0)
> class MyType {
> public:
> void* operator new[](size_t sz, const std::nothrow_t& nt) {
Your bug is here. This need to be noexcept.
Passing std::nothrow_t doesn't tell the compiler that this is a nothrow-new,
only making it noexcept does that. So the compiler assumes this will throw on
failure, and so a non-exceptional return is always non-null.
[Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845 --- Comment #8 from Jonathan Wakely --- Alternatively, compile with -fcheck-new to tell the compiler that *all* operator new overloads can return a null pointer. That means it always checks for null, even for overloads that are declared as potentially-throwing. This is probably not what you want to do, you probably just need to use 'noexcept' in the right places.
[Bug c++/98990] [10 Regression] ICE when two overloaded functions return `auto &&` and one accepts an `auto` parameter since r10-6571-ga6ee556c7659877b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98990 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c76d503527394839f9192ee27abbc0626b4e40d8 commit r10-9637-gc76d503527394839f9192ee27abbc0626b4e40d8 Author: Patrick Palka Date: Thu Feb 25 19:55:43 2021 -0500 c++: abbreviated function template return type rewriting [PR98990] When an abbreviated function template has a complex placeholder return type such auto& or auto**, the level adjustment performed by splice_late_return_type directly replaces the 'auto' inside the original return type with the level-adjusted 'auto', but that breaks TYPE_CANONICAL caching. Instead, we should rebuild the entire return type using the adjusted 'auto'. This patch makes this happen by tsubsting the original return type with an argument vector that maps the original 'auto' to the adjusted 'auto'. In passing, this patch also reverts the misguided changes to find_type_usage in r10-6571 that made find_type_usage return a tree* instead of a tree so as to discourage this kind of in-place type modification. It occurred to me that the constraint also needs to be rebuilt so that it refers to the adjusted 'auto', but this oversight doesn't seem to cause any issues at the moment due to how do_auto_deduction "manually" substitutes the 'auto' inside the constraint before performing satisfaction. So this'll be fixed later as part of a rework of placeholder type constraint checking. gcc/cp/ChangeLog: PR c++/98990 * pt.c (splice_late_return_type): Rebuild the entire return type if we have to adjust the level of an auto within. (type_uses_auto): Adjust call to find_type_usage. * type-utils.h (find_type_usage): Revert r10-6571 change that made this function return a pointer to the auto node. gcc/testsuite/ChangeLog: PR c++/98990 * g++.dg/concepts/abbrev8.C: New test. (cherry picked from commit 6bd409cfc83683a9be5c6b3b8f9a3ec8959f9356)
[Bug c++/96531] [10 Regression] ICE for concepts here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96531 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a834e6d59d74ccaefbcbbed5ea7ee25305057853 commit r10-9634-ga834e6d59d74ccaefbcbbed5ea7ee25305057853 Author: Patrick Palka Date: Sat Sep 19 11:02:46 2020 -0400 c++: Fix self-mapping in map_arguments [PR96531, PR97103] With r10-8077 we stopped passing the argified current_template_parms to normalize_constraint_expression from finish_nested_requirement, and instead made map_arguments perform a self-mapping of parameters when args is NULL. But we're currently not handling parameter packs and BOUND_TEMPLATE_TEMPLATE_PARMs properly during this self-mapping, which leads to ICEs later during satisfaction. To properly handle self-mapping of a parameter pack, this patch extends template_parm_to_arg to handle TEMPLATE_PARM_P nodes, and makes map_arguments use it. (This change revealed that the call to template_parm_to_arg in convert_generic_types_to_packs was a no-op because the argument 't' is never a TREE_LIST, so this patch additionally removes this call.) As for bound ttps, map_arguments before r10-8077 would map a BOUND_TEMPLATE_TEMPLATE_PARM not to itself but to its underlying TEMPLATE_TEMPLATE_PARM. We could restore this behavior in map_arguments, but since a bound ttp is not really a template parameter it seems better to make keep_template_parm not give us a bound ttp in the first place. So this patch makes keep_template_parm return the underlying ttp when it sees a bound ttp. gcc/cp/ChangeLog: PR c++/96531 PR c++/97103 * constraint.cc (map_arguments): Call template_parm_to_arg in the self-mapping case. (finish_shorthand_constraint): No need to build a TREE_LIST before calling template_parm_to_arg. * pt.c (template_parm_to_arg): Rewrite to handle TEMPLATE_PARM_P nodes as well as DECL_TEMPLATE_PARM_P nodes, and to make the overlying TREE_LIST node optional. (keep_template_parm): Don't record a BOUND_TEMPLATE_TEMPLATE_PARM, instead record its corresponding TEMPLATE_TEMPLATE_PARM. (convert_generic_types_to_packs): Don't call template_parm_to_arg. gcc/testsuite/ChangeLog: PR c++/96531 PR c++/97103 * g++.dg/cpp2a/concepts-ttp2.C: New test. * g++.dg/cpp2a/concepts-variadic1.C: New test. (cherry picked from commit e5d72c840a226fdbab65912f97d42a1dbdaf6ed2)
[Bug c++/98611] [concepts][10 Regression] ICE in get_underlying_template, at cp/pt.c:6494 since r10-3735-gcb57504a55015891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98611 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:57b0df85b7e4b50198a8d3a09d57c52f0d994ba8 commit r10-9635-g57b0df85b7e4b50198a8d3a09d57c52f0d994ba8 Author: Patrick Palka Date: Tue Jan 12 09:34:41 2021 -0500 c++: Fix ICE with CTAD in concept [PR98611] This patch teaches cp_walk_subtrees to visit the template represented by a CTAD placeholder, which would otherwise be not visited during find_template_parameters. The template may be a template template parameter (as in the first testcase), or it may implicitly use the template parameters of an enclosing class template (as in the second testcase), and in either case we need to visit this tree to record the template parameters used therein for later satisfaction. gcc/cp/ChangeLog: PR c++/98611 * tree.c (cp_walk_subtrees) : Visit the template of a CTAD placeholder. gcc/testsuite/ChangeLog: PR c++/98611 * g++.dg/cpp2a/concepts-ctad1.C: New test. * g++.dg/cpp2a/concepts-ctad2.C: New test. (cherry picked from commit e0bec6ceac47752616dd9fe0801344ed45db2fd3)
[Bug c++/97103] [10 Regression] ICE on nested requires expression template template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97103 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a834e6d59d74ccaefbcbbed5ea7ee25305057853 commit r10-9634-ga834e6d59d74ccaefbcbbed5ea7ee25305057853 Author: Patrick Palka Date: Sat Sep 19 11:02:46 2020 -0400 c++: Fix self-mapping in map_arguments [PR96531, PR97103] With r10-8077 we stopped passing the argified current_template_parms to normalize_constraint_expression from finish_nested_requirement, and instead made map_arguments perform a self-mapping of parameters when args is NULL. But we're currently not handling parameter packs and BOUND_TEMPLATE_TEMPLATE_PARMs properly during this self-mapping, which leads to ICEs later during satisfaction. To properly handle self-mapping of a parameter pack, this patch extends template_parm_to_arg to handle TEMPLATE_PARM_P nodes, and makes map_arguments use it. (This change revealed that the call to template_parm_to_arg in convert_generic_types_to_packs was a no-op because the argument 't' is never a TREE_LIST, so this patch additionally removes this call.) As for bound ttps, map_arguments before r10-8077 would map a BOUND_TEMPLATE_TEMPLATE_PARM not to itself but to its underlying TEMPLATE_TEMPLATE_PARM. We could restore this behavior in map_arguments, but since a bound ttp is not really a template parameter it seems better to make keep_template_parm not give us a bound ttp in the first place. So this patch makes keep_template_parm return the underlying ttp when it sees a bound ttp. gcc/cp/ChangeLog: PR c++/96531 PR c++/97103 * constraint.cc (map_arguments): Call template_parm_to_arg in the self-mapping case. (finish_shorthand_constraint): No need to build a TREE_LIST before calling template_parm_to_arg. * pt.c (template_parm_to_arg): Rewrite to handle TEMPLATE_PARM_P nodes as well as DECL_TEMPLATE_PARM_P nodes, and to make the overlying TREE_LIST node optional. (keep_template_parm): Don't record a BOUND_TEMPLATE_TEMPLATE_PARM, instead record its corresponding TEMPLATE_TEMPLATE_PARM. (convert_generic_types_to_packs): Don't call template_parm_to_arg. gcc/testsuite/ChangeLog: PR c++/96531 PR c++/97103 * g++.dg/cpp2a/concepts-ttp2.C: New test. * g++.dg/cpp2a/concepts-variadic1.C: New test. (cherry picked from commit e5d72c840a226fdbab65912f97d42a1dbdaf6ed2)
[Bug c++/95468] [8/9/10 Regression] ICE in expression sfinae
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95468 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:78e6c55b0d0d2d49f489c581cf8d5a8125b28563 commit r10-9636-g78e6c55b0d0d2d49f489c581cf8d5a8125b28563 Author: Patrick Palka Date: Tue Feb 23 09:40:09 2021 -0500 c++: Fix folding of non-dependent BASELINKs [PR95468] Here, the problem ultimately seems to be that tsubst_copy_and_build, when called with empty args as we do during non-dependent expression folding, doesn't touch BASELINKs at all: it delegates to tsubst_copy which then immediately exits early due to the empty args. This means that the CAST_EXPR int(1) in the BASELINK A::condition never gets folded (as part of folding of the overall CALL_EXPR), which later causes us to crash when performing overload resolution of the rebuilt CALL_EXPR (which is still in terms of this templated BASELINK). This doesn't happen when condition() is a namespace-scope function because then condition is represented by a TEMPLATE_ID_EXPR rather than by a BASELINK, which does get handled directly from tsubst_copy_and_build. This patch fixes this issue by having tsubst_copy_and_build handle BASELINK directly rather than delegating to tsubst_copy, so that it processes BASELINKs even when args is empty. gcc/cp/ChangeLog: PR c++/95468 * pt.c (tsubst_copy_and_build) : New case, copied over from tsubst_copy. gcc/testsuite/ChangeLog: PR c++/95468 * g++.dg/template/non-dependent15.C: New test. (cherry picked from commit 5bd7afb71fca3a5a6e9f8586d86903bae1849193)
[Bug rtl-optimization/98601] [8/9/10/11 Regression] aarch64: ICE in rtx_addr_can_trap_p_1, at rtlanal.c:467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98601
Alex Coplan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2021-03-31
Keywords||ice-on-valid-code
--- Comment #4 from Alex Coplan ---
richi: thanks for the pointers. I agree it looks like this should be valid.
E.g. the very reasonable:
void foo(void *p)
{
asm volatile ("str xzr, %0" : "=Q"(*p));
}
gives:
foo:
str xzr, [x0]
ret
at -O2 on AArch64. (Dropping the volatile in this case reproduce the ICE.)
I bisected the ICE to r8-7484-g532c7a45847f3401e26fa2f07e52613891c80718:
commit 532c7a45847f3401e26fa2f07e52613891c80718
Author: Jakub Jelinek
Date: Fri Mar 23 20:55:40 2018
re PR inline-asm/85022 (internal compiler error: in write_dependence_p, at
alias.c:3003)
PR inline-asm/85022
* emit-rtl.c (init_emit_regs): Indicate that VOIDmode MEMs don't
have
known size by default.
[Bug target/99753] [11 Regression] ICE in ix86_target_macros_internal, at config/i386/i386-c.c:250 since r11-5757-g3e2ae3ee285a5745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99753
--- Comment #3 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jan Hubicka
:
https://gcc.gnu.org/g:f87a08caf42e45162e934c7120a677565149708a
commit r10-9639-gf87a08caf42e45162e934c7120a677565149708a
Author: Martin Liska
Date: Wed Mar 24 15:58:03 2021 +0100
i386: fix -march=amd crash
It started with g:3e2ae3ee285a57455d5a23bd352a68c289130186 where
new entry was added to processor_alias_table after generic node:
+ {"amdfam19h", PROCESSOR_GENERIC, CPU_GENERIC, 0,
+M_CPU_TYPE (AMDFAM19H), P_NONE},
and then the following is violated:
/* NB: processor_alias_table stops at the "generic" entry. */
gcc/ChangeLog:
PR target/99753
* common/config/i386/i386-common.c (ARRAY_SIZE): Fix off-by-one
error.
* config/i386/i386-options.c (ix86_option_override_internal):
Add run-time assert.
gcc/testsuite/ChangeLog:
PR target/99753
* gcc.target/i386/pr99753.c: New test.
(cherry picked from commit 4f00c4d40a539360938607561460904663c64cda)
[Bug rtl-optimization/96264] [10 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #20 from Tamar Christina --- (In reply to Vladimir Makarov from comment #19) > (In reply to Richard Biener from comment #18) > > Please somebody do it quick then (not omitting necessary testing, of > > course). > > I am working on it. It is my highest priority work. The patch is ready. > If the testing is ok (arm64 machines are a bottleneck for me), I'll commit > it today. That should hopefully be resolved soon https://github.com/WorksOnArm/cluster/issues/252
[Bug tree-optimization/97849] [10 Regression] aarch64: ICE (segfault) during GIMPLE pass: ifcvt since r10-3543-gf30b3d28
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97849 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Alex Coplan : https://gcc.gnu.org/g:ad8c55c1df32839cf74704b68a072772b14bd1e2 commit r10-9642-gad8c55c1df32839cf74704b68a072772b14bd1e2 Author: Prathamesh Kulkarni Date: Tue Nov 24 06:50:53 2020 +0530 tree-opt: Fix segfault in tree-if-conv.c with -march=armv8.2-a+sve [PR97849] The issue here is that rpo vn may eliminate target ssa_name referred to in redundant_ssa_names, and thus ifcvt_local_dce may replace candidate ssa_name with invalid ssa_name resulting in incorrect IR. The patch simply does ssa_name replacement before calling do_rpo_vn, which fixes the issue. gcc/ 2020-11-24 Prathamesh Kulkarni PR tree-optimization/97849 * tree-if-conv.c (tree_if_conversion): Move ssa_name replacement code from ifcvt_local_dce to this function before calling do_rpo_vn. gcc/testsuite/ 2020-11-24 Prathamesh Kulkarni PR tree-optimization/97849 * gcc.dg/tree-ssa/pr97849.c: New test.
[Bug ipa/99834] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99834 --- Comment #2 from Zhendong Su --- Hi Richard and all, thanks for analyzing these reports! I have some more cases, and wonder whether you folks would prefer that I open a meta issue report and append these (and others that we find) to that report (rather than filing these one by one). Thanks.
[Bug target/99847] Optimization breaks alignment on CPU32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Component|rtl-optimization|target Last reconfirmed||2021-03-31 --- Comment #1 from Richard Biener --- At least 'odata' is aligned according to your source. Did you try -mstrict-align? It looks like this is not the default.
[Bug target/99847] Optimization breaks alignment on CPU32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847
--- Comment #2 from ⎓ ---
The same thing is with other way around. I.e.:
void ntoh(uint16_t idata, uint8_t *odata) {
odata[0] = idata >> 8;
odata[1] = idata & 0xff;
}
results with:
move.l 8(%sp),%a0
move.w 6(%sp),(%a0)
rts
I've tried with both -mstrict-align and -mno-strict-align and there are no
differences in the produced assembly file (generated with -S).
[Bug target/98601] [8/9/10/11 Regression] aarch64: ICE in rtx_addr_can_trap_p_1, at rtlanal.c:467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98601
Richard Biener changed:
What|Removed |Added
Component|rtl-optimization|target
--- Comment #2 from Richard Biener ---
Note for 'm' constraints (*b) might be preferred over (*(non-void *)b), esp.
if used in address context.
The generic code rejects it on x86_64 here:
#1 0x00a8c37c in build_asm_expr (loc=262658, string=,
outputs=, inputs=, clobbers=,
labels=,
simple=false, is_inline=false) at
/home/rguenther/src/gcc3/gcc/c/c-typeck.c:10669
10669 error_at (loc, "invalid use of void expression");
(gdb) l
10664 output = error_mark_node;
10665 if (!(!allows_reg && allows_mem)
10666 && output != error_mark_node
10667 && VOID_TYPE_P (TREE_TYPE (output)))
10668 {
10669 error_at (loc, "invalid use of void expression");
10670 output = error_mark_node;
but it looks like Q is a memory constraint on arm? If so then I don't see
why it should be invalid.
[Bug lto/99828] inlining failed in call to ‘always_inline’ ‘memcpy’: --param max-inline-insns-auto limit reached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
--- Comment #10 from Martin Liška ---
> ?? obviously bad reduction.
Fixed with:
$ cat 3.i
enum { false, true } * __memcpy();
_Bool kasan_check_range();
void *memcpy(void *dest, void *src, long len) {
if (kasan_check_range(len, false, 0) || kasan_check_range(len, true, 0))
return __memcpy(dest, src, len);
}
char LZ4_decompress_safe_forceExtDict_lowPrefix,
LZ4_decompress_safe_forceExtDict_op;
long LZ4_decompress_safe_forceExtDict_restSize;
void LZ4_decompress_safe_forceExtDict() {
__builtin_memcpy(_decompress_safe_forceExtDict_op,
_decompress_safe_forceExtDict_lowPrefix,
LZ4_decompress_safe_forceExtDict_restSize);
}
$ gcc -r [123].o
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
warning: incremental linking of LTO and non-LTO objects; using
-flinker-output=nolto-rel which will bypass whole program optimization
3.i: In function ‘LZ4_decompress_safe_forceExtDict’:
1.i:2:1: error: inlining failed in call to ‘always_inline’ ‘memcpy’: --param
max-inline-insns-auto limit reached
2 | memcpy();
| ^
3.i:12:3: note: called from here
12 | __builtin_memcpy(_decompress_safe_forceExtDict_op,
| ^
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
error: lto-wrapper failed
[Bug c++/97103] [10 Regression] ICE on nested requires expression template template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97103 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Patrick Palka --- Fixed.
[Bug c++/98990] [10 Regression] ICE when two overloaded functions return `auto &&` and one accepts an `auto` parameter since r10-6571-ga6ee556c7659877b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98990 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Patrick Palka --- Fixed.
[Bug c++/96531] [10 Regression] ICE for concepts here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96531 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Patrick Palka --- fixed.
[Bug fortran/99839] [8/9/10/11 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Btw. started with r6-523-gf1abbf6901a64919.
[Bug target/99813] [11 Regression] SVE: Invalid assembly at -O3 (multiplier out of range in incb instruction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99813 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3753ceff562d8614a94a164b312f389812bd6cd8 commit r10-9641-g3753ceff562d8614a94a164b312f389812bd6cd8 Author: Jakub Jelinek Date: Wed Mar 31 10:46:01 2021 +0200 aarch64: Fix up *add3_poly_1 [PR99813] As mentioned in the PR, Uai constraint stands for aarch64_sve_scalar_inc_dec_immediate while Uav for aarch64_sve_addvl_addpl_immediate. Both *add3_aarch64 and *add3_poly_1 patterns use * return aarch64_output_sve_scalar_inc_dec (operands[2]); * return aarch64_output_sve_addvl_addpl (operands[2]); in that order, but the former with Uai,Uav order, while the latter with Uav,Uai instead. This patch swaps the constraints so that they match the output. Co-authored-by: Richard Sandiford 2021-03-31 Jakub Jelinek Richard Sandiford PR target/99813 * config/aarch64/aarch64.md (*add3_poly_1): Swap Uai and Uav constraints on operands[2] and similarly 0 and rk constraints on operands[1] corresponding to that. * g++.target/aarch64/sve/pr99813.C: New test. (cherry picked from commit c001c194a2f73fb32461b597e91a35f9bbcf4414)
[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227 Bug 99227 depends on bug 99223, which changed state. Bug 99223 Summary: [modules] stdl header-unit ICE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99223 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/99223] [modules] stdl header-unit ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99223 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Marek Polacek --- Closing as a dup then. Thanks. *** This bug has been marked as a duplicate of bug 99241 ***
[Bug c++/99241] [modules] ICE in install_entity, at cp/module.cc:7584
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99241 --- Comment #3 from Marek Polacek --- *** Bug 99223 has been marked as a duplicate of this bug. ***
[Bug target/99786] [11 Regression] ICE in in extract_insn, at recog.c:2770 since r11-4199-g0f41b5e02fa47db2080b77e4e1f7cd3305457c05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99786 Christophe Lyon changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Christophe Lyon --- Fixed
[Bug c++/99445] [11 Regression] ICE in hashtab_chk_error, at hash-table.c:137 since r11-7011-g6e0a231a4aa2407b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99445 --- Comment #8 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a2531859bf5bf6cf1f29c0dca85fd26e80904a5d commit r11-7931-ga2531859bf5bf6cf1f29c0dca85fd26e80904a5d Author: Jason Merrill Date: Tue Mar 30 20:31:18 2021 -0400 c++: Alias template in pack expansion [PR99445] In this testcase, iterative_hash_template_arg checks alias_template_specialization_p to determine whether to treat a type as a dependent alias, and structural_comptypes checks dependent_alias_template_spec_p. Normally that difference isn't a problem because canonicalizing template arguments strips non-dependent aliases, but that wasn't happening for the pack expansion. Fixed thus. gcc/cp/ChangeLog: PR c++/99445 * tree.c (strip_typedefs): Handle TYPE_PACK_EXPANSION. gcc/testsuite/ChangeLog: PR c++/99445 * g++.dg/cpp0x/alias-decl-variadic1.C: New test.
[Bug rtl-optimization/96264] [10 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 --- Comment #19 from Vladimir Makarov --- (In reply to Richard Biener from comment #18) > Please somebody do it quick then (not omitting necessary testing, of course). I am working on it. It is my highest priority work. The patch is ready. If the testing is ok (arm64 machines are a bottleneck for me), I'll commit it today.
[Bug fortran/99840] [9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99840 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Started with r8-4151-g6c6bde30706c29ff.
[Bug c++/99284] [modules] ICE in key_mergeable, at cp/module.cc:10441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99284 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from Marek Polacek --- I also couldn't reproduce anymore.
[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227 Bug 99227 depends on bug 99284, which changed state. Bug 99284 Summary: [modules] ICE in key_mergeable, at cp/module.cc:10441 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99284 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/99792] MVE: Assemble failure with "branch out of range" at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99792 --- Comment #3 from Martin Liška --- (In reply to Alex Coplan from comment #2) > Ok, I'd guess it just exposes a latent backend / rtl-optimization issue then Yes, I would expect the same.
[Bug rtl-optimization/98601] [8/9/10/11 Regression] aarch64: ICE in rtx_addr_can_trap_p_1, at rtlanal.c:467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98601 Alex Coplan changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/98611] [concepts][10 Regression] ICE in get_underlying_template, at cp/pt.c:6494 since r10-3735-gcb57504a55015891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98611 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Patrick Palka --- Fixed.
[Bug target/99792] MVE: Assemble failure with "branch out of range" at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99792 --- Comment #2 from Alex Coplan --- Ok, I'd guess it just exposes a latent backend / rtl-optimization issue then
[Bug rtl-optimization/99847] New: Optimization breaks alignment on CPU32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847
Bug ID: 99847
Summary: Optimization breaks alignment on CPU32
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: m.frohiky at gmail dot com
Target Milestone: ---
For CPU32 architecture optimizes two byte accesses into a single word access,
without any regard that the original array may be unaligned.
So this code:
void ntoh(const uint8_t *idata, uint16_t *odata) {
*odata = ((uint16_t)idata[0] << 8) | idata[1];
}
Compiled with -Os or -O2 produces:
move.l 4(%sp),%a1
move.l 8(%sp),%a0
move.w (%a1),(%a0)
rts
And if idata (address in register a1) is not aligned, the CPU will crash.
The compiler I'm using is m68k-linux-gnu-gcc (g++ has the same problem) which
comes from Debian repository. The exact version is "(Debian 10.2.1-6) 10.2.1
20210110"
Even if it's relying on exception handler to handle the unaligned data it makes
no sense because it's sooo much slower.
[Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
--- Comment #6 from Jonathan Wakely ---
(In reply to Keith Halligan from comment #0)
> class MemAlloc {
> public:
> MemAlloc() {}
> void* operator new[](size_t sz, const std::nothrow_t& nt) {
> return ::operator new(sz, nt);
> }
Why is this function written as an overloaded operator new?
You never use it for new-expressions like `new MemAlloc[n]` so why isn't it
just a normal named member function that allocates memory?
It isn't the cause of the bug, but it is confusing to have this extra operator
new[] involved that is a red herring.
It should probably be something like:
struct MemAlloc {
static void* alloc(size_t sz) {
return ::operator new(sz, std::nothrow);
}
};
and then just call it as a normal static member function:
void* operator new[](size_t sz, const std::nothrow_t&) {
return MemAlloc::alloc(sz);
}
[Bug target/97653] [11 Regression] Incorrect long double calculation with -mabi=ibmlongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653 --- Comment #16 from Jakub Jelinek --- Actually, there is code to handle that already, just with typos and omissions in it. So perhaps better: 2021-03-31 Jakub Jelinek PR target/97653 * config/rs6000/t-linux (IBM128_STATIC_OBJS): Fix spelling, use $(objext) instead of $(object). Use _floatunditf instead of _floatunsditf. Add tf <-> ti conversion objects. --- libgcc/config/rs6000/t-linux.jj 2020-12-04 08:08:06.556434569 +0100 +++ libgcc/config/rs6000/t-linux2021-03-31 14:20:50.953852864 +0200 @@ -11,9 +11,11 @@ HOST_LIBGCC2_CFLAGS += -mno-minimal-toc # the IBM extended double format. Also turn off gnu attributes on the static # modules. IBM128_STATIC_OBJS = ibm-ldouble$(objext) _powitf2$(objext) \ - ppc64-fp$(objext) _divtc3$(object) _multc3$(object) \ - _fixtfdi$(object) _fixunstfdi$(object) \ - _floatditf$(objext) _floatunsditf$(objext) + ppc64-fp$(objext) _divtc3$(objext) _multc3$(objext) \ + _fixtfdi$(objext) _fixunstfdi$(objext) \ + _floatditf$(objext) _floatunditf$(objext) \ + _fixtfti$(objext) _fixunstfti$(objext) \ + _floattitf$(objext) _floatuntitf$(objext) IBM128_SHARED_OBJS = $(IBM128_STATIC_OBJS:$(objext):_s$(objext)) IBM128_OBJS= $(IBM128_STATIC_OBJS) $(IBM128_SHARED_OBJS)
[Bug fortran/99818] [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99818 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Last reconfirmed||2021-03-31 --- Comment #1 from Martin Liška --- Started with r11-7188-gff6903288d96aa1d.
[Bug ipa/99785] Awful lot of time spent building gl.cc in Firefox
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99785 --- Comment #17 from Richard Biener --- (In reply to Jeff Muizelaar from comment #14) > re: __builtin_shuffle vs __builtin_shufflevector - It looks like > __builtin_shuffle doesn't support constructing vectors of a different size > than input type. That's mostly what we're using __builtin_shufflevector for. > __builtin_shufflevector > https://github.com/servo/webrender/blob/master/swgl/src/vector_type.h Indeed that's more powerful that __builtin_shuffle. It would map loosely as to what (vec_select (vec_concat ) ...) on RTL can do but on GIMPLE we don't have a 1:1 match though I've thought of extending it this way at multiple occasions (by extending the existing VEC_PERM_EXPR, basically relaxing the set of valid operands/results). The complication of doing that is always that targets need to be made aware of the possibilities. At least internally I've also pondered allowing a scalar as input serving as single-element vector. > I briefly tried to get the gcc variant of the code compiling with clang but > ran into a number of issues including clang's lack of support for > '__builtin_shuffle'. If you'd like to try, the swgl code is pretty easy to > build locally if you. You should be able to just checkout > https://github.com/servo/webrender/ navigate to the the 'swgl' directory and > run 'cargo build --release' > > re: inlining huge functions - We tried not inlining blend_pixels with clang > and it seems to have a negative impact on a number of benchmarks. Did you report this as an issue to them? That is, leaving auto-inlining to clangs heuristic and those not working?
[Bug tree-optimization/96974] [10/11 Regression] ICE in vect_get_vector_types_for_stmt compiling for SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96974 --- Comment #15 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:05de07136a8c288086def19fa7a6ed817e26c6aa commit r11-7930-g05de07136a8c288086def19fa7a6ed817e26c6aa Author: Christophe Lyon Date: Mon Mar 29 11:36:41 2021 + testsuite/aarch64: Skip SLP diagnostic under ILP32 (PR target/96974) The vectorizer has a very different effect with -mabi=ilp32, and doesn't emit the expecte diagnostic, so this patch expects it only under lp64. 2021-03-29 Christophe Lyon gcc/testsuite/ PR target/96974 * g++.target/aarch64/sve/pr96974.C: Expect SLP diagnostic only under lp64.
[Bug target/99748] MVE: Wrong code at -O0 with float to integer conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99748 Alex Coplan changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org Last reconfirmed||2021-03-31 Status|UNCONFIRMED |ASSIGNED --- Comment #3 from Alex Coplan --- I'm taking a look.
[Bug c++/99848] New: Parameter packs not expanded in type-constraint placeholder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99848
Bug ID: 99848
Summary: Parameter packs not expanded in type-constraint
placeholder
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/hxed4eorx
template
concept C = false;
template
auto f(Ts...) {
([](C auto){}, ...);
}
gcc rejects it.
[Bug target/97653] [11 Regression] Incorrect long double calculation with -mabi=ibmlongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |11.0
Summary|Incorrect long double |[11 Regression] Incorrect
|calculation with|long double calculation
|-mabi=ibmlongdouble |with -mabi=ibmlongdouble
--- Comment #14 from Jakub Jelinek ---
So, what I missed was that my gcc on gccfarm has been configured without the
--with-long-double-format=ieee option, but Jonathan's gcc has been configured
with that option.
When compiling the #c9 testcase with -mabi=ibmlongdouble , both on compiler
that
was configured --with-long-double-format=ieee and on compiler that was
configured without it, gcc emits calls to
__floatunditf
__gcc_qmul
__fixunstfdi
while when compiling the testcase with -mabi=ieeelongdouble , on both compilers
it emits calls to
__floatundikf
__mulkf3
__fixunskfdi
So far so good.
The problem I see is that depending on how gcc has been configured, libgcc
changes.
In gcc configured without --with-long-double-format=ieee , I see
__floatunditf calling __gcc_qadd and __gcc_qmul, so looks that the tf it talks
about is IBM double double aka if.
But looking at __floatunditf on --with-long-double-format=ieee configured gcc,
I see it calls __floatundikf, __mulkf3 and __addkf3. So it looks both like ABI
incompatibility and something else weird going on, because if it was treating
the
tf as kf, why would it call __floatundikf and something on top of that?
Skimming other __*tf* functions in libgcc.a in --with-long-double-format=ieee
configured gcc, __powitf2 calls __gcc_q{mul,div}, so might be ok,
__eprintf calls __fprintfieee128 rather than fprintf from the other gcc,
but maybe it is ok because it passes to fprintf only arguments that are not
floating point.
__fixtfdi calls __lekf2, so looks ABI incompatible, ditto __fixunstfdi,
__floatditf calls __gcc_q{mul,add}, so might be ok, __fixtfti calls __lekf2,
so looks ABI incompatible, ditto __fixunstfti, __floattitf also looks broken,
ditto __floatuntitf.
Ignoring the decimal stuff (_dpd*).
So, if we want backwards ABI compatibility, I'm afraid when building libgcc,
at least the *tf* entry points, they should be built with explicit
-mabi=ibmlongdouble or otherwise ensure it is using IFmode rather than TFmode
stuff.
[Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
--- Comment #5 from Jonathan Wakely ---
Reduced:
namespace std {
using size_t = decltype(sizeof(0));
struct nothrow_t { } const nothrow = { };
}
void* operator new(std::size_t);
void* operator new[](std::size_t);
void operator delete(void*) noexcept;
void operator delete[](void*) noexcept;
void operator delete(void*, std::size_t) noexcept;
void operator delete[](void*, std::size_t) noexcept;
void* operator new(std::size_t, const std::nothrow_t&) noexcept;
void* operator new[](std::size_t, const std::nothrow_t&) noexcept;
void operator delete(void*, const std::nothrow_t&) noexcept;
void operator delete[](void*, const std::nothrow_t&) noexcept;
extern "C" int printf(const char* ...);
using std::size_t;
struct X
{
void* operator new[](size_t sz, const std::nothrow_t& nt) {
return ::operator new(sz, nt);
}
unsigned data = 0;
};
struct Y
{
static X* alloc(unsigned n) { return new(std::nothrow) X[n]; }
};
int main()
{
Y::alloc(-1u);
}
[Bug rtl-optimization/98601] [8/9/10/11 Regression] aarch64: ICE in rtx_addr_can_trap_p_1, at rtlanal.c:467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98601
Richard Biener changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #3 from Richard Biener ---
For some reason we have
(insn 5 9 12 2 (set (mem (reg/v/f:DI 0 x0 [orig:92 b ] [92]) [0 *b_2(D)+0 A8])
(asm_operands ("") ("=Q") 0 []
[]
[] t.c:3)) "t.c":3:3 -1
(expr_list:REG_DEAD (reg/v/f:DI 0 x0 [orig:92 b ] [92])
(nil)))
on x86_64 we get (with a "=m" constraint):
(insn 6 3 12 2 (parallel [
(set (mem (reg:DI 5 di [83]) [0 *b_2(D)+0 A8])
(asm_operands ("") ("=m") 0 []
[]
[] t.c:2))
(clobber (reg:CC 17 flags))
]) "t.c":2:3 -1
(expr_list:REG_DEAD (reg:DI 5 di [83])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
I suppose we could special-case the VOIDmode/unknown-size and make it
possibly trapping (conservatively so). I'm sure rejecting the code
will break existing code.
That said, I can't reproduce on x86_64. Target independent testcase
(still ICEs on aarch64):
void a(void *b) {
asm("" : "=m"(*b));
}
[Bug target/97653] [11 Regression] Incorrect long double calculation with -mabi=ibmlongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653 --- Comment #15 from Jakub Jelinek --- So, just completely untested possibility: --- libgcc/config/rs6000/t-float128.jj 2021-03-30 18:11:52.572091848 +0200 +++ libgcc/config/rs6000/t-float128 2021-03-31 13:55:47.199756547 +0200 @@ -90,8 +90,16 @@ ibm128_dec_objs = $(addsuffix $(objext) FP128_CFLAGS_DECIMAL = -mno-gnu-attribute -Wno-psabi -mabi=ieeelongdouble IBM128_CFLAGS_DECIMAL = -mno-gnu-attribute -Wno-psabi -mabi=ibmlongdouble +ibm128_siditi_tf_funcs = \ + $(foreach f,$(sifuncs) $(difuncs) $(tifuncs),$(if $(findstring tf,$f),$f)) +ibm128_siditi_tf_objs = $(patsubst %,%$(objext),$(ibm128_siditi_tf_funcs)) +ifeq ($(enable_shared),yes) +ibm128_siditi_tf_objs += $(patsubst %,%_s$(objext),$(ibm128_siditi_tf_funcs)) +endif + $(fp128_dec_objs) : INTERNAL_CFLAGS += $(FP128_CFLAGS_DECIMAL) $(ibm128_dec_objs) : INTERNAL_CFLAGS += $(IBM128_CFLAGS_DECIMAL) +$(ibm128_siditi_tf_objs) : INTERNAL_CFLAGS += $(IBM128_CFLAGS_DECIMAL) $(fp128_softfp_src) : $(srcdir)/soft-fp/$(subst -sw,,$(subst kf,tf,$@)) $(fp128_dep) @src="$(srcdir)/soft-fp/$(subst -sw,,$(subst kf,tf,$@))"; \ (though IBM128_CFLAGS_DECIMAL is misnamed for those because it has nothing to do with decimal).
[Bug fortran/99818] [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99818 --- Comment #2 from Paul Thomas --- (In reply to Martin Liška from comment #1) > Started with r11-7188-gff6903288d96aa1d. Thanks, Gerhard and Martin. Have you ever tried to put a tent up in a storm? Sometimes maintaining gfortran feels just like that :-) Paul
