[Bug c++/110349] [C++26] P2169R4 - Placeholder variables with no name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110349
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:6c9973e46bdb4496b5af8a7170269e91e36ad35a
commit r14-5991-g6c9973e46bdb4496b5af8a7170269e91e36ad35a
Author: Jakub Jelinek
Date: Thu Nov 30 09:09:21 2023 +0100
c++: Implement C++26 P2169R4 - Placeholder variables with no name
[PR110349]
The following patch implements the C++26 P2169R4 paper.
As written in the PR, the patch expects that:
1) https://eel.is/c++draft/expr.prim.lambda.capture#2
"Ignoring appearances in initializers of init-captures, an identifier
or this shall not appear more than once in a lambda-capture."
is adjusted such that name-independent lambda captures with initializers
can violate this rule (but lambda captures which aren't name-independent
can't appear after name-independent ones)
2) https://eel.is/c++draft/class.mem#general-5
"A member shall not be declared twice in the member-specification,
except that"
having an exception that name-independent non-static data member
declarations can appear multiple times (but again, if there is
a member which isn't name-independent, it can't appear after
name-independent ones)
3) it assumes that any name-independent declarations which weren't
previously valid result in the _ lookups being ambiguous, not just
if there are 2 _ declarations in the same scope, in particular the
https://eel.is/c++draft/basic.scope#block-2 mentioned cases
4) it assumes that _ in static function/block scope structured bindings
is never name-independent like in namespace scope structured bindings;
it matches clang behavior and is consistent with e.g. static type _;
not being name-independent both at namespace scope and at function/block
scope
As you preferred in the PR, for local scope bindings, the ambiguous cases
use a TREE_LIST with the ambiguous cases which can often be directly fed
into print_candidates. For member_vec after sorting/deduping, I chose to
use
instead OVERLOAD with a new flag but only internally inside of the
member_vec, get_class_binding_direct turns it into a TREE_LIST. There are
2 reasons for that, in order to keep the member_vec binary search fast, I
think it is better to keep OVL_NAME usable on all elements because having
to special case TREE_LIST would slow everything down, and the callers need
to be able to chain the results anyway and so need an unshared TREE_LIST
they can tweak/destroy anyway.
name-independent declarations (even in older standards) will not have
-Wunused{,-variable,-but-set-variable} or -Wshadow* warnings diagnosed, but
unlike e.g. the clang implementation, this patch does diagnose
-Wunused-parameter for parameters with _ names because they aren't
name-independent and one can just omit their name instead.
2023-11-30 Jakub Jelinek
PR c++/110349
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_placeholder_variables=202306L for C++26.
gcc/cp/
* cp-tree.h: Implement C++26 P2169R4 - Placeholder variables with
no
name.
(OVL_NAME_INDEPENDENT_DECL_P): Define.
(add_capture): Add unsigned * argument.
(name_independent_decl_p): New inline function.
* name-lookup.cc (class name_lookup): Make ambiguous and
add_value members public.
(name_independent_linear_search): New function.
(get_class_binding_direct): Handle member_vec_binary_search
returning OVL_NAME_INDEPENDENT_DECL_P OVERLOAD. Use
name_independent_linear_search rather than fields_linear_search
for linear lookup of _ name if !want_type.
(member_name_cmp): Sort name-independent declarations first.
(member_vec_dedup): Handle name-independent declarations.
(pop_local_binding): Handle binding->value being a TREE_LIST for
ambiguous name-independent declarations.
(supplement_binding): Handle name-independent declarations.
(update_binding): Likewise.
(check_local_shadow): Return tree rather than void, normally
NULL_TREE but old for name-independent declarations which used
to conflict with outer scope declaration. Don't emit -Wshadow*
warnings for name-independent declarations.
(pushdecl): Handle name-independent declarations.
* search.cc (lookup_field_r): Handle nval being a TREE_LIST.
* lambda.cc (build_capture_proxy): Adjust for ___.
names of members.
(add_capture): Add NAME_INDEPENDENT_CNT argument. Use ___.
name rather than ___ for second and following capture with
_ name.
(add_d
[Bug middle-end/112733] [14 Regression] ICE: Segmentation fault in wide-int.cc during GIMPLE pass: sccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112733 --- Comment #14 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:248bf197148451a3fb950b54fa313d1d252864b5 commit r14-5992-g248bf197148451a3fb950b54fa313d1d252864b5 Author: Jakub Jelinek Date: Thu Nov 30 09:13:00 2023 +0100 wide-int: Fix wide_int division/remainder [PR112733] This patch fixes the other half of the PR, where we were crashing on the UNSIGNED widest_int modulo of 1 % -128 (where the -128 in UNSIGNED is 131072 bit 0xf...f80). The patch actually has 2 independent parts. The fix for the divmod buffer overflow is in the 2nd-5th and 7th-8th hunks of the patch. abs (remainder) <= min (abs (dividend), abs (divisor)) and the wide-int.h callers estimate the remainder size to be the same as the quotient size, i.e. for UNSIGNED dividend with msb set quotient (same as remainder) precision based estimation, for SIGNED or dividend with msb clear estimate based on divident len (+ 1). For quotient (if any), wi_pack is called as quotient_len = wi_pack (quotient, b_quotient, m, dividend_prec); where m is m = dividend_blocks_needed; while (m > 1 && b_dividend[m - 1] == 0) m--; and dividend_blocks_needed = 2 * BLOCKS_NEEDED (dividend_prec); where wi_pack stores to result (in_len + 1) / 2 limbs (or one more if (in_len & 1) == 0 and in_len / 2 < BLOCKS_NEEDED (dividend_prec)). In any case, that is never more than BLOCKS_NEEDED (dividend_prec) and matches caller's estimations (then it is canonicalized and perhaps shrunk that way). The problematic case is the remainder, where wi_pack is called as *remainder_len = wi_pack (remainder, b_remainder, n, dividend_prec); The last argument is again based on the dividend precision like for quotient, but n is instead: n = divisor_blocks_needed; while (n > 1 && b_divisor[n - 1] == 0) n--; so based on the divisor rather than dividend. Now, in the wi::multiple_of_p (1, -128, UNSIGNED) widest_int precision case, dividend_prec is very small, the dividend is 1 and while the official precision is 131072 bits, dividend_len is 1 and if (sgn == SIGNED || dividend_val[dividend_len - 1] >= 0) dividend_prec = MIN ((dividend_len + 1) * HOST_BITS_PER_WIDE_INT, dividend_prec); shrinks the estimate to 128 bits in this case; but divisor_prec is huge, because the divisor is negative UNSIGNED, so 131072 bits, 2048 limbs, 4096 half-limbs (so divisor_blocks_needed and n are 4096). Now, wi_pack relies on the penultimate argument to be smaller or equal to 2 * BLOCKS_NEEDED of the last argument and that is not the case here, 4096 is certainly larger than 2 * BLOCKS_NEEDED (128) aka 4 and so wi_pack overflows the array. Unfortunately looking around, this isn't the only overflow, already in divmod_internal_2 we have an overflow, though there not overflowing a buffer during writing, but during reading. When divmod_internal_2 is called with the last 2 arguments like m=1, n=4096 as in this case (but generally any where m < n), it has a special case for n == 1 (which won't be the problem, we never have m or n 0), then decides based on msb of divisor whether there should be some shift canonicalization, then performs a for (j = m - n; j >= 0; j--) main loop and finally initializes b_remainder: if (s) for (i = 0; i < n; i++) b_remainder[i] = (b_dividend[i] >> s) | (b_dividend[i+1] << (HOST_BITS_PER_HALF_WIDE_INT - s)); else for (i = 0; i < n; i++) b_remainder[i] = b_dividend[i]; In the usual case of m >= n, the main loop will iterate at least once, b_dividend has m + 1 valid elements and the copying to b_remainder is correct. But for the m < n unusual case, the main loop never iterates and we want to copy the b_dividend right into b_remainder (possibly with shifts). Except when it copies n elements, it copies garbage which isn't there at all for the last n - m elements. Because the decision whether the main loop should iterate at all or not and the s computation should be based on the original n, the following patch sets n to MIN (n, m) only after the main loop, such that we copy to b_remainder at most what is initialized in b_dividend, and returns that adjusted value to the caller which then passes it to wi_pack and so satisfies again the requirement there, rather than trying to do the n = MIN (n, m) before calling divmod_internal_2 or after it. I believe the bug is mostly something I've only introduced myself in the > 576 bit wide_int/widest_int support changes, before that there was no attempt to decrease the precisions and so I think dividend_prec and divisor_prec were pretty much always t
[Bug middle-end/112733] [14 Regression] ICE: Segmentation fault in wide-int.cc during GIMPLE pass: sccp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112733 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Jakub Jelinek --- Should be fixed now.
[Bug c++/110349] [C++26] P2169R4 - Placeholder variables with no name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110349 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Jakub Jelinek --- Implemented for GCC 14.
[Bug c++/110338] Implement C++26 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110338 Bug 110338 depends on bug 110349, which changed state. Bug 110349 Summary: [C++26] P2169R4 - Placeholder variables with no name https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110349 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112740 --- Comment #3 from Zdenek Sojka --- (In reply to Andrew Pinski from comment #2) > Does this work post: > https://gcc.gnu.org/pipermail/gcc-cvs/2023-November/394162.html > > ? > > If so I will commit a testcase. thank you for checking Assuming this should have been fixed in r14-5938, it is still failing for me with r14-5940 and r14-5986: $ riscv64-unknown-linux-gnu-gcc testcase.c -static $ ./a.out Aborted The value of x[0] is "...". It is FAILing on: aarch64-unknown-linux-gnu, mips64el-unknown-linux-gnuabi64, riscv64-unknown-linux-gnu And PASSing on: x86_64-pc-linux-gnu, powerpc64le-unknown-linux-gnu $ riscv64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-5940-20231128183456-g3d104d93a70-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.0/lto-wrapper Target: riscv64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-isa-spec=2.2 --with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu --with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld --with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-5940-20231128183456-g3d104d93a70-checking-yes-rtl-df-extra-riscv64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231128 (experimental) (GCC)
[Bug target/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112740 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-11-30 Target|riscv64-unknown-linux-gnu |riscv64-unknown-linux-gnu ||aarch64 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- I will check tomorrow if I can see if I can spot what is wrong on aarch64.
[Bug middle-end/111497] [11/12/13 Regression] ICE building mariadb on i686 since r8-470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111497 Richard Biener changed: What|Removed |Added Known to work||14.0 Summary|[11/12/13/14 Regression]|[11/12/13 Regression] ICE |ICE building mariadb on |building mariadb on i686 |i686 since r8-470 |since r8-470 --- Comment #8 from Richard Biener --- Fixed on trunk sofar, will test on the 13 branch now.
[Bug target/112411] ICE: SIGSEGV with --param=min-nondebug-insn-uid=2147483647 on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411 --- Comment #5 from Zdenek Sojka --- Thank you for the evaluation. I am not reporting ICEs (assertion / checking failures) due to overflows caused by extreme --param values: - this param is typically causing ICEs due to insn UID overflow - params affecting inlining or unrolling often cause ICEs due to function::last_clique wraparound (it's 16bit uint) - generally, I am trying to consider if a real-world scenario could trigger the ICE This is different, since there is no assertion or checking failure, but a segmentation fault; that is uncommon.
[Bug target/112411] ICE: SIGSEGV with --param=min-nondebug-insn-uid=2147483647 on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411 --- Comment #6 from rguenther at suse dot de --- On Thu, 30 Nov 2023, zsojka at seznam dot cz wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411 > > --- Comment #5 from Zdenek Sojka --- > Thank you for the evaluation. > > - params affecting inlining or unrolling often cause ICEs due to > function::last_clique wraparound (it's 16bit uint) Ah, do you have a testcase for this? I see we have an assert in IL verification but not really any handling of the overflow itself (there is a way to gracefully handle it though!). A testcase would really be useful (in a new bug).
[Bug driver/112759] [13/14 regression] mips -march=native detection broken with gcc 13+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.3
[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug target/102543] -march=cascadelake performs odd alignment peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102543 liuhongt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||liuhongt at gcc dot gnu.org Resolution|--- |FIXED --- Comment #12 from liuhongt at gcc dot gnu.org --- Fixed in GCC12 and above.
[Bug target/107261] ICE: in classify_argument, at config/i386/i386.cc:2523 on __bf16 vect argument or return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107261 liuhongt at gcc dot gnu.org changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from liuhongt at gcc dot gnu.org --- Fixed in GCC13 and above.
[Bug tree-optimization/112774] New: Vectorize the loop by inferring nonwrapping information from arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112774
Bug ID: 112774
Summary: Vectorize the loop by inferring nonwrapping
information from arrays
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hliu at amperecomputing dot com
Target Milestone: ---
This case extracted from another benchmark and it is simpler than the case in
PR101450, as it has the additional boundary information from the array:
int A[1024 * 2];
int foo (unsigned offset, unsigned N)
{
int sum = 0;
for (unsigned i = 0; i < N; i++)
sum += A[i + offset];
return sum;
}
The Gimple before the vectorization pass is:
[local count: 955630224]:
# sum_12 = PHI
# i_14 = PHI
_1 = offset_8(D) + i_14;
_2 = A[_1];
sum_9 = _2 + sum_12;
i_10 = i_14 + 1;
GCC failed to vectorize it as it the chrec "{offset_8, +, 1}_1" may
overflow/wrap. I summarized more details in the email:
https://gcc.gnu.org/pipermail/gcc/2023-November/242854.html
Actually, GCC already knows it won't by inferring the range from the array
(in estimate_numbers_of_iterations -> infer_loop_bounds_from_undefined ->
infer_loop_bounds_from_array):
Induction variable (unsigned int) offset_8(D) + 1 * iteration does not wrap
in statement _2 = A[_1];
in loop 1.
Statement _2 = A[_1];
is executed at most 2047 (bounded by 2047) + 1 times in loop 1.
We can use re-use this information to vectorize this case. I already have a
simple patch to achieve this, and will send it out later (after doing more
tests).
[Bug tree-optimization/112766] [14 regression] spurious -Wmaybe-uninitialized with array new since r14-4089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112766 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Keywords||missed-optimization Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- OK, so one uninit use occurs on the exceptional path from Result::Result() during the initialization loop of the allocated array, this then has [count: 0]: # _71 = PHI <_58(21), _42(D)(6), _42(D)(45), _42(D)(14), _42(D)(24)> # _72 = PHI <_85(21), _43(D)(6), _43(D)(45), _43(D)(14), _43(D)(24)> # _73 = PHI <_44(D)(21), _44(D)(6), _41(45), _44(D)(14), _44(D)(24)> # nElements.2_74 = PHI <_17(21), _17(6), nElements.2_47(D)(45), nElements.2_47(D)(14), _17(24)> # cleanup.4_75 = PHI <1(21), 0(6), 0(45), 0(14), 0(24)> # nElements.6_76 = PHI # cleanup.7_77 = PHI <0(21), 0(6), 1(45), 0(14), 0(24)> : resx 3 // goes to L25 : if (cleanup.7_77 != 0) goto ; [0.00%] else goto ; [0.00%] but somehow we are not seeing that cleanup.7_77 is 0 on all the paths n_Elements.6_76 are uninitialized. (We're also not threading this for unknown reasons, likely the threader not going up EH edges)
[Bug target/101471] AVX512 incorrect writemask generated for _mm512_fpclass_ps_mask in O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101471 liuhongt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||liuhongt at gcc dot gnu.org --- Comment #9 from liuhongt at gcc dot gnu.org --- Fixed.
[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773 JuzheZhong changed: What|Removed |Added CC||juzhe.zhong at rivai dot ai --- Comment #1 from JuzheZhong --- I don't have such issue with. You need to try trunk GCC.
[Bug c++/112775] New: Class template partial specialization with decltype(n) is wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112775
Bug ID: 112775
Summary: Class template partial specialization with decltype(n)
is wrongly rejected
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
In this program
template
class A;
template
class A {};
class template A has one type parameter T, and two arbitrary non-type
parameters (of type T). And also a specialization of A is provided, having
equal non-type template parameters.
The program is accepted by Clang and MSVC, but not by GCC:
error: partial specialization 'class A' is not more
specialized than
5 | class A {};
| ^~~~
note: primary template 'template, T > class
A'
Online demo: https://godbolt.org/z/qjYMn8bd6
[Bug tree-optimization/112766] [14 regression] spurious -Wmaybe-uninitialized with array new since r14-4089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112766 --- Comment #3 from Richard Biener --- There's some logic in uninit_analysis::overlap, it looks incomplete.
[Bug c/112776] New: RISC-V Regression: Missed optimization of VSETVL PASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112776
Bug ID: 112776
Summary: RISC-V Regression: Missed optimization of VSETVL PASS
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
#include "riscv_vector.h"
void
foo_vec(float *r, const float *x)
{
int i, k;
vfloat32m4_t x_vec;
vfloat32m4_t x_forward_vec;
vfloat32m4_t temp_vec;
/**
* I have to use m1 to complicat intrisic
*/
vfloat32m1_t dst_vec;
vfloat32m1_t src_vec;
float result = 0.0f;
float shift_prev = 0.0f;
size_t n = 64;
for(size_t vl; n>0; n -=vl){
vl = __riscv_vsetvl_e32m4(n); //LMUL=4
x_vec = __riscv_vle32_v_f32m4(&x[0], vl);
x_forward_vec = __riscv_vle32_v_f32m4(&x[0], vl);
temp_vec = __riscv_vfmul_vv_f32m4(x_vec, x_forward_vec, vl);
/**
* I have to use m1 to complicat intrisic
*/
//vfloat32m1_t __riscv_vfmv_s_tu(vfloat32m1_t vd, float rs1, size_t vl);
src_vec = __riscv_vfmv_s_tu(src_vec, 0.0f, vl); //initial
src_vec
//dst_vec = __riscv_vfmv_s_f_f32m1_tu(dst_vec, 0.0f, vl); //clean
for vfredosum
dst_vec = __riscv_vfmv_s_tu(dst_vec, 0.0f, vl); //clean for
vfredosum
dst_vec = __riscv_vfredosum_tu(dst_vec, temp_vec, src_vec, vl);
r[0] = __riscv_vfmv_f_s_f32m1_f32(dst_vec);
}
}
ASM:
GCC-14 foo_vec:
li a4,64
.L2:
vsetvli a5,a4,e8,m1,ta,ma --->
vsetvli zero,a5,e32,m1,tu,ma
vmv.s.x v2,zero
vmv.s.x v1,zero
vsetvli zero,a5,e32,m4,tu,ma
vle32.v v4,0(a1)
vfmul.vvv4,v4,v4
vfredosum.vsv1,v4,v2
vfmv.f.sfa5,v1
fsw fa5,0(a0)
sub a4,a4,a5
bne a4,zero,.L2
ret
GCC-13:
foo_vec(float*, float const*):
fmv.s.x fa5,zero
li a4,64
.L2:
vsetvli a5,a4,e32,m4,ta,ma
vle32.v v28,0(a1)
vfmv.s.fv25,fa5
vfmul.vvv28,v28,v28
vfmv.s.fv24,fa5
sub a4,a4,a5
vfredosum.vsv24,v28,v25
vfmv.f.sfa4,v24
fsw fa4,0(a0)
bne a4,zero,.L2
ret
[Bug middle-end/112750] wrong code with _BitInt(256) and above with __builtin_sub_overflow_p() at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112750 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2023-11-30 --- Comment #1 from Jakub Jelinek --- Created attachment 56725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56725&action=edit gcc14-pr112750.patch Untested fix.
[Bug rtl-optimization/107057] [11/12 Regression] ICE in extract_constrain_insn, at recog.cc:2692
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107057 liuhongt at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||liuhongt at gcc dot gnu.org Resolution|--- |FIXED --- Comment #13 from liuhongt at gcc dot gnu.org --- .
[Bug target/107322] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with __bf16 compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107322 liuhongt at gcc dot gnu.org changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from liuhongt at gcc dot gnu.org --- .
[Bug target/111907] ICE: in curr_insn_transform, at lra-constraints.cc:4294 unable to generate reloads for: {*andnottf3} with -mavx512f -mno-evex512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111907 liuhongt at gcc dot gnu.org changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from liuhongt at gcc dot gnu.org --- .
[Bug target/111225] ICE in curr_insn_transform, unable to generate reloads for xor, since r14-2447-g13c556d6ae84be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111225 liuhongt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||liuhongt at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from liuhongt at gcc dot gnu.org --- .
[Bug target/111062] ICE: in final_scan_insn_1, at final.cc:2808 could not split insn {*andndi_1} with -O -mavx10.1-256 -mavx512bw -mno-avx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111062 liuhongt at gcc dot gnu.org changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from liuhongt at gcc dot gnu.org --- Fixed in GCC14.
[Bug target/111061] ICE: in emit_move_insn, at expr.cc:4219 with -O -mavx10.1-512 and __builtin_convertvector()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111061 liuhongt at gcc dot gnu.org changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from liuhongt at gcc dot gnu.org --- Fixed in GCC14.
[Bug target/112431] RISC-V GCC-15 feature: Support register overlap on widen RVV instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112431 --- Comment #7 from GCC Commits --- The trunk branch has been updated by Lehua Ding : https://gcc.gnu.org/g:5a35152f87a36db480693884dfb27ff6a5d5d683 commit r14-6007-g5a35152f87a36db480693884dfb27ff6a5d5d683 Author: Juzhe-Zhong Date: Thu Nov 30 18:12:04 2023 +0800 RISC-V: Remove earlyclobber for wx/wf instructions. While working on overlap for widening instructions, I realize that we set vwadd.wx/vfwadd.wf as earlyclobber which is incorrect. Since according to RVV ISA: "The destination EEW equals the source EEW." vwadd.vx widens the first source operand (i.e. 2 * source EEW = dest EEW) while vwadd.wx only widens the second/scalar source operand. Therefore overlap is legal for wx but not for vx. Before this patch (heave spillings): csrra5,vlenb sllia5,a5,1 addia5,a5,64 vfwadd.wf v2,v14,fs0 add a5,a5,sp vs2r.v v2,0(a5) vl2re32.v v2,0(a1) vfwadd.wf v14,v12,fs0 vfwadd.wf v12,v10,fs0 vfwadd.wf v10,v8,fs0 vfwadd.wf v8,v6,fs0 vfwadd.wf v6,v4,fs0 vfwadd.wf v4,v2,fs0 vfwadd.wf v2,v16,fs0 vfwadd.wf v16,v18,fs0 vfwadd.wf v18,v20,fs0 vfwadd.wf v20,v22,fs0 vfwadd.wf v22,v24,fs0 vfwadd.wf v24,v26,fs0 vfwadd.wf v26,v28,fs0 vfwadd.wf v28,v30,fs0 vfwadd.wf v30,v0,fs0 nop vsetvli zero,zero,e32,m2,ta,ma csrra5,vlenb After this patch (no spillings): vfwadd.wf v16,v16,fs0 vfwadd.wf v14,v14,fs0 vfwadd.wf v12,v12,fs0 vfwadd.wf v10,v10,fs0 vfwadd.wf v8,v8,fs0 vfwadd.wf v6,v6,fs0 vfwadd.wf v4,v4,fs0 vfwadd.wf v2,v2,fs0 vfwadd.wf v18,v18,fs0 vfwadd.wf v20,v20,fs0 vfwadd.wf v22,v22,fs0 vfwadd.wf v24,v24,fs0 vfwadd.wf v26,v26,fs0 vfwadd.wf v28,v28,fs0 vfwadd.wf v30,v30,fs0 vfwadd.wf v0,v0,fs0 Confirm the codegen above run successfully on both SPIKE/QEMU. PR target/112431 gcc/ChangeLog: * config/riscv/vector.md: Remove earlyclobber for wx/wf instructions. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/pr112431-19.c: New test. * gcc.target/riscv/rvv/base/pr112431-20.c: New test. * gcc.target/riscv/rvv/base/pr112431-21.c: New test.
[Bug target/110788] Spilling to mask register for GPR vec_duplicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110788 liuhongt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||liuhongt at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from liuhongt at gcc dot gnu.org --- .
[Bug target/112777] New: [14 Regression] profiled bootstrap fails on powerpc-linux-gnu, undefined references to __atomic_fetch_add_8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112777 Bug ID: 112777 Summary: [14 Regression] profiled bootstrap fails on powerpc-linux-gnu, undefined references to __atomic_fetch_add_8 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- trunk 20231130 fails to build on powerpc-linux-gnu in stageprofile. Not seen on powerpc64-linux-gnu and powerpc64el-linux-gnu make profiledbootstrap-lean [...] configure:3088: checking whether the C compiler works configure:3110: /home/doko/gcc-snapshot-20231130/build/./prev-gcc/xgcc -B/home/doko/gcc-snapshot-20231130/build/./prev-gcc/ -B/usr/lib/gcc-snapshot/powerpc-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/powerpc-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/powerpc-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/powerpc-linux-gnu/include -isystem /usr/lib/gcc-snapshot/powerpc-linux-gnu/sys-include -fno-checking -g -O2 -fno-checking -gtoggle -fprofile-generate -static-libstdc++ -static-libgcc -Wl,-z,relro conftest.c >&5 /usr/bin/powerpc-linux-gnu-ld: /home/doko/gcc-snapshot-20231130/build/./prev-gcc/libgcov.a(_gcov_indirect_call_profiler_v4.o): in function `gcov_counter_add': /home/doko/gcc-snapshot-20231130/build/powerpc-linux-gnu/libgcc/../../../src/libgcc/libgcov.h:423:(.text+0x4bc): undefined reference to `__atomic_fetch_add_8' /usr/bin/powerpc-linux-gnu-ld: /home/doko/gcc-snapshot-20231130/build/powerpc-linux-gnu/libgcc/../../../src/libgcc/libgcov.h:423:(.text+0x740): undefined reference to `__atomic_fetch_add_8' /usr/bin/powerpc-linux-gnu-ld: /home/doko/gcc-snapshot-20231130/build/powerpc-linux-gnu/libgcc/../../../src/libgcc/libgcov.h:423:(.text+0x798): undefined reference to `__atomic_fetch_add_8' collect2: error: ld returned 1 exit status configure:3114: $? = 1
[Bug target/109504] [12/13/14 Regression] Compilation fails with pragma GCC target sse4.1 and immintrin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109504 liuhongt at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED CC||liuhongt at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #11 from liuhongt at gcc dot gnu.org --- .
[Bug target/112778] New: [14 Regression] ICE in ppc64-linux-gnu crosscompiler in store_by_pieces, at expr.cc:1820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112778 Bug ID: 112778 Summary: [14 Regression] ICE in ppc64-linux-gnu crosscompiler in store_by_pieces, at expr.cc:1820 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fkastl at suse dot cz Target Milestone: --- Host: x86_64-linux Target: ppc64-linux-gnu Compiling the gcc.dg/strlenopt-5.c GCC testsuite testcase with ppc64-linux-gnu as target like this: ppc64-linux-gnu-gcc /home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.dg/strlenopt-5.c -finline-stringops results in and ICE: during RTL pass: expand ../src/gcc/testsuite/gcc.dg/strlenopt-5.c: In function ‘main’: ../src/gcc/testsuite/gcc.dg/strlenopt-5.c:35:3: internal compiler error: in store_by_pieces, at expr.cc:1820 35 | memset (buf, 'v', 3); | ^~~~ 0x644072 store_by_pieces(rtx_def*, unsigned long, rtx_def* (*)(void*, void*, long, fixed_size_mode), void*, unsigned int, bool, memop_ret) /home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/expr.cc:1820 0x7a1197 try_store_by_multiple_pieces(rtx_def*, rtx_def*, unsigned int, unsigned long, unsigned long, rtx_def*, char, unsigned int) /home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/builtins.cc:4456 0x7a7f63 expand_builtin_memset_args /home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/builtins.cc:4661 0x7aa174 expand_builtin_memset(tree_node*, rtx_def*, machine_mode) /home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/builtins.cc:4279 0x7aa174 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) /home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/builtins.cc:7834 0x8cbd08 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/expr.cc:12304 0x7c8366 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier) /home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/expr.h:313 0x7c8366 expand_call_stmt /home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/cfgexpand.cc:2832 0x7c8366 expand_gimple_stmt_1 /home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/cfgexpand.cc:3881 0x7c8366 expand_gimple_stmt /home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/cfgexpand.cc:4045 0x7ccd07 expand_gimple_basic_block /home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/cfgexpand.cc:6101 0x7ce9fe execute /home/worker/buildworker/tiber-gcc-trunk-ppc64/build/gcc/cfgexpand.cc:6836 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. The same error (even the same stacktrace) also occurs with ppc64-linux-gnu-gfortran /home/worker/llvm/src/flang/test/Lower/HLFIR/function-return.f90 -finline-stringops ppc64-linux-gnu-gfortran /home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/implied_do_io_4.f90 -Os -finline-stringops ppc64-linux-gnu-gfortran /home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/gomp/defaultmap-5.f90 -finline-stringops ppc64-linux-gnu-gfortran /home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gfortran.dg/verify_2.f90 -finline-stringops Compiler configuration: Using built-in specs. COLLECT_GCC=/home/worker/cross/bin/ppc64-linux-gnu-gfortran COLLECT_LTO_WRAPPER=/home/worker/cross/libexec/gcc/ppc64-linux-gnu/14.0.0/lto-wrapper Target: ppc64-linux-gnu Configured with: /home/worker/buildworker/tiber-gcc-trunk-ppc64/build/configure --enable-languages=c,c++,fortran,rust,m2 --disable-bootstrap --disable-libsanitizer --disable-multilib --enable-checking=release --prefix=/home/worker/cross --target=ppc64-linux-gnu --with-as=/usr/bin/powerpc64-suse-linux-as Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231130 (experimental) 31d8cf17ca4537e35bc7507ff1d9dfce077c0c68 (GCC)
[Bug target/110591] [i386] (Maybe) Missed optimisation: _cmpccxadd sets flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110591 liuhongt at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||liuhongt at gcc dot gnu.org --- Comment #6 from liuhongt at gcc dot gnu.org --- .
[Bug target/110227] [13/14 Regression] gcc generates invalid AVX-512 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110227 liuhongt at gcc dot gnu.org changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from liuhongt at gcc dot gnu.org --- .
[Bug target/110438] generating all-ones zmm needs dep-breaking pxor before ternlog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110438 liuhongt at gcc dot gnu.org changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from liuhongt at gcc dot gnu.org --- .
[Bug middle-end/112779] New: [OpenMP] Support omp Metadirectives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112779
Bug ID: 112779
Summary: [OpenMP] Support omp Metadirectives
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
There is a rather complete support for metadirectives on the OG13 branch, i.e.
devel/omp/gcc-13 branch.
Several patches have been already posted.
* * *
Known issues with those patches:
(A) OpenMP 5.2's renaming of clause 'default' is now (also) 'otherwise'
(B) ---
ICE (segfault) for "kind: nohost" in default()
og12-offload/testlogs-2023-05-04 shows several 'internal compiler error:
Segmentation fault' for the 'default' clause of the metadirectives
→ sollve_vv's test_metadirective_target_device{,_kind{,_any}}.c testcases.
The problem for one test case at least is in omp-general.cc's omp_dynamic_cond
:
'kind_sel' = {purpose = "kind", value = "{ purpose: "nohost", value: NULL}" } -
and accessing TREE_VALUE (TREE_VALUE (kind_sel)).
That's for the following code:
tree kind_sel = omp_get_context_selector (ctx, "target_device", "kind");
if (kind_sel)
{
const char *str
= (TREE_VALUE (TREE_VALUE (kind_sel))
? TREE_STRING_POINTER (TREE_VALUE (TREE_VALUE (kind_sel)))
: IDENTIFIER_POINTER (TREE_PURPOSE (TREE_VALUE (kind_sel;
kind = build_string_literal (strlen (str) + 1, str);
}
I wonder why that's not already handled in gcc/omp-general.cc's
omp_context_selector_matches (which has some code) – but it might indeed only
be available at run time?!?
(C) --
wonder whether libgomp/target.c's GOMP_evaluate_target_device lacks a check for
kind == "nohost" — I only see "host" (for the host) and "gpu" (for the GPU) and
the generic "any".
(D) -
Fortran's DO with do-end-label{}
Fortran permits loops with label instead of a simple END DO, example:
DO 123 i=1,5
DO 123 j=1,5
123 CONTINUE ! or '123 END DO' — Note the *shared* end-do-label (which
invalid/deleted since F2018, before deprecated but valid)
Such code is not handled with metadirectives as already indicated at
gcc/fortran/parse.cc's parse_omp_metadirective_body:
case_omp_do:
st = parse_omp_do (clause->stmt);
/* TODO: Does st == ST_IMPLIED_ENDDO need special handling? */
break;
The answer seems to be yes — failing testcase is the following ("Error: END DO
statement expected"):
implicit none
integer :: i, j, psi(5,5)!$omp metadirective &
!$omp&when(user={condition(.false. )}: target teams &
!$omp& distribute parallel do simd collapse(2)) &
!$omp&when(user={condition(.false. )}: target teams &
!$omp& distribute parallel do) &
!$omp&default(target teams loop collapse(2))
DO 50 I=1,5
!$omp metadirective &
!$omp& when(user={condition(.false. )}: simd)
DO 51 J=1,5
PSI(j,i) = j
51 CONTINUE
50 CONTINUE
end
(E) ---
internal compiler error: in c_parser_omp_metadirective, at c/c-parser.cc:26565
11 | #pragma omp metadirective when (user = { condition (USE_GPU == 1) } :
target enter data map(alloc : number[ : SIZE]))
for:
#include
#include
int main(int argc, char ** argv){
const int SIZE = 10;
int USE_GPU = 1;
double number[SIZE];
double *number_d;
#pragma omp metadirective when (user = { condition (USE_GPU == 1) } : target
enter data map(alloc : number[ : SIZE]))
if (USE_GPU)
number_d = (double *)omp_get_mapped_ptr(number,
omp_get_default_device());
else
number_d = number;
printf("number_d = %pnumber= %p\n", number_d, number);
return 0;
}
(F)
For C/C++, begin/end metadirective is not handled - it is for Fortran, where it
is much more useful.
Note: It is less useful that it sounds. From an internal bug tracker:
This was a deliberate design decision. From the OpenMP 5.0 spec (2.3.4):
"The begin metadirective directive behaves identically to the metadirective
directive, except that the directive syntax for the specified directive
variants must accept a paired end directive."
so having 'target enter data' in a 'begin metadirective' is invalid.
The only OpenMP directive supported in GCC that takes an end directive in C/C++
is 'declare target' (is this still true?), and we have already said that we
would not support declarative constructs in metadirectives. So the 'begin/end
metadirective' support was left out in C/C++.
(Invalid) testcase:
#pragma omp begin metadirective when (user = { condition
[Bug tree-optimization/112767] [14 regression] spurious -Waggressive-loop-optimizations since r14-2944-g3d48c11ad082de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112767 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Richard Biener --- Confirmed. Now with SCCP after loop splitting that's the pass exposing enough info but not eliding the loop before IVCANON comes and diagnoses this. SCCP does [local count: 119292719]: - # i_23 = PHI - # phi_24 = PHI + i_23 = 16; + phi_24 = 8; if (phi_24 != 8) and only copyprop3 removes the condition.
[Bug middle-end/111497] [11/12/13 Regression] ICE building mariadb on i686 since r8-470
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111497 --- Comment #9 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:741743c028dc00f27b9c8b1d5211c1f602f2fddd commit r13-8109-g741743c028dc00f27b9c8b1d5211c1f602f2fddd Author: Vladimir N. Makarov Date: Mon Sep 25 16:19:50 2023 -0400 [PR111497][LRA]: Copy substituted equivalence When we substitute the equivalence and it becomes shared, we can fail to correctly update reg info used by LRA. This can result in wrong code generation, e.g. because of incorrect live analysis. It can also result in compiler crash as the pseudo survives RA. This is what exactly happened for the PR. This patch solves this problem by unsharing substituted equivalences. gcc/ChangeLog: PR middle-end/111497 * lra-constraints.cc (lra_constraints): Copy substituted equivalence. * lra.cc (lra): Change comment for calling unshare_all_rtl_again. gcc/testsuite/ChangeLog: PR middle-end/111497 * g++.target/i386/pr111497.C: new test. (cherry picked from commit 3c23defed384cf17518ad6c817d94463a445d21b)
[Bug c++/112780] New: ICE: symtab_node::verify failed: "Two symbols with same comdat_group are not linked by the same_comdat_group list." with -mlong-double-128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112780 Bug ID: 112780 Summary: ICE: symtab_node::verify failed: "Two symbols with same comdat_group are not linked by the same_comdat_group list." with -mlong-double-128 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 56726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56726&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -mlong-double-128 testcase.C testcase.C:10:32: error: Two symbols with same comdat_group are not linked by the same_comdat_group list. 10 | template void foo(__float128 t); |^ _Z3fooIgEvT_/7 (void foo(T) [with T = __float128]) Type: function definition analyzed Visibility: forced_by_abi semantic_interposition no_reorder public weak comdat comdat_group:_Z3fooIgEvT_ one_only previous sharing asm name: 6 References: Referring: Function flags: body Called by: Calls: _Z3fooIgEvT_/6 (void foo(T) [with T = long double]) Type: function definition analyzed Visibility: forced_by_abi semantic_interposition no_reorder public weak comdat comdat_group:_Z3fooIgEvT_ one_only next sharing asm name: 7 References: Referring: Function flags: body Called by: Calls: testcase.C:10:32: internal compiler error: symtab_node::verify failed 0x12953f1 symtab_node::verify_symtab_nodes() /repo/gcc-trunk/gcc/symtab.cc:1412 0x12aacf0 symtab_node::checking_verify_symtab_nodes() /repo/gcc-trunk/gcc/cgraph.h:686 0x12aacf0 symbol_table::compile() /repo/gcc-trunk/gcc/cgraphunit.cc:2314 0x12ada77 symbol_table::compile() /repo/gcc-trunk/gcc/cgraphunit.cc:2311 0x12ada77 symbol_table::finalize_compilation_unit() /repo/gcc-trunk/gcc/cgraphunit.cc:2583 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-5986-2023112923-g8315f998659-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-5986-2023112923-g8315f998659-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231130 (experimental) (GCC)
[Bug target/112431] RISC-V GCC-15 feature: Support register overlap on widen RVV instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112431
--- Comment #8 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:303195e2a6b6f0e8f42e0578b61f9f37c6250beb
commit r14-6008-g303195e2a6b6f0e8f42e0578b61f9f37c6250beb
Author: Juzhe-Zhong
Date: Thu Nov 30 20:08:43 2023 +0800
RISC-V: Support widening register overlap for vf4/vf8
size_t
foo (char const *buf, size_t len)
{
size_t sum = 0;
size_t vl = __riscv_vsetvlmax_e8m8 ();
size_t step = vl * 4;
const char *it = buf, *end = buf + len;
for (; it + step <= end;)
{
vint8m1_t v0 = __riscv_vle8_v_i8m1 ((void *) it, vl);
it += vl;
vint8m1_t v1 = __riscv_vle8_v_i8m1 ((void *) it, vl);
it += vl;
vint8m1_t v2 = __riscv_vle8_v_i8m1 ((void *) it, vl);
it += vl;
vint8m1_t v3 = __riscv_vle8_v_i8m1 ((void *) it, vl);
it += vl;
asm volatile("nop" ::: "memory");
vint64m8_t vw0 = __riscv_vsext_vf8_i64m8 (v0, vl);
vint64m8_t vw1 = __riscv_vsext_vf8_i64m8 (v1, vl);
vint64m8_t vw2 = __riscv_vsext_vf8_i64m8 (v2, vl);
vint64m8_t vw3 = __riscv_vsext_vf8_i64m8 (v3, vl);
asm volatile("nop" ::: "memory");
size_t sum0 = __riscv_vmv_x_s_i64m8_i64 (vw0);
size_t sum1 = __riscv_vmv_x_s_i64m8_i64 (vw1);
size_t sum2 = __riscv_vmv_x_s_i64m8_i64 (vw2);
size_t sum3 = __riscv_vmv_x_s_i64m8_i64 (vw3);
sum += sumation (sum0, sum1, sum2, sum3);
}
return sum;
}
Before this patch:
add a3,s0,s1
add a4,s6,s1
add a5,s7,s1
vsetvli zero,s0,e64,m8,ta,ma
vle8.v v4,0(s1)
vle8.v v3,0(a3)
mv s1,s2
vle8.v v2,0(a4)
vle8.v v1,0(a5)
nop
vsext.vf8 v8,v4
vsext.vf8 v16,v2
vs8r.v v8,0(sp)
vsext.vf8 v24,v1
vsext.vf8 v8,v3
nop
vmv.x.s a1,v8
vl8re64.v v8,0(sp)
vmv.x.s a3,v24
vmv.x.s a2,v16
vmv.x.s a0,v8
add s2,s2,s5
callsumation
add s3,s3,a0
bgeus4,s2,.L5
After this patch:
add a3,s0,s1
add a4,s6,s1
add a5,s7,s1
vsetvli zero,s0,e64,m8,ta,ma
vle8.v v15,0(s1)
vle8.v v23,0(a3)
mv s1,s2
vle8.v v31,0(a4)
vle8.v v7,0(a5)
vsext.vf8 v8,v15
vsext.vf8 v16,v23
vsext.vf8 v24,v31
vsext.vf8 v0,v7
vmv.x.s a3,v0
vmv.x.s a2,v24
vmv.x.s a1,v16
vmv.x.s a0,v8
add s2,s2,s5
callsumation
add s3,s3,a0
bgeus4,s2,.L5
PR target/112431
gcc/ChangeLog:
* config/riscv/vector.md: Add widening overlap of vf2/vf4.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr112431-16.c: New test.
* gcc.target/riscv/rvv/base/pr112431-17.c: New test.
* gcc.target/riscv/rvv/base/pr112431-18.c: New test.
[Bug target/112640] [14 regression] Failed profiledbootstrap on arm64 (libgcc/config/libbid/bid128_fma.c:3569:1: internal compiler error: in extract_base_offset_in_addr, at config/aarch64/aarch64.cc:2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112640 --- Comment #10 from Jakub Jelinek --- Does this still fail? I've done a non-LTO profiledbootstrap on aarch64 as well as LTO profiledbootstrap on aarch64 recently: https://kojipkgs.fedoraproject.org//work/tasks/758/109700758/build.log https://kojipkgs.fedoraproject.org//work/tasks/5554/109705554/build.log and both were successful.
[Bug target/112777] [14 Regression] profiled bootstrap fails on powerpc-linux-gnu, undefined references to __atomic_fetch_add_8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112777 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 --- Comment #1 from Richard Biener --- I guess this was fixed by r14-5783-g8674d70ce37ca3?
[Bug testsuite/112728] gcc.dg/scantest-lto.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112728 --- Comment #3 from Jorn Wolfgang Rennecke --- (In reply to Rainer Orth from comment #0) > The gcc.dg/scantest-lto.c FAILs on quite a number of targets: ... > * On Darwin, the __TEXT,__eh_frame contains .ascii because the assembler > lacks support for cfi directives. I suppose we could handle the darwin case by: - Not doing the common scan-assembler* tests for darwin - doing a scan-assembler-times test that expects exactly how many .ascii are emitted for cfi.
[Bug tree-optimization/112774] Vectorize the loop by inferring nonwrapping information from arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112774 Richard Biener changed: What|Removed |Added Blocks||53947 Ever confirmed|0 |1 Last reconfirmed||2023-11-30 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed, though the fix should be to SCEV. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug ada/112781] New: [13?/14 regression] ICE in generic instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112781 Bug ID: 112781 Summary: [13?/14 regression] ICE in generic instantiation Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 56727 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56727&action=edit Reproducer: to be gnatchopped I'm not sure this is in fact a regression in 13; with 13.1.0, the program builds, but when run reports $ ./test Hello World raised PROGRAM_ERROR : test.adb:4 finalize/adjust raised exception With 14.0.0, built from LATEST, we get a bug box: $ gnatmake test.adb gcc -c test.adb +===GNAT BUG DETECTED==+ | 14.0.0 20231126 (experimental) (x86_64-apple-darwin21) Assert_Failure sem_ch3.adb:16970| | Error detected at example.ads:3:9 [test.adb:16:4]| | Compiling test.adb | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). test.adb example.ads compilation abandoned gnatmake: "test.adb" compilation error Reproducer (to be gnat chopped) attached.
[Bug middle-end/111925] fail to build qemu when compile with lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111925 yancheng.li at foxmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from yancheng.li at foxmail dot com --- using gcc-ar and gcc-ranlib instead of ar/ranlib could solve this problem.
[Bug tree-optimization/112766] [14 regression] spurious -Wmaybe-uninitialized with array new since r14-4089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112766 --- Comment #4 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:8a6062a47b33da6d961c6354fd5788bc46aef0a9 commit r14-6009-g8a6062a47b33da6d961c6354fd5788bc46aef0a9 Author: Richard Biener Date: Thu Nov 30 10:58:13 2023 +0100 tree-optimization/112766 - improve pruning of uninit diagnostics Uninit diagnostics has code to prune based on incoming PHI args that prove the uninit code is never executed. But that only looks at the first found flag candidate while in the PRs case only the second candidate would be the one to prune on. The following patch makes us consider all of the flag candidates which is cycles well spent IMHO. PR tree-optimization/112766 * gimple-predicate-analysis.cc (find_var_cmp_const): Support continuing the iteration and report every candidate. (uninit_analysis::overlap): Iterate over all flag var candidates. * g++.dg/torture/uninit-pr112766.C: New testcase.
[Bug tree-optimization/112767] [14 regression] spurious -Waggressive-loop-optimizations since r14-2944-g3d48c11ad082de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112767 --- Comment #4 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:2dde9f326ded84814a78c3044294b535c1f97b41 commit r14-6010-g2dde9f326ded84814a78c3044294b535c1f97b41 Author: Richard Biener Date: Thu Nov 30 12:38:53 2023 +0100 tree-optimization/112767 - spurious diagnostic after sccp/loop-split swap We are diagnosing an unreachable loop which we only manage to elide after the copyprop pass after sccp which leaves the code open for diagnosing by the intermittent ivcanon pass. The following makes sure to clean things up a bit earlier, propagating constant final values to uses immediately. PR tree-optimization/112767 * tree-scalar-evolution.cc (final_value_replacement_loop): Propagate constants to immediate uses immediately. * gcc.dg/tree-ssa/pr112767.c: New testcase. * gcc.dg/graphite/pr83255.c: Disable SCCP.
[Bug tree-optimization/112766] [14 regression] spurious -Wmaybe-uninitialized with array new since r14-4089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112766 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed. Note it's a generally latent issue.
[Bug tree-optimization/112767] [14 regression] spurious -Waggressive-loop-optimizations since r14-2944-g3d48c11ad082de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112767 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug target/112777] [14 Regression] profiled bootstrap fails on powerpc-linux-gnu, undefined references to __atomic_fetch_add_8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112777 --- Comment #2 from Matthias Klose --- that commit was from 20231123, my build is from 20231130, so it includes this patch.
[Bug fortran/112764] Associating entity does not have target attribute if selector has pointer attribute in associate block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112764 --- Comment #7 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:951a3e3749a9bf15cea3940ad4bd76d696e1b0b6 commit r14-6011-g951a3e3749a9bf15cea3940ad4bd76d696e1b0b6 Author: Harald Anlauf Date: Wed Nov 29 21:47:24 2023 +0100 Fortran: fix TARGET attribute of associating entity in ASSOCIATE [PR112764] The associating entity in an ASSOCIATE construct has the TARGET attribute if and only if the selector is a variable and has either the TARGET or POINTER attribute (e.g. F2018:11.1.3.3). gcc/fortran/ChangeLog: PR fortran/112764 * primary.cc (gfc_variable_attr): Set TARGET attribute of associating entity dependent on TARGET or POINTER attribute of selector. gcc/testsuite/ChangeLog: PR fortran/112764 * gfortran.dg/associate_62.f90: New test.
[Bug c/112782] New: [14 Regression] stage2/3 differs when compiled with -mfix-r5900 on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112782 Bug ID: 112782 Summary: [14 Regression] stage2/3 differs when compiled with -mfix-r5900 on mips Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: immoloism at googlemail dot com Target Milestone: --- While testing GCC-14 support in Gentoo I have found an interesting issue where GCC no longer builds correctly when setting -mfix-r5900. With the help of Sam James we have confirmed this causes the error in the stage 2 and 3 checks however I have been unable to find where this breakage started so far and can only confirm there is no issue using the flag with versions 12 and 13. To reproduce: (sorry for vague steps but I normally use portage to manage this) Setup a MIPS install (cross compiling does not hit the issue) Set CFLAGS to "-Os -march=mips3 -mabi=32 -mplt -pipe -mfix-r5900" Compile GCC14 as normal Error: Comparing stages 2 and 3 Bootstrap comparison failure! gcc/spellcheck.o differs gcc/tree-data-ref.o differs gcc/asan.o differs gcc/pointer-query.o differs gcc/tree-ssa-math-opts.o differs gcc/lto/lto-common.o differs gcc/lto/lto-partition.o differs gcc/tree-vectorizer.o differs gcc/gimple-range-op.o differs gcc/dwarf2out.o differs gcc/gimple-match-4.o differs gcc/gimple-ssa-warn-restrict.o differs gcc/tree-chrec.o differs gcc/function.o differs gcc/tree-vect-loop-manip.o differs gcc/tree-vrp.o differs gcc/gimple-array-bounds.o differs gcc/generic-match-2.o differs gcc/tree-vect-patterns.o differs gcc/gimple-match-5.o differs gcc/simplify-rtx.o differs gcc/tree-vect-data-refs.o differs gcc/tree-vect-slp.o differs gcc/tree-ssa-alias.o differs gcc/ipa-fnsummary.o differs gcc/tree.o differs gcc/tree-scalar-evolution.o differs gcc/splay-tree-utils.o differs gcc/lto-streamer-in.o differs gcc/fortran/trans-array.o differs gcc/fortran/trans-intrinsic.o differs gcc/fortran/interface.o differs gcc/fortran/frontend-passes.o differs gcc/fortran/openmp.o differs gcc/fortran/trans-common.o differs gcc/fortran/parse.o differs gcc/vr-values.o differs gcc/predict.o differs gcc/var-tracking.o differs gcc/mips.o differs gcc/gimple-walk.o differs gcc/tree-switch-conversion.o differs gcc/tree-ssa-loop-prefetch.o differs gcc/optabs.o differs gcc/rtl-ssa/accesses.o differs gcc/omp-offload.o differs gcc/tree-ssa-phiopt.o differs gcc/symtab.o differs gcc/gimple-match-7.o differs gcc/value-range.o differs gcc/tree-ssa-operands.o differs gcc/sel-sched-ir.o differs gcc/tree-ssa-sink.o differs gcc/tree-ssa-reassoc.o differs gcc/analyzer/region-model.o differs gcc/analyzer/checker-path.o differs gcc/analyzer/program-point.o differs gcc/analyzer/sm-file.o differs gcc/analyzer/region.o differs gcc/analyzer/call-details.o differs gcc/analyzer/diagnostic-manager.o differs gcc/analyzer/sm-fd.o differs gcc/analyzer/sm-malloc.o differs gcc/analyzer/record-layout.o differs gcc/analyzer/constraint-manager.o differs gcc/analyzer/program-state.o differs gcc/analyzer/access-diagram.o differs gcc/analyzer/infinite-recursion.o differs gcc/analyzer/call-summary.o differs gcc/analyzer/engine.o differs gcc/analyzer/store.o differs gcc/analyzer/supergraph.o differs gcc/analyzer/feasible-graph.o differs gcc/tree-cfg.o differs gcc/gimple-match-6.o differs gcc/tree-inline.o differs gcc/tree-ssa-ccp.o differs gcc/haifa-sched.o differs gcc/input.o differs gcc/loop-init.o differs gcc/gcov.o differs gcc/cfgrtl.o differs gcc/ipa-utils.o differs gcc/gimple-ssa-warn-access.o differs gcc/combine.o differs gcc/wide-int.o differs gcc/tree-vect-loop.o differs gcc/gimple-match-8.o differs gcc/passes.o differs gcc/cfg.o differs gcc/ipa-devirt.o differs gcc/tree-ssa-dom.o differs gcc/final.o differs gcc/tree-ssa-loop-unswitch.o differs gcc/read-md.o differs gcc/text-art/styled-string.o differs gcc/text-art/widget.o differs gcc/text-art/style.o differs gcc/text-art/table.o differs gcc/gimple-match-2.o differs gcc/generic-match-5.o differs gcc/tree-ssa-threadedge.o differs gcc/fold-const.o differs gcc/varasm.o differs gcc/modulo-sched.o differs gcc/omp-low.o differs gcc/tree-pretty-print.o differs gcc/gimplify.o differs gcc/gimple-range-path.o differs gcc/cgraphunit.o differs gcc/generic-match-4.o differs gcc/print-rtl.o differs gcc/sched-deps.o differs gcc/gimple-ssa-strength-reduction.o differs gcc/gimple-match-3.o differs gcc/gimple-fold.o differs gcc/df-core.o differs gcc/dwarf2cfi.o differs gcc/tree-ssa-loop-niter.o differs gcc/gimple-match-10.o differs gcc/tree-ssa-uncprop.o differs gcc/gimple-match-9.o differs gcc/build/print-rtl.o differs gcc/build/genmatch.o differs gcc/build/genrecog.o differs gcc/build/read-md.o differs gcc/c-family/c-common.o differs gcc/c-family/c-omp.o differs gcc/c-family/c-warn.o differs gcc/value-range-storage.o differs gcc/tree-eh.o differs gcc/gimple-match-1.o d
[Bug c/112782] [14 Regression] stage2/3 differs when compiled with -mfix-r5900 on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112782 --- Comment #1 from Immolo --- Created attachment 56728 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56728&action=edit build log
[Bug c/112782] [14 Regression] stage2/3 differs when compiled with -mfix-r5900 on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112782 --- Comment #2 from Immolo --- Created attachment 56729 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56729&action=edit spellcheck.o Output of stage2 and stage3 spellcheck.o
[Bug ipa/112783] New: core dump on libxo when function is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783
Bug ID: 112783
Summary: core dump on libxo when function is inlined
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: yancheng.li at foxmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hi all, i meet a segment fault when using libxo compiled with gcc 10 or gcc
trunk.
I found we can skip this problem when add attribute((noinline)) on the wrong
function "xo_xml_leader_len".
we can use these following commands to reproduce the problem:
```
yum install libtool git make
cp /usr/include/linux/sysctl.h /usr/include/sys/sysctl.h
git clone http://github.com/Juniper/libxo.git
sh bin/setup.sh
cd build
../configure
make
make install
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib/
[root@localhost build]# cat test.c
#include
int main(int argc, char *argv[])
{
xo_emit("{d:/%-*.*s}{etk:name}{eq:flags/0x%x}", 0, 0, NULL, NULL, 0);
}
gcc test.c -g -L /usr/local/lib/ -lxo -I /usr/local/include/libxo -o test
./test
Segmentation fault (core dumped)
Program received signal SIGSEGV, Segmentation fault.
0xf7f9d4b8 in xo_xml_leader_len (nlen=0, name=0x0, xop=0xf7ddbe00)
at ../../libxo/libxo.c:567
567 if (name == NULL || isalpha(name[0]) || name[0] == '_')
(gdb) bt
#0 0xf7f9d4b8 in xo_xml_leader_len (nlen=0, name=0x0,
xop=0xf7ddbe00) at ../../libxo/libxo.c:567
#1 xo_format_value (xop=xop@entry=0xf7ddbe00, name=name@entry=0x0,
nlen=nlen@entry=0, value=value@entry=0x0, vlen=vlen@entry=0, fmt=0x4006e4
"%-*.*s}{etk:name}{eq:flags/0x%x}", flen=6, encoding=0x0, elen=0,
flags=flags@entry=64) at ../../libxo/libxo.c:4362
#2 0xf7f9f434 in xo_do_emit_fields (xop=xop@entry=0xf7ddbe00,
fields=fields@entry=0xe940, max_fields=max_fields@entry=9, fmt=0x4006e0
"{d:/%-*.*s}{etk:name}{eq:flags/0x%x}")
at ../../libxo/libxo.c:6372
#3 0xf7f9fa60 in xo_do_emit (xop=xop@entry=0xf7ddbe00,
flags=, flags@entry=0, fmt=fmt@entry=0x4006e0
"{d:/%-*.*s}{etk:name}{eq:flags/0x%x}") at ../../libxo/libxo.c:6551
#4 0xf7f9fd04 in xo_emit (fmt=0x4006e0
"{d:/%-*.*s}{etk:name}{eq:flags/0x%x}") at ../../libxo/libxo.c:6622
#5 0x004006b4 in main (argc=1, argv=0xef98) at test.c:5
```
[Bug target/112777] [14 Regression] profiled bootstrap fails on powerpc-linux-gnu, undefined references to __atomic_fetch_add_8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112777
--- Comment #3 from Sebastian Huber ---
I think the issue is in c-cppbuiltin.cc:
builtin_define_with_int_value ("__LIBGCC_HAVE_LIBATOMIC",
targetm.have_libatomic);
Which is used in libgcov.h like this:
/* Detect whether target can support atomic update of profilers. */
#if (__SIZEOF_LONG_LONG__ == 4 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4) \
|| (__SIZEOF_LONG_LONG__ == 8 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8) \
|| defined (__LIBGCC_HAVE_LIBATOMIC)
#define GCOV_SUPPORTS_ATOMIC 1
#else
#define GCOV_SUPPORTS_ATOMIC 0
#endif
Should I keep the defined (__LIBGCC_HAVE_LIBATOMIC) and change c-cppbuiltin.cc
to:
if (targetm.have_libatomic)
builtin_define ("__LIBGCC_HAVE_LIBATOMIC");
Or, should I change libgcov.h to use:
#if (__SIZEOF_LONG_LONG__ == 4 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4) \
|| (__SIZEOF_LONG_LONG__ == 8 && __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8) \
|| __LIBGCC_HAVE_LIBATOMIC
[Bug target/103100] [11/12/13/14 Regression] unaligned access generated with memset or {} and -O2 -mstrict-align
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103100 --- Comment #25 from GCC Commits --- The master branch has been updated by Wilco Dijkstra : https://gcc.gnu.org/g:318f5232cfb3e0c9694889565e1f5424d0354463 commit r14-6012-g318f5232cfb3e0c9694889565e1f5424d0354463 Author: Wilco Dijkstra Date: Wed Oct 25 16:28:04 2023 +0100 AArch64: Fix strict-align cpymem/setmem [PR103100] The cpymemdi/setmemdi implementation doesn't fully support strict alignment. Block the expansion if the alignment is less than 16 with STRICT_ALIGNMENT. Clean up the condition when to use MOPS. gcc/ChangeLog/ PR target/103100 * config/aarch64/aarch64.md (cpymemdi): Remove pattern condition. (setmemdi): Likewise. * config/aarch64/aarch64.cc (aarch64_expand_cpymem): Support strict-align. Cleanup condition for using MOPS. (aarch64_expand_setmem): Likewise.
[Bug bootstrap/112782] [14 Regression] stage2/3 differs when compiled with -mfix-r5900 on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112782 Richard Biener changed: What|Removed |Added Component|c |bootstrap Target||mips Target Milestone|--- |14.0
[Bug ada/112781] [13?/14 regression] ICE in generic instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112781 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.3
[Bug middle-end/112784] New: ICE in smallest_mode_for_size, at stor-layout.cc:356 | -finline-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112784
Bug ID: 112784
Summary: ICE in smallest_mode_for_size, at stor-layout.cc:356 |
-finline-stringops
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mjires at suse dot cz
CC: aoliva at gcc dot gnu.org
Target Milestone: ---
Compiling reduced testcase c-c++-common/torture/builtin-clear-padding-2.c
results in ICE with new -finline-stringops.
$ cat builtin-clear-padding-2.c
struct S {
int e;
} __attribute__((aligned(128)));
int main() {
struct S s1;
struct S s2;
int v = __builtin_memcmp(&s1, &s2, sizeof(s1));
}
$ gcc builtin-clear-padding-2.c -mavx512cd -finline-stringops
during RTL pass: expand
builtin-clear-padding-2.c: In function ‘main’:
builtin-clear-padding-2.c:8:11: internal compiler error: in
smallest_mode_for_size, at stor-layout.cc:356
8 | int v = __builtin_memcmp(&s1, &s2, sizeof(s1));
| ^~
0x10111ef smallest_mode_for_size(poly_int<1u, unsigned long>, mode_class)
/home/mjires/git/GCC/master/gcc/stor-layout.cc:356
0xc19bc2 smallest_int_mode_for_size(poly_int<1u, unsigned long>)
/home/mjires/git/GCC/master/gcc/machmode.h:916
0xc19bc2 emit_block_cmp_via_loop
/home/mjires/git/GCC/master/gcc/expr.cc:2705
0xab40ab expand_builtin_memcmp
/home/mjires/git/GCC/master/gcc/builtins.cc:4825
0xabea1f expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/mjires/git/GCC/master/gcc/builtins.cc:7893
0xc0e9e4 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/mjires/git/GCC/master/gcc/expr.cc:12304
0xc1b4d5 store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/mjires/git/GCC/master/gcc/expr.cc:6711
0xc21870 expand_assignment(tree_node*, tree_node*, bool)
/home/mjires/git/GCC/master/gcc/expr.cc:6432
0xc21870 expand_assignment(tree_node*, tree_node*, bool)
/home/mjires/git/GCC/master/gcc/expr.cc:5947
0xae9026 expand_call_stmt
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:2830
0xae9026 expand_gimple_stmt_1
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:3881
0xae9026 expand_gimple_stmt
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:4045
0xaea307 expand_gimple_basic_block
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:6101
0xaebf66 execute
/home/mjires/git/GCC/master/gcc/cfgexpand.cc:6836
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --disable-bootstrap --enable-checking
--enable-languages=c,c++,fortran,lto
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231130 (experimental) (GCC)
[Bug fortran/102689] Segfault with RESHAPE of CLASS as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102689 --- Comment #2 from Paul Thomas --- Created attachment 56730 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56730&action=edit Another failing testcase With the attached, we should get: [pault@pc30 pr87477]$ rm ./a.out;ifort ~/prs/pr102689/pr1*.f90 ;./a.out type is 's' at line0 type is 's' at line2 type is 's' at line3 type is 's' at line4 type is 's' at line5 whereas gfortran gives type is 's' at line0 type is 't' at line2 line 2 1275 should be 5050 type is 't' at line3 line 3 1275 should be 5050 type is 't' at line4 line 4 1275 should be 5050 type is 't' at line5 line 5 1275 should be 5050
[Bug tree-optimization/112785] New: ICE: in duplicate_insn_chain, at cfgrtl.cc:4386 with -O1 -funroll-all-loops --param=max-unroll-times=100000 --param=max-average-unrolled-insns=1000000 --param=max-u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112785 Bug ID: 112785 Summary: ICE: in duplicate_insn_chain, at cfgrtl.cc:4386 with -O1 -funroll-all-loops --param=max-unroll-times=10 --param=max-average-unrolled-insns=100 --param=max-unrolled-insns=100 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: rguenth at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 56731 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56731&action=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O1 -funroll-all-loops --param=max-unroll-times=10 --param=max-average-unrolled-insns=100 --param=max-unrolled-insns=100 testcase.C during RTL pass: loop2_unroll testcase.C: In function 'void foo()': testcase.C:25:1: internal compiler error: in duplicate_insn_chain, at cfgrtl.cc:4386 25 | } | ^ 0x807a7b duplicate_insn_chain(rtx_insn*, rtx_insn*, loop*, copy_bb_data*) /repo/gcc-trunk/gcc/cfgrtl.cc:4386 0x128a37f cfg_layout_duplicate_bb /repo/gcc-trunk/gcc/cfgrtl.cc:4474 0x126d3ca duplicate_block(basic_block_def*, edge_def*, basic_block_def*, copy_bb_data*) /repo/gcc-trunk/gcc/cfghooks.cc:1119 0x126db7e copy_bbs(basic_block_def**, unsigned int, basic_block_def**, edge_def**, unsigned int, edge_def**, loop*, basic_block_def*, bool) /repo/gcc-trunk/gcc/cfghooks.cc:1384 0x127b751 duplicate_loop_body_to_header_edge(loop*, edge_def*, unsigned int, simple_bitmap_def*, edge_def*, vec*, int) /repo/gcc-trunk/gcc/cfgloopmanip.cc:1403 0x15c4f95 unroll_loop_stupid /repo/gcc-trunk/gcc/loop-unroll.cc:1252 0x15c4f95 unroll_loops(int) /repo/gcc-trunk/gcc/loop-unroll.cc:299 0x15b27cc execute /repo/gcc-trunk/gcc/loop-init.cc:592 0x15b27cc execute /repo/gcc-trunk/gcc/loop-init.cc:579 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. (gdb) p cfun->last_clique $1 = 0 It has probably wrapped to 0 from 65535 $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-5986-2023112923-g8315f998659-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-5986-2023112923-g8315f998659-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231130 (experimental) (GCC)
[Bug c++/110734] Attributes cannot be applied to asm declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734 Julian Waters changed: What|Removed |Added Attachment #56717|0 |1 is obsolete|| --- Comment #8 from Julian Waters --- Created attachment 56732 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56732&action=edit Attribute for asm declarations
[Bug tree-optimization/112785] ICE: in duplicate_insn_chain, at cfgrtl.cc:4386 with -O1 -funroll-all-loops --param=max-unroll-times=100000 --param=max-average-unrolled-insns=1000000 --param=max-unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112785 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-11-30 --- Comment #1 from Richard Biener --- Thanks, I'll have a look.
[Bug target/112698] gcc r14-5617-gb8592186611 introduces regressions in bfloat16_vector_typecheck_1.c for cortex-m0 and cortex-m3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698 --- Comment #2 from GCC Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:d77d2dd9bdea7b8963db2a0a06ca481458ef2c98 commit r14-6018-gd77d2dd9bdea7b8963db2a0a06ca481458ef2c98 Author: Christophe Lyon Date: Thu Nov 30 10:10:24 2023 + testsuite/arm: Fix bfloat16_vector_typecheck_[12].c tests [PR 112698] After commit r14-5617-gb8592186611, int32x[24]_t types now use elements of 'long int' type instead of 'int' on arm-eabi (it's still 'int' on arm-linux-gnueabihf). Both are 32-bit types anyway. This patch adjust the two tests so that they optionnally accept 'long ' before 'int' in the expected error message. 2023-11-30 Christophe Lyon PR target/112698 gcc/testsuite/ * gcc.target/arm/bfloat16_vector_typecheck_1.c: Update expected error message. * gcc.target/arm/bfloat16_vector_typecheck_2.c: Likewise.
[Bug target/112698] gcc r14-5617-gb8592186611 introduces regressions in bfloat16_vector_typecheck_1.c for cortex-m0 and cortex-m3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698 Christophe Lyon changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-11-30 --- Comment #3 from Christophe Lyon --- gcc.target/arm/bfloat16_vector_typecheck_[12].c testcases fixed. There's still a problem with experimental/simd/pr109261_constexpr_simd.cc, which may involve a change to simd_neon.h or simd.h
[Bug driver/112759] [13/14 regression] mips -march=native detection broken with gcc 13+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759
--- Comment #3 from matoro ---
(In reply to Andrew Pinski from comment #2)
> Hmm, looks like it is this part of the change:
> + if (cpu)
> +ret = reconcat (ret, ret, "-m", argv[0], "=", cpu, NULL);
>
> - return concat ("-m", argv[0], "=", cpu, NULL);
>
>
> Maybe it should have been:
> ```
> if (cpu)
> {
> if (!ret)
> ret = concat ("-m", argv[0], "=", cpu, NULL);
> else
> ret = reconcat (ret, ret, "-m", argv[0], "=", cpu, NULL);
> }
> ```
>
> Can you try that?
Indeed fixes it, thanks!
[Bug bootstrap/110275] [14 Regression] trunk fails to build with binutils trunk on riscv64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110275 Matthias Klose changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Matthias Klose --- this works for me now with binutils trunk 20231125 and gcc trunk 20231125.
[Bug target/112698] gcc r14-5617-gb8592186611 introduces regressions in bfloat16_vector_typecheck_1.c for cortex-m0 and cortex-m3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698 --- Comment #4 from Christophe Lyon --- @mkretz, this commit may also be of interest for some more context: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d12d2aa4fccc76a9a08c8120c5e37d9cab8683e8
[Bug c++/110734] Attributes cannot be applied to asm declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #9 from Xi Ruoyao --- (In reply to Julian Waters from comment #8) > Created attachment 56732 [details] > Attribute for asm declarations Please just fix this issue (i.e. make [[gnu::no_reorder]] work) instead of adding fancy new features. Now we are in stage 3 of GCC 14 so any fancy new feature should be deferred into stage 1 of GCC 15.
[Bug c++/110734] Attributes cannot be applied to asm declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734 --- Comment #10 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #9) > (In reply to Julian Waters from comment #8) > > Created attachment 56732 [details] > > Attribute for asm declarations > > Please just fix this issue (i.e. make [[gnu::no_reorder]] work) instead of > adding fancy new features. Now we are in stage 3 of GCC 14 so any fancy new > feature should be deferred into stage 1 of GCC 15. Ok, I see you are only using no_reorder as an example. Then try to make the existing attributes work instead of adding a new one.
[Bug c++/110734] Attributes cannot be applied to asm declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #11 from Marek Polacek --- (In reply to Xi Ruoyao from comment #10) > (In reply to Xi Ruoyao from comment #9) > > (In reply to Julian Waters from comment #8) > > > Created attachment 56732 [details] > > > Attribute for asm declarations > > > > Please just fix this issue (i.e. make [[gnu::no_reorder]] work) instead of > > adding fancy new features. Now we are in stage 3 of GCC 14 so any fancy new > > feature should be deferred into stage 1 of GCC 15. > > Ok, I see you are only using no_reorder as an example. Then try to make the > existing attributes work instead of adding a new one. I agree. I can hardly see the need for a new and a very complicated attribute.
[Bug target/111404] [AArch64] 128-bit __sync_val_compare_and_swap is not atomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111404 --- Comment #2 from GCC Commits --- The master branch has been updated by Wilco Dijkstra : https://gcc.gnu.org/g:df8958e6bc5d050dab8bdc5954c1632fb0e98d18 commit r14-6021-gdf8958e6bc5d050dab8bdc5954c1632fb0e98d18 Author: Wilco Dijkstra Date: Thu Nov 30 16:14:35 2023 + AArch64: Fix __sync_val_compare_and_swap [PR111404] __sync_val_compare_and_swap may be used on 128-bit types and either calls the outline atomic code or uses an inline loop. On AArch64 LDXP is only atomic if the value is stored successfully using STXP, but the current implementations do not perform the store if the comparison fails. In this case the value returned is not read atomically. gcc/ChangeLog: PR target/111404 * config/aarch64/aarch64.cc (aarch64_split_compare_and_swap): For 128-bit store the loaded value and loop if needed. libgcc/ChangeLog: PR target/111404 * config/aarch64/lse.S (__aarch64_cas16_acq_rel): Execute STLXP using either new value or loaded value.
[Bug middle-end/112771] during GIMPLE pass: bitintlower0 ICE: in build_bitint_type, at tree.cc:7178 with _BitInt(65535) and division by zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112771 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-11-30 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Created attachment 56733 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56733&action=edit gcc14-pr112771.patch Untested fix. Thanks for the report.
[Bug testsuite/112786] New: [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and scev-5.c XPASSing on most ilp32 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112786 Bug ID: 112786 Summary: [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and scev-5.c XPASSing on most ilp32 targets Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: testsuite-fail Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: aoliva at gcc dot gnu.org Blocks: 96831 Target Milestone: --- Target: cris-elf, m68k-linux-gnu, arm-eabi, pru-elf, ft32-elf, c6x-elf, epiphany-elf, lm32-elf, microblaze-linux, m32r-elf, mcore-elf, shle-linux This tracks the three regressions for most ilp32 targets (see target field; default configurations only) that were appearing with r14-5608-g69741355e6dbcf; regressions because they didn't show up before, in particular as a XPASS. For discussing underlying issues, PR96831 is probably a better choice. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96831 [Bug 96831] gcc.dg/tree-ssa/scev-[345].c FAIL on i?86 and arm
[Bug testsuite/112786] [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and scev-5.c XPASSing on most ilp32 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112786 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |hp at gcc dot gnu.org Last reconfirmed||2023-11-30
[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773
Patrick O'Neill changed:
What|Removed |Added
Attachment #56724|0 |1
is obsolete||
--- Comment #2 from Patrick O'Neill ---
Created attachment 56734
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56734&action=edit
-freport-bug output
I'm still seeing this on the most recent trunk: r14-6020-g18d8a50a042
> ./bin/riscv64-unknown-linux-gnu-gcc -march=rv32gcv_zvl256b -mabi=ilp32d -O3
> -S red.c
during RTL pass: expand
red.c: In function 'e':
red.c:4:6: internal compiler error: in force_align_down_and_div, at
poly-int.h:1828
4 | void e(unsigned f) {
... (trimmed)
I've updated the -freport-bug-output with the most recent run.
[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601 --- Comment #27 from Jeevitha --- Jakub's patch fixed the issue on powerpc64le-linux-gnu
[Bug target/112787] New: Codegen regression of large GCC vector extensions when enabling SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787
Bug ID: 112787
Summary: Codegen regression of large GCC vector extensions when
enabling SVE
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
When compiling:
typedef int __attribute__((__vector_size__ (64))) vec;
vec fn (vec a, vec b)
{
return a + b;
}
with '-O2 -march=armv8-a' vs '-O2 -march=armv8-a+sve' the codegen defaults to
scalar rather than using Advanced SIMD vectors.
[Bug target/112787] Codegen regression of large GCC vector extensions when enabling SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112787 avieira at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |avieira at gcc dot gnu.org Last reconfirmed||2023-11-30 Target||aarch64 --- Comment #1 from avieira at gcc dot gnu.org --- The problem is veclower tries to find the largest vector type it can use for a particular element type, which when SVE is enabled without a specified vector length will always be a VLA type. This then fails the check of it having less elements than the type being used to do the computation, given that a VLA element count is never 'known_lt' a constant one. I am currently testing a patch that makes sure the mode selected does not have more elements than the type we are trying to compute, given that it wouldn't be used anyway.
[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922 --- Comment #13 from Andrew Macleod --- Created attachment 56735 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56735&action=edit patch (In reply to Sam James from comment #12) > Is the plan to backport to 11/12/13 or to leave it? hmm. I don't think I would apply the same patch (it wouldn't work as is anyway), but if we wanted to fix this in earlier releases we could simply have the custom fold_ranges return false when the precision doesn't match... it would at least avoid most of these traps in earlier releases...? The attached patch for instance would probably apply to GCC 13, 12 and 11.. I can test these if we want to do that...
[Bug target/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112740
--- Comment #5 from Andrew Pinski ---
x86_64 IR:
c.0_6 = c_5(D);
_2 = (__int128 unsigned) c.0_6;
_1 = {_2};
_10 = VIEW_CONVERT_EXPR<__int128 unsigned>(v_7(D));
_11 = _10 >= _2;
_12 = (int128_t) _11;
_13 = -_12;
_14 = () _13;
_3 = {_14};
_15 = _12 + -1;
_16 = () _15;
_4 = {_16};
_8 = VIEW_CONVERT_EXPR(_4);
aarch64 (and I think riscv) IR:
c.0_6 = c_5(D);
_2 = (__int128 unsigned) c.0_6;
_1 = {_2};
_10 = VIEW_CONVERT_EXPR<__int128 unsigned>(v_7(D));
_11 = _10 >= _2;
_12 = (int128_t) _11;
_13 = -_12;
_14 = () _13;
_3 = {_14};
_4 = ~_3;
_15 = VIEW_CONVERT_EXPR<>(_4);
_16 = _15 != 0;
_17 = (__int128 unsigned) _16;
_18 = -_17;
_8 = {_18};
[Bug c++/112769] ICE on valid code related to requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112769
--- Comment #1 from janpmoeller at gmx dot de ---
The following equivalent program does not trigger the ICE:
//
template
concept C = requires (U u) { T{u}; };
template
struct type
{
constexpr explicit type(T value)
{
}
template
constexpr explicit type(type value)
requires C>
{
}
};
template
using alias = type<0, T>;
constexpr alias foo{123};
//
[Bug other/112788] New: [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788 Bug ID: 112788 Summary: [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6 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:ea19de921b01a6ab470929f8da4dde526edb08f1, r14-5972-gea19de921b01a6 make -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/float128-hw4.c" FAIL: gcc.target/powerpc/float128-hw4.c (internal compiler error: in fold_range, at range-op.cc:206) FAIL: gcc.target/powerpc/float128-hw4.c (test for excess errors) # of unexpected failures2 # of unresolved testcases 16 Also: FAIL: gcc.target/powerpc/pr82748-1.c (internal compiler error: in fold_range, at range-op.cc:206) FAIL: gcc.target/powerpc/pr82748-1.c (test for excess errors) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/float128-hw4.c -fdiagnostics-plain-output -mpower9-vector -O2 -mabi=ieeelongdouble -Wno-psabi -ffat-lto-objects -fno-ident -S -o float128-hw4.s during GIMPLE pass: evrp /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/float128-hw4.c: In function 'nfma_odd': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/float128-hw4.c:119:1: internal compiler error: in fold_range, at range-op.cc:206 0x10bb131b range_op_handler::fold_range(vrange&, tree_node*, vrange const&, vrange const&, relation_trio) const /home/seurer/gcc/git/gcc-test/gcc/range-op.cc:206 0x11bfa13f fold_using_range::range_of_range_op(vrange&, gimple_range_op_handler&, fur_source&) /home/seurer/gcc/git/gcc-test/gcc/gimple-range-fold.cc:678 0x11bfb003 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&, tree_node*) /home/seurer/gcc/git/gcc-test/gcc/gimple-range-fold.cc:602 0x11bfb75b fold_range(vrange&, gimple*, range_query*) /home/seurer/gcc/git/gcc-test/gcc/gimple-range-fold.cc:322 0x11be4203 ranger_cache::get_global_range(vrange&, tree_node*, bool&) /home/seurer/gcc/git/gcc-test/gcc/gimple-range-cache.cc:1052 0x11bd5b97 gimple_ranger::range_of_stmt(vrange&, gimple*, tree_node*) /home/seurer/gcc/git/gcc-test/gcc/gimple-range.cc:311 0x1119ba4f range_query::value_of_stmt(gimple*, tree_node*) /home/seurer/gcc/git/gcc-test/gcc/value-query.cc:113 0x1113f4ab rvrp_folder::value_of_stmt(gimple*, tree_node*) /home/seurer/gcc/git/gcc-test/gcc/tree-vrp.cc:999 0x10fbe62f substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) /home/seurer/gcc/git/gcc-test/gcc/tree-ssa-propagate.cc:820 0x11b5514b dom_walker::walk(basic_block_def*) /home/seurer/gcc/git/gcc-test/gcc/domwalk.cc:311 0x10fbcd5b substitute_and_fold_engine::substitute_and_fold(basic_block_def*) /home/seurer/gcc/git/gcc-test/gcc/tree-ssa-propagate.cc:999 0x1113a74b execute_ranger_vrp(function*, bool, bool) /home/seurer/gcc/git/gcc-test/gcc/tree-vrp.cc:1064 commit ea19de921b01a6ab470929f8da4dde526edb08f1 (HEAD) Author: Andrew MacLeod Date: Tue Nov 28 09:39:30 2023 -0500 Add operand_check_p to range-ops.
[Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788 Andrew Pinski changed: What|Removed |Added Component|other |tree-optimization Target Milestone|--- |14.0 Keywords||ice-on-valid-code
[Bug sanitizer/112748] memmove(ptr, ptr, n) call optimized out even at -O0 with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112748
--- Comment #4 from Jakub Jelinek ---
So, do we want something like
--- gcc/gimple-fold.cc.jj 2023-11-02 12:15:12.205998817 +0100
+++ gcc/gimple-fold.cc 2023-11-30 20:24:01.092095623 +0100
@@ -5083,12 +5083,16 @@ gimple_fold_builtin (gimple_stmt_iterato
return gimple_fold_builtin_bzero (gsi);
case BUILT_IN_MEMSET:
+ if (!optimize)
+ return false;
return gimple_fold_builtin_memset (gsi,
gimple_call_arg (stmt, 1),
gimple_call_arg (stmt, 2));
case BUILT_IN_MEMCPY:
case BUILT_IN_MEMPCPY:
case BUILT_IN_MEMMOVE:
+ if (!optimize)
+ return false;
return gimple_fold_builtin_memory_op (gsi, gimple_call_arg (stmt, 0),
gimple_call_arg (stmt, 1), fcode);
case BUILT_IN_SPRINTF_CHK:
(and repeat for many other builtins)?
I'm afraid we can't do if (!optimize) return false; for all builtins in
gimple_fold_builtin, because some builtins by design must be always folded and
never expand. E.g. __builtin_clear_padding,
__builtin_{clz,ctz,clrsb,ffs,popcount,parity}g,
__builtin_{add,sub,mul}_overflow{,_p} and many others.
expand_builtin has
/* When not optimizing, generate calls to library functions for a certain
set of builtins. */
if (!optimize
&& !called_as_built_in (fndecl)
&& fcode != BUILT_IN_FORK
&& fcode != BUILT_IN_EXECL
&& fcode != BUILT_IN_EXECV
&& fcode != BUILT_IN_EXECLP
&& fcode != BUILT_IN_EXECLE
&& fcode != BUILT_IN_EXECVP
&& fcode != BUILT_IN_EXECVE
&& fcode != BUILT_IN_CLEAR_CACHE
&& !ALLOCA_FUNCTION_CODE_P (fcode)
&& fcode != BUILT_IN_FREE
&& (fcode != BUILT_IN_MEMSET
|| !(flag_inline_stringops & ILSOP_MEMSET))
&& (fcode != BUILT_IN_MEMCPY
|| !(flag_inline_stringops & ILSOP_MEMCPY))
&& (fcode != BUILT_IN_MEMMOVE
|| !(flag_inline_stringops & ILSOP_MEMMOVE))
&& (fcode != BUILT_IN_MEMCMP
|| !(flag_inline_stringops & ILSOP_MEMCMP)))
return expand_call (exp, target, ignore);
Perhaps just a general
if (!optimize && !called_as_built_in (fndecl))
return false;
at the start of gimple_fold_builtin? Or do we want to let some exceptions?
Do we also apply GIMPLE match.pd simplification at -O0?
[Bug target/112753] [14 Regression] unrecognizable insn building glibc for s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112753
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
I think
--- gcc/config/s390/s390.cc.jj 2023-11-30 21:18:50.678840298 +0100
+++ gcc/config/s390/s390.cc 2023-11-30 21:27:28.952545221 +0100
@@ -17604,6 +17604,10 @@ s390_md_asm_adjust (vec &outputs, v
outputs[i] = fprx2;
}
+ if (!TARGET_VXE)
+/* Long doubles are stored in FPR pairs - nothing to do. */
+return after_md_seq;
+
for (unsigned i = 0; i < ninputs; i++)
{
if (GET_MODE (inputs[i]) != TFmode)
should fix this.
[Bug fortran/112772] Some issues with OPTIONAL, ALLOCATABLE dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112772 --- Comment #1 from anlauf at gcc dot gnu.org --- Created attachment 56736 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56736&action=edit Fix for testcase 1 The attached rather obvious patch fixes the copy-out issue for class dummies and regtests ok.
[Bug c++/112789] New: Missing clang __builtin_ctzs for short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789 Bug ID: 112789 Summary: Missing clang __builtin_ctzs for short Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gonzalo.gadeschi at gmail dot com Target Milestone: --- GCC is missing clang's __builtin_ctzs .
[Bug c++/112789] Missing clang __builtin_ctzs for short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789 --- Comment #1 from Andrew Pinski --- ok, and?
[Bug target/112753] [14 Regression] unrecognizable insn building glibc for s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112753 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2023-11-30 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 56737 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56737&action=edit gcc14-pr112753.patch Full patch I'm going to bootstrap/regtest now.
[Bug c++/112789] Missing clang __builtin_ctzs for short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Andrew Pinski --- Anyways GCC 14 adds __builtin_ctzg, __builtin_stdc_first_trailing_one, and __builtin_stdc_trailing_zeros : https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fctzg
[Bug fortran/112772] Some issues with OPTIONAL, ALLOCATABLE dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112772 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Fix for first testcase submitted: https://gcc.gnu.org/pipermail/fortran/2023-November/059976.html
[Bug c++/112789] Missing clang __builtin_ctzs for short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789 --- Comment #3 from Andrew Pinski --- Also clang does not even document __builtin_ctzs anywhere ...
[Bug middle-end/112572] [14 regression] LLVM miscompiled since r14-5355-g3cd3a09b3f91a1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572 --- Comment #28 from Jakub Jelinek --- So, what is the state here? Andrew, are you going to post the #c18 patch? Do we have a reduced testcase?
[Bug middle-end/112572] [14 regression] LLVM miscompiled since r14-5355-g3cd3a09b3f91a1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572 --- Comment #29 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #28) > So, what is the state here? Andrew, are you going to post the #c18 patch? > Do we have a reduced testcase? I was hoping someone else would take over since there seems to be a disagreement of if the bug is in compare-elim or in postreload pass. As far as a reduced testcase, I don't think we have one.
[Bug analyzer/112790] New: -Wanalyzer-deref-before-check false positives seen in Linux kernel due to inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112790
Bug ID: 112790
Summary: -Wanalyzer-deref-before-check false positives seen in
Linux kernel due to inlining
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
https://godbolt.org/z/4fjjcfbPb
False positive on:
typedef unsigned char u8;
struct inode {
void *i_mapping;
u8 i_blkbits;
};
struct block_device {
struct inode *bd_inode;
};
int sync_blockdev(struct block_device *bdev);
int set_blocksize(struct block_device *bdev, u8 size) {
if (bdev->bd_inode->i_blkbits != size) {
sync_blockdev(bdev);
}
return 0;
}
extern int filemap_write_and_wait(void *);
int sync_blockdev(struct block_device *bdev) {
if (!bdev)
return 0;
return filemap_write_and_wait(bdev->bd_inode->i_mapping);
}
$ xgcc B. -Wall -fno-delete-null-pointer-checks -O2 -fanalyzer -g -S
False positive:
In function ‘sync_blockdev’,
inlined from ‘set_blocksize’ at t.c:12:5:
t.c:18:6: warning: check of ‘bdev’ for NULL after already dereferencing it
[-Wanalyzer-deref-before-check]
18 | if (!bdev)
| ^
‘set_blocksize’: events 1-4
|
| 11 | if (bdev->bd_inode->i_blkbits != size) {
| | ~^~
| | ||
| | |(1) pointer ‘bdev’ is dereferenced here
| | (2) following ‘true’ branch...
| 12 | sync_blockdev(bdev);
| | ~
| | |
| | (3) ...to here
| | (4) inlined call to ‘sync_blockdev’ from ‘set_blocksize’
|
+--> ‘sync_blockdev’: event 5
|
| 18 | if (!bdev)
| | ^
| | |
| | (5) pointer ‘bdev’ is checked for NULL here but it was
already dereferenced at (1)
|
The check from the inlined function shouldn't lead to this warning.
All of "-fno-delete-null-pointer-checks -O2 -fanalyzer -g" seem to be
necessary.
(reduced from block/bdev.c)
[Bug analyzer/112790] -Wanalyzer-deref-before-check false positives seen in Linux kernel due to inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112790 David Malcolm changed: What|Removed |Added Last reconfirmed||2023-11-30 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from David Malcolm --- Also affects gcc 13.2: https://godbolt.org/z/3WTrzGTTc
