[Bug debug/109591] Multiple -fdebug-prefix-map= prefixes match, which one wins?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591 --- Comment #3 from Fangrui Song --- (In reply to Andrew Pinski from comment #2) > GCC added -fdebug-prefix-map= back in r0-82686-gc8aea42ce2c691e4e8 2 years > before clang was first release . So Thank you for the super rapid response! I have created https://reviews.llvm.org/D148975 to change Clang to follow GCC's lead. There is an opinion that is different, though: > For me long matching prefix makes more sense, but if the same prefix is used > multiple times, the last option should win.
[Bug c++/108179] [11/12 regression] ICE related to template template parameters in tsubst, at cp/pt.cc:15782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108179 --- Comment #7 from Jason Merrill --- (In reply to stu t from comment #6) > Thank you for looking into this! :) You're welcome! I'm currently leaning toward backporting this to 12.4 rather than 12.3, but am interested in your thoughts.
[Bug c++/107163] [10/11 Regression] huge Compile time increase when using templated base classes, virtual method, and Wall since r10-2823-g6a07489267e55084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107163 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:9ab083eb8a96b7f8baf6fe632d03aa496017e456 commit r11-10647-g9ab083eb8a96b7f8baf6fe632d03aa496017e456 Author: Jason Merrill Date: Thu Mar 23 15:57:39 2023 -0400 c-family: -Wsequence-point and COMPONENT_REF [PR107163] The patch for PR91415 fixed -Wsequence-point to treat shifts and ARRAY_REF as sequenced in C++17, and COMPONENT_REF as well. But this is unnecessary for COMPONENT_REF, since the RHS is just a FIELD_DECL with no actual evaluation, and in this testcase handling COMPONENT_REF as sequenced blows up fast in a deep inheritance tree. Instead, look through it. PR c++/107163 gcc/c-family/ChangeLog: * c-common.c (verify_tree): Don't use sequenced handling for COMPONENT_REF. gcc/testsuite/ChangeLog: * g++.dg/warn/Wsequence-point-5.C: New test.
[Bug c++/105996] [10/11 Regression] reinterpret_cast in constexpr failure creating a pair with a function pointer of class parent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105996 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b6c8048cdd2c1e523f663f248ba39caed5af90e7 commit r11-10646-gb6c8048cdd2c1e523f663f248ba39caed5af90e7 Author: Jason Merrill Date: Thu Mar 23 16:50:09 2023 -0400 c++: constexpr PMF conversion [PR105996] Here, we were calling build_reinterpret_cast regardless of whether there was actually a cast, and that now sets REINTERPRET_CAST_P. But that optimization seems dodgy anyway, as it involves NOP_EXPR from one RECORD_TYPE to another and we try to reserve NOP_EXPR for fundamental types. And the generated code seems the same, so let's drop it. And also strip location wrappers. PR c++/105996 gcc/cp/ChangeLog: * typeck.c (build_ptrmemfunc): Drop 0-offset optimization and location wrappers. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-pmf3.C: New test.
[Bug c++/108975] [10/11 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 --- Comment #16 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:51738bb097444dd3ca7adcfa28ae8dcff5a14c50 commit r11-10645-g51738bb097444dd3ca7adcfa28ae8dcff5a14c50 Author: Jason Merrill Date: Fri Mar 17 17:26:40 2023 -0400 c++: constant, array, lambda, template [PR108975] When a lambda refers to a constant local variable in the enclosing scope, we tentatively capture it, but if we end up pulling out its constant value, we go back at the end of the lambda and prune any unneeded captures. Here while parsing the template we decided that the dim capture was unneeded, because we folded it away, but then we brought back the use in the template trees that try to preserve the source representation with added type info. So then when we tried to instantiate that use, we couldn't find what it was trying to use, and crashed. Fixed by not trying to prune when parsing a template; we'll prune at instantiation time. PR c++/108975 gcc/cp/ChangeLog: * lambda.c (prune_lambda_captures): Don't bother in a template. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-const11.C: New test.
[Bug c++/101869] [10/11 Regression] ::enumvalue is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101869 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:691e385b354482f3379bba471774873ca7179b79 commit r11-10643-g691e385b354482f3379bba471774873ca7179b79 Author: Jason Merrill Date: Thu Mar 16 13:11:32 2023 -0400 c++: ::enumerator [PR101869] We don't want to call build_offset_ref with an enum. PR c++/101869 gcc/cp/ChangeLog: * semantics.c (finish_qualified_id_expr): Don't try to build a pointer-to-member if the scope is an enumeration. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/enum43.C: New test.
[Bug c++/105406] [11 Regression] coroutines: since 11.3 co_await attempts to copy a move-only value when await_transform(T &) exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105406 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:657fb0db2648a8cd7ba355fdec570fe2f08448ac commit r11-10642-g657fb0db2648a8cd7ba355fdec570fe2f08448ac Author: Jason Merrill Date: Wed Mar 15 17:02:15 2023 -0400 c++: co_await and move-only type [PR105406] Here we were building a temporary MoveOnlyAwaitable to hold the result of evaluating 'o', but since 'o' is an lvalue we should build a reference instead. PR c++/105406 gcc/cp/ChangeLog: * coroutines.cc (build_co_await): Handle lvalue 'o'. gcc/testsuite/ChangeLog: * g++.dg/coroutines/co-await-moveonly1.C: New test.
[Bug c++/69410] [10/11 Regression] friend declarations in local classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69410 --- Comment #15 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:fbf72bbaed4477f1e3881a8d25977dd3890015eb commit r11-10644-gfbf72bbaed4477f1e3881a8d25977dd3890015eb Author: Jason Merrill Date: Fri Mar 17 09:43:48 2023 -0400 c++: namespace-scoped friend in local class [PR69410] do_friend was only considering class-qualified identifiers for the qualified-id case, but we also need to skip local scope when there's an explicit namespace scope. PR c++/69410 gcc/cp/ChangeLog: * friend.c (do_friend): Handle namespace as scope argument. * decl.c (grokdeclarator): Pass down in_namespace. gcc/testsuite/ChangeLog: * g++.dg/lookup/friend24.C: New test.
[Bug c++/98056] coroutines: ICE tree check: expected record_type or union_type or qual_union_type, have array_type since r11-2183-g0f66b8486cea8668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056 --- Comment #24 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:998e77e55126269b3e67b2f05f0f27a421839673 commit r11-10641-g998e77e55126269b3e67b2f05f0f27a421839673 Author: Jason Merrill Date: Wed Mar 15 16:33:37 2023 -0400 c++: co_await and initializer_list [PR103871] When flatten_await_stmt processes the backing array for an initializer_list, we call cp_build_modify_expr to initialize the promoted variable from the TARGET_EXPR; that needs to be accepted. PR c++/103871 PR c++/98056 gcc/cp/ChangeLog: * typeck.c (cp_build_modify_expr): Allow array initialization of DECL_ARTIFICIAL variable. gcc/testsuite/ChangeLog: * g++.dg/coroutines/co-await-initlist1.C: New test.
[Bug c++/103871] [11 Regression] coroutines: co_await causes build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103871 --- Comment #21 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:998e77e55126269b3e67b2f05f0f27a421839673 commit r11-10641-g998e77e55126269b3e67b2f05f0f27a421839673 Author: Jason Merrill Date: Wed Mar 15 16:33:37 2023 -0400 c++: co_await and initializer_list [PR103871] When flatten_await_stmt processes the backing array for an initializer_list, we call cp_build_modify_expr to initialize the promoted variable from the TARGET_EXPR; that needs to be accepted. PR c++/103871 PR c++/98056 gcc/cp/ChangeLog: * typeck.c (cp_build_modify_expr): Allow array initialization of DECL_ARTIFICIAL variable. gcc/testsuite/ChangeLog: * g++.dg/coroutines/co-await-initlist1.C: New test.
[Bug c++/108468] [11 Regression] ICE in most_specialized_partial_spec/builtin_guide_p in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108468 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:469881efc4ad365dce3db26dab7d33f95d36f92f commit r11-10640-g469881efc4ad365dce3db26dab7d33f95d36f92f Author: Jason Merrill Date: Tue Mar 14 16:32:31 2023 -0400 c++: variable tmpl partial specialization [PR108468] Generally we expect TPARMS_PRIMARY_TEMPLATE to be set, but sometimes it isn't for partial instantiations. This ought to be improved, but it's trivial to work around it in this case. PR c++/108468 gcc/cp/ChangeLog: * pt.c (unify_pack_expansion): Check that TPARMS_PRIMARY_TEMPLATE is non-null. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/var-templ78.C: New test.
[Bug tree-optimization/106888] [RISCV] Negative optimization that excess andi instructions are generated in gcc.dg/pr90838.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888 --- Comment #10 from Jeffrey A. Law --- The sign_extend later gets turned into zero_extend. Presumably because we know the value is never negative. That in and of itself wouldn't be a big deal as it should be easily recognizable using any_extend. But combine steps in and scrambles the RTL in various unhelpful ways.
[Bug rtl-optimization/109592] New: Failure to recognize shifts as sign/zero extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592
Bug ID: 109592
Summary: Failure to recognize shifts as sign/zero extension
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
Target Milestone: ---
This is a trivial sign extension:
int sextb32(int x)
{ return (x << 24) >> 24; }
Yet on RV64 with ZBB enabled we get:
sextb32:
slliw a0,a0,24# 6 [c=4 l=4] ashlsi3
sraiw a0,a0,24# 13[c=8 l=4] *ashrsi3_extend
ret # 21[c=0 l=4] simple_return
We actually get a good form to optimize in simplify_binary_operation_1:
> #0 simplify_context::simplify_binary_operation (this=0x7fffda68,
> code=ASHIFTRT, mode=E_SImode, op0=0x7fffea11eb40, op1=0x7fffea009610) at
> /home/jlaw/riscv-persist/ventana/gcc/gcc/simplify-rtx.cc:2558
> 2558 gcc_assert (GET_RTX_CLASS (code) != RTX_COMPARE);
> (gdb) p code
> $24 = ASHIFTRT
> (gdb) p mode
> $25 = E_SImode
> (gdb) p debug_rtx (op0)
> (ashift:SI (subreg/s/u:SI (reg/v:DI 74 [ x ]) 0)
> (const_int 24 [0x18]))
> $26 = void
> (gdb) p debug_rtx (op1)
> (const_int 24 [0x18])
> $27 = void
So that's (ashiftrt (ashift (object) 24) 24), ie sign extension.
I suspect if we fix simplify_binary_operation_1 then we'll see this get
simplified by fwprop. I also suspect we could construct a zero extension
variant.
[Bug tree-optimization/106888] [RISCV] Negative optimization that excess andi instructions are generated in gcc.dg/pr90838.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888 --- Comment #9 from Vineet Gupta --- (In reply to Jeffrey A. Law from comment #6) > Comment on attachment 54905 [details] > proposed patch > > So that's a subset of what we've done. We initially thought that was going > to be enough to solve this class of problems. But it's actually deeper > than just having a zero_extension variant of this pattern. Yeah it seems adding a new define_insn with zero_extend is not enough (nor is the more elegant any_extend to existing "*disi2") Thing is at expand time, we have gimple CTZ expand to ctz+sign_extend, so adding zero_extend won't really help ? (insn 6 3 7 2 (set (reg:SI 74) (ctz:SI (subreg/s/u:SI (reg/v:DI 73 [ x ]) 0))) "pr90838-red.c":11:15 -1 (nil)) (insn 7 6 8 2 (set (reg:DI 72 [ ]) (sign_extend:DI (reg:SI 74))) "pr90838-red.c":11:15 -1 (nil)) > I'll officially submit the zero_extension pattern and the match.pd bits. > The other pattern we wrote is fugly and I'd like to look at it one more time. But that other pattern is needed for combine to fuse them together.
[Bug analyzer/109580] #pragma GCC diagnostic ignored "-Wanalyzer-fd-leak" is ineffective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109580
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2023-04-21
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from David Malcolm ---
Thanks for filing this bug report.
Here's a reduced version of the reproducer (needs -O2 -fanalyzer):
#pragma GCC diagnostic ignored "-Wanalyzer-fd-leak"
int daemon_type;
static int daemon_pipe[2];
void Fdaemon_initialized(void) {
_Bool err = 0;
if (daemon_type == 2) {
int nfd;
nfd = emacs_open_noquit("/dev/null", 02, 0);
err |= nfd < 0;
err |= dup2(nfd, 0) < 0;
err |= dup2(nfd, 1) < 0;
err |= dup2(nfd, 2) < 0;
err |= emacs_close(nfd) != 0;
err |= write(daemon_pipe[1], "\n", 1) < 0;
err |= emacs_close(daemon_pipe[1]) != 0;
}
daemon_type = -daemon_type;
if (err)
error("I/O error during daemon initialization");
}
https://godbolt.org/z/o6PxhjEvq
[Bug debug/109591] Multiple -fdebug-prefix-map= prefixes match, which one wins?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591 --- Comment #2 from Andrew Pinski --- GCC added -fdebug-prefix-map= back in r0-82686-gc8aea42ce2c691e4e8 2 years before clang was first release . So
[Bug debug/109591] Multiple -fdebug-prefix-map= prefixes match, which one wins?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591 --- Comment #1 from Andrew Pinski --- >When multiple -fdebug-prefix-map= options are applicable, it seems that the >last wins. Right, that is the standard way all options in GCC works.
[Bug debug/109591] New: Multiple -fdebug-prefix-map= prefixes match, which one wins?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591
Bug ID: 109591
Summary: Multiple -fdebug-prefix-map= prefixes match, which one
wins?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: i at maskray dot me
Target Milestone: ---
mkdir -p a/b/c
echo 'int main(){}' > a/b/c/d.c
~/Dev/gcc/out/release/gcc/xgcc -B ~/Dev/gcc/out/release/gcc -g -c
-fdebug-prefix-map=a/b/c=z -fdebug-prefix-map=a/b=y -fdebug-prefix-map=a=x
a/b/c/d.c
objdump -Wi d.o | grep 'd\.c' # <12> DW_AT_name: (indirect line
string, offset: 0): x/b/c/d.c
~/Dev/gcc/out/release/gcc/xgcc -B ~/Dev/gcc/out/release/gcc -g -c
-fdebug-prefix-map=a=x -fdebug-prefix-map=a/b=y -fdebug-prefix-map=a/b/c=z
a/b/c/d.c
objdump -Wi d.o | grep 'd\.c' # <12> DW_AT_name: (indirect line
string, offset: 0): z/d.c
return
When multiple -fdebug-prefix-map= options are applicable, it seems that the
last wins.
In Clang, after https://reviews.llvm.org/D49466 (landed in Nov 2019), the
longest prefix wins.
clang -g -c -fdebug-prefix-map=a=x -fdebug-prefix-map=a/b=y
-fdebug-prefix-map=a/b/c=z a/b/c/d.c # z/d.c
clang -g -c -fdebug-prefix-map=a=x -fdebug-prefix-map=a/b=y
-fdebug-prefix-map=a/b/c=z a/b/c/d.c # z/d.c
This issue is motivated by https://reviews.llvm.org/D148757
---
Related, there is a strange use case where the old prefix is empty. The new
prefix may or may not end with a slash: '-fdebug-prefix-map==w' and
'-fdebug-prefix-map==w/'.
'-fdebug-prefix-map==w' changes the file name to wa/b/c/d.c . I am unsure
whether it should be w/a/b/c/d.c instead. Clang has the same problem.
[Bug tree-optimization/106888] [RISCV] Negative optimization that excess andi instructions are generated in gcc.dg/pr90838.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888 --- Comment #8 from Jeffrey A. Law --- So coming back to this after a couple months, I'm confident the match.pd change is unnecessary and in fact wrong. So we definitely want to set that aside.
[Bug fortran/109575] Implement runtime check for valid function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109575
--- Comment #3 from Steve Kargl ---
On Fri, Apr 21, 2023 at 08:24:45PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109575
>
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> I have some idea how (and where) the runtime checks need to be implemented,
> but I am confused by the following observations on the occurence of an
> explicit RETURN statement and the use of a RESULT variable:
>
> __attribute__((fn spec (". ")))
> integer(kind=4) q2 ()
> {
> integer(kind=4) f;
>
> f = 2;
> return f;
> }
>
>
> __attribute__((fn spec (". ")))
> integer(kind=4) g ()
> {
> integer(kind=4) __result_g;
>
> return __result_g;
> return __result_g;
> }
>
So, if I follow you correctly, you're worried by about
the two 'return __result_g' versus the one 'return f'?
Dead code elimination likely removes the second
'return __result_g'. It indeed seems odd!
[Bug tree-optimization/106888] [RISCV] Negative optimization that excess andi instructions are generated in gcc.dg/pr90838.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888 --- Comment #7 from Vineet Gupta --- (In reply to Roger Sayle from comment #5) > Created attachment 54905 [details] > proposed patch > > This patch should fix this problem, by adding another pattern the machine > description to also recognize zero_extend of clz/ctz/pcnt, matching the > current pattern that only matches sign_extend. Clearly for SI operands, the > result must always be 0..32, so sign extension and zero extension are > equivalent, and the zero extension is perhaps (now) the preferred canonical > form. Thx for the patch Roger, but as Jeff noted, it alone is not enough and generates same extra ANDI. Would you have expected combine to recog() the new pattern ?
[Bug tree-optimization/109590] array-bounds does not warn about address 0x0 dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109590 --- Comment #2 from Jonny Grant --- (In reply to Andrew Pinski from comment #1) > There is -Wnull-dereference for this ... I agree. I set that -Wnull-dereference in usual projects (it doesn't seem to get enabled by -Wall -Wextra) I just expected -Warray-bounds to get the 0x0 address too
[Bug c++/109590] array-bounds does not warn about address 0x0 dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109590 --- Comment #1 from Andrew Pinski --- There is -Wnull-dereference for this ...
[Bug c++/109590] New: array-bounds does not warn about address 0x0 dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109590
Bug ID: 109590
Summary: array-bounds does not warn about address 0x0
dereference
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
Could -Warray-bounds give a warning when a buffer is at address 0x0 like it
does when buffers are at addresses under 0x1000 ? example below.
int main()
{
const char * n = nullptr;
const char * p = reinterpret_cast(0x100);
return *n + *p;
}
https://godbolt.org/z/n6ffhfEn9
: In function 'int main()':
:7:17: warning: array subscript 0 is outside array bounds of 'const
char [0]' [-Warray-bounds=]
7 | return *n + *p;
| ^~
cc1plus: note: source object is likely at address zero
Compiler returned: 0
I know the --param=min-pagesize default is 0x1000 so I had expected the warning
to occur on 0x0 as well as 0x100 in this example
[Bug c++/108795] [10/11/12 Regression] ICE in prep_operand, at cp/call.cc:6325 since r7-2549-gf3365c1201908df5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108795 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:1c1a9a0b60a9a182bcff79084e5ac367a6329bc2 commit r12-9463-g1c1a9a0b60a9a182bcff79084e5ac367a6329bc2 Author: Jason Merrill Date: Tue Mar 21 15:15:27 2023 -0400 c++: attribute on dtor in template [PR108795] Since r7-2549 we were throwing away the explicit C:: when we found that ~C has an attribute that we treat as making its type dependent. PR c++/108795 gcc/cp/ChangeLog: * semantics.cc (finish_id_expression_1): Check scope before returning id_expression. gcc/testsuite/ChangeLog: * g++.dg/ext/attr-tsafe1.C: New test.
[Bug tree-optimization/109546] [13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-3596-ge7310e24b1c0ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109546 --- Comment #5 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:f828503eeb79ad1f1ada6db7deccc5abcc2f3ca3 commit r14-160-gf828503eeb79ad1f1ada6db7deccc5abcc2f3ca3 Author: Andrew MacLeod Date: Fri Apr 21 15:03:43 2023 -0400 Do not fold ADDR_EXPR conditions leading to builtin_unreachable early. Ranges can not represent globally yet, so we cannot fold these expressions early or we lose the __builtin_unreachable information. PR tree-optimization/109546 gcc/ * tree-vrp.cc (remove_unreachable::remove_and_update_globals): Do not fold conditions with ADDR_EXPR early. gcc/testsuite/ * gcc.dg/pr109546.c: New.
[Bug c++/107163] [10/11 Regression] huge Compile time increase when using templated base classes, virtual method, and Wall since r10-2823-g6a07489267e55084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107163 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:e81e393cd864abcd2de02602bd51e435dc28f418 commit r10-11307-ge81e393cd864abcd2de02602bd51e435dc28f418 Author: Jason Merrill Date: Thu Mar 23 15:57:39 2023 -0400 c-family: -Wsequence-point and COMPONENT_REF [PR107163] The patch for PR91415 fixed -Wsequence-point to treat shifts and ARRAY_REF as sequenced in C++17, and COMPONENT_REF as well. But this is unnecessary for COMPONENT_REF, since the RHS is just a FIELD_DECL with no actual evaluation, and in this testcase handling COMPONENT_REF as sequenced blows up fast in a deep inheritance tree. Instead, look through it. PR c++/107163 gcc/c-family/ChangeLog: * c-common.c (verify_tree): Don't use sequenced handling for COMPONENT_REF. gcc/testsuite/ChangeLog: * g++.dg/warn/Wsequence-point-5.C: New test.
[Bug c++/108975] [10/11 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 --- Comment #15 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:92e2bb31ffe25271e5ae70d7533469419b883864 commit r10-11305-g92e2bb31ffe25271e5ae70d7533469419b883864 Author: Jason Merrill Date: Fri Mar 17 17:26:40 2023 -0400 c++: constant, array, lambda, template [PR108975] When a lambda refers to a constant local variable in the enclosing scope, we tentatively capture it, but if we end up pulling out its constant value, we go back at the end of the lambda and prune any unneeded captures. Here while parsing the template we decided that the dim capture was unneeded, because we folded it away, but then we brought back the use in the template trees that try to preserve the source representation with added type info. So then when we tried to instantiate that use, we couldn't find what it was trying to use, and crashed. Fixed by not trying to prune when parsing a template; we'll prune at instantiation time. PR c++/108975 gcc/cp/ChangeLog: * lambda.c (prune_lambda_captures): Don't bother in a template. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-const11.C: New test.
[Bug c++/105996] [10/11 Regression] reinterpret_cast in constexpr failure creating a pair with a function pointer of class parent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105996 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:da17a9049ee0a8ca9f93edf137df92e824a7593e commit r10-11306-gda17a9049ee0a8ca9f93edf137df92e824a7593e Author: Jason Merrill Date: Thu Mar 23 16:50:09 2023 -0400 c++: constexpr PMF conversion [PR105996] Here, we were calling build_reinterpret_cast regardless of whether there was actually a cast, and that now sets REINTERPRET_CAST_P. But that optimization seems dodgy anyway, as it involves NOP_EXPR from one RECORD_TYPE to another and we try to reserve NOP_EXPR for fundamental types. And the generated code seems the same, so let's drop it. And also strip location wrappers. PR c++/105996 gcc/cp/ChangeLog: * typeck.c (build_ptrmemfunc): Drop 0-offset optimization and location wrappers. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-pmf3.C: New test.
[Bug c++/69410] [10/11 Regression] friend declarations in local classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69410 --- Comment #14 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:fc03893d2fead133ed336511ac00d75c10c5a88d commit r10-11304-gfc03893d2fead133ed336511ac00d75c10c5a88d Author: Jason Merrill Date: Fri Mar 17 09:43:48 2023 -0400 c++: namespace-scoped friend in local class [PR69410] do_friend was only considering class-qualified identifiers for the qualified-id case, but we also need to skip local scope when there's an explicit namespace scope. PR c++/69410 gcc/cp/ChangeLog: * friend.c (do_friend): Handle namespace as scope argument. * decl.c (grokdeclarator): Pass down in_namespace. gcc/testsuite/ChangeLog: * g++.dg/lookup/friend24.C: New test.
[Bug c++/101869] [10/11 Regression] ::enumvalue is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101869 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6f7f90113bc78440a248bef4b917583fde3e6e5f commit r10-11303-g6f7f90113bc78440a248bef4b917583fde3e6e5f Author: Jason Merrill Date: Thu Mar 16 13:11:32 2023 -0400 c++: ::enumerator [PR101869] We don't want to call build_offset_ref with an enum. PR c++/101869 gcc/cp/ChangeLog: * semantics.c (finish_qualified_id_expr): Don't try to build a pointer-to-member if the scope is an enumeration. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/enum43.C: New test.
[Bug tree-optimization/109587] Deeply nested loop unrolling overwhelms register allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109587 --- Comment #2 from Andrew Pinski --- At -O2 we get: size: 26-3, last_iteration: 2-2 Loop size: 26 Estimated size after unrolling: 245 Not unrolling loop 1: size would grow. With -O3: size: 20-4, last_iteration: 2-2 Loop size: 20 Estimated size after unrolling: 170 /app/example.cpp:8:29: optimized: loop with 16 iterations completely unrolled (header execution count 63136016) Exit condition of peeled iterations was eliminated. Last iteration exit edge was proved true. Forced exit to be taken: if (0 != 0) Well yes -O3 is known to cause issues like this. I had thought it was documented saying that sometimes -O3 might cause performance issues over -O2 but I can't find that documentation either.
[Bug fortran/109575] Implement runtime check for valid function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109575
--- Comment #2 from anlauf at gcc dot gnu.org ---
I have some idea how (and where) the runtime checks need to be implemented,
but I am confused by the following observations on the occurence of an
explicit RETURN statement and the use of a RESULT variable:
function f()
integer :: f
end
function f1()
integer :: f1
f1 = 1
end
function q() result (f)
integer :: f
end
function q2() result (f)
integer :: f
f = 2
end
function g()
integer :: g
return
end
function g3()
integer :: g3
g3 = 3
return
end
function r() result (f)
integer :: f
return
end
function r4() result (f)
integer :: f
f = 4
return
end
While the dump-fortran-original does not show any surprises, the tree-dump
looks somewhat irregular:
__attribute__((fn spec (". ")))
integer(kind=4) f ()
{
(void) 0;
}
__attribute__((fn spec (". ")))
integer(kind=4) f1 ()
{
integer(kind=4) __result_f1;
__result_f1 = 1;
return __result_f1;
}
__attribute__((fn spec (". ")))
integer(kind=4) q ()
{
(void) 0;
}
__attribute__((fn spec (". ")))
integer(kind=4) q2 ()
{
integer(kind=4) f;
f = 2;
return f;
}
__attribute__((fn spec (". ")))
integer(kind=4) g ()
{
integer(kind=4) __result_g;
return __result_g;
return __result_g;
}
__attribute__((fn spec (". ")))
integer(kind=4) g3 ()
{
integer(kind=4) __result_g3;
__result_g3 = 3;
return __result_g3;
return __result_g3;
}
__attribute__((fn spec (". ")))
integer(kind=4) r ()
{
return;
}
__attribute__((fn spec (". ")))
integer(kind=4) r4 ()
{
integer(kind=4) f;
f = 4;
return f;
return f;
}
This seems to correspond to two different paths to gfc_generate_return().
[Bug tree-optimization/109587] Deeply nested loop unrolling overwhelms register allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109587
Andrew Pinski changed:
What|Removed |Added
Keywords|ra |
--- Comment #1 from Andrew Pinski ---
Simplified testcase which shows the issue even on x86:
```
typedef float float32_t;
template
void f(const float32_t *__restrict a, const float32_t *__restrict b, float32_t
*c) {
for (int i = 0; i < N; ++i) {
for (int j=0; j < M; ++j) {
for (int k=0; k < K; ++k) {
c[i*N + j] += a[i*K + k] * b[k*M + j];
}
}
}
}
template void f<16, 16, 16>(const float32_t *__restrict a, const float32_t
*__restrict b, float32_t *c);
```
[Bug tree-optimization/109587] Deeply nested loop unrolling overwhelms register allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109587 Andrew Pinski changed: What|Removed |Added Keywords||ra Severity|normal |enhancement
[Bug c++/106893] [12 Regression] auto deduces wrong type for function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106893 Jason Merrill changed: What|Removed |Added Known to work||12.3.0, 13.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jason Merrill --- Fixed for 12.3/13.
[Bug target/54816] [avr] shift is better than widening mul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54816
--- Comment #6 from Georg-Johann Lay ---
(In reply to Roger Sayle from comment #5)
> This is now fixed on mainline [but was present in GCC 12.2], and a new test
> case added to ensure this stays fixed.
Hi Roger,
I am having a problem with your new test case in gcc.target/avr/pr54816.c :
When we run the testsuite for any device other than ATmega8, it will fail due
to the explicit -mmcu=atmega8 in dg-options:
xgcc: error: specified option '-mmcu' more than once
compiler exited with status 1
FAIL: gcc.target/avr/pr54816.c (test for excess errors)
Usually, one would run the testsuite several times for a variety of different
devices like ATmega128, ATtiny40, etc. so that explicit -mmcu in dg-options is
to be avoided. (The -mmcu will be provided by the board description file like
atmega128-sim.exp).
If a test requires a specific device, then place it at gcc.target/avr/mmcu/.
The avr-mmcu.exp will care to remove unwanted -mmcu to that testcases can set
-mmcu as they wish.
In your case, as you scan assembly for "muls" instruction, you need some -mmcu
that supports MULS (like ATmega8).
Hence, could you move pr54816.c to the gcc.target/avr/mmcu subfolder?
Alternatively, you can extend lib/target-supports.exp by a new feature like
check_effective_target_avr_mul. A new function could be similar to already
existing check_effective_target_avr_tiny, but check for built-in macro
__AVR_HAVE_MUL__. Then use the new functon as a filter like in
/* { dg-do compile { target { avr_mul } } } */
[Bug c++/108099] [12/13/14 Regression] ICE with type alias with `signed __int128_t`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099 --- Comment #26 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:03cebd304955a6b9c5607e09312d77f1307cc98e commit r14-159-g03cebd304955a6b9c5607e09312d77f1307cc98e Author: Jason Merrill Date: Tue Apr 18 21:32:07 2023 -0400 c++: fix 'unsigned typedef-name' extension [PR108099] In the comments for PR108099 Jakub provided some testcases that demonstrated that even before the regression noted in the patch we were getting the semantics of this extension wrong: in the unsigned case we weren't producing the corresponding standard unsigned type but another distinct one of the same size, and in the signed case we were just dropping it on the floor and not actually returning a signed type at all. The former issue is fixed by using c_common_signed_or_unsigned_type instead of unsigned_type_for, and the latter issue by adding a (signed_p && typedef_decl) case. This patch introduces a failure on std/ranges/iota/max_size_type.cc due to the latter issue, since the testcase expects 'signed rep_t' to do something sensible, and previously we didn't. Now that we do, it exposes a bug in the __max_diff_type::operator>>= handling of sign extension: when we evaluate -1000 >> 2 in __max_diff_type we keep the MSB set, but leave the second-most-significant bit cleared. PR c++/108099 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Don't clear typedef_decl after 'unsigned typedef' pedwarn. Use c_common_signed_or_unsigned_type. Also handle 'signed typedef'. gcc/testsuite/ChangeLog: * g++.dg/ext/int128-8.C: Remove xfailed dg-bogus markers. * g++.dg/ext/unsigned-typedef2.C: New test. * g++.dg/ext/unsigned-typedef3.C: New test.
[Bug tree-optimization/109546] [13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-3596-ge7310e24b1c0ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109546 --- Comment #4 from Andrew Macleod --- And I think the first part of this is a duplicate of another PR from GCC12 time (I dont know which one) whereby we are not making staticly initialized values available in main(). so VRP never sees that d == , and can do nothing with the first condition, thus leaving the call to __assert_fail.
[Bug tree-optimization/109546] [13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-3596-ge7310e24b1c0ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109546 --- Comment #3 from Andrew Macleod --- Patch in testing. when deciding to fold condition of builtin_unreachable, VRP is failing to recognize that given if (ptr == ) __builtin_unreachable () is not a representable range, and thus should not be eliminated early even though it satisfies the other criteria. it just sees it as a symbolic value == CONSTANT and thinks its smart enough when it isn't.
[Bug tree-optimization/109588] [13 Regression] Missed Dead Code Elimination when using __builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109588 Andrew Macleod changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Macleod --- This is a result of the same issue, too early removal of if (ptr == ) with builtin_unreachable (). *** This bug has been marked as a duplicate of bug 109546 ***
[Bug tree-optimization/109546] [13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-3596-ge7310e24b1c0ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109546 --- Comment #2 from Andrew Macleod --- *** Bug 109588 has been marked as a duplicate of this bug. ***
[Bug testsuite/109549] [14 Regression] cmov6.c test fail after commit r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549 --- Comment #8 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:f1f18198b069f461155191ecba41bc87bf5689dd commit r14-156-gf1f18198b069f461155191ecba41bc87bf5689dd Author: Jeff Law Date: Fri Apr 21 12:22:24 2023 -0600 Adjust x86 testsuite for recent if-conversion cost checking gcc/testsuite PR testsuite/109549 * gcc.target/i386/cmov6.c: No longer expect this test to generate 'cmov' instructions.
[Bug bootstrap/109589] [14 regression] r14-35-g278f8f567b5470 breaks build with older gcc build compilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109589 --- Comment #2 from Jakub Jelinek --- Untested workaround, going to test it momentarily: 2023-04-21 Jakub Jelinek PR bootstrap/109589 * system.h (class auto_mpz): Workaround PR62101 bug in GCC 4.8 and 4.9. * realmpfr.h (class auto_mpfr): Likewise. --- gcc/system.h.jj 2023-04-20 09:36:09.097375720 +0200 +++ gcc/system.h2023-04-21 20:13:09.212049563 +0200 @@ -714,8 +714,11 @@ public: auto_mpz (const auto_mpz &) = delete; auto_mpz = (const auto_mpz &) = delete; +#if GCC_VERSION < 4008 || GCC_VERSION >= 5000 + /* GCC 4.8 and 4.9 don't support this, only fixed in PR62101 for 5.0. */ friend void mpz_clear (auto_mpz&) = delete; friend void mpz_init (auto_mpz&) = delete; +#endif private: mpz_t m_mpz; --- gcc/realmpfr.h.jj 2023-04-20 09:36:09.066376175 +0200 +++ gcc/realmpfr.h 2023-04-21 20:13:36.191663089 +0200 @@ -37,9 +37,12 @@ public: auto_mpfr (const auto_mpfr &) = delete; auto_mpfr = (const auto_mpfr &) = delete; +#if GCC_VERSION < 4008 || GCC_VERSION >= 5000 + /* GCC 4.8 and 4.9 don't support this, only fixed in PR62101 for 5.0. */ friend void mpfr_clear (auto_mpfr&) = delete; friend void mpfr_init (auto_mpfr&) = delete; friend void mpfr_init2 (auto_mpfr&, mpfr_prec_t) = delete; +#endif private: mpfr_t m_mpfr;
[Bug other/109589] [14 regression] r14-35-g278f8f567b5470 breaks build with older gcc build compilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109589 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Last reconfirmed||2023-04-21 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jakub Jelinek --- I believe the problem is that only since r5-2699-g5d9607f0ee036a aka PR62101 fix we accept those friend void mpz_clear (auto_mpz&) = delete; friend void mpz_init (auto_mpz&) = delete; lines in system.h and realmpfr.h, errors on this break various configure tests and so we end up with e.g. typedef __rlim_t long; because #define rlim_t long. So, either we need to say 4.8.5 and 4.9.x are unsupported, or perhaps could these friend deletions be not done for (GCC_VERSION >= 4008 && GCC_VERSION < 5000)?
[Bug target/108779] AARCH64 should add an option to change TLS register location to support EL1/EL2/EL3 system registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108779 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #10 from ktkachov at gcc dot gnu.org --- Implemented for GCC 14.
[Bug target/108779] AARCH64 should add an option to change TLS register location to support EL1/EL2/EL3 system registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108779 --- Comment #9 from CVS Commits --- The master branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:573624ec90c80d1a024ab405e2575785b869a833 commit r14-154-g573624ec90c80d1a024ab405e2575785b869a833 Author: Kyrylo Tkachov Date: Fri Apr 21 19:00:02 2023 +0100 PR target/108779 aarch64: Implement -mtp= option A user has requested that we support the -mtp= option in aarch64 GCC for changing the TPIDR register to read for TLS accesses. I'm not a big fan of the option name, but we already support it in the arm port and Clang supports it for AArch64 already, where it accepts the 'el0', 'el1', 'el2', 'el3' values. This patch implements the same functionality in GCC. Bootstrapped and tested on aarch64-none-linux-gnu. Confirmed with godbolt that the sequences and options are the same as what Clang accepts/generates. gcc/ChangeLog: PR target/108779 * config/aarch64/aarch64-opts.h (enum aarch64_tp_reg): Define. * config/aarch64/aarch64-protos.h (aarch64_output_load_tp): Define prototype. * config/aarch64/aarch64.cc (aarch64_tpidr_register): Declare. (aarch64_override_options_internal): Handle the above. (aarch64_output_load_tp): New function. * config/aarch64/aarch64.md (aarch64_load_tp_hard): Call aarch64_output_load_tp. * config/aarch64/aarch64.opt (aarch64_tp_reg): Define enum. (mtp=): New option. * doc/invoke.texi (AArch64 Options): Document -mtp=. gcc/testsuite/ChangeLog: PR target/108779 * gcc.target/aarch64/mtp.c: New test. * gcc.target/aarch64/mtp_1.c: New test. * gcc.target/aarch64/mtp_2.c: New test. * gcc.target/aarch64/mtp_3.c: New test. * gcc.target/aarch64/mtp_4.c: New test.
[Bug target/99195] Optimise away vec_concat of 64-bit AdvancedSIMD operations with zeroes in aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99195 --- Comment #3 from CVS Commits --- The master branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:f824216cdb078ea9de0980ae066a0e1e83494fd2 commit r14-153-gf824216cdb078ea9de0980ae066a0e1e83494fd2 Author: Kyrylo Tkachov Date: Fri Apr 21 18:56:21 2023 +0100 aarch64: PR target/99195 Add scheme to optimise away vec_concat with zeroes on 64-bit Advanced SIMD ops I finally got around to trying out the define_subst approach for PR target/99195. The problem we have is that many Advanced SIMD instructions have 64-bit vector variants that clear the top half of the 128-bit Q register. This would allow the compiler to avoid generating explicit zeroing instructions to concat the 64-bit result with zeroes for code like: vcombine_u16(vadd_u16(a, b), vdup_n_u16(0)) We've been getting user reports of GCC missing this optimisation in real world code, so it's worth doing something about it. The straightforward approach that we've been taking so far is adding extra patterns in aarch64-simd.md that match the 64-bit result in a vec_concat with zeroes. Unfortunately for big-endian the vec_concat operands to match have to be the other way around, so we would end up adding two extra define_insns. This would lead to too much bloat in aarch64-simd.md This patch defines a pair of define_subst constructs that allow us to annotate patterns in aarch64-simd.md with the and subst_attrs and the compiler will automatically produce the vec_concat widening patterns, properly gated for BYTES_BIG_ENDIAN when needed. This seems like the least intrusive way to describe the extra zeroing semantics. I've had a look at the generated insn-*.cc files in the build directory and it seems that define_subst does what we want it to do when applied multiple times on a pattern in terms of insn conditions and modes. This patch adds the define_subst machinery and adds the annotations to some of the straightforward binary and unary integer operations. Many more such annotations are possible and I aim add them in future patches if this approach is acceptable. Bootstrapped and tested on aarch64-none-linux-gnu and on aarch64_be-none-elf. gcc/ChangeLog: PR target/99195 * config/aarch64/aarch64-simd.md (add_vec_concat_subst_le): Define. (add_vec_concat_subst_be): Likewise. (vczle): Likewise. (vczbe): Likewise. (add3): Rename to... (add3): ... This. (sub3): Rename to... (sub3): ... This. (mul3): Rename to... (mul3): ... This. (and3): Rename to... (and3): ... This. (ior3): Rename to... (ior3): ... This. (xor3): Rename to... (xor3): ... This. * config/aarch64/iterators.md (VDZ): Define. gcc/testsuite/ChangeLog: PR target/99195 * gcc.target/aarch64/simd/pr99195_1.c: New test.
[Bug other/109589] [14 regression] r14-35-g278f8f567b5470 breaks build with older gcc build compilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109589 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||build
[Bug tree-optimization/106888] [RISCV] Negative optimization that excess andi instructions are generated in gcc.dg/pr90838.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888 --- Comment #6 from Jeffrey A. Law --- Comment on attachment 54905 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54905 proposed patch So that's a subset of what we've done. We initially thought that was going to be enough to solve this class of problems. But it's actually deeper than just having a zero_extension variant of this pattern. I'll officially submit the zero_extension pattern and the match.pd bits. The other pattern we wrote is fugly and I'd like to look at it one more time.
[Bug tree-optimization/106888] [RISCV] Negative optimization that excess andi instructions are generated in gcc.dg/pr90838.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888 --- Comment #5 from Roger Sayle --- Created attachment 54905 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54905=edit proposed patch This patch should fix this problem, by adding another pattern the machine description to also recognize zero_extend of clz/ctz/pcnt, matching the current pattern that only matches sign_extend. Clearly for SI operands, the result must always be 0..32, so sign extension and zero extension are equivalent, and the zero extension is perhaps (now) the preferred canonical form.
[Bug middle-end/109585] Carla/sord miscompiled with -O2 on ARM64 with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585 Andrew Pinski changed: What|Removed |Added Summary|Carla/sord miscompiled with |Carla/sord miscompiled with |-O2 on ARM64 (inlining |-O2 on ARM64 with flexible |issue) |array member --- Comment #12 from Andrew Pinski --- Looks like the aliasing code is getting the flexible array member aliasing wrong. Replacing: ZixBTreeIterFrame stack[]; With: ZixBTreeIterFrame stack[1]; Fixes the issue ...
[Bug middle-end/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585 --- Comment #11 from Hector Martin --- Giving a nonzero size to the `ZixBTreeIterFrame stack[]` member also avoids the segfault, so this might be a flexible array member thing.
[Bug middle-end/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
--- Comment #10 from Andrew Pinski ---
If I change zix_btree_iter_is_end to:
ZIX_API bool
zix_btree_iter_is_end(const struct ZixBTreeIterImpl* const i)
{
if (!i)
return 1;
if (i->stack[0].node == NULL)
return 1;
return 0;
}
Then both the C and C++ front-end generated IR causes the segfault.
[Bug middle-end/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585 --- Comment #9 from Hector Martin --- Yes, a strict aliasing violation could explain the behavior of the optimizer here... but given all the types are identical and there is no casting going on, clearly there is no strict aliasing violation.
[Bug middle-end/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585 --- Comment #8 from Andrew Pinski --- Interesting compiling with the C++ front-end (with one minor change of adding a cast to the malloc) does not seg fault at -O2.
[Bug target/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585 --- Comment #7 from Andrew Pinski --- -fno-strict-aliasing also fixes the issue ...
[Bug target/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585 --- Comment #6 from Hector Martin --- Cleaned it up into a self-contained repro. Simply compiling with `gcc -O2 -o test test.c && test` gives a segfault. -O1 or -fno-schedule-insns -fno-schedule-insns2 avoids the issue. Looking at assembly output on godbolt, it seems this likely goes at least as far back as 11.1 if not earlier.
[Bug target/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585 --- Comment #5 from Hector Martin --- Created attachment 54904 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54904=edit self-contained reproducer
[Bug other/109589] New: [14 regression] r14-35-g278f8f567b5470 breaks build with older gcc build compilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109589 Bug ID: 109589 Summary: [14 regression] r14-35-g278f8f567b5470 breaks build with older gcc build compilers Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:278f8f567b5470e87e2e6482ee385d61c7f45a5d, r14-35-g278f8f567b5470 This update is causing build failures on a couple of our old RHEL 7.9 systems if I use the system compiler. If I use a newer build compiler it works fine. gcc -v gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) Is gcc 4.8.5 no longer suitable for builds? make[2]: Entering directory '/home/seurer/gcc/git/build/gcc-test/gcc' g++ -std=gnu++11 -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/seurer/gcc/git/gcc-test/gcc -I/home/seurer/gcc/git/gcc-test/gcc/build -I/home/seurer/gcc/git/gcc-test/gcc/../include -I/home/seurer/gcc/git/gcc-test/gcc/../libcpp/include \ -o build/genmodes.o /home/seurer/gcc/git/gcc-test/gcc/genmodes.cc In file included from ./bconfig.h:3:0, from /home/seurer/gcc/git/gcc-test/gcc/genmodes.cc:20: ./auto-host.h:2637:16: error: declaration does not declare anything [-fpermissive] #define rlim_t long ^ In file included from /home/seurer/gcc/git/gcc-test/gcc/genmodes.cc:21:0: /home/seurer/gcc/git/gcc-test/gcc/system.h:500:23: error: declaration of C function 'void* sbrk(int)' conflicts with extern void *sbrk (int); ^ In file included from /home/seurer/gcc/git/gcc-test/gcc/system.h:302:0, from /home/seurer/gcc/git/gcc-test/gcc/genmodes.cc:21: /usr/include/unistd.h:1065:14: error: previous declaration 'void* sbrk(intptr_t)' here extern void *sbrk (intptr_t __delta) __THROW; ^ In file included from /home/seurer/gcc/git/gcc-test/gcc/genmodes.cc:21:0: /home/seurer/gcc/git/gcc-test/gcc/system.h:508:48: error: new declaration 'char* strstr(const char*, const char*)' extern char *strstr (const char *, const char *); ^ In file included from /usr/include/c++/4.8.2/cstring:42:0, from /home/seurer/gcc/git/gcc-test/gcc/system.h:241, from /home/seurer/gcc/git/gcc-test/gcc/genmodes.cc:21: /usr/include/string.h:331:1: error: ambiguates old declaration 'const char* strstr(const char*, const char*)' strstr (const char *__haystack, const char *__needle) __THROW ^ In file included from /home/seurer/gcc/git/gcc-test/gcc/genmodes.cc:21:0: /home/seurer/gcc/git/gcc-test/gcc/system.h:556:34: error: declaration of C function 'const char* strsignal(int)' conflicts with extern const char *strsignal (int); ^ In file included from /usr/include/c++/4.8.2/cstring:42:0, from /home/seurer/gcc/git/gcc-test/gcc/system.h:241, from /home/seurer/gcc/git/gcc-test/gcc/genmodes.cc:21: /usr/include/string.h:562:14: error: previous declaration 'char* strsignal(int)' here extern char *strsignal (int __sig) __THROW; ^ In file included from ./bconfig.h:5:0, from /home/seurer/gcc/git/gcc-test/gcc/genmodes.cc:20: /home/seurer/gcc/git/gcc-test/gcc/../include/ansidecl.h:128:64: error: new declaration 'char* basename(const char*)' # define ATTRIBUTE_NONNULL(m) __attribute__ ((__nonnull__ (m))) ^ /home/seurer/gcc/git/gcc-test/gcc/../include/libiberty.h:112:64: note: in expansion of macro 'ATTRIBUTE_NONNULL' extern char *basename (const char *) ATTRIBUTE_RETURNS_NONNULL ATTRIBUTE_NONNULL(1); ^ In file included from /usr/include/c++/4.8.2/cstring:42:0, from /home/seurer/gcc/git/gcc-test/gcc/system.h:241, from /home/seurer/gcc/git/gcc-test/gcc/genmodes.cc:21: /usr/include/string.h:599:26: error: ambiguates old declaration 'const char* basename(const char*)' extern "C++" const char *basename (const char *__filename) ^ make[2]: *** [Makefile:2860: build/genmodes.o] Error 1 commit 278f8f567b5470e87e2e6482ee385d61c7f45a5d Author: Richard Biener Date: Mon Mar 6 11:06:38 2023 +0100 RAII auto_mpfr and autp_mpz
[Bug other/109584] Chinese Antimalware software Qihoo 360 delete entire GCC installation and all programs compiled with GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109584 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #4 from Andrew Pinski --- If anything it is binutils issue rather than a gcc issue. Gcc just produces assembly code and not the final object or linked code.
[Bug libstdc++/103755] {has,use}_facet() and iostream constructor performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755 Jonathan Wakely changed: What|Removed |Added Target Milestone|13.0|12.3 --- Comment #18 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #16) > So to avoid a regression from detecting the bug and throwing an exception to > crashing with a segfault, I think we need to change __try_use_facet to use > dynamic_cast, unfortunately. Ugh, I completely forgot about this.
[Bug libstdc++/103387] powerpc64le: segmentation fault on std::cout with ieee128 long double variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Jonathan Wakely --- Also fixed for 12.3 now.
[Bug libstdc++/103387] powerpc64le: segmentation fault on std::cout with ieee128 long double variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387 --- Comment #14 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8caf5805ad76125b84430b8653003f4776489d46 commit r12-9462-g8caf5805ad76125b84430b8653003f4776489d46 Author: Jonathan Wakely Date: Thu Apr 20 21:02:22 2023 +0100 libstdc++: Optimize std::try_facet and std::use_facet [PR103755] The std::try_facet and std::use_facet functions were optimized in r13-3888-gb3ac43a3c05744 to avoid redundant checking for all facets that are required to always be present in every locale. This performs a simpler version of the optimization that only applies to std::ctype, std::num_get, std::num_put, and the wchar_t specializations of those facets. Those are the facets that are cached by std::basic_ios, which means they're used on construction for every iostream object. This smaller change is suitable for the gcc-12 branch, and mitigates the performance loss for powerpc64le-linux on the gcc-12 branch caused by r12-9454-g24cf9f4c6f45f7 for PR 103387. It also greatly improves the performance of constructing iostreams objects, for all targets. libstdc++-v3/ChangeLog: PR libstdc++/103755 * include/bits/locale_classes.tcc (try_facet, use_facet): Do not check array index or dynamic type when accessing required specializations of std::ctype, std::num_get, or std::num_put. * testsuite/22_locale/ctype/is/string/89728_neg.cc: Adjust expected errors.
[Bug libstdc++/103755] {has,use}_facet() and iostream constructor performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755 --- Comment #17 from CVS Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8caf5805ad76125b84430b8653003f4776489d46 commit r12-9462-g8caf5805ad76125b84430b8653003f4776489d46 Author: Jonathan Wakely Date: Thu Apr 20 21:02:22 2023 +0100 libstdc++: Optimize std::try_facet and std::use_facet [PR103755] The std::try_facet and std::use_facet functions were optimized in r13-3888-gb3ac43a3c05744 to avoid redundant checking for all facets that are required to always be present in every locale. This performs a simpler version of the optimization that only applies to std::ctype, std::num_get, std::num_put, and the wchar_t specializations of those facets. Those are the facets that are cached by std::basic_ios, which means they're used on construction for every iostream object. This smaller change is suitable for the gcc-12 branch, and mitigates the performance loss for powerpc64le-linux on the gcc-12 branch caused by r12-9454-g24cf9f4c6f45f7 for PR 103387. It also greatly improves the performance of constructing iostreams objects, for all targets. libstdc++-v3/ChangeLog: PR libstdc++/103755 * include/bits/locale_classes.tcc (try_facet, use_facet): Do not check array index or dynamic type when accessing required specializations of std::ctype, std::num_get, or std::num_put. * testsuite/22_locale/ctype/is/string/89728_neg.cc: Adjust expected errors.
[Bug tree-optimization/109588] [13 Regression] Missed Dead Code Elimination when using __builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109588 Marek Polacek changed: What|Removed |Added Component|c |tree-optimization CC||amacleod at redhat dot com, ||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Changed in r13-3596-ge7310e24b1c0ca: commit e7310e24b1c0ca67b1bb507c1330b2bf39e59e32 Author: Andrew MacLeod Date: Tue Oct 25 16:42:41 2022 -0400 Make ranger vrp1 default.
[Bug target/109478] FAIL: g++.dg/other/pr104989.C -std=gnu++14 (internal compiler error: Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109478 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by John David Anglin : https://gcc.gnu.org/g:dca9419cc3844d3cf3c06f51d5ca57e3b5f50920 commit r12-9461-gdca9419cc3844d3cf3c06f51d5ca57e3b5f50920 Author: John David Anglin Date: Fri Apr 21 14:38:42 2023 + Fix handling of large arguments passed by value. 2023-04-15 John David Anglin gcc/ChangeLog: PR target/109478 * config/pa/pa-protos.h (pa_function_arg_size): Update prototype. * config/pa/pa.cc (pa_function_arg): Return NULL_RTX if argument size is zero. (pa_arg_partial_bytes): Don't call pa_function_arg_size twice. (pa_function_arg_size): Change return type to int. Return zero for arguments larger than 1 GB. Update comments.
[Bug c/109588] New: [13 Regression] Missed Dead Code Elimination when using __builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109588
Bug ID: 109588
Summary: [13 Regression] Missed Dead Code Elimination when
using __builtin_unreachable
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
void foo(void);
static int a, b;
static int *c =
static int **d, **e =
int main() {
if (b) {
int *f =
if (a)
*e = f = *d;
if (f == )
; else foo();
}
}
both gcc trunk and 12.2 at -O3 generate:
main:
movlb(%rip), %eax
testl %eax, %eax
je .L2
cmpl$0, a(%rip)
je .L2
movq0, %rax
ud2
.L2:
xorl%eax, %eax
ret
Annotating a dead branch with __builting_unreachable():
void foo(void);
static int a, b;
static int *c =
static int **d, **e =
int main() {
if (b) {
int *f =
if (a)
*e = f = *d;
if (f == )
__builtin_unreachable(); else foo();
}
}
gcc trunk -O3 now generates:
main:
movlb(%rip), %ecx
testl %ecx, %ecx
je .L5
cmpl$0, a(%rip)
je .L3
movq0, %rax
ud2
.L3:
pushq %rax
callfoo
xorl%eax, %eax
popq%rdx
ret
.L5:
xorl%eax, %eax
ret
but gcc 12 generates:
main:
movlb(%rip), %eax
testl %eax, %eax
je .L2
movq0, %rax
ud2
.L2:
xorl%eax, %eax
ret
[Bug bootstrap/105664] Install with suffix creates extra file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105664 Francois-Xavier Coudert changed: What|Removed |Added Last reconfirmed||2023-04-21 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #9 from Francois-Xavier Coudert --- Present in gcc-13.1.0-RC-20230421
[Bug modula2/109586] cc1gm2 ICE when compiling large source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109586 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Gaius Mulley --- Closing as patch has been applied and no change to regression tests after successful bootstrap.
[Bug modula2/109586] cc1gm2 ICE when compiling large source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109586 --- Comment #3 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:a7e1ee39e4fa37d005929c4ff9457d1a199559c6 commit r14-140-ga7e1ee39e4fa37d005929c4ff9457d1a199559c6 Author: Gaius Mulley Date: Fri Apr 21 13:19:54 2023 +0100 PR modula2/109586 cc1gm2 ICE when compiling large source files. The function m2block_RememberConstant calls m2tree_IsAConstant. However IsAConstant does not recognise TREE_CODE(t) == CONSTRUCTOR as a constant. Without this patch CONSTRUCTOR contants are garbage collected (and not preserved) resulting in a corrupt tree and crash. gcc/m2/ChangeLog: PR modula2/109586 * gm2-gcc/m2tree.cc (m2tree_IsAConstant): Add (TREE_CODE (t) == CONSTRUCTOR) to expression. Signed-off-by: Gaius Mulley
[Bug tree-optimization/109587] New: Deeply nested loop unrolling overwhelms register allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109587
Bug ID: 109587
Summary: Deeply nested loop unrolling overwhelms register
allocator
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tnfchris at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*
On matrix multiplication routines such as
#include
template
void f(const float32_t *__restrict a, const float32_t *__restrict b, float32_t
*c) {
for (int i = 0; i < N; ++i) {
for (int j=0; j < M; ++j) {
for (int k=0; k < K; ++k) {
c[i*N + j] += a[i*K + k] * b[k*M + j];
}
}
}
}
template void f<16, 16, 16>(const float32_t *__restrict a, const float32_t
*__restrict b, float32_t *c);
the loop unroller fully unrolls the inner loop because the iteration count 16
is below the threshold. But especially because this results in a RMW operation
we don't have enough registers to deal with it and we spill profoundly.
The loop can be split in two but this requires manual work on each GEMM kernel.
Perhaps the loop unroller can use a better heuristic here?
It also looks like adding a pragmas
template
void f(const float32_t *__restrict a, const float32_t *__restrict b, float32_t
*c) {
for (int i = 0; i < N; ++i) {
for (int j=0; j < M; ++j) {
#pragma GCC unroll 8
for (int k=0; k < K; ++k) {
c[i*N + j] += a[i*K + k] * b[k*M + j];
}
}
}
}
helps but because this blocks cunrolli and instead unrolls in RTL we loose
scheduling and result in not as efficient code.
So can we do better here with early unrolling?
[Bug tree-optimization/109573] [11/12/13/14 regression] ICE in vectorizable_live_operation, at tree-vect-loop.cc:9060 with -march=ivybridge since r11-3025-g095d42feed09f8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109573 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:cddfe6bc40b3dc0806e260bbfb4cac82d609a258 commit r14-139-gcddfe6bc40b3dc0806e260bbfb4cac82d609a258 Author: Richard Biener Date: Fri Apr 21 12:57:17 2023 +0200 tree-optimization/109573 - avoid ICEing on unexpected live def The following relaxes the assert in vectorizable_live_operation where we catch currently unhandled cases to also allow an intermediate copy as it happens here but also relax the assert to checking only. PR tree-optimization/109573 * tree-vect-loop.cc (vectorizable_live_operation): Allow unhandled SSA copy as well. Demote assert to checking only. * g++.dg/vect/pr109573.cc: New testcase.
[Bug target/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585
--- Comment #4 from Hector Martin ---
This whole codebase is complex, and the problem is in btree code which is hard
to simplify down. Best I can do right now is this. First grab the lv2.tar.gz
attachment and extract it into /tmp. Then:
$ git clone https://github.com/falkTX/Carla
$ cd Carla && make -C source/modules/lilv
$ cat > test.c << EOF
#include "lilv/lilv.h"
int main(int argc, char **argv)
{
LilvWorld* world = lilv_world_new();
lilv_world_load_all(world, "/tmp/lv2");
}
EOF
$ gcc -I source/includes/ -I source/modules/lilv/lilv-0.24.0/ -o test test.c
./build/modules/Release/lilv.a -lm
$ ./test
Compiling with -fno-schedule-insns -fno-schedule-insns2 seems to work properly.
[Bug target/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585 --- Comment #3 from Hector Martin --- Created attachment 54903 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54903=edit lv2 plugin bundle for testing
[Bug modula2/109586] cc1gm2 ICE when compiling large source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109586 --- Comment #2 from Gaius Mulley --- Created attachment 54902 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54902=edit Add missing constant type to m2tree_IsAConstant The function m2block_RememberConstant calls m2tree_IsAConstant. However IsAConstant does not recognise TREE_CODE(t) == CONSTRUCTOR as a constant. This proposed patch updates IsAConstant and in turn fixes the PR.
[Bug tree-optimization/109583] [13/14 Regression] ICE in related_vector_mode, at stor-layout.cc:537 since r14-22-g2349e69125335d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109583 Jakub Jelinek changed: What|Removed |Added Target Milestone|14.0|13.0
[Bug tree-optimization/109583] [13/14 Regression] ICE in related_vector_mode, at stor-layout.cc:537 since r14-22-g2349e69125335d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109583
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Summary|[14 Regression] ICE in |[13/14 Regression] ICE in
|related_vector_mode, at |related_vector_mode, at
|stor-layout.cc:537 since|stor-layout.cc:537 since
|r14-22-g2349e69125335d |r14-22-g2349e69125335d
Status|NEW |ASSIGNED
--- Comment #1 from Jakub Jelinek ---
Change it to:
typedef float v8sf __attribute__((vector_size (8 * sizeof (float;
typedef int v8si __attribute__((vector_size (8 * sizeof (int;
v8sf
foo (v8sf x, v8sf y)
{
v8sf tem0 = x + y;
v8sf tem1 = x - y;
return __builtin_shuffle (tem0, tem1, (v8si) { 0, 9, 2, 11, 4, 13, 6, 15 });
}
and it started to ICE already in r13-4122-g1bc7efa948f751 (again -O1 -mno-avx
-Wno-psabi).
[Bug modula2/109586] cc1gm2 ICE when compiling large source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109586 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-04-21 --- Comment #1 from Gaius Mulley --- After some investigation it appears to be a GC problem and in particular a constant is being garbage collected. Disabling GC allows the compile to succeed.
[Bug modula2/109586] New: cc1gm2 ICE when compiling large source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109586 Bug ID: 109586 Summary: cc1gm2 ICE when compiling large source file Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- gm2 -fiso -g squash1_bug3.mod tree becomes corrupted when compiling large sources (as reported on gm2 mailing list). terminate called after throwing an instance of 'unsigned int' *** WARNING *** there are active plugins, do not report this as a bug unless you can reproduce it without enabling any plugins. Event| Plugins PLUGIN_FINISH| m2rte In function ‘welche_tabelle’: cc1gm2: internal compiler error: Aborted 0x14ba4df crash_signal ../../gcc-read-write/gcc/toplev.cc:314 0x7f4b50033d5f ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x7f4b50033ce1 __GI_raise ../sysdeps/unix/sysv/linux/raise.c:51 0x7f4b5001d536 __GI_abort ./stdlib/abort.c:79 0xd43eb7 InvokeHandler m2/gm2-libs-boot/RTExceptions.c:484 0xd448c6 RTExceptions_Raise m2/gm2-libs-boot/RTExceptions.c:946 0xd44386 invalidloc m2/gm2-libs-boot/RTExceptions.c:755 0xd49bee sigbusDespatcher ../../gcc-read-write/gcc/m2/gm2-libs-ch/SysExceptions.c:125 0x7f4b50033d5f ??? ./signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0xc2c189 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../gcc-read-write/gcc/tree.h:3653 0xc5c1a5 m2statement_BuildAssignmentTree ../../gcc-read-write/gcc/m2/gm2-gcc/m2statement.cc:169 0xc5c2f8 m2statement_BuildAssignmentStatement ../../gcc-read-write/gcc/m2/gm2-gcc/m2statement.cc:187 0xca0d64 CodeBecomes m2/gm2-compiler-boot/M2GenGCC.c:4441 0xc9c359 CodeStatement m2/gm2-compiler-boot/M2GenGCC.c:1769 0xcaa1f3 M2GenGCC_ConvertQuadsToTree m2/gm2-compiler-boot/M2GenGCC.c:8500 0xcd9662 M2Scope_ForeachScopeBlockDo m2/gm2-compiler-boot/M2Scope.c:661 0xc8c989 M2Code_CodeBlock m2/gm2-compiler-boot/M2Code.c:512 0xc7941c Lists_ForeachItemInListDo m2/gm2-compiler-boot/Lists.c:394 0xcf3ced SymbolTable_ForeachProcedureDo m2/gm2-compiler-boot/SymbolTable.c:14299 0xc8cab7 M2Code_CodeBlock m2/gm2-compiler-boot/M2Code.c:544
[Bug c++/108993] Value initialization does not occur for derived class , for gcc versions > 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993 --- Comment #14 from m.cencora at gmail dot com --- Yeah, in CWG issue comments it is much more clear - but I cannot find such a wording in C++ latest draft. English is not my native language so this one is on me.
[Bug c/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585 --- Comment #2 from Richard Biener --- I wonder if you can provide a harness exercising this at runtime? Can you try -fno-schedule-insns -fno-schedule-insns2?
[Bug c++/108993] Value initialization does not occur for derived class , for gcc versions > 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993 --- Comment #13 from Jonathan Wakely --- And that's clearly the committee's intent: https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#302 "Zero the object, then call the default generated constructor" ... "Zero first, and generate the object code for the default constructor when it's needed for value-initialization cases" https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#543 "Change 9.4 [dcl.init] to specify that non-union class objects with no user-declared constructor are value-initialized by first zero-initializing the object and then calling the (implicitly-defined) default constructor,"
[Bug c++/108993] Value initialization does not occur for derived class , for gcc versions > 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993 --- Comment #12 from Jonathan Wakely --- I don't see any ambiguity: "otherwise, the object is zero-initialized and the semantic constraints for default-initialization are checked, **and** if T has a non-trivial default constructor, the object is default-initialized;" It doesn't say zero-init OR default-init, it very clearly says zero-init AND default-init.
[Bug c/109585] Carla/sord miscompiled with -O2 on ARM64 (inlining issue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585 --- Comment #1 from Hector Martin --- Created attachment 54901 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54901=edit Preprocessed input
[Bug c/109585] New: Carla/sord miscompiled with -O2 on ARM64 (inlining issue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109585 Bug ID: 109585 Summary: Carla/sord miscompiled with -O2 on ARM64 (inlining issue) Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: hector at marcansoft dot com Target Milestone: --- Created attachment 54900 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54900=edit Manually annotated disassembly identifying the problem GCC 12.1.0 miscompiles sord_free() with -O2 due to bad inlining on ARM64. Reproducible on Compiler Explorer on 12.2 and also trunk. https://godbolt.org/z/rvxP1oodh (includes full preprocessed input) I've attached an annotated disassembly. The problem is that zix_btree_iter_increment() and zix_btree_iter_is_end() are inlined together into sord_free(), but the `i->stack[0].node == NULL` check in zix_btree_iter_is_end() somehow got hoisted before the `f->node = NULL;` in zix_btree_iter_increment(), so the check fails when it pass (ending the loop), and then the loop body goes on to deref a NULL pointer.
[Bug target/109582] riscv/generic.md:28:1: unknown value `smin' for attribute `type'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109582 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed hopefully
[Bug tree-optimization/109583] [14 Regression] ICE in related_vector_mode, at stor-layout.cc:537 since r14-22-g2349e69125335d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109583 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug other/109584] Chinese Antimalware software Qihoo 360 delete entire GCC installation and all programs compiled with GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109584 --- Comment #3 from Richard Biener --- I'm curious what it keys on here ...
[Bug target/108270] un-optimal vsetvl for multi-loop if avl is 0 ~ 31 immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108270
--- Comment #2 from CVS Commits ---
The master branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:d06e9264b0192c2c77e07d7fb0fe090efcb510c0
commit r14-135-gd06e9264b0192c2c77e07d7fb0fe090efcb510c0
Author: Juzhe-Zhong
Date: Fri Apr 21 17:19:12 2023 +0800
RISC-V: Defer vsetvli insertion to later if possible [PR108270]
Fix issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108270.
Consider the following testcase:
void f (void * restrict in, void * restrict out, int l, int n, int m)
{
for (int i = 0; i < l; i++){
for (int j = 0; j < m; j++){
for (int k = 0; k < n; k++)
{
vint8mf8_t v = __riscv_vle8_v_i8mf8 (in + i + j, 17);
__riscv_vse8_v_i8mf8 (out + i + j, v, 17);
}
}
}
}
Compile option: -O3
Before this patch:
mv a7,a2
mv a6,a0
mv t1,a1
mv a2,a3
vsetivlizero,17,e8,mf8,ta,ma
ble a7,zero,.L1
ble a4,zero,.L1
ble a3,zero,.L1
...
After this patch:
mv a7,a2
mv a6,a0
mv t1,a1
mv a2,a3
ble a7,zero,.L1
ble a4,zero,.L1
ble a3,zero,.L1
add a1,a0,a4
li a0,0
vsetivlizero,17,e8,mf8,ta,ma
...
This issue is a missed optmization produced by Phase 3 global backward
demand
fusion instead of LCM.
This patch is fixing poor placement of the vsetvl.
This point is seletected not because LCM but by Phase 3 (VL/VTYPE demand
info
backward fusion and propogation) which
is I introduced into VSETVL PASS to enhance LCM && improve vsetvl
instruction
performance.
This patch is to supress the Phase 3 too aggressive backward fusion and
propagation to the top of the function program
when there is no define instruction of AVL (AVL is 0 ~ 31 imm since
vsetivli
instruction allows imm value instead of reg).
You may want to ask why we need Phase 3 to the job.
Well, we have so many situations that pure LCM fails to optimize, here I
can
show you a simple case to demonstrate it:
void f (void * restrict in, void * restrict out, int n, int m, int cond)
{
size_t vl = 101;
for (size_t j = 0; j < m; j++){
if (cond) {
for (size_t i = 0; i < n; i++)
{
vint8mf8_t v = __riscv_vle8_v_i8mf8 (in + i + j, vl);
__riscv_vse8_v_i8mf8 (out + i, v, vl);
}
} else {
for (size_t i = 0; i < n; i++)
{
vint32mf2_t v = __riscv_vle32_v_i32mf2 (in + i + j, vl);
v = __riscv_vadd_vv_i32mf2 (v,v,vl);
__riscv_vse32_v_i32mf2 (out + i, v, vl);
}
}
}
}
You can see:
The first inner loop needs vsetvli e8 mf8 for vle+vse.
The second inner loop need vsetvli e32 mf2 for vle+vadd+vse.
If we don't have Phase 3 (Only handled by LCM (Phase 4)), we will end up
with :
outerloop:
...
vsetvli e8mf8
inner loop 1:
vsetvli e32mf2
inner loop 2:
However, if we have Phase 3, Phase 3 is going to fuse the vsetvli e32 mf2
of
inner loop 2 into vsetvli e8 mf8, then we will end up with this result
after
phase 3:
outerloop:
...
inner loop 1:
vsetvli e32mf2
inner loop 2:
vsetvli e32mf2
Then, this demand information after phase 3 will be well optimized after
phase 4
(LCM), after Phase 4 result is:
vsetvli e32mf2
outerloop:
...
inner loop 1:
inner loop 2:
You can see this is the optimal codegen after current VSETVL PASS (Phase 3:
Demand backward fusion and propagation + Phase 4: LCM ). This is a known
issue
when I start to implement VSETVL PASS.
gcc/ChangeLog:
PR target/108270
* config/riscv/riscv-vsetvl.cc
(vector_infos_manager::all_empty_predecessor_p): New function.
(pass_vsetvl::backward_demand_fusion): Ditto.
* config/riscv/riscv-vsetvl.h: Ditto.
gcc/testsuite/ChangeLog:
PR target/108270
* gcc.target/riscv/rvv/vsetvl/imm_bb_prop-1.c: Adapt testcase.
* gcc.target/riscv/rvv/vsetvl/imm_conflict-3.c: Ditto.
* gcc.target/riscv/rvv/vsetvl/pr108270.c: New test.
[Bug c++/108993] Value initialization does not occur for derived class , for gcc versions > 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993 --- Comment #11 from m.cencora at gmail dot com --- Nvm, I understood this rule differently. You are saying that initialization is two step: - first zero-initialized, - then default-initialized. For me the way this rule is written is ambiguous.
[Bug c++/108993] Value initialization does not occur for derived class , for gcc versions > 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993 m.cencora at gmail dot com changed: What|Removed |Added CC||m.cencora at gmail dot com --- Comment #10 from m.cencora at gmail dot com --- Does it really apply? Base constructor is user-provided hence non-trivial, hence Derived defaulted default constructor is non-trivial as well. Which means we end up in this clause: "and if T has a non-trivial default constructor, the object is default-initialized"
[Bug target/109582] riscv/generic.md:28:1: unknown value `smin' for attribute `type'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109582 --- Comment #1 from CVS Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:98d66b204932e343bbf940990914b949e8fccbd5 commit r14-134-g98d66b204932e343bbf940990914b949e8fccbd5 Author: Robin Dapp Date: Fri Apr 21 09:38:06 2023 +0200 riscv: Fix fallout. PR109582: Since r14-116 generic.md uses standard names instead of the types defined in the iterator (that match instruction names). Change this. gcc/ChangeLog: PR target/109582 * config/riscv/generic.md: Change standard names to insn names.
[Bug rtl-optimization/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753 Georg-Johann Lay changed: What|Removed |Added Attachment #53561|0 |1 is obsolete|| --- Comment #17 from Georg-Johann Lay --- Created attachment 54899 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54899=edit pr105753.diff: Patch based on comment 1 This is a patch similar to that of comment 5 (based on a remark in comment 1). It removes the superfluous PARALELLs in [u]divmodsi4 and [u]divmodpsi4 insn patterns. Difference to the previous patch is that it indents the RTL according to the coding rules (basically lisp for that part). The patch is untested. ChangeLog would be something like: gcc/ PR target/105753 * config/avr/avr.md (divmodpsi4, udivmodpsi4, divmodsi4, udivmodsi4): Remove extra parallel in insn patterns.
[Bug other/109584] Chinese Antimalware software Qihoo 360 delete entire GCC installation and all programs compiled with GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109584 --- Comment #2 from Jonathan Wakely --- Why is that a GCC bug?
[Bug target/109566] powerpc: unrecognizable insn for -mcpu=e6500
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109566 --- Comment #2 from Sebastian Huber --- Sorry for the confusion, the actual bad commit was the follow up commit (NOT d75be7e4343f049176546aa9517d570e5eb67954): commit 6cc3394507a2303a18891d34222c53f679256c37 Author: Andrew MacLeod Date: Wed Oct 5 10:42:07 2022 -0400 propagate partial equivs in the cache. Adjust on-entry cache propagation to look for and propagate both full and partial equivalences. gcc/ PR tree-optimization/102540 PR tree-optimization/102872 * gimple-range-cache.cc (ranger_cache::fill_block_cache): Handle partial equivs. (ranger_cache::range_from_dom): Cleanup dump output. gcc/testsuite/ * gcc.dg/pr102540.c: New. * gcc.dg/pr102872.c: New.
[Bug other/109584] Chinese Antimalware software Qihoo 360 delete entire GCC install and all programs compiled with GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109584 --- Comment #1 from cqwrteur --- Created attachment 54898 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54898=edit An example Example 360 deletes programs compiled with GCC
[Bug other/109584] New: Chinese Antimalware software Qihoo 360 delete entire GCC install and all programs compiled with GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109584 Bug ID: 109584 Summary: Chinese Antimalware software Qihoo 360 delete entire GCC install and all programs compiled with GCC Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- https://www.360totalsecurity.com/
[Bug target/108728] gcc.dg/torture/float128-cmp-invalid.c fails on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108728 --- Comment #3 from CVS Commits --- The master branch has been updated by HaoChen Gui : https://gcc.gnu.org/g:6afa7d31a0e8865e17b317ada5cc5014b5d07da3 commit r14-133-g6afa7d31a0e8865e17b317ada5cc5014b5d07da3 Author: Haochen Gui Date: Fri Apr 21 16:42:31 2023 +0800 rs6000: xfail float128 comparison test case that fails on powerpc64. This patch xfails a float128 comparison test case on powerpc64 that fails due to a longstanding issue with floating-point compares. See PR58684 for more information. When float128 hardware is enabled (-mfloat128-hardware), xscmpuqp is generated for comparison which is unexpected. When float128 software emulation is enabled (-mno-float128-hardware), we still have to xfail the hardware version (__lekf2_hw) which finally generates xscmpuqp. gcc/testsuite/ PR target/108728 * gcc.dg/torture/float128-cmp-invalid.c: Add xfail.
[Bug target/108728] gcc.dg/torture/float128-cmp-invalid.c fails on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108728 --- Comment #2 from CVS Commits --- The master branch has been updated by HaoChen Gui : https://gcc.gnu.org/g:4dca6024fb8254117bc1b0ea005a92ee6a7b84be commit r14-132-g4dca6024fb8254117bc1b0ea005a92ee6a7b84be Author: Haochen Gui Date: Fri Apr 21 16:35:07 2023 +0800 testsuite: make ppc_cpu_supports_hw as effective target keyword [PR108728] gcc/testsuite/ PR target/108728 * lib/target-supports.exp (is-effective-target-keyword): Add ppc_cpu_supports_hw.
