[Bug c++/118626] C++20 std::variant causes a segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118626 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2025-01-23 --- Comment #1 from Andrew Pinski --- Can you provide the source you are compiling. Preprocessed would be best. You might need to compress it if it is too large.
[Bug fortran/96087] [12/13/14/15 Regression] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1575
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96087 --- Comment #9 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:b3f51ea894947e495baffc67407647a3b25acdd5 commit r15-7150-gb3f51ea894947e495baffc67407647a3b25acdd5 Author: Paul Thomas Date: Thu Jan 23 08:27:04 2025 + Fortran: Regression- fix ICE at fortran/trans-decl.c:1575 [PR96087] 2025-01-23 Paul Thomas gcc/fortran PR fortran/96087 * trans-decl.cc (gfc_get_symbol_decl): If a dummy is missing a backend decl, it is likely that it has come from a module proc interface. Look for the formal symbol by name in the containing proc and use its backend decl. * trans-expr.cc (gfc_apply_interface_mapping_to_expr): For the same reason, match the name, rather than the symbol address to perform the mapping. gcc/testsuite/ PR fortran/96087 * gfortran.dg/pr96087.f90: New test.
[Bug c++/118626] C++20 std::variant causes a segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118626 --- Comment #3 from Jan Papesch --- (In reply to Andrew Pinski from comment #1) > Can you provide the source you are compiling. Preprocessed would be best. > You might need to compress it if it is too large. I'm sorry, I thought I attached it when I created the issue.
[Bug rtl-optimization/118623] [12/13/14/15 regression] Miscompile with -O2/3 and -O0/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118623 --- Comment #7 from Richard Biener --- RTL if-conversion is it, -fno-if-conversion fixes it. CE1 does IF-THEN-ELSE-JOIN block found, pass 1, test 2, then 3, else 4, join 5 scanning new insn with uid = 33. scanning new insn with uid = 34. scanning new insn with uid = 35. scanning new insn with uid = 36. if-conversion succeeded through noce_try_cmove_arith deleting insn with uid = 4. deleting block 4 Removing jump 12. deleting insn with uid = 12. deleting insn with uid = 14. deleting block 3 Merging block 5 into block 2... changing bb of uid 16 ...
[Bug c++/118626] C++20 std::variant causes a segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118626 --- Comment #2 from Jan Papesch --- Created attachment 60248 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60248&action=edit Zipped preprocessed source
[Bug target/118460] [14/15 Regression] ICE on armv8.1-m.main with -mfloat-abi=hard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118460 --- Comment #7 from Christophe Lyon --- Besides fixing the ICE, the patch I proposed in c#5 changes the codegen for armv8_2-fp16-move-2.c, which is compiled with -marm -mcpu=unset -march=armv8.2-a+fp16 from: test_select: vcvtb.f32.f16 s15, s0 @ 9 [c=8 l=4] extendhfsf2 vcvtb.f32.f16 s14, s1 @ 10[c=8 l=4] extendhfsf2 vmovs0, s2 @ __fp16@ 4 [c=4 l=4] *movhf_vfp_hf16/2 vcmpe.f32 s15, s14@ 68[c=4 l=4] *cmpsf_trap_vfp/0 vmrsAPSR_nzcv, FPSCR@ 69[c=4 l=4] *movcc_vfp bxpllr @ 12[c=16 l=12] *cond_return vmovs0, s1 @ __fp16@ 6 [c=4 l=4] *movhf_vfp_hf16/2 bx lr @ 74[c=8 l=12] *arm_return to: test_select: vcvtb.f32.f16 s0, s0 @ 9 [c=8 l=4] extendhfsf2 vcvtb.f32.f16 s15, s1 @ 10[c=8 l=4] extendhfsf2 vcmp.f32s0, s15 @ 57[c=4 l=4] *cmpsf_vfp/0 vmrsAPSR_nzcv, FPSCR@ 58[c=4 l=4] *movcc_vfp ite mi @ 23[c=4 l=10] *thumb2_movhfcc_vfp/2 vmovmi.f16 s0, s1 vmovpl.f16 s0, s2 bx lr @ 63[c=8 l=12] *arm_return
[Bug tree-optimization/114589] missed optimization: losing bool range information, missed sinking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589 --- Comment #10 from Richard Biener --- (In reply to Andrew Macleod from comment #9) > (In reply to Richard Biener from comment #8) > > The missed sinking is now fixed for GCC 15, VRP is still confused by what > > IVOPTs does so without -fno-ivopts the loop remains. > > WHy is it VRP that should figure out that the loop doesn't iterate? That > seems very much a loop analysis thing... VRP makes no attempt to do loop > analysis. without IVOPTs we DOM2 threading the loop exit, allowing us to optimize: [local count: 105119324]: # PT = nonlocal _11 = &o_3(D)->val; # RANGE [irange] sizetype [0, 1] MASK 0x1 VALUE 0x0 _12 = (sizetype) _5; # RANGE [irange] sizetype [0, 0][4, 4] MASK 0x4 VALUE 0x0 _13 = _12 << 2; # PT = nonlocal _10 = _11 + _13; [local count: 955630224]: # PT = nonlocal # __for_begin_15 = PHI <__for_begin_8(6), _11(3)> i_6 = *__for_begin_15; # USE = nonlocal escaped # CLB = nonlocal escaped f (i_6); # PT = nonlocal __for_begin_8 = __for_begin_15 + 4; if (__for_begin_8 != _10) goto ; [89.00%] else goto ; [11.00%] [local count: 850510900]: goto ; [100.00%] while IVOPTs turns the IL into the following which we do not optimize: [local count: 105119324]: # PT = nonlocal _11 = &o_3(D)->val; # RANGE [irange] sizetype [0, 1] MASK 0x1 VALUE 0x0 _12 = (sizetype) _5; # RANGE [irange] sizetype [0, 0][4, 4] MASK 0x4 VALUE 0x0 _13 = _12 << 2; # PT = nonlocal _10 = _11 + _13; _9 = (unsigned long) o_3(D); ivtmp.11_14 = _9 + 4; [local count: 955630224]: # ivtmp.11_17 = PHI # PT = nonlocal null _18 = (void *) ivtmp.11_17; i_6 = MEM[(const int *)_18]; # USE = nonlocal escaped # CLB = nonlocal escaped f (i_6); ivtmp.11_2 = ivtmp.11_17 + 4; __for_begin_19 = (const int *) ivtmp.11_2; if (__for_begin_19 != _10) goto ; [89.00%] else goto ; [11.00%] there's a missed optimization at least, not noticing that ivtmp.11_14 == _11 (that might be a recent regression), FRE5 doesn't figure this out, but note it would need to still preserve a cast from pointer to unsigned long. Possibly IVOPTs replacing the pointer IV with an integer IV (but nothing else really) is the issue here. "VRP" because of how threading works now (but it's catched only by DOM threading, not by threadfull2 for example).
[Bug rtl-optimization/118623] [12/13/14/15 regression] Miscompile with -O2/3 and -O0/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118623 Richard Biener changed: What|Removed |Added Component|tree-optimization |rtl-optimization --- Comment #6 from Richard Biener --- What PRE does is OK. In fact this looks like it goes wrong somewhere on RTL (or during expansion). @@ -19,17 +356,18 @@ e_7 = 1 << _1; _9 = g_5(D) & e_7; if (_9 != 0) -goto ; [48.89%] +goto ; [48.89%] else -goto ; [51.11%] +goto ; [51.11%] - [local count: 524952376]: + [local count: 548789448]: + _14 = g_5(D) + 5; [local count: 1073741824]: # RANGE [irange] int [0, 0][5, 5] MASK 0x5 VALUE 0x0 - # _10 = PHI <5(2), 0(3)> - _2 = g_5(D) + _10; - _3 = _2 + g_5(D); + # _10 = PHI <5(3), 0(2)> + # prephitmp_15 = PHI <_14(3), g_5(D)(2)> + _3 = g_5(D) + prephitmp_15; # RANGE [irange] int [0, 1] MASK 0x1 VALUE 0x0 _4 = _3 & 1; if (_4 == 0)
[Bug c++/118626] C++20 std::variant causes a segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118626 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED --- Comment #4 from Andrew Pinski --- (In reply to Jan Papesch from comment #3) > (In reply to Andrew Pinski from comment #1) > > Can you provide the source you are compiling. Preprocessed would be best. > > You might need to compress it if it is too large. > > I'm sorry, I thought I attached it when I created the issue. Most likely it was too big and bugzilla does return an error back while creating a bug report that the attachment is too large. It does it when attaching after the fact though.
[Bug tree-optimization/118527] When a loop is unlooped due to sccvn, its profile is not updated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118527
--- Comment #5 from rguenther at suse dot de ---
On Thu, 23 Jan 2025, dizhao at os dot amperecomputing.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118527
>
> --- Comment #4 from Di Zhao ---
> The problem is found in 548.exchange2 of SPEC2017. As the profile counts are
> not adjusted after PRE, bbro produced sub-optimized order of basic blocks. In
> my test results on x86 (i0-10700) and aarch64 (Graviton), with the above
> change
> in sccvn, there is about 1% improvement in 548.exchange2.
>
> I think when sccvn finds a loop won't iterate, it replaces a guessed iteration
> count with a known count (=1). So although there are chances that the profile
> counts for extra exits are still wrong, considering other optimizations like
> bbro, it is still beneficial than harmful?
I think the argument is that short of re-doing profile guessing for the
whole function "local" fixups are just doing garbage-in (the original
guess, proved wrong) garbage-out ("adjusting" the original wrong guess).
Maybe we _should_ re-do local profile guessing at some point?
[Bug target/117726] [avr] better optimize multi-byte shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117726 --- Comment #7 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:f30edd17e62e9474f90785a5915959cd6d8c3f62 commit r15-7151-gf30edd17e62e9474f90785a5915959cd6d8c3f62 Author: Georg-Johann Lay Date: Wed Jan 22 21:11:22 2025 +0100 AVR: PR117726 - Tweak 32-bit logical shifts of 25...30 for -Oz. As it turns out, logical 32-bit shifts with an offset of 25..30 can be performed in 7 instructions or less. This beats the 7 instruc- tions required for the default code of a shift loop. Plus, with zero overhead, these cases can be 3-operand. This is only relevant for -Oz because with -Os, 3op shifts are split with -msplit-bit-shift (which is not performed with -Oz). PR target/117726 gcc/ * config/avr/avr.cc (avr_ld_regno_p): New function. (ashlsi3_out) [case 25,26,27,28,29,30]: Handle and tweak. (lshrsi3_out): Same. (avr_rtx_costs_1) [SImode, ASHIFT, LSHIFTRT]: Adjust costs. * config/avr/avr.md (ashlsi3, *ashlsi3, *ashlsi3_const): Add "r,r,C4L" alternative. (lshrsi3, *lshrsi3, *lshrsi3_const): Add "r,r,C4R" alternative. * config/avr/constraints.md (C4R, C4L): New, gcc/testsuite/ * gcc.target/avr/torture/avr-torture.exp (AVR_TORTURE_OPTIONS): Turn one option variant into -Oz.
[Bug c++/117827] [12/13/14/15 regression] Incorrect destructor calls after array-new-expression since r12-6328-gbeaee0a871b648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117827 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Jakub Jelinek --- Created attachment 60249 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60249&action=edit gcc15-pr117827.patch With this updated version even those seems to work. There is a difference between build_vec_init e.g. for an automatic array, in that case build_vec_init needs to ensure destruction of the array elements at the end of the scope, and build_vec_init for new expression, there such destruction is needed if something throws during the construction (i.e. from code emitted by build_vec_init) but is incorrect once it successfully completes - it is up to the user to delete the pointer afterwards manually which destructs the array elements.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114877
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d19b0682f18f9f5217aee8002e3d04f8ded04ae8
commit r15-7153-gd19b0682f18f9f5217aee8002e3d04f8ded04ae8
Author: Jakub Jelinek
Date: Thu Jan 23 11:11:23 2025 +0100
builtins: Store unspecified value to *exp for inf/nan [PR114877]
The fold_builtin_frexp folding for NaN/Inf just returned the first argument
with evaluating second arguments side-effects, rather than storing
something
to what the second argument points to.
The PR argues that the C standard requires the function to store something
there but what exactly is stored is unspecified, so not storing there
anything can result in UB if the value isn't initialized and is read later.
glibc and newlib store there 0, musl apparently doesn't store anything.
The following patch stores there zero (or would you prefer storing there
some other value, 42, INT_MAX, INT_MIN, etc.?; zero is cheapest to form
in assembly though) and adjusts the test so that it
doesn't rely on not storing there anything but instead checks for
-Wmaybe-uninitialized warning to find out that something has been stored
there.
Unfortunately I had to disable the NaN tests for -O0, while we can fold
__builtin_isnan (__builtin_nan ("")) at compile time, we can't fold
__builtin_isnan ((i = 0, __builtin_nan (""))) at compile time.
fold_builtin_classify uses just tree_expr_nan_p and if that isn't true
(because expr is a COMPOUND_EXPR with tree_expr_nan_p on the second arg),
it does
arg = builtin_save_expr (arg);
return fold_build2_loc (loc, UNORDERED_EXPR, type, arg, arg);
and that isn't folded at -O0 further, as we wrap it into SAVE_EXPR and
nothing propagates the NAN to the comparison.
I think perhaps tree_expr_nan_p etc. could have case COMPOUND_EXPR:
added and recurse on the second argument, but that feels like stage1
material to me if we want to do that at all.
2025-01-23 Jakub Jelinek
PR middle-end/114877
* builtins.cc (fold_builtin_frexp): Handle rvc_nan and rvc_inf
cases
like rvc_zero, return passed in arg and set *exp = 0.
* gcc.dg/torture/builtin-frexp-1.c: Add -Wmaybe-uninitialized as
dg-additional-options.
(bar): New function.
(TESTIT_FREXP2): Rework the macro so that it doesn't test whether
nothing has been stored to what the second argument points to, but
instead that something has been stored there, whatever it is.
(main): Temporarily don't enable the nan tests for -O0.
[Bug tree-optimization/118605] gcc/tree-assume.cc:108: dangling field problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118605 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |14.3 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far. Should be backported to 14.3 as well eventually.
[Bug tree-optimization/118605] gcc/tree-assume.cc:108: dangling field problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118605
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:27a05f8d11798889ecfb610db9bde781c3d218f7
commit r15-7158-g27a05f8d11798889ecfb610db9bde781c3d218f7
Author: Jakub Jelinek
Date: Thu Jan 23 11:46:18 2025 +0100
tree-assume: Fix UB in assume_query [PR118605]
The assume_query constructor does
assume_query::assume_query (function *f, bitmap p) : m_parm_list (p),
m_func (f)
where m_parm_list is bitmap &. This is compile time UB, because
as soon as the constructor returns, m_parm_list reference is still
bound to the parameter of the constructor which is no longer in scope.
Now, one possible fix would be change the ctor argument to be bitmap &,
but that doesn't really work because in the only user of that class
we have
auto_bitmap decls;
...
assume_query query (fun, decls);
and auto_bitmap just has
operator bitmap () { return &m_bits; }
Could be perhaps const bitmap &, but why? bitmap is a pointer:
typedef class bitmap_head *bitmap;
and the EXECUTE_IF_SET_IN_BITMAP macros don't really change that point,
they just inspect what is inside of that bitmap_head the pointer points
to.
So, the simplest I think is avoid references (which cause even worse
code as it has to be dereferenced twice rather than once).
2025-01-23 Jakub Jelinek
PR tree-optimization/118605
* tree-assume.cc (assume_query::m_parm_list): Change type
from bitmap & to bitmap.
[Bug c++/118604] gcc/cp/parser.cc:51316: Non clear code produces clang warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118604 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114877 Jakub Jelinek changed: What|Removed |Added Summary|[12/13/14/15 Regression]|[12/13/14 Regression] |wrong-code for frexp(NAN, |wrong-code for frexp(NAN, |&uninitialized) |&uninitialized) --- Comment #8 from Jakub Jelinek --- Fixed on the trunk. Unsure about backports.
[Bug c/118627] New: gcc/omp-general.cc:4197: Possible read of uninitialised data ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118627 Bug ID: 118627 Summary: gcc/omp-general.cc:4197: Possible read of uninitialised data ? Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Clang says: gcc/omp-general.cc:4197:7: warning: variable 'am_expr' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] Source code is tree am_expr; if (omp_parse_access_method (&expr, &kind)) am_expr = expr; // ... addr_tokens.safe_push (new omp_addr_token (kind, am_expr)); Suggest add an initialiser to am_expr at its declaration.
[Bug c/118627] gcc/omp-general.cc:4197: Possible read of uninitialised data ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118627 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org Keywords||internal-improvement --- Comment #1 from Xi Ruoyao --- omp_parse_access_method seems always returning true.
[Bug c/118628] New: gcc/tree-vect-stmts.cc:10642: Possible read of uninitialised data ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118628 Bug ID: 118628 Summary: gcc/tree-vect-stmts.cc:10642: Possible read of uninitialised data ? Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- clang says: gcc/tree-vect-stmts.cc:10642:11: warning: variable 'offvar' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] working $ grep -n offvar ../trunk/gcc/tree-vect-stmts.cc 8642: tree offvar; 8787:insert_after, &offvar, NULL); 8801: running_off = offvar; 10600: tree offvar; 10676: &offvar, NULL); 10681: running_off = offvar; working $ It looks like clang is complaining about the second case. The first case might be worth fixing too. Suggest initialise offvar at it's declaration.
[Bug c/118627] gcc/omp-general.cc:4197: Possible read of uninitialised data ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118627 Xi Ruoyao changed: What|Removed |Added Last reconfirmed||2025-01-23 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #1) > omp_parse_access_method seems always returning true. So reading uninitialized data is not possible. But the code indeed should be refactored.
[Bug rtl-optimization/118623] [12/13/14/15 regression] Miscompile with -O2/3 and -O0/1 since r12-7751-g919fbffef07555
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118623 --- Comment #9 from rguenther at suse dot de --- On Thu, 23 Jan 2025, sjames at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118623 > > Sam James changed: > >What|Removed |Added > > CC||liuhongt at gcc dot gnu.org > Summary|[12/13/14/15 regression]|[12/13/14/15 regression] >|Miscompile with -O2/3 and |Miscompile with -O2/3 and >|-O0/1 |-O0/1 since >||r12-7751-g919fbffef07555 > > --- Comment #8 from Sam James --- > r12-7751-g919fbffef07555 that might have just exposed a latent issue
[Bug rtl-optimization/118623] [12/13/14/15 regression] Miscompile with -O2/3 and -O0/1 since r12-7751-g919fbffef07555
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118623 Sam James changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org Summary|[12/13/14/15 regression]|[12/13/14/15 regression] |Miscompile with -O2/3 and |Miscompile with -O2/3 and |-O0/1 |-O0/1 since ||r12-7751-g919fbffef07555 --- Comment #8 from Sam James --- r12-7751-g919fbffef07555
[Bug tree-optimization/116855] [14/15 Regression] Unsafe early-break vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
--- Comment #8 from Richard Biener ---
char string2[4095] __attribute__((aligned(1))) = { 2, };
char string[4097] = { 1, };
char * find(int n, char c)
{
for (int i = 1; i < n; i++) {
if (string[i] == c)
return &string[i];
}
return 0;
}
get's you
.data
.align 32
.type string, @object
.size string, 4097
string:
.string "\001"
.zero 4095
.globl string2
.type string2, @object
.size string2, 4095
string2:
.string "\002"
.zero 4093
.section.rodata.cst16,"aM",@progbits,16
so the trick to get an actual faulting testcase would be to either
manually unmap .data after string[] or use a guard page that's placed
there by other means. I think the sizes of the arrays need to be
adjusted as well so when the last element in string[] is the char
we search for the misaligned vector access will touch the next page.
[Bug c++/118590] [14/15 regression] ICE with acc enter data copyin and dependent types since r14-7033-g1413af02d62182
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118590 --- Comment #11 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b02c061bb84c0a2dbf3987e9ff77243d089cbd7a commit r15-7155-gb02c061bb84c0a2dbf3987e9ff77243d089cbd7a Author: Jakub Jelinek Date: Thu Jan 23 11:17:47 2025 +0100 c++: Fix build_omp_array_section for type dependent array_expr [PR118590] As can be seen on the testcase, when array_expr is type dependent, assuming it has non-NULL TREE_TYPE is just wrong, it can often have NULL type, and even if not, blindly assuming it is a pointer or array type is also wrong. So, like in many other spots in the C++ FE, for type dependent expressions we want to create something which will survive until instantiation and can be redone at that point. Unfortunately, build_omp_array_section is called before we actually do any kind of checking what array_expr really is, and on invalid code it can be e.g. a TYPE_DECL on which type_dependent_expression_p ICEs (as can be seen on the pr67522.C testcase). So, I've hacked this by checking it is not TYPE_DECL, I hope a TYPE_P can't make it through there when we just lookup an identifier. Anyway, this patch is not enough, we can ICE e.g. on __uint128_t[0:something] during instantiation, so I think something needs to be done for this in pt.cc as well. 2025-01-23 Jakub Jelinek PR c++/118590 * typeck.cc (build_omp_array_section): If array_expr is type dependent or a TYPE_DECL, build OMP_ARRAY_SECTION with NULL type. * g++.dg/goacc/pr118590.C: New test.
[Bug c++/118604] gcc/cp/parser.cc:51316: Non clear code produces clang warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118604 --- Comment #2 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:dd14b08e2caba952c0d8ff756a84e15d83aebeff commit r15-7154-gdd14b08e2caba952c0d8ff756a84e15d83aebeff Author: Jakub Jelinek Date: Thu Jan 23 11:13:52 2025 +0100 c++: Fix weird expression in test for clauses other than when/default/otherwise [PR118604] Some clang analyzer warned about if (!strcmp (p, "when") == 0 && !default_p) which really looks weird, it is better to use strcmp (p, "when") != 0 or !!strcmp (p, "when"). Furthermore, as a micro optimization, it is cheaper to evaluate default_p than calling strcmp, so that can be put first in the &&. The C test for the same thing wasn't that weird, but I think for consistency it is better to use the same test rather than trying to be creative. 2025-01-23 Jakub Jelinek PR c++/118604 gcc/c/ * c-parser.cc (c_parser_omp_metadirective): Rewrite condition for clauses other than when, default and otherwise. gcc/cp/ * parser.cc (cp_parser_omp_metadirective): Test !default_p first and use strcmp () != 0 rather than !strcmp () == 0.
[Bug c/118606] gcc/omp-general.cc:3294: Possible precedence problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118606 --- Comment #3 from David Binderman --- (In reply to Jakub Jelinek from comment #1) > What is confusing about that? It's a matter of style. Clang considers that some style boundary has been stepped over in the original case. > Is that any different from non-overloaded > operator? > We have > combine.cc: && nonzero_bits (XEXP (varop, 1), int_result_mode) >> > count == 0 > combine.cc: && const_op >> i == 0 > simplify-rtx.cc: if (mask >> count == INTVAL (trueop1) I'd add extra () for clarity in all these cases too. I've seen too many cases where junior programmers get precedence wrong.
[Bug c/118628] gcc/tree-vect-stmts.cc:10642: Possible read of uninitialised data ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118628
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||matz at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Seems it is like
tree offvar;
tree running_off;
if (!costing_p)
{
... (..., &offvar, ...);
}
running_off = offvar;
for (...)
{
if (costing_p)
{
...
continue;
}
use running_off;
}
So, all wrong it does is that it is copying possibly uninitialized value
unconditionally to something that will not be used unless it is initialized.
Agreed we should either initialize offvar to NULL_TREE or rework in some other
way.
[Bug c/118628] gcc/tree-vect-stmts.cc:10642: Possible read of uninitialised data ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118628
--- Comment #2 from rguenther at suse dot de ---
On Thu, 23 Jan 2025, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118628
>
> Jakub Jelinek changed:
>
>What|Removed |Added
>
> CC||jakub at gcc dot gnu.org,
>||matz at gcc dot gnu.org,
>||rguenth at gcc dot gnu.org
>
> --- Comment #1 from Jakub Jelinek ---
> Seems it is like
> tree offvar;
> tree running_off;
> if (!costing_p)
> {
> ... (..., &offvar, ...);
> }
> running_off = offvar;
> for (...)
> {
> if (costing_p)
> {
> ...
> continue;
> }
> use running_off;
> }
> So, all wrong it does is that it is copying possibly uninitialized value
> unconditionally to something that will not be used unless it is initialized.
> Agreed we should either initialize offvar to NULL_TREE or rework in some other
> way.
I'd say zero-initialize it.
[Bug tree-optimization/118628] gcc/tree-vect-stmts.cc:10642: Possible read of uninitialised data ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118628
--- Comment #3 from Jakub Jelinek ---
Ok, will test
2025-01-23 Jakub Jelinek
PR tree-optimization/118628
* tree-vect-stmts.cc (vectorizable_store, vectorizable_load):
Initialize offvar to NULL_TREE.
--- gcc/tree-vect-stmts.cc.jj 2025-01-23 11:10:48.357722650 +0100
+++ gcc/tree-vect-stmts.cc 2025-01-23 13:24:23.200875907 +0100
@@ -8645,7 +8645,7 @@ vectorizable_store (vec_info *vinfo,
gimple_stmt_iterator incr_gsi;
bool insert_after;
gimple *incr;
- tree offvar;
+ tree offvar = NULL_TREE;
tree ivstep;
tree running_off;
tree stride_base, stride_step, alias_off;
@@ -10603,7 +10603,7 @@ vectorizable_load (vec_info *vinfo,
{
gimple_stmt_iterator incr_gsi;
bool insert_after;
- tree offvar;
+ tree offvar = NULL_TREE;
tree ivstep;
tree running_off;
vec *v = NULL;
then.
[Bug tree-optimization/118567] [15 Regression] gcc.target/powerpc/vsx-vectorize-1.c fail starting with r15-6807-g68326d5d1a593d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118567 --- Comment #1 from Jeevitha --- The following vectorization testcases are failing, FAIL: gcc.target/powerpc/vsx-vectorize-1.c scan-tree-dump-times vect "Alignment of access forced using versioning" 1 FAIL: gcc.target/powerpc/vsx-vectorize-2.c scan-tree-dump-times vect "Alignment of access forced using versioning" 0 FAIL: gcc.target/powerpc/vsx-vectorize-3.c scan-tree-dump-times vect "Alignment of access forced using versioning" 0 FAIL: gcc.target/powerpc/vsx-vectorize-4.c scan-tree-dump-times vect "Alignment of access forced using versioning" 0 FAIL: gcc.target/powerpc/vsx-vectorize-5.c scan-tree-dump-times vect "Alignment of access forced using versioning" 0 FAIL: gcc.target/powerpc/vsx-vectorize-6.c scan-tree-dump-times vect "Alignment of access forced using versioning" 0 FAIL: gcc.target/powerpc/vsx-vectorize-7.c scan-tree-dump-times vect "Alignment of access forced using versioning" 0 FAIL: gcc.target/powerpc/vsx-vectorize-8.c scan-tree-dump-times vect "Alignment of access forced using versioning" 2
[Bug c++/118629] New: ice in cp_parser_expression_statement, at cp/parser.cc:13584
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118629
Bug ID: 118629
Summary: ice in cp_parser_expression_statement, at
cp/parser.cc:13584
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
>From the clang C++ testsuite, file SemaCXX/crash-GH121274.cpp
does this with g++:
test $ ~/gcc/results/bin/gcc -c SemaCXX/crash-GH121274.cpp
SemaCXX/crash-GH121274.cpp: In function ‘void foo()’:
SemaCXX/crash-GH121274.cpp:8:11: internal compiler error: in
cp_parser_expression_statement, at cp/parser.cc:13584
8 | }();
| ^
Source code is
// RUN: %clang_cc1 -std=c++11 -verify %s
// expected-no-diagnostics
// Do not crash when __PRETTY_FUNCTION__ appears in the trailing return type of
the lambda
void foo() {
[]() -> decltype(static_cast(__PRETTY_FUNCTION__)) {
return nullptr;
}();
#ifdef MS
[]() -> decltype(static_cast(__FUNCSIG__)) {
return nullptr;
}();
#endif
}
The clang test suite is at
https://github.com/llvm/llvm-project/tree/main/clang/test
The code first goes wrong in g++ sometime before g:0b06abe027a78681
[Bug tree-optimization/113590] The vectorizer introduces signed overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113590 --- Comment #2 from Richard Biener --- Move update to the latch: diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc index edd7d4d8763..8b282019840 100644 --- a/gcc/tree-vect-loop.cc +++ b/gcc/tree-vect-loop.cc @@ -10808,7 +10808,9 @@ vectorizable_induction (loop_vec_info loop_vinfo, vec_def = gimple_build (&stmts, PLUS_EXPR, step_vectype, vec_def, up); vec_def = gimple_convert (&stmts, vectype, vec_def); - gsi_insert_seq_before (&si, stmts, GSI_SAME_STMT); + gimple_stmt_iterator si2 + = gsi_after_labels (loop_latch_edge (iv_loop)->src); + gsi_insert_seq_before (&si2, stmts, GSI_SAME_STMT); add_phi_arg (induction_phi, vec_def, loop_latch_edge (iv_loop), UNKNOWN_LOCATION); generates jmp .L6 .p2align 5 .p2align 4,,10 .p2align 3 .L4: paddd %xmm3, %xmm0 .L6: movdqa %xmm0, %xmm1 addq$16, %rax paddd %xmm2, %xmm1 movups %xmm1, -16(%rax) cmpq%rdx, %rax jne .L4 instead of .p2align 5 .p2align 4 .p2align 3 .L4: movdqa %xmm0, %xmm1 addq$16, %rax paddd %xmm2, %xmm0 paddd %xmm3, %xmm1 movups %xmm1, -16(%rax) cmpq%rdx, %rax jne .L4
[Bug rtl-optimization/118615] [15 Regression] Bootstrap failure on aarch64 after r15-2810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118615 --- Comment #12 from Andrew Pinski --- (In reply to Andrew Pinski from comment #8) > Let me apply r15-6661 and r15-2810 on top of r15-5746 to see if we get a > failure. That worked. Tomorrow I will see what I can do about the comparison failure.
[Bug tree-optimization/118527] When a loop is unlooped due to sccvn, its profile is not updated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118527 --- Comment #4 from Di Zhao --- The problem is found in 548.exchange2 of SPEC2017. As the profile counts are not adjusted after PRE, bbro produced sub-optimized order of basic blocks. In my test results on x86 (i0-10700) and aarch64 (Graviton), with the above change in sccvn, there is about 1% improvement in 548.exchange2. I think when sccvn finds a loop won't iterate, it replaces a guessed iteration count with a known count (=1). So although there are chances that the profile counts for extra exits are still wrong, considering other optimizations like bbro, it is still beneficial than harmful?
[Bug c++/118626] New: C++20 std::variant causes a segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118626
Bug ID: 118626
Summary: C++20 std::variant causes a segmentation fault
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: JanPapuch at seznam dot cz
Target Milestone: ---
This issue may be a regression of [Bug
104470](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104470).
Output of `gcc -v -save-temps --std=c++20 main.cpp`:
```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
13.1.0-8ubuntu1~20.04.2' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=x86_64-linux-gnu- --
enable-shared --enable-linker-build-id --libexecdir=/usr/libexec
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --en
able-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (Ubuntu 13.1.0-8ubuntu1~20.04.2)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a-'
/usr/libexec/gcc/x86_64-linux-gnu/13/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE main.cpp -mtune=generic -march=x86-64 -std=c++20
-fpch-preprocess -fasynchronous-unwind-tables -fstack-protector-strong -Wformat
-Wformat-security -fstack-clash-protection -fcf-protection -o a-main.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/13"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/13/include-fixed/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/13/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/13/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/13
/usr/include/x86_64-linux-gnu/c++/13
/usr/include/c++/13/backward
/usr/lib/gcc/x86_64-linux-gnu/13/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a-'
/usr/libexec/gcc/x86_64-linux-gnu/13/cc1plus -fpreprocessed a-main.ii -quiet
-dumpdir a- -dumpbase main.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64
-std=c++20 -version -fasynchronous-unwind-tables -fstack-protector-strong
-Wformat -Wformat-security -fstack-clash-protection -fcf-protection -o a-main.s
GNU C++20 (Ubuntu 13.1.0-8ubuntu1~20.04.2) version 13.1.0 (x86_64-linux-gnu)
compiled by GNU C version 13.1.0, GMP version 6.2.0, MPFR version
4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 391880e3be75f4e1ac78bddcb50fff0c
In file included from main.cpp:2:
/usr/include/c++/13/variant: In substitution of ‘template
template using std::variant<_Types>::__accepted_type =
std::variant<_Types>::__to_type<__accepted_index<_Tp> > [with _Tp = _Tp&&;
= typename std::enable_if,
Leaf>::__not_self<_Tp&&>, void>::type; _Types = {Node, Leaf}]’:
main.cpp:43:9: required from here
/usr/include/c++/13/variant:1383:43: internal compiler error: Segmentation
fault
1383 | using __accepted_type = __to_type<__accepted_index<_Tp>>;
| ^~~~
0xdd3543 crash_signal
../../src/gcc/toplev.cc:314
0x7f01cdb5308f ???
/build/glibc-LcI20x/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x84c3eb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:20450
0x85bf30 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:19895
0x85ff09 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:13766
0x8601b2 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:13748
0x85037a tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:15966
0x85a562 ts
[Bug tree-optimization/118623] [12/13/14/15 regression] Miscompile with -O2/3 and -O0/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118623
Richard Biener changed:
What|Removed |Added
Keywords||needs-bisection
Last reconfirmed||2025-01-23
CC||rguenth at gcc dot gnu.org
Priority|P3 |P2
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #5 from Richard Biener ---
Further reduced, not analyzed.
static int c(int f, int g)
{
int e = 1 << f;
if (g & e)
return 0;
return 5;
}
__attribute__((noipa))
void h(int g)
{
if (((c(g - 50, g) + g + g) & 1) == 0)
__builtin_abort ();
}
int main()
{
h(63);
return 0;
}
[Bug middle-end/118627] gcc/omp-general.cc:4197: The code looks like reading uninitialised data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118627 Tobias Burnus changed: What|Removed |Added Keywords||openmp --- Comment #3 from Tobias Burnus --- Crossref: That code was added in commit r14-6515-g5fdb150cd4bf8f OpenMP/OpenACC: Rework clause expansion and nested struct handling The called function static bool omp_parse_access_method (tree *expr0, enum access_method_kinds *kind) duly sets 'kind' based on 'expr0', which might get modified. And then unconditionally returns 'true'. -> Could be set 'void' (there is a single caller, the one of comment 0). - And some more cleanup could be done. For instance, omp_parse_access_methods also returns true unconditionally, called in an if clause in 'omp_parse_expr'. I checked some pending OpenMP patches but those do not modify/extend those functions, either.
[Bug rtl-optimization/118615] [15 Regression] Bootstrap failure on aarch64 after r15-2810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118615 --- Comment #14 from Andrew Pinski --- Just for the record here is the comparison failure: ``` make[3]: Leaving directory '/home/pinskia/src/upstream/gcc/objdir' Comparing stages 2 and 3 Bootstrap comparison failure! gcc/analyzer/region-model.o differs gcc/tree-data-ref.o differs gcc/df-scan.o differs make[2]: *** [Makefile:30073: compare] Error 1 ```
[Bug tree-optimization/118628] gcc/tree-vect-stmts.cc:10642: Possible read of uninitialised data ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118628
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8f6dd185d16dec8ca9351a754f0ece153f89d85c
commit r15-7166-g8f6dd185d16dec8ca9351a754f0ece153f89d85c
Author: Jakub Jelinek
Date: Thu Jan 23 20:03:36 2025 +0100
vect: Avoid copying of uninitialized variable [PR118628]
vectorizable_{store,load} does roughly
tree offvar;
tree running_off;
if (!costing_p)
{
... initialize offvar ...
}
running_off = offvar;
for (...)
{
if (costing_p)
{
...
continue;
}
... use running_off ...
}
so, it copies unconditionally sometimes uninitialized variable (but then
uses the copied variable only if it was set to something initialized).
Still, I think it is better to avoid copying around maybe uninitialized
vars.
2025-01-23 Jakub Jelinek
PR tree-optimization/118628
* tree-vect-stmts.cc (vectorizable_store, vectorizable_load):
Initialize offvar to NULL_TREE.
[Bug tree-optimization/118628] gcc/tree-vect-stmts.cc:10642: Possible read of uninitialised data ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118628 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |15.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug libstdc++/71945] Integer overflow in use counter of shared pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71945 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2025-01-23 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- We should terminate if the counter reaches its maximum value. We could also consider treating the counters as unsigned, which would double their range. I think that could be done an an ABI-compatible way, because no correct programs overflow the counters into negative values today.
[Bug tree-optimization/118634] New: [15 Regression] missed optimization leading to maybe-uninitiallized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118634
Bug ID: 118634
Summary: [15 Regression] missed optimization leading to
maybe-uninitiallized warning
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: false-positive, missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: phosit at autistici dot org
Target Milestone: ---
Created attachment 60255
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60255&action=edit
reduced testcase
When compiling the attached source with `gcc-15 -Wmaybe-uninitialized -O2`
there is a warning:
maybe-uninitialized.cpp: In function 'int main()':
maybe-uninitialized.cpp:43:31: warning:
'((::optional*))[2].{anonymous}::optional::value' may be used
uninitialized [-Wmaybe-uninitialized]
43 | if (find(c, counter)->value != counter) {
| ~~^
When compiling with gcc 14 or with -O3 there is no warning and the asm is a
simple `ret`.
[Bug tree-optimization/118634] [15 Regression] missed optimization leading to maybe-uninitiallized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118634 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0 --- Comment #1 from Andrew Pinski --- Looks like this was due to the unrolling heurstics: size: 28-7, last_iteration: 28-7 Loop size: 28 Estimated size after unrolling: 42 Not unrolling loop 1: size would grow.
[Bug c++/118619] ICE on lambda with explicit this parameter in concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118619
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2025-01-23
Status|UNCONFIRMED |NEW
--- Comment #1 from Marek Polacek ---
clang++ accepts this.
Started with r14-7075:
commit fbc980d85149409ce62c22f48d3693113803929e
Author: waffl3x
Date: Sun Jan 7 00:01:48 2024 +
c++: P0847R7 (deducing this) - initial functionality. [PR102609]
before:
118619.C:2:17: error: expected identifier before ‘this’
2 | concept A = ([](this auto){}, true);
| ^~~~
118619.C:2:17: error: expected ‘,’ or ‘...’ before ‘this’
[Bug c++/118630] New: [modules] ICE in sort_cluster when streaming decltype(lambda) return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118630
Bug ID: 118630
Summary: [modules] ICE in sort_cluster when streaming
decltype(lambda) return type
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nshead at gcc dot gnu.org
Blocks: 103524
Target Milestone: ---
The following sample:
export module M;
template decltype([]{}) f();
ICEs on current trunk when compiled with 'g++ -fmodules -std=c++20'.
It hits the checking-only assertion here (added in r15-4861):
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -14909,21 +14909,21 @@ sort_cluster (depset::hash *original, depset *scc[],
unsigned size)
{
gcc_checking_assert (order[ix]->is_special ());
bool tight = order[ix]->cluster == cluster;
depset *dep = order[ix]->deps[0];
dump (dumper::MERGE)
&& dump ("Mergeable %u is %N%s%s", ix, dep->get_entity (),
tight ? " (tight)" : "", dep->is_entry () ? " (entry)" : "");
scc[ix] = dep;
if (tight)
{
! gcc_checking_assert (dep->is_maybe_recursive ());
if (dep->is_entry ())
{
/* There should only be one entry dep in a cluster. */
gcc_checking_assert (!scc[entry_pos]->is_entry ());
gcc_checking_assert (scc[entry_pos]->is_maybe_recursive ());
scc[ix] = scc[entry_pos];
scc[entry_pos] = dep;
}
}
else
Without this assertion failure streaming seems to proceed correctly for this
specific case, but it's indicative of a potential underlying issue.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue
[Bug c++/118631] New: Public class member as const reference to protected member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118631
Bug ID: 118631
Summary: Public class member as const reference to protected
member
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: i...@joerg-brueggmann.de
Target Milestone: ---
Created attachment 60253
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60253&action=edit
cpp-file as self contained bug report
Dear all,
in the public member 'msets' is a const reference to the protected member
'msets_'.
class StringSet {
...
public:
const std::set< std::string >& msets;
protected:
std::set< std::string > msets_;
It was assumed that both members 'msets' and 'msets_' will ALWAYS represent the
same content. But it seems that I created some code where this it is not the
case.
Please, find the details in the attachment.
Thank you.
Best regards
Jörg Brüggmann
[Bug rtl-optimization/115568] [12/13/14/15 Regression] wrong code at -O2 with "-fno-tree-sink -fno-tree-ter -fschedule-insns" on x86_64-linux-gnu since r12-6122-g9407058a430316
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115568 Uroš Bizjak changed: What|Removed |Added Keywords||ra --- Comment #6 from Uroš Bizjak --- It looks the problem is in LRA. sched1 pass just reorders the instruction in just the right way to expose the problem. When compiling with -O2 -fno-tree-sink -fno-tree-ter -fschedule-insns, we have the following dump in _.317r.asmcons: 120: NOTE_INSN_BASIC_BLOCK 9 121: r100:SI=~r165:SI 122: r109:SI=r165:SI REG_DEAD r165:SI 123: r112:SI=~r167:SI 124: r104:SI=r167:SI 16: r170:SI=r164:SI REG_DEAD r164:SI 17: r164:SI=r109:SI 18: r145:SI=r168:SI REG_DEAD r168:SI 19: r168:SI=r116:SI REG_DEAD r116:SI 312: r163:QI=0x1 335: pc=L160 336: barrier FTR, the sched1 pass just reorders these instructions to: 120: NOTE_INSN_BASIC_BLOCK 9 122: r109:SI=r165:SI REG_DEAD r165:SI 16: r170:SI=r164:SI REG_DEAD r164:SI 18: r145:SI=r168:SI REG_DEAD r168:SI 121: r100:SI=~r165:SI 123: r112:SI=~r167:SI 312: r163:QI=0x1 124: r104:SI=r167:SI 17: r164:SI=r109:SI 19: r168:SI=r116:SI REG_DEAD r116:SI 335: pc=L160 336: barrier IRA pass renames a couple of registers to (_.323r.ira): 316: r223:SI=0x REG_EQUAL 0x ... 43: r164:SI=[`e'] 361: r218:SI=r164:SI REG_DEAD r164:SI ... 120: NOTE_INSN_BASIC_BLOCK 9 122: r109:SI=r223:SI 16: r170:SI=r218:SI REG_DEAD r218:SI 18: r145:SI=r220:SI REG_DEAD r220:SI 121: r100:SI=~r223:SI REG_DEAD r223:SI 123: r112:SI=~r219:SI 312: r163:QI=0x1 124: r104:SI=r219:SI 17: r218:SI=r109:SI 19: r220:SI=r222:SI REG_DEAD r222:SI 335: pc=L160 336: barrier Now LRA reloads this sequence to (_.324r.reload): 316: di:SI=0x REG_EQUAL 0x ... 43: r14:SI=[`e'] 361: [sp:DI-0x34]=r14:SI ... 120: NOTE_INSN_BASIC_BLOCK 9 122: r14:SI=di:SI 476: [sp:DI-0x2c]=r14:SI 483: ax:SI=di:SI<--- here 482: NOTE_INSN_DELETED 16: [sp:DI-0x24]=ax:SI 18: [sp:DI-0x1c]=r11:SI 121: di:SI=~di:SI 413: r9:SI=di:SI 414: r8:SI=r13:SI 123: r8:SI=~r8:SI 312: [sp:DI-0x1]=0x1 124: di:SI=r13:SI 17: [sp:DI-0x34]=r14:SI 19: r11:SI=cx:SI 335: pc=L160 336: barrier Please note (insn 483). While LRA substitutes register r218:SI in (insn 361) and (insn 17) with [sp:DI-0x34], it fails to do so in (insn 16) and creates wrong reload (insn 483), effectively assigning -1 to [sp:DI-0x24]. (insn 483) should read 483: ax:SI=[sp:DI-0x34] instead. The above invalid RTX sequence results in (please add -fno-schedule-insns2 -fno-cprop-registers to compile flags to avoid further reordering of the RTX sequence): movl%edi, %r14d # 122 [c=4 l=3] *movsi_internal/0 movl%r14d, -44(%rsp)# 476 [c=4 l=5] *movsi_internal/1 --> movl%edi, -36(%rsp) # 16[c=4 l=4] *movsi_internal/1 movl%r11d, -28(%rsp)# 18[c=4 l=5] *movsi_internal/1 notl%edi# 121 [c=4 l=2] *one_cmplsi2_1/0 movl%edi, %r9d # 413 [c=4 l=3] *movsi_internal/0 movl%r13d, %r8d # 414 [c=4 l=3] *movsi_internal/0 notl%r8d# 123 [c=4 l=3] *one_cmplsi2_1/0 movb$1, -1(%rsp)# 312 [c=4 l=5] *movqi_internal/8 movl%r13d, %edi # 124 [c=4 l=3] *movsi_internal/0 movl%r14d, -52(%rsp)# 17[c=4 l=5] *movsi_internal/1 movl%ecx, %r11d # 19[c=4 l=3] *movsi_internal/0 The insn #16 above is wrong due to the invalid reload. When the offending insn #16 is substituted with expected sequence in the assembly dump: ... movl-52(%rsp), %eax movl%eax, -36(%rsp) # 16 ... the testcase executes without problems.
[Bug libstdc++/118635] New: P2510R3 "Formatting pointers" is not available in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118635 Bug ID: 118635 Summary: P2510R3 "Formatting pointers" is not available in C++20 Product: gcc Version: 14.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: koraq at xs4all dot nl Target Milestone: --- As discussed by the standard library vendors the paper P2510R3 "Formatting pointers" would be applied as an DR against C++20. In libstdc++ the paper is not implemented as an DR (https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/format#L2428). MSVC STL and libc++ have implemented the paper as an DR (https://godbolt.org/z/98aEs3bP4).
[Bug libstdc++/118635] P2510R3 "Formatting pointers" is not available in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118635 --- Comment #1 from Andrew Pinski --- https://github.com/gcc-mirror/gcc/commit/72cd15b20a887bed9b0b1f4196be99fe052247b4
[Bug libstdc++/118635] P2510R3 "Formatting pointers" is not available in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118635 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |15.0 --- Comment #2 from Andrew Pinski --- Yes it was applied as DR by r15-2445-g72cd15b20a887b so this was fixed in GCC 15.
[Bug libstdc++/118635] P2510R3 "Formatting pointers" is not available in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118635 --- Comment #3 from Andrew Pinski --- and yes I tested the trunk to see it works with -std=c++20 now unlike GCC 14.2.0 rejects it.
[Bug rtl-optimization/118615] [15 Regression] Bootstrap failure on aarch64 after r15-2810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118615 --- Comment #13 from Surya Kumari Jangala --- Created attachment 60251 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60251&action=edit r15-2810 plus fix for xstormy16-elf issue Hello Andrew, Just wanted to let you know that I made a small change to r15-2810 to fix a compile time regression on xstormy16-elf. The regression was pointed out by Jeff Law. Please see https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660028.html The compile time regression is happening because LRA pass is taking a lot of time. LRA consists of several stages and all the stages are repeated till the RTL reaches a stable state, ie, no more changes occur in the RTL. But with r15-2810, the stable state is not being reached. I made a small change to r15-2810 that fixes this compile time regression. The change is to move the caller-save register spill insn before the call insn only if the write insn (ie, the insn that writes to a pseudo which has been assigned a caller-save reg) and the call insn belong to separate basic blocks. I did not really check why this fix is enabling LRA to reach stable state. I have attached the patch containing the fix.
[Bug c++/118629] [14/15 Regression] ice in cp_parser_expression_statement, at cp/parser.cc:13584
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118629 --- Comment #2 from Andrew Pinski --- Created attachment 60252 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60252&action=edit Reduced testcase
[Bug c++/118620] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118620 Marek Polacek changed: What|Removed |Added Keywords||c++-lambda CC||mpolacek at gcc dot gnu.org Last reconfirmed||2025-01-23 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Started with r14-7075: commit fbc980d85149409ce62c22f48d3693113803929e Author: waffl3x Date: Sun Jan 7 00:01:48 2024 + c++: P0847R7 (deducing this) - initial functionality. [PR102609] Not a regression.
[Bug c++/118626] C++20 std::variant causes a segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118626
Marek Polacek changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #6 from Marek Polacek ---
Reduced (but invalid):
```
template struct _Nth_type;
template long __accepted_index = 0;
template struct variant {
template
static constexpr long __accepted_index2 = __accepted_index<_Tp, variant>;
template using __to_type = _Nth_type<_Np>;
template
using __accepted_type = __to_type<__accepted_index2<_Tp>>;
template > variant();
};
template struct Node;
template using Tree = variant>;
auto tree = Tree {};
```
[Bug tree-optimization/118634] [15 Regression] missed optimization leading to maybe-uninitiallized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118634 --- Comment #2 from Phosit --- When unrolling is forbidden by `#pragma GCC unroll 0` there is no warning.
[Bug fortran/118613] maxval/minval may evaluate argument too often
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118613 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |15.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed.
[Bug fortran/118580] Incorrect complex (sp) - real (dp) operation within maxval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118580 --- Comment #8 from anlauf at gcc dot gnu.org --- It appears that the issue is solved with r15-7165-g3cef53a4d4ff44 . Can you please check?
[Bug c++/118629] [14/15 Regression] ice in cp_parser_expression_statement, at cp/parser.cc:13584
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118629 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Summary|ice in |[14/15 Regression] ice in |cp_parser_expression_statem |cp_parser_expression_statem |ent, at cp/parser.cc:13584 |ent, at cp/parser.cc:13584 CC||mpolacek at gcc dot gnu.org Last reconfirmed||2025-01-23 Status|UNCONFIRMED |NEW Priority|P3 |P2 Target Milestone|--- |14.3 --- Comment #1 from Marek Polacek --- Confirmed, started with r14-6343: commit 0c018a74eb1affe2a1fa385cdddaa93979683420 Author: Patrick Palka Date: Fri Dec 8 13:34:04 2023 -0500 c++: guard more against undiagnosed error_mark_node [PR112658] so it was a latent issue.
[Bug target/80813] [12/13/14/15 Regression] x86: std::vector::operator[] could be somewhat faster using BT instead of SHL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80813
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:2d55c0161562f96d2230cd132b494a5d06352a23
commit r15-7163-g2d55c0161562f96d2230cd132b494a5d06352a23
Author: Jan Hubicka
Date: Thu Jan 23 15:50:50 2025 +0100
Optimize vector::operator[]
the following testcase:
bool f(const std::vector& v, std::size_t x) {
return v[x];
}
is compiled as:
f(std::vector > const&, unsigned long):
testq %rsi, %rsi
leaq63(%rsi), %rax
movq(%rdi), %rdx
cmovns %rsi, %rax
sarq$6, %rax
leaq(%rdx,%rax,8), %rdx
movq%rsi, %rax
sarq$63, %rax
shrq$58, %rax
addq%rax, %rsi
andl$63, %esi
subq%rax, %rsi
jns .L2
addq$64, %rsi
subq$8, %rdx
.L2:
movl$1, %eax
shlx%rsi, %rax, %rax
andq(%rdx), %rax
setne %al
ret
which is quite expensive for simple bit access in a bitmap. The reason is
that
the bit access is implemented using iterators
return begin()[__n];
Which in turn cares about situation where __n is negative yielding the
extra
conditional.
_GLIBCXX20_CONSTEXPR
void
_M_incr(ptrdiff_t __i)
{
_M_assume_normalized();
difference_type __n = __i + _M_offset;
_M_p += __n / int(_S_word_bit);
__n = __n % int(_S_word_bit);
if (__n < 0)
{
__n += int(_S_word_bit);
--_M_p;
}
_M_offset = static_cast(__n);
}
While we can use __builtin_unreachable to declare that __n is in range
0...max_size () but I think it is better to implement it directly, since
resulting code is shorter and much easier to optimize.
We now porduce:
.LFB1248:
.cfi_startproc
movq(%rdi), %rax
movq%rsi, %rdx
shrq$6, %rdx
andq(%rax,%rdx,8), %rsi
andl$63, %esi
setne %al
ret
Testcase suggests
movq(%rdi), %rax
movl%esi, %ecx
shrq$5, %rsi# does still need to be 64-bit
movl(%rax,%rsi,4), %eax
btl %ecx, %eax
setb%al
retq
Which is still one instruction shorter.
libstdc++-v3/ChangeLog:
PR target/80813
* include/bits/stl_bvector.h (vector::operator []):
Do
not use iterators.
gcc/testsuite/ChangeLog:
PR target/80813
* g++.dg/tree-ssa/bvector-3.C: New test.
[Bug middle-end/118012] [avr][13/14/15 Regression] Expensive code (bit extract + extend + neg + and) instead of bit test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012 --- Comment #17 from Georg-Johann Lay --- (In reply to GCC Commits from comment #16) > AVR: PR118012 - Try to work around sick code from match.pd. The patch above just tries to work around PR118012 / PR118360. It is by no means a proper fix, and some of the new test cases are failing (e.g. since MULT is performed as a libgcc call). Patches to fix this PR should be conducted with -mno-pr118012 so that they are not distracted by the work-around. Once a proper fix is available, the parts that only run when avropt_pr118012 is on should be removed.
[Bug fortran/118499] Exponentiation of UNSIGNED is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499 --- Comment #21 from anlauf at gcc dot gnu.org --- When doing x ** n in unsigned binary arithmetic, and x is an unsigned with k bits, and we do arithmetic modulo 2^k, then x ** n = x ** min (n, k) (mod 2^k) so we can immediately saturate the exponent. Does this also help?
[Bug fortran/118499] Exponentiation of UNSIGNED is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499 --- Comment #22 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #21) > When doing x ** n in unsigned binary arithmetic, and x is an unsigned with k > bits, and we do arithmetic modulo 2^k, then > > x ** n = x ** min (n, k) (mod 2^k) Scrap that, this is wrong.
[Bug c++/118632] New: 0 vs nullptr mixup in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118632
Bug ID: 118632
Summary: 0 vs nullptr mixup in template
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pobrn at protonmail dot com
Target Milestone: ---
Consider the following piece of code:
#include
template > * =
nullptr>
class Matrix {};
template void operator*(Matrix, int rgb) {
Matrix{} * rgb;
}
-- https://gcc.godbolt.org/z/GTqMf69K4
It fails on gcc 15 with the following error:
: In function 'void operator*(Matrix, int)':
:7:17: error: no match for 'operator*' (operand types are
'Matrix' and 'int') [-Wtemplate-body]
7 | Matrix{} * rgb;
| ~~^
:7:17: note: there is 1 candidate
:6:28: note: candidate 1: 'template void
operator*(Matrix, int)'
6 | template void operator*(Matrix, int rgb) {
|^~~~
:6:28: note: template argument deduction/substitution failed:
:7:19: note: template argument '0' does not match 'nullptr'
7 | Matrix{} * rgb;
| ^~~
This does not happen with clang, msvc, or earlier gcc versions.
[Bug c/118403] uninitialized warning with automatic union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118403 --- Comment #16 from Stephen Hemminger --- (In reply to Sam James from comment #15) > (In reply to Stephen Hemminger from comment #14) > > (In reply to Sam James from comment #13) > > > (In reply to Stephen Hemminger from comment #12) > > > > > > What does `gcc --version` give? > > > > $ gcc-15 --version > > gcc-15 (GCC) 15.0.0 2024 (experimental) > > You need >= r15-5746-g0547dbb725b6d8 which is from November 28th. These tests are being run on Gcc being built from upstream git (ie. latest). There was an install issue where an old version was left behind. The lastest version fixes the zero-init-flag issue.
[Bug c++/118631] Public class member as const reference to protected member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118631 --- Comment #4 from Jörg Brüggmann --- Aha. Got it. Thank you!
[Bug c++/118632] [15 Regression] 0 vs nullptr mixup in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118632 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Last reconfirmed||2025-01-23 Target Milestone|--- |15.0 Status|UNCONFIRMED |NEW CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Summary|0 vs nullptr mixup in |[15 Regression] 0 vs |template|nullptr mixup in template Priority|P3 |P1 --- Comment #1 from Marek Polacek --- Started with r15-2761: commit b2a8ee0e5d8cfa92bafd0db4b03626b26ac21948 Author: Jason Merrill Date: Mon Aug 5 13:20:17 2024 -0400 c++: more non-type template parms [PR116223]
[Bug c++/118626] C++20 std::variant causes a segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118626 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Keywords|needs-source|needs-reduction CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #5 from Marek Polacek --- Confirmed. Started with r10-5020 I think. commit 1a291106384cabc73da0bc0f457b1cd3a4015970 Author: Jason Merrill Date: Wed Nov 27 17:05:53 2019 -0500 Implement P1814R0, CTAD for alias templates. So probably not a regression.
[Bug middle-end/118360] [avr] Expensive shift instead of bit test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118360 --- Comment #5 from Georg-Johann Lay --- (In reply to GCC Commits from comment #4) > AVR: PR118012 - Try to work around sick code from match.pd. The patch above just tries to work around PR118012 / PR118360. It is by no means a proper fix, and some of the new test cases are failing (e.g. since MULT is performed as a libgcc call). Patches to fix this PR should be conducted with -mno-pr118012 so that they are not distracted by the work-around. Once a proper fix is available, the parts that only run when avropt_pr118012 is on should be removed.
[Bug fortran/118613] maxval/minval may evaluate argument too often
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118613 --- Comment #6 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3cef53a4d4ff44a5b61284bb0e6977f7ba7b3aab commit r15-7165-g3cef53a4d4ff44a5b61284bb0e6977f7ba7b3aab Author: Harald Anlauf Date: Wed Jan 22 22:44:39 2025 +0100 Fortran: do not evaluate arguments of MAXVAL/MINVAL too often [PR118613] PR fortran/118613 gcc/fortran/ChangeLog: * trans-intrinsic.cc (gfc_conv_intrinsic_minmaxval): Adjust algorithm for inlined version of MINLOC and MAXLOC so that arguments are only evaluted once, and create temporaries where necessary. Document change of algorithm. gcc/testsuite/ChangeLog: * gfortran.dg/maxval_arg_eval_count.f90: New test.
[Bug c++/118626] C++20 std::variant causes a segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118626 --- Comment #7 from Andrew Pinski --- Created attachment 60254 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60254&action=edit Reduced testcase Note this reduced testcase is invalid in this case. I didn't try to reduce it to a valid case though.
[Bug c++/118632] [15 Regression] 0 vs nullptr mixup as default argument of dependently typed NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118632
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Summary|[15 Regression] 0 vs|[15 Regression] 0 vs
|nullptr mixup in template |nullptr mixup as default
||argument of dependently
||typed NTTP
--- Comment #2 from Patrick Palka ---
Reduced:
template
class Matrix {};
template
void operator*(Matrix, int);
int main() {
Matrix m;
m * 42;
}
[Bug fortran/118499] Exponentiation of UNSIGNED is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #20 from Thomas Koenig ---
Right now, I am doing unsigned**unsigned. This is already a
bit larger than I originally thought. After this is committed,
we can still discuss how to extend it, I think.
There is actually an interesting simplification for modulo
arithmetic, which I do not know how to do in C.
Assume that power_simple() does the same as our current library
implementation.
What I would like to do is
uint8_t
power_complicated (uint8_t x, uint32_t n)
{
uint8_t zeros = __builtin_ctz (x);
uint8_t n_times_zeros;
if (x == 0)
return 0;
if (zeros == 0)
return power_simple (x, n & 127);
n_times_zeros = n * zeros;
if (n_times_zeros > 8)
return 0;
return power_simple (x, n & 255);
}
(The n & 127 follows from Euler's theorem, because phi(2^n) = 2^(n-1)).
So basically, a number with zeros trailing zeros to a power of x will
be zero under modulo 2^8 arithmetic if the number of zeros times n
is larger than 8. But I have not found a reasonable way to check if
n * zeros has overflowed. So, I will probably settle for something like
if (x & 1)
return power_simple (x, n & 127);
if (n > 8)
return 0;
return power_simple (x, n & 255);
[Bug tree-optimization/115363] Missing loop vectorization due to loop bound load not being pulled out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115363
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
||m-project/issues/124105
--- Comment #3 from Andrew Pinski ---
So this can easily show up in C++ code in lambdas where it is not obvious a
reference even:
```
void foo(int *A, int *B, int *C, int *D, int len) {
auto func = [&] () {
for (int i =0; i < len; i++)
A[i] = B[i] * C[i] + D[i];
};
func();
}
```
Compile with `-O3 -fno-inline` Note the no-inline here is important
This shows up in Geekbench 6.1
src/geekbench/ml/backend/cpu/depthwise_convolution_2d.cpp
[Bug middle-end/118633] New: Early optimizations/transformations vs. heterogeneous offloading compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118633 Bug ID: 118633 Summary: Early optimizations/transformations vs. heterogeneous offloading compilation Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: openacc, openmp Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org, pinskia at gcc dot gnu.org, rguenth at gcc dot gnu.org Target Milestone: --- I had wondered about that issue before (years ago, but don't think a PR already exists), and now remembered when reading PR118012 "[avr][13/14/15 Regression] Expensive code (bit extract + extend + neg + and) instead of bit test", PR118360 "[avr] Expensive shift instead of bit test". These -- if I quickly got that right -- may intend to add more target hooks use (like, costing of multiplication vs. jump) to guide early optimizations/transformations (GENERIC/GIMPLE 'match.pd' etc.). I understand the motivation. However, somewhat reciprocal to that, for heterogeneous offloading compilation (basically, multi-target GCC), we should rather *not* do any such optimizations/transformations before the offloading code has been split off: what is beneficial for the host (such as x86_64, PPC64, aarch64, RISC-V) may not necessarily be so for heterogeneous device code generation (such as nvptx, GCN). And worse, if for different hosts we end up with different "patterns", it'll become more and more complex to handle (recognize, possibly un-do) these transformations during offloading compilation. Do we have a coherent story regarding this issue? Can we defer "all this" until after the offloading code has been split off? What I would not like to do is guide early optimizations/transformations on whether offloading compilation is enabled or not, because that may result in different host code being generated (even if offloading is then not actually used). (I think PR95622 already describes one such case?) If I remember correctly, we already have a few ad-hoc cases where optimizations/transformations are deferred based on whether we're inside an offloading code region. This also has a bit of a bad taste to it? (..., but may be necessary in some cases, I understand.) I had the idea to add a check for this via an internal flag whether the offloading code has been split off, and if "non-allowed" target hooks are used before, error out. Does that make any sense?
[Bug c++/118631] Public class member as const reference to protected member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118631 --- Comment #1 from Andrew Pinski --- Most likely you forgot a copy constructor. A default copy constructor will point the new msets to the old msets_ .
[Bug middle-end/118012] [avr][13/14/15 Regression] Expensive code (bit extract + extend + neg + and) instead of bit test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #16 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:0bb3223097e5ced4f9a13d18c6c65f2a9496437e
commit r15-7164-g0bb3223097e5ced4f9a13d18c6c65f2a9496437e
Author: Georg-Johann Lay
Date: Sat Jan 11 14:10:29 2025 +0100
AVR: PR118012 - Try to work around sick code from match.pd.
This patch tries to work around PR118012 which may use a
full fledged multiplication instead of a simple bit test.
This is because match.pd's
/* (zero_one == 0) ? y : z y -> ((typeof(y))zero_one * z) y */
/* (zero_one != 0) ? z y : y -> ((typeof(y))zero_one * z) y */
"optimizes" code with op in { plus, ior, xor } like
if (a & 1)
b = b c;
to something like:
x1 = EXTRACT_BIT0 (a);
x2 = c MULT x1;
b = b x2;
or
x1 = EXTRACT_BIT0 (a);
x2 = ZERO_EXTEND (x1);
x3 = NEG x2;
x4 = a AND x3:
b = b x4;
which is very expensive and may even result in a libgcc call for
a 32-bit multiplication on devices that don't even have MUL.
Notice that EXTRACT_BIT0 is already more expensive (slower, more
code, more register pressure) than a bit-test + branch.
The patch:
o Adds some combiner patterns that try to map sick code back
to a bit test + branch.
o Adjusts costs to make MULT (x AND 1) cheap, in the hope that the
middle-end will use that alternative (which we map to sane code).
o On devices without MUL, 32-bit multiplication was performed by a
library call, which bypasses the MULT (x AND 1) and similar patterns.
Therefore, mulsi3 is also allowed for devices without MUL so that
we get at MULT pattern that can be transformed. (Though this is
not possible on AVR_TINY since it passes arguments on the stack).
o Add a new command line option -mpr118012, so most of the patterns
and cost computations can be switched off as they have
avropt_pr118012 in their insn condition.
o Added sign-extract.0 patterns unconditionally (no avropt_pr118012).
Notice that this patch is just a work-around, it's not a fix of the
root cause, which are the patterns in match.pd that don't care about
the target and don't even care about costs.
The work-around is incomplete, and 3 of the new tests are still failing.
This is because there are situations where it does not work:
* The MULT is realized as a library call.
* The MULT is realized as an ASHIFT, and the ASHIFT again is transformed
into something else. For example, with -O2 -mmcu=atmega128,
ASHIFT(3) is transformed into ASHIFT(1) + ASHIFT(2).
PR tree-optimization/118012
PR tree-optimization/118360
gcc/
* config/avr/avr.opt (-mpr118012): New undocumented option.
* config/avr/avr-protos.h (avr_out_sextr)
(avr_emit_skip_pixop, avr_emit_skip_clear): New protos.
* config/avr/avr.cc (avr_adjust_insn_length)
[case ADJUST_LEN_SEXTR]: Handle case.
(avr_rtx_costs_1) [NEG]: Costs for NEG (ZERO_EXTEND
(ZERO_EXTRACT)).
[MULT && avropt_pr118012]: Costs for MULT (x AND 1).
(avr_out_sextr, avr_emit_skip_pixop, avr_emit_skip_clear): New
functions.
* config/avr/avr.md [avropt_pr118012]: Add combine patterns with
that condition that try to work around PR118012.
(adjust_len) : Add insn attr value.
(pixop): New code iterator.
(mulsi3) [avropt_pr118012 && !AVR_TINY]: Allow these in insn
condition.
gcc/testsuite/
* gcc.target/avr/mmcu/pr118012-1.h: New file.
* gcc.target/avr/mmcu/pr118012-1-o2-m128.c: New test.
* gcc.target/avr/mmcu/pr118012-1-os-m128.c: New test.
* gcc.target/avr/mmcu/pr118012-1-o2-m103.c: New test.
* gcc.target/avr/mmcu/pr118012-1-os-m103.c: New test.
* gcc.target/avr/mmcu/pr118012-1-o2-t40.c: New test.
* gcc.target/avr/mmcu/pr118012-1-os-t40.c: New test.
* gcc.target/avr/mmcu/pr118360-1.h: New file.
* gcc.target/avr/mmcu/pr118360-1-o2-m128.c: New test.
* gcc.target/avr/mmcu/pr118360-1-os-m128.c: New test.
* gcc.target/avr/mmcu/pr118360-1-o2-m103.c: New test.
* gcc.target/avr/mmcu/pr118360-1-os-m103.c: New test.
* gcc.target/avr/mmcu/pr118360-1-o2-t40.c: New test.
* gcc.target/avr/mmcu/pr118360-1-os-t40.c: New test.
[Bug middle-end/118360] [avr] Expensive shift instead of bit test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118360
--- Comment #4 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:0bb3223097e5ced4f9a13d18c6c65f2a9496437e
commit r15-7164-g0bb3223097e5ced4f9a13d18c6c65f2a9496437e
Author: Georg-Johann Lay
Date: Sat Jan 11 14:10:29 2025 +0100
AVR: PR118012 - Try to work around sick code from match.pd.
This patch tries to work around PR118012 which may use a
full fledged multiplication instead of a simple bit test.
This is because match.pd's
/* (zero_one == 0) ? y : z y -> ((typeof(y))zero_one * z) y */
/* (zero_one != 0) ? z y : y -> ((typeof(y))zero_one * z) y */
"optimizes" code with op in { plus, ior, xor } like
if (a & 1)
b = b c;
to something like:
x1 = EXTRACT_BIT0 (a);
x2 = c MULT x1;
b = b x2;
or
x1 = EXTRACT_BIT0 (a);
x2 = ZERO_EXTEND (x1);
x3 = NEG x2;
x4 = a AND x3:
b = b x4;
which is very expensive and may even result in a libgcc call for
a 32-bit multiplication on devices that don't even have MUL.
Notice that EXTRACT_BIT0 is already more expensive (slower, more
code, more register pressure) than a bit-test + branch.
The patch:
o Adds some combiner patterns that try to map sick code back
to a bit test + branch.
o Adjusts costs to make MULT (x AND 1) cheap, in the hope that the
middle-end will use that alternative (which we map to sane code).
o On devices without MUL, 32-bit multiplication was performed by a
library call, which bypasses the MULT (x AND 1) and similar patterns.
Therefore, mulsi3 is also allowed for devices without MUL so that
we get at MULT pattern that can be transformed. (Though this is
not possible on AVR_TINY since it passes arguments on the stack).
o Add a new command line option -mpr118012, so most of the patterns
and cost computations can be switched off as they have
avropt_pr118012 in their insn condition.
o Added sign-extract.0 patterns unconditionally (no avropt_pr118012).
Notice that this patch is just a work-around, it's not a fix of the
root cause, which are the patterns in match.pd that don't care about
the target and don't even care about costs.
The work-around is incomplete, and 3 of the new tests are still failing.
This is because there are situations where it does not work:
* The MULT is realized as a library call.
* The MULT is realized as an ASHIFT, and the ASHIFT again is transformed
into something else. For example, with -O2 -mmcu=atmega128,
ASHIFT(3) is transformed into ASHIFT(1) + ASHIFT(2).
PR tree-optimization/118012
PR tree-optimization/118360
gcc/
* config/avr/avr.opt (-mpr118012): New undocumented option.
* config/avr/avr-protos.h (avr_out_sextr)
(avr_emit_skip_pixop, avr_emit_skip_clear): New protos.
* config/avr/avr.cc (avr_adjust_insn_length)
[case ADJUST_LEN_SEXTR]: Handle case.
(avr_rtx_costs_1) [NEG]: Costs for NEG (ZERO_EXTEND
(ZERO_EXTRACT)).
[MULT && avropt_pr118012]: Costs for MULT (x AND 1).
(avr_out_sextr, avr_emit_skip_pixop, avr_emit_skip_clear): New
functions.
* config/avr/avr.md [avropt_pr118012]: Add combine patterns with
that condition that try to work around PR118012.
(adjust_len) : Add insn attr value.
(pixop): New code iterator.
(mulsi3) [avropt_pr118012 && !AVR_TINY]: Allow these in insn
condition.
gcc/testsuite/
* gcc.target/avr/mmcu/pr118012-1.h: New file.
* gcc.target/avr/mmcu/pr118012-1-o2-m128.c: New test.
* gcc.target/avr/mmcu/pr118012-1-os-m128.c: New test.
* gcc.target/avr/mmcu/pr118012-1-o2-m103.c: New test.
* gcc.target/avr/mmcu/pr118012-1-os-m103.c: New test.
* gcc.target/avr/mmcu/pr118012-1-o2-t40.c: New test.
* gcc.target/avr/mmcu/pr118012-1-os-t40.c: New test.
* gcc.target/avr/mmcu/pr118360-1.h: New file.
* gcc.target/avr/mmcu/pr118360-1-o2-m128.c: New test.
* gcc.target/avr/mmcu/pr118360-1-os-m128.c: New test.
* gcc.target/avr/mmcu/pr118360-1-o2-m103.c: New test.
* gcc.target/avr/mmcu/pr118360-1-os-m103.c: New test.
* gcc.target/avr/mmcu/pr118360-1-o2-t40.c: New test.
* gcc.target/avr/mmcu/pr118360-1-os-t40.c: New test.
[Bug c++/118631] Public class member as const reference to protected member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118631
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Andrew Pinski ---
With this copy constructor added, I get the results you expected:
StringSet(const StringSet & o) : msets {msets_}, msets_(o.msets_) {};
[Bug c++/118631] Public class member as const reference to protected member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118631
--- Comment #3 from Andrew Pinski ---
The copy constructor is needed because of:
```
StringSet operator + ( const StringSet& stringSetA, const StringSet& stringSetB
) {
StringSet resultStringSet{ stringSetA };
resultStringSet.include( stringSetB );
return resultStringSet;
}
```
That copies stringSetA but it uses the default one which will copy the
reference pointing to the stringSetA.msets_ and still point to that.
[Bug tree-optimization/114589] missed optimization: losing bool range information, missed sinking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589 Andrew Macleod changed: What|Removed |Added CC||aldyh at gcc dot gnu.org --- Comment #11 from Andrew Macleod --- (In reply to Richard Biener from comment #10) > > from pointer to unsigned long. Possibly IVOPTs replacing the pointer > IV with an integer IV (but nothing else really) is the issue here. > Yes, this would be my guess. with pointers we make an attempt to track the symbolic base in VRP, whereas with integers there is not usually a need. So when it comes to the loop there is no attempt to track that the lower bound of the loop/PHI is o_3... Instead, we see a non-zero integral range. PHI analysis can detect that it is increasing, but it has no way to recognize a starting base range. Its possible when prange has points to analysis implemented it might be able to determine something (ie look at what the integer is derived from, looking for a cast in the past to determine a base) , but moving back and forth to an integer certainly complicated things.
[Bug tree-optimization/111494] Signed overflow introduced by vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111494 --- Comment #2 from Richard Biener --- Created attachment 60250 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60250&action=edit patch OK, so it at least got re-broken when refactoring reduction vectorization to rely on vectorizable_* for vectorizing the reduction stmt. So like the attached, generating vect__1.10_27 = MEM [(int *)vectp_a.8_25]; vect_sum_6.13_29 = VIEW_CONVERT_EXPR(vect__1.10_27); vect_sum_6.13_30 = VIEW_CONVERT_EXPR(vect_sum_10.11_28); vect_sum_6.13_31 = vect_sum_6.13_29 + vect_sum_6.13_30; vect_sum_6.12_32 = VIEW_CONVERT_EXPR(vect_sum_6.13_31); _1 = a[i_12]; but it's a bit of a local hack and it might be better to promote the whole reduction variable to unsigned.
[Bug rtl-optimization/118562] [15 Regression] SEGV in late-combine (rtl_ssa::function_info::remove_use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118562 --- Comment #6 from GCC Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:3dbcf794f0fe89443288143405718d72e7963805 commit r15-7162-g3dbcf794f0fe89443288143405718d72e7963805 Author: Richard Sandiford Date: Thu Jan 23 13:57:02 2025 + rtl-ssa: Avoid dangling phi uses [PR118562] rtl-ssa uses degenerate phis to maintain an RPO list of accesses in which every use is of the RPO-previous definition. Thus, if it finds that a phi is always equal to a particular value V, it sometimes needs to keep the phi and make V the single input, rather than replace all uses of the phi with V. The code to do that rerouted the phi's first input to the single value V. But as this PR shows, it failed to unlink the uses of the other inputs. The specific problem in the PR was that we had: x = PHI The code replaced the first input with V and removed the second input from the phi, but it didn't unlink the use of V associated with that second input. gcc/ PR rtl-optimization/118562 * rtl-ssa/blocks.cc (function_info::replace_phi): When converting to a degenerate phi, make sure to remove all uses of the previous inputs. gcc/testsuite/ PR rtl-optimization/118562 * gcc.dg/torture/pr118562.c: New test.
[Bug target/116330] -fcompare-debug -gno-statement-frontiers failure with -O3 -march=znver3 -mshstk when building qtbase-6.7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116330 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Keywords||needs-reduction --- Comment #4 from Andrew Pinski --- Reducing ...
[Bug middle-end/118633] Early optimizations/transformations vs. heterogeneous offloading compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118633 --- Comment #1 from Richard Biener --- IMO we can't have both - "early" optimized offload code and optimization that's suited for the offload target. Instead we should somehow work towards "offloading" (aka outlining) relevant parts before early optimizations (that possibly affect the offload target adversely) are run on the code that at that point appears to be targeted to the host. I'll note that we for example apply the host targets inlining target hooks to decide on early inlining done. The mentioned match.pd (much like code in fold-const.cc) should be always seen as canonicalization (and partial constant folding), they are not tied to a specific target but of course people contributing usually have "common" targets in mind as well.
[Bug middle-end/118608] [14/15 regression][mips64] Lack of sign extension with -Os after r14-6915
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118608 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-01-24 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug rtl-optimization/118562] [15 Regression] SEGV in late-combine (rtl_ssa::function_info::remove_use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118562 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Richard Sandiford --- Fixed.
[Bug driver/118636] `-Werror` and `-w` do not affect linker warnings, but the docs say they should [docs bug?]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118636 --- Comment #2 from Andrew Pinski --- >so maybe it's universal enough I don't think Solaris's linker accepts it. Nor does AIX ld. Nor HPUX's (yes these targets are all supported still). Apple's linkers might all but I am not 100% sure there.
[Bug rtl-optimization/118623] [12/13/14/15 regression] Miscompile with -O2/3 and -O0/1 since r12-7751-g919fbffef07555
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118623 --- Comment #10 from Hongtao Liu --- > > r12-7751-g919fbffef07555 > > that might have just exposed a latent issue Should be, the guilty commit just extent a splitter to handle reversed condition, didn't see anything abnormal.
[Bug gcov-profile/114291] -fcompare-debug failure (length) with -fprofile-use at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114291 Andrew Pinski changed: What|Removed |Added Component|middle-end |gcov-profile Ever confirmed|0 |1 Last reconfirmed||2025-01-24 Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug fortran/118571] UTF-8 output and the A edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118571 --- Comment #8 from Jerry DeLisle --- Created attachment 60256 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60256&action=edit Proposed final patch This patch submitted for approval.
[Bug target/118103] [15 Regression] GCC miscompile rvv intrinsics at `-O3`, missing the `fsrm` instruction to the recover status of frm CSR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118103
--- Comment #3 from Li Pan ---
Interesting the test_example in a separate function other than main will have
the frm restore insn, but there will be no such frm in main function.
62 │ test_exampe:
63 │ frrma2
64 │ fsrmi 2
65 │ lui a3,%hi(a)
66 │ addia3,a3,%lo(a)
67 │ lui a5,%hi(b)
68 │ vsetivlizero,4,e16,m1,ta,ma
69 │ vle16.v v1,0(a3)
70 │ addia5,a5,%lo(b)
71 │ vfnmadd.vv v1,v1,v1
72 │ fsrma2// Has FRM
73 │ vfmsub.vv v1,v1,v1
74 │ vse16.v v1,0(a5)
75 │ ret
76 │ .size test_exampe, .-test_exampe
77 │ .section.text.startup,"ax",@progbits
78 │ .align 1
79 │ .globl main
80 │ .type main, @function
81 │ main:
82 │ addisp,sp,-16
83 │ sd ra,8(sp)
84 │ callinitialize
85 │ fsrmi 2
86 │ lui a3,%hi(a)
87 │ addia3,a3,%lo(a)
88 │ lui a5,%hi(b)
89 │ vsetivlizero,4,e16,m1,ta,ma
90 │ vle16.v v1,0(a3)
91 │ addia5,a5,%lo(b)
92 │ vfnmadd.vv v1,v1,v1 // No FRM
93 │ vfmsub.vv v1,v1,v1
94 │ vse16.v v1,0(a5)
95 │ callprint_result
96 │ ld ra,8(sp)
97 │ li a0,0
98 │ addisp,sp,16
99 │ jr ra
52 │ void test_exampe () {
53 │ int avl = dataLen;
54 │ float16_t* ptr_a = a; float16_t* ptr_b = b;
55 │ size_t vl = __riscv_vsetvl_e16m1(avl);
56 │ vfloat16m1_t va = __riscv_vle16_v_f16m1(ptr_a, vl);
57 │ va = __riscv_vfnmadd_vv_f16m1_rm(va, va, va, __RISCV_FRM_RDN, vl);
58 │ va = __riscv_vfmsac_vv_f16m1(va, va, va, vl);
59 │ __riscv_vse16_v_f16m1(ptr_b, va, vl);
60 │ }
61 │
62 │ int main(){
63 │ initialize();
64 │
65 │ int avl = dataLen;
66 │ float16_t* ptr_a = a; float16_t* ptr_b = b;
67 │ size_t vl = __riscv_vsetvl_e16m1(avl);
68 │ vfloat16m1_t va = __riscv_vle16_v_f16m1(ptr_a, vl);
69 │ va = __riscv_vfnmadd_vv_f16m1_rm(va, va, va, __RISCV_FRM_RDN, vl);
70 │ va = __riscv_vfmsac_vv_f16m1(va, va, va, vl);
71 │ __riscv_vse16_v_f16m1(ptr_b, va, vl);
72 │
73 │ print_result ();
74 │
75 │ return 0;
76 │ }
[Bug target/118103] [15 Regression] GCC miscompile rvv intrinsics at `-O3`, missing the `fsrm` instruction to the recover status of frm CSR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118103 --- Comment #4 from Li Pan --- gcc-14 has the correct behavior and mostly some middle-end change I guess. └─(11:39:07 on master⚑ ✭)──> riscv64-linux-gnu-gcc-14 --version riscv64-linux-gnu-gcc-14 (Ubuntu 14.2.0-4ubuntu2~24.04) 14.2.0 70 │ test_exampe: 71 │ .LFB2: 72 │ .cfi_startproc 73 │ frrma3 74 │ fsrmi 2 75 │ lla a2,.LANCHOR0 76 │ lla a4,.LANCHOR0+8 77 │ vsetivlizero,4,e16,m1,ta,ma 78 │ vle16.v v1,0(a2) 79 │ vfnmadd.vv v1,v1,v1 80 │ fsrma3 81 │ vfmsub.vv v1,v1,v1 82 │ vse16.v v1,0(a4) 83 │ ret 84 │ .cfi_endproc 85 │ .LFE2: 86 │ .size test_exampe, .-test_exampe 87 │ .section.text.startup,"ax",@progbits 88 │ .align 1 89 │ .globl main 90 │ .type main, @function 91 │ main: 92 │ .LFB3: 93 │ .cfi_startproc 94 │ addisp,sp,-16 95 │ .cfi_def_cfa_offset 16 96 │ sd ra,8(sp) 97 │ .cfi_offset 1, -8 98 │ callinitialize 99 │ frrma3 100 │ fsrmi 2 101 │ lla a2,.LANCHOR0 102 │ lla a4,.LANCHOR0+8 103 │ vsetivlizero,4,e16,m1,ta,ma 104 │ vle16.v v1,0(a2) 105 │ vfnmadd.vv v1,v1,v1 106 │ fsrma3 107 │ vfmsub.vv v1,v1,v1 108 │ vse16.v v1,0(a4) 109 │ callprint_result
[Bug fortran/116668] A very strange error when trying to copy substrings from a select type generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116668 --- Comment #5 from kargls at comcast dot net --- (In reply to Jerry DeLisle from comment #4) > I wonder if this should be closed? Yes.
[Bug fortran/117188] ICE when OUT variable dimension is defined by a IN variable member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117188 --- Comment #4 from kargls at comcast dot net --- (In reply to Jerry DeLisle from comment #3) > I think this can be closed. yes.
[Bug tree-optimization/118637] gcc fails to optimize unsigned division by 2 to shift right by 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118637 Andrew Pinski changed: What|Removed |Added Component|other |tree-optimization Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug rtl-optimization/118638] [14/15 Regression] Miscompile with -Os and -O0/1/2/3 since r14-4810-ge28869670c9879
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118638 Sam James changed: What|Removed |Added Keywords|needs-bisection | CC||roger at nextmovesoftware dot com, ||uros at gcc dot gnu.org Summary|[14/15 Regression] |[14/15 Regression] |Miscompile with -Os and |Miscompile with -Os and |-O0/1/2/3 |-O0/1/2/3 since ||r14-4810-ge28869670c9879 --- Comment #6 from Sam James --- yep
[Bug rtl-optimization/118615] [15 Regression] Bootstrap failure on aarch64 after r15-2810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118615 --- Comment #15 from Andrew Pinski --- Created attachment 60259 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60259&action=edit Non-reduced testcase for compare debug issue [apinski@xeond2 gcc]$ !./x ./xgcc -B. -fno-exceptions -fschedule-insns t.ii -O2 -fno-rtti -g -fcompare-debug -S Happens with a cross on the trunk with r15-2810 reapplied.
[Bug rtl-optimization/118615] [15 Regression] Bootstrap failure on aarch64 after r15-2810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118615 Andrew Pinski changed: What|Removed |Added Keywords||compare-debug-failure --- Comment #16 from Andrew Pinski --- (In reply to Andrew Pinski from comment #15) > Created attachment 60259 [details] > Non-reduced testcase for compare debug issue > > [apinski@xeond2 gcc]$ !./x > ./xgcc -B. -fno-exceptions -fschedule-insns t.ii -O2 -fno-rtti -g > -fcompare-debug -S > > Happens with a cross on the trunk with r15-2810 reapplied. Note it does not show up with -gno-statement-frontiers but that might just because there are less debug statements . But does not see like the standard statement-frontiers issue. That is: _ZL23split_constant_offset_1P9tree_nodeS0_9tree_codeS0_PS0_S2_P6irangeR8hash_mapIS0_St4pairIS0_S0_E21simple_hashmap_traitsI19default_hash_traitsIS0_ES7_EEPj has a different stack space that is saved. - sub sp, sp, #1808 + sub sp, sp, #1792 - is with -g. While + is without.
