[Bug target/112962] [14 Regression] ICE: SIGSEGV in operator() (recog.h:431) with -fexceptions -mssse3 and __builtin_ia32_pabsd128()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112962 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug tree-optimization/112961] [13/14 Regression] middle-end Missed vectorization: failed to vectorize simple reduction max since GCC-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112961 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Yup, unpropagated copies can confuse the vectorizer. Let me look into it.
[Bug target/96340] Extend AArch64 "omp declare simd" support to general simdlen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96340 --- Comment #1 from Andrew Pinski --- was this also fixed by r14-6416-gf5fc001a84a7db ?
[Bug tree-optimization/112939] [14 Regression] ICE: verify_ssa failed with -O -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112939 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug middle-end/112444] [14 regression] ICE when buliding libqmi with -O3 -ftrivial-auto-var-init=zero (internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112444 Bug 112444 depends on bug 112939, which changed state. Bug 112939 Summary: [14 Regression] ICE: verify_ssa failed with -O -ftrivial-auto-var-init=zero https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112939 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/112939] [14 Regression] ICE: verify_ssa failed with -O -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112939 --- Comment #3 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f5f33b44b5dd4c41ae335445ae3f06b1ca3cfbcb commit r14-6448-gf5f33b44b5dd4c41ae335445ae3f06b1ca3cfbcb Author: Richard Biener Date: Mon Dec 11 13:00:18 2023 +0100 tree-optimization/112939 - VN PHI visiting and -ftrivial-auto-var-init The following builds upon the last fix, making sure we only value-number to visited (un-)defs, otherwise prefer .VN_TOP. PR tree-optimization/112939 * tree-ssa-sccvn.cc (visit_phi): When all args are undefined make sure we end up with a value that was visited, otherwise fall back to .VN_TOP. * gcc.dg/pr112939.c: New testcase.
[Bug target/96341] Support mixed element widths for AArch64 "omp declare simd" functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96341 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed by r14-6416-gf5fc001a84a7db .
[Bug target/112693] declare-simd-4.f90 fails on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112693 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- Fixed by r14-6416-gf5fc001a84a7db .
[Bug target/112970] LoongArch: Suboptimal code when the address and the value of an array element are both used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112970 --- Comment #2 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #1) > With -mexplicit-relocs=auto the generated code is sub-optimal as well: I mean "always", not "auto". > pcalau12i $r12,%pc_hi20(.LANCHOR0) > addi.d $r12,$r12,%pc_lo12(.LANCHOR0) > ld.wu $r5,$r12,4 > addi.d $r4,$r12,4
[Bug target/112970] LoongArch: Suboptimal code when the address and the value of an array element are both used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112970 --- Comment #1 from Xi Ruoyao --- With -mexplicit-relocs=auto the generated code is sub-optimal as well: pcalau12i $r12,%pc_hi20(.LANCHOR0) addi.d $r12,$r12,%pc_lo12(.LANCHOR0) ld.wu $r5,$r12,4 addi.d $r4,$r12,4
[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929 --- Comment #18 from Li Pan --- I see, thanks all, will have a try with variadic function call.
[Bug preprocessor/112978] Five minute long error message when OpenMP pragma is erroneously placed in macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112978 --- Comment #2 from Raymond Chang --- (In reply to Andrew Pinski from comment #1) > I doubt this is fixable really because the number of expansions is huge. Thanks, I think this is a pretty uncommon situtation anyways. I figured I'd report it anyways though.
[Bug preprocessor/112978] Five minute long error message when OpenMP pragma is erroneously placed in macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112978 Andrew Pinski changed: What|Removed |Added Keywords||compile-time-hog --- Comment #1 from Andrew Pinski --- I doubt this is fixable really because the number of expansions is huge.
[Bug preprocessor/112978] New: Five minute long error message when OpenMP pragma is erroneously placed in macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112978
Bug ID: 112978
Summary: Five minute long error message when OpenMP pragma is
erroneously placed in macro
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: raymondkenchang at gmail dot com
Target Milestone: ---
When an OpenMP pragma is placed in a macro definition incorrectly, the error
message is extremly long. It took 5 minutes on my machine to output.
```
```
```
./compilers/gcc_install/bin/gcc -c -fopenmp hello.c 23.68s user 8.56s system
10% cpu 5:06.35 total
```
Test case:
```
#define LIM1(x) x##0, x##1, x##2, x##3, x##4, x##5, x##6, x##7, x##8, x##9,
#define LIM2(x) LIM1(x##0) LIM1(x##1) LIM1(x##2) LIM1(x##3) LIM1(x##4) \
LIM1(x##5) LIM1(x##6) LIM1(x##7) LIM1(x##8) LIM1(x##9)
#define LIM3(x) LIM2(x##0) LIM2(x##1) LIM2(x##2) LIM2(x##3) LIM2(x##4) \
LIM2(x##5) LIM2(x##6) LIM2(x##7) LIM2(x##8) LIM2(x##9)
#define LIM4(x) LIM3(x##0) LIM3(x##1) LIM3(x##2) LIM3(x##3) LIM3(x##4) \
LIM3(x##5) LIM3(x##6) LIM3(x##7) LIM3(x##8) LIM3(x##9)
#define LIM5(x) LIM4(x##0) LIM4(x##1) LIM4(x##2) LIM4(x##3) LIM4(x##4) \
LIM4(x##5) LIM4(x##6) LIM4(x##7) LIM4(x##8) LIM4(x##9)
#define LIM6(x) LIM5(x##0) LIM5(x##1) LIM5(x##2) LIM5(x##3) LIM5(x##4) \
#pragma omp barrier
LIM5(x##5) LIM5(x##6) LIM5(x##7) LIM5(x##8) LIM5(x##9)
#define LIM7(x) LIM6(x##0) LIM6(x##1) LIM6(x##2) LIM6(x##3) LIM6(x##4) \
LIM6(x##5) LIM6(x##6) LIM6(x##7) LIM6(x##8) LIM6(x##9)
enum q21_enum
{
LIM5 (e)
};
```
[Bug target/112891] [11/12/13/14 Regression] Missing vzeroupper insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112891 --- Comment #5 from GCC Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:fc62716fe8d1d60a9f1c6906e5a4845b3331b828 commit r14-6447-gfc62716fe8d1d60a9f1c6906e5a4845b3331b828 Author: liuhongt Date: Thu Dec 7 09:17:27 2023 +0800 Don't assume it's AVX_U128_CLEAN after call_insn whose abi.mode_clobber(V4DImode) deosn't contains all SSE_REGS. If the function desn't clobber any sse registers or only clobber 128-bit part, then vzeroupper isn't issued before the function exit. the status not CLEAN but ANY after the function. Also for sibling_call, it's safe to issue an vzeroupper. Also there could be missing vzeroupper since there's no mode_exit for sibling_call_p. gcc/ChangeLog: PR target/112891 * config/i386/i386.cc (ix86_avx_u128_mode_after): Return AVX_U128_ANY if callee_abi doesn't clobber all_sse_regs to align with ix86_avx_u128_mode_needed. (ix86_avx_u128_mode_needed): Return AVX_U128_ClEAN for sibling_call. gcc/testsuite/ChangeLog: * gcc.target/i386/pr112891.c: New test. * gcc.target/i386/pr112891-2.c: New test.
[Bug target/112334] ICE in gen_untyped_return arm.md:9197 while compiling harden-cfr-bret.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112334 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Alexandre Oliva --- Fixed, though there's an (optional) followup, posted along with the fix, that's not clearly approved.
[Bug target/112334] ICE in gen_untyped_return arm.md:9197 while compiling harden-cfr-bret.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112334 --- Comment #4 from GCC Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:d96533559e26dd0c86f0708fa46eef65c35f7b90 commit r14-6446-gd96533559e26dd0c86f0708fa46eef65c35f7b90 Author: Alexandre Oliva Date: Tue Dec 12 01:12:04 2023 -0300 untyped calls: enable target switching [PR112334] The computation of apply_args_size and apply_result_size is saved in a static variable, so that the corresponding _mode arrays are initialized only once. That is not compatible with switchable targets, and ARM's arm_set_current_function, by saving and restoring target globals, exercises this problem with a testcase such as that in the PR, in which more than one function in the translation unit calls __builtin_apply or __builtin_return, respectively. This patch moves the _size statics into the target_builtins array, with a bit of ugliness over _plus_one so that zero initialization of the struct does the right thing. for gcc/ChangeLog PR target/112334 * builtins.h (target_builtins): Add fields for apply_args_size and apply_result_size. * builtins.cc (apply_args_size, apply_result_size): Cache results in fields rather than in static variables. (get_apply_args_size, set_apply_args_size): New. (get_apply_result_size, set_apply_result_size): New.
[Bug ipa/112783] core dump on libxo when function is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |MOVED --- Comment #6 from Andrew Pinski --- .
[Bug ipa/112783] core dump on libxo when function is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #5 from Andrew Pinski --- .
[Bug ipa/112783] core dump on libxo when function is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783 yancheng.li at foxmail dot com changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #4 from yancheng.li at foxmail dot com --- Thanks for your reply andrew. It really solved my problem.
[Bug middle-end/100942] ccmp is not used if the value is used later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100942 --- Comment #2 from Andrew Pinski --- Created attachment 56860 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56860=edit Patch which I am testing Patch which I am testing. Will be doing some benchmarking too.
[Bug target/112943] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1176 with -O2 -march=westmere -mapxf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112943 Hongyu Wang changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Hongyu Wang --- Fixed on trunk.
[Bug target/112943] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1176 with -O2 -march=westmere -mapxf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112943 --- Comment #4 from GCC Commits --- The master branch has been updated by Hongyu Wang : https://gcc.gnu.org/g:07dcb39e08aa52f166e8d74420364757002ad756 commit r14-6445-g07dcb39e08aa52f166e8d74420364757002ad756 Author: Hongyu Wang Date: Mon Dec 11 19:30:42 2023 +0800 i386: Fix missed APX_NDD check for shift/rotate expanders [PR 112943] The ashl/lshr/ashr expanders calls ix86_expand_binary_operator, while they will be called for some post-reload split, and TARGET_APX_NDD is required for these calls to avoid force-load to memory at postreload stage. gcc/ChangeLog: PR target/112943 * config/i386/i386.md (ashl3): Add TARGET_APX_NDD to ix86_expand_binary_operator call. (3): Likewise for rshift. (di3): Likewise for DImode rotate. (3): Likewise for SWI124 rotate. gcc/testsuite/ChangeLog: PR target/112943 * gcc.target/i386/pr112943.c: New test.
[Bug tree-optimization/99407] s243 benchmark of TSVC is vectorized by clang and not by gcc, missed DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99407 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/107247] SLP reduction results fail to reduce to a single accumulator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107247 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/111972] [14 regression] missed vectorzation for bool a = j != 1; j = (long int)a;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972 --- Comment #20 from Hongtao Liu --- (In reply to Andrew Pinski from comment #19) > Fixed. Thanks.
[Bug target/112943] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1176 with -O2 -march=westmere -mapxf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112943 Hongtao Liu changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #3 from Hongtao Liu --- (In reply to Jakub Jelinek from comment #1) > Why does ix86_expand_binary_operator have the use_ndd argument at all? > Shouldn't it always act as if the argument is TARGET_APX_NDD? > Or, any particular reason why it isn't done in ashl3 (but in other > shifts/rotates)? By the time we support apx_ndd, the use_ndd is introduced to enable ndd pattern by pattern so that avoid other patterns crash, and now that we've completed the ndd patch, I think we can try to remove it. We need to make sure that there is no pattern under TARGET_APX_NDD but force a call to ix86_expand_binary_operator with use_ndd as false.
[Bug middle-end/112938] ice with -fstrub=internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938 --- Comment #4 from Alexandre Oliva --- Patch at https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640252.html
[Bug analyzer/112977] -Wanalyzer-tainted-offset false positive seen on Linux kernel's drivers/scsi/aacraid/aachba.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112977 --- Comment #1 from David Malcolm --- Created attachment 56859 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56859=edit Reduced reproducer (needs adding to plugin.exp)
[Bug analyzer/112977] New: -Wanalyzer-tainted-offset false positive seen on Linux kernel's drivers/scsi/aacraid/aachba.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112977 Bug ID: 112977 Summary: -Wanalyzer-tainted-offset false positive seen on Linux kernel's drivers/scsi/aacraid/aachba.c 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 Blocks: 106358 Target Milestone: --- drivers/scsi/aacraid/aachba.c: In function ‘force_delete_disk’: drivers/scsi/aacraid/aachba.c:3307:36: warning: use of attacker-controlled value as offset without upper-bounds checking [CWE-823] [-Wanalyzer-tainted-offset] 3307 | fsa_dev_ptr[dd.cnum].valid = 0; | ~~~^~~ ‘force_delete_disk’: events 1-7 | | 3292 | if (!fsa_dev_ptr) | |^ | || | |(1) following ‘false’ branch (when ‘fsa_dev_ptr’ is non-NULL)... |.. | 3295 | if (copy_from_user(, arg, sizeof (struct aac_delete_disk))) | | ~~ ~ | | | | | | | (3) following ‘false’ branch (when ‘n == 0’)... | | (2) ...to here |.. | 3298 | if (dd.cnum >= dev->maximum_num_containers) | | ~~ ~ | | | | | | | (5) following ‘false’ branch... | | (4) ...to here |.. | 3303 | fsa_dev_ptr[dd.cnum].deleted = 1; | | ~~~ | | | | | (6) ...to here |.. | 3307 | fsa_dev_ptr[dd.cnum].valid = 0; | | ~~ | || | |(7) use of attacker-controlled value as offset without upper-bounds checking | drivers/scsi/aacraid/aachba.c: In function ‘delete_disk’: drivers/scsi/aacraid/aachba.c:3335:49: warning: use of attacker-controlled value as offset without upper-bounds checking [CWE-823] [-Wanalyzer-tainted-offset] 3335 | fsa_dev_ptr[dd.cnum].devname[0] = '\0'; | ^~ ‘delete_disk’: events 1-9 | | 3317 | if (!fsa_dev_ptr) | |^ | || | |(1) following ‘false’ branch (when ‘fsa_dev_ptr’ is non-NULL)... |.. | 3320 | if (copy_from_user(, arg, sizeof (struct aac_delete_disk))) | | ~~ ~ | | | | | | | (3) following ‘false’ branch (when ‘n == 0’)... | | (2) ...to here |.. | 3323 | if (dd.cnum >= dev->maximum_num_containers) | | ~~ ~ | | | | | | | (5) following ‘false’ branch... | | (4) ...to here |.. | 3328 | if (fsa_dev_ptr[dd.cnum].locked) | | ~~ ~ | | | | | | | (7) following ‘false’ branch... | | (6) ...to here |.. | 3334 | fsa_dev_ptr[dd.cnum].valid = 0; | | ~~~ | | | | | (8) ...to here | 3335 | fsa_dev_ptr[dd.cnum].devname[0] = '\0'; | | ~~ | | | | | (9) use of attacker-controlled value as offset without upper-bounds checking | In both of these, dd.cnum is clearly checked, both at event (5) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358 [Bug 106358] [meta-bug] tracker bug for building the Linux kernel with -fanalyzer
[Bug target/112919] LoongArch: Alignments in tune parameters are not precise and they regress performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919 --- Comment #5 from chenglulu --- (In reply to Xi Ruoyao from comment #4) > Lulu: can you help to run some other benchmarks like SPEC (I don't have an > access to it) and update these values for LA464 and LA664? No problem, this is what I should do. However, there are many parameter combinations, so the time may be longer.
[Bug c++/112737] [14 Regression] g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112737 --- Comment #3 from Patrick Palka --- Created attachment 56858 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56858=edit untested fix Changing CLASS_PLACEHOLDER_TEMPLATE of a CTAD placeholder that names a ttp to point to the ttp's TEMPLATE_TEMPLATE_PARM node instead of its TEMPLATE_DECL seems to fix the issue, but I'm not sure if this is what we really want...
[Bug middle-end/100942] ccmp is not used if the value is used later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100942 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-12-12 --- Comment #1 from Andrew Pinski --- I have a fix.
[Bug middle-end/112976] expand_gimple_stmt_1 vs gimple_assign_nontemporal_move_p vs SSA_NAME on lhs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112976 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Last reconfirmed||2023-12-12 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Mine for cleanup for GCC 15.
[Bug middle-end/112976] New: expand_gimple_stmt_1 vs gimple_assign_nontemporal_move_p vs SSA_NAME on lhs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112976 Bug ID: 112976 Summary: expand_gimple_stmt_1 vs gimple_assign_nontemporal_move_p vs SSA_NAME on lhs Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: internal-improvement Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- As far as I can tell if TREE_CODE (lhs) == SSA_NAME then gimple_assign_nontemporal_move_p should always be false as it is never a store. So all of the code for nontemporal in the else case of `TREE_CODE (lhs) != SSA_NAME` if in cfgexpand.cc is dead. This has been there since r0-95521-g28ed065ef9f345 which added expand from tuples directly. We most likely should also have gimple_assign_set_nontemporal_move assert that the gimple assign's lhs is not a SSA_NAME.
[Bug c++/109876] [11/12 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|[11/12/13 Regression] |[11/12 Regression] |initializer_list not usable |initializer_list not usable |in constant expressions in |in constant expressions in |a template |a template --- Comment #17 from Marek Polacek --- Fixed in GCC 13 and 14.
[Bug c++/110106] [11/12 Regression] ICE on noexcept(noexcept(...)) with optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110106 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Summary|[11/12/13 Regression] ICE |[11/12 Regression] ICE on |on noexcept(noexcept(...)) |noexcept(noexcept(...)) |with optional |with optional --- Comment #7 from Marek Polacek --- Fixed for GCC 13+.
[Bug c++/112410] error when auto(x) is used in a variable initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112410 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Fixed.
[Bug c++/112410] error when auto(x) is used in a variable initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112410
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:60979215517629400902938b1c5666f97d0653cf
commit r13-8147-g60979215517629400902938b1c5666f97d0653cf
Author: Marek Polacek
Date: Thu Nov 9 12:25:25 2023 -0500
c++: fix parsing with auto(x) [PR112410]
Here we are wrongly parsing
int y(auto(42));
which uses the C++23 cast-to-prvalue feature, and initializes y to 42.
However, we were treating the auto as an implicit template parameter.
Fixing the auto{42} case is easy, but when auto is followed by a (,
I found the fix to be much more involved. For instance, we cannot
use cp_parser_expression, because that can give hard errors. It's
also necessary to disambiguate 'auto(i)' as 'auto i', not a cast.
auto(), auto(int), auto(f)(int), auto(*), auto(i[]), auto(...), etc.
are all function declarations.
This patch rectifies that by undoing the implicit function template
modification. In the test above, we should notice that the parameter
list is ill-formed, and since we've synthesized an implicit template
parameter, we undo it by calling abort_fully_implicit_template. Then,
we'll parse the "(auto(42))" as an initializer.
PR c++/112410
gcc/cp/ChangeLog:
* parser.cc (cp_parser_direct_declarator): Maybe call
abort_fully_implicit_template if it turned out the parameter list
was
ill-formed.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/auto-fncast13.C: New test.
* g++.dg/cpp23/auto-fncast14.C: New test.
(cherry picked from commit 70060dadfbf0d0af5f4cab5f3aff3223a4523606)
[Bug c++/110106] [11/12/13 Regression] ICE on noexcept(noexcept(...)) with optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110106 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:d44830a1364cf8cb726d59e91298a5b3077a86d9 commit r13-8148-gd44830a1364cf8cb726d59e91298a5b3077a86d9 Author: Marek Polacek Date: Tue Jul 18 16:02:21 2023 -0400 c++: fix ICE with is_really_empty_class [PR110106] is_really_empty_class is liable to crash when it gets an incomplete or dependent type. Since r11-557, we pass the yet-uninstantiated class type S<0> of the PARM_DECL s to is_really_empty_class -- because of the potential_rvalue_constant_expression -> is_rvalue_constant_expression change in cp_parser_constant_expression. Here we're not parsing a template so we did not check COMPLETE_TYPE_P as we should. It should work to complete the type before checking COMPLETE_TYPE_P. PR c++/110106 gcc/cp/ChangeLog: * constexpr.cc (potential_constant_expression_1): Try to complete the type when !processing_template_decl. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/noexcept80.C: New test. (cherry picked from commit e36d1994051122fc6e1f8c728fbd109a59e0a822)
[Bug c++/109876] [11/12/13 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876
--- Comment #16 from GCC Commits ---
The releases/gcc-13 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:08f4496aa619f9b0e8dbb459452dd96edb870236
commit r13-8146-g08f4496aa619f9b0e8dbb459452dd96edb870236
Author: Marek Polacek
Date: Thu May 25 18:54:18 2023 -0400
c++: wrong error with static constexpr var in tmpl [PR109876]
Since r8-509, we'll no longer create a static temporary var for
the initializer '{ 1, 2 }' for num in the attached test because
the code in finish_compound_literal is now guarded by
'&& fcl_context == fcl_c99' but it's fcl_functional here. This
causes us to reject num as non-constant when evaluating it in
a template.
Jason's idea was to treat num as value-dependent even though it
actually isn't. This patch implements that suggestion.
We weren't marking objects whose type is an empty class type
constant. This patch changes that so that v_d_e_p doesn't need
to check is_really_empty_class.
Co-authored-by: Jason Merrill
PR c++/109876
gcc/cp/ChangeLog:
* decl.cc (cp_finish_decl): Set TREE_CONSTANT when initializing
an object of empty class type.
* pt.cc (value_dependent_expression_p) : Treat a
constexpr-declared non-constant variable as value-dependent.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-template12.C: New test.
* g++.dg/cpp1z/constexpr-template1.C: New test.
* g++.dg/cpp1z/constexpr-template2.C: New test.
(cherry picked from commit b5138df96a93d3b5070c88b8617eabd38cb24ab6)
[Bug analyzer/112975] -Wanalyzer-tainted-allocation-size false positive seen in Linux kernel's drivers/xen/privcmd.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112975 --- Comment #1 from David Malcolm --- Created attachment 56857 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56857=edit Reduced reproducer (needs adding to plugin.exp)
[Bug analyzer/112975] New: -Wanalyzer-tainted-allocation-size false positive seen in Linux kernel's drivers/xen/privcmd.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112975
Bug ID: 112975
Summary: -Wanalyzer-tainted-allocation-size false positive seen
in Linux kernel's drivers/xen/privcmd.c
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
Blocks: 106358
Target Milestone: ---
In file included from drivers/xen/privcmd.c:15:
In function ‘kcalloc’,
inlined from ‘privcmd_ioctl_dm_op’ at drivers/xen/privcmd.c:640:10:
./include/linux/slab.h:645:16: warning: use of attacker-controlled value as
allocation size without upper-bounds checking [CWE-789]
[-Wanalyzer-tainted-allocation-size]
645 | return kmalloc_array(n, size, flags | __GFP_ZERO);
|^~
‘privcmd_ioctl’: events 1-4
|
|drivers/xen/privcmd.c:834:13:
| 834 | static long privcmd_ioctl(struct file *file,
| | ^
| | |
| | (1) entry to ‘privcmd_ioctl’
|..
| 840 | switch (cmd) {
| | ~~
| | |
| | (2) following ‘case 1069061:’ branch...
|..
| 857 | case IOCTL_PRIVCMD_DM_OP:
| |
| | |
| | (3) ...to here
| 858 | ret = privcmd_ioctl_dm_op(file, udata);
| |
| | |
| | (4) calling ‘privcmd_ioctl_dm_op’ from
‘privcmd_ioctl’
|
+--> ‘privcmd_ioctl_dm_op’: events 5-12
|
| 615 | static long privcmd_ioctl_dm_op(struct file *file, void
__user *udata)
| | ^~~
| | |
| | (5) entry to ‘privcmd_ioctl_dm_op’
|..
| 627 | if (copy_from_user(, udata, sizeof(kdata)))
| |~
| ||
| |(6) following ‘false’ branch (when ‘n == 0’)...
|..
| 631 | if (data->domid != DOMID_INVALID && data->domid !=
kdata.dom)
| | ~~
| | |
| | (7) ...to here
|..
| 634 | if (kdata.num == 0)
| |~
| ||
| |(8) following ‘false’ branch...
|..
| 637 | if (kdata.num > privcmd_dm_op_max_num)
| | ~~ ~
| | | |
| | | (10) following ‘false’ branch...
| | (9) ...to here
|..
| 640 | kbufs = kcalloc(kdata.num, sizeof(*kbufs),
GFP_KERNEL);
| | ~ ~
| | | |
| | | (12) inlined call to ‘kcalloc’ from
‘privcmd_ioctl_dm_op’
| | (11) ...to here
|
+--> ‘kcalloc’: event 13
|
|./include/linux/slab.h:645:16:
| 645 | return kmalloc_array(n, size, flags |
__GFP_ZERO);
| |
^~
| ||
| |(13) use of attacker-controlled value
as allocation size without upper-bounds checking
|
...when the value is checked at (10).
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
[Bug 106358] [meta-bug] tracker bug for building the Linux kernel with
-fanalyzer
[Bug target/112599] RISC-V regression testsuite errors with rv64gcv_zvl1024b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112599 Patrick O'Neill changed: What|Removed |Added Attachment #56795|0 |1 is obsolete|| --- Comment #8 from Patrick O'Neill --- Created attachment 56856 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56856=edit rv64gcv_zvl1024b testsuite failures 2023-12-10 Tested with hash fbfe43daec6443978df65530dc5f7f3f8a4e6f9e CI run: https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7158896306 ! New issue found with strided_store_run-2.c testcase - seems to timeout when compiling. Comparison with zvl128b (pr112583): Resolved failures (present on zvl128b but not zvl1024b): XPASS: g++.dg/tree-ssa/pr83518.C -std=gnu++14 scan-tree-dump optimized "return 15;" XPASS: g++.dg/tree-ssa/pr83518.C -std=gnu++17 scan-tree-dump optimized "return 15;" XPASS: g++.dg/tree-ssa/pr83518.C -std=gnu++20 scan-tree-dump optimized "return 15;" XPASS: g++.dg/tree-ssa/pr83518.C -std=gnu++98 scan-tree-dump optimized "return 15;" FAIL: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 72) FAIL: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 77) FAIL: gcc.dg/Wstringop-overflow-47.c pr97027 note (test for warnings, line 68) XPASS: gcc.dg/tree-ssa/pr84512.c scan-tree-dump optimized "return 285;" XPASS: gcc.dg/vect/bb-slp-68.c -flto -ffat-lto-objects scan-tree-dump-not slp2 "from scalars" XPASS: gcc.dg/vect/bb-slp-68.c scan-tree-dump-not slp2 "from scalars" FAIL: gcc.dg/vect/bb-slp-cond-1.c -flto -ffat-lto-objects scan-tree-dump-times vect "loop vectorized" 2 FAIL: gcc.dg/vect/bb-slp-cond-1.c scan-tree-dump-times vect "loop vectorized" 2 FAIL: gcc.dg/vect/bb-slp-pr65935.c -flto -ffat-lto-objects scan-tree-dump-times slp1 "optimized: basic block" 11 FAIL: gcc.dg/vect/bb-slp-pr65935.c scan-tree-dump-times slp1 "optimized: basic block" 11 FAIL: gcc.dg/vect/bb-slp-subgroups-2.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "optimized: basic block" 1 FAIL: gcc.dg/vect/bb-slp-subgroups-2.c scan-tree-dump-times slp2 "optimized: basic block" 1 XPASS: gcc.dg/vect/bb-slp-subgroups-3.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "optimized: basic block" 2 XPASS: gcc.dg/vect/bb-slp-subgroups-3.c scan-tree-dump-times slp2 "optimized: basic block" 2 FAIL: gcc.dg/vect/pr66251.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 2 FAIL: gcc.dg/vect/pr66251.c scan-tree-dump-times vect "vectorized 1 loops" 2 New failures (present on zvl1024b but not zvl128b): FAIL: gfortran.dg/matmul_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/matmul_1.f90 -O3 -g execution test FAIL: gfortran.dg/proc_ptr_comp_12.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/proc_ptr_comp_12.f90 -O3 -g execution test FAIL: gfortran.dg/vect/pr83232.f90 -O scan-tree-dump-times slp1 "vectorizing stmts using SLP" 3 FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.avlprop, -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions comparison FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.reload, -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions comparison FAIL: gcc.dg/no-strict-overflow-6.c scan-tree-dump optimized "return 0" FAIL: gcc.dg/pr30957-1.c execution test FAIL: gcc.dg/pr30957-1.c scan-rtl-dump loop2_unroll "Expanding Accumulator" FAIL: gcc.dg/pr53265.c (test for excess errors) FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI
[Bug target/112598] RISC-V regression testsuite errors with rv64gcv_zvl512b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112598 Patrick O'Neill changed: What|Removed |Added Attachment #56794|0 |1 is obsolete|| --- Comment #19 from Patrick O'Neill --- Created attachment 56855 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56855=edit rv64gcv_zvl512b testsuite failures 2023-12-10 Tested with hash fbfe43daec6443978df65530dc5f7f3f8a4e6f9e CI run: https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7158896306 Comparison with zvl128b (pr112583): Resolved failures (present on zvl128b but not zvl512b): XPASS: gcc.dg/tree-ssa/pr84512.c scan-tree-dump optimized "return 285;" XPASS: gcc.dg/vect/bb-slp-68.c -flto -ffat-lto-objects scan-tree-dump-not slp2 "from scalars" XPASS: gcc.dg/vect/bb-slp-68.c scan-tree-dump-not slp2 "from scalars" FAIL: gcc.dg/vect/bb-slp-cond-1.c -flto -ffat-lto-objects scan-tree-dump-times vect "loop vectorized" 2 FAIL: gcc.dg/vect/bb-slp-cond-1.c scan-tree-dump-times vect "loop vectorized" 2 FAIL: gcc.dg/vect/bb-slp-pr65935.c -flto -ffat-lto-objects scan-tree-dump-times slp1 "optimized: basic block" 11 FAIL: gcc.dg/vect/bb-slp-pr65935.c scan-tree-dump-times slp1 "optimized: basic block" 11 FAIL: gcc.dg/vect/bb-slp-subgroups-2.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "optimized: basic block" 1 FAIL: gcc.dg/vect/bb-slp-subgroups-2.c scan-tree-dump-times slp2 "optimized: basic block" 1 XPASS: gcc.dg/vect/bb-slp-subgroups-3.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "optimized: basic block" 2 XPASS: gcc.dg/vect/bb-slp-subgroups-3.c scan-tree-dump-times slp2 "optimized: basic block" 2 FAIL: gcc.dg/vect/pr66251.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 2 FAIL: gcc.dg/vect/pr66251.c scan-tree-dump-times vect "vectorized 1 loops" 2 New failures (present on zvl512b but not zvl128b): FAIL: gfortran.dg/matmul_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/matmul_1.f90 -O3 -g execution test FAIL: gfortran.dg/proc_ptr_comp_12.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/proc_ptr_comp_12.f90 -O3 -g execution test FAIL: gfortran.dg/vect/pr83232.f90 -O scan-tree-dump-times slp1 "vectorizing stmts using SLP" 3 FAIL: gcc.dg/no-strict-overflow-6.c scan-tree-dump optimized "return 0" FAIL: gcc.dg/pr30957-1.c execution test FAIL: gcc.dg/pr30957-1.c scan-rtl-dump loop2_unroll "Expanding Accumulator" FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI
[Bug analyzer/112974] -Wanalyzer-tainted-array-index false positive seen on Linux kernel drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112974 --- Comment #1 from David Malcolm --- Created attachment 56854 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56854=edit Patch adding reduced reproducer
[Bug analyzer/112974] New: -Wanalyzer-tainted-array-index false positive seen on Linux kernel drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112974 Bug ID: 112974 Summary: -Wanalyzer-tainted-array-index false positive seen on Linux kernel drivers/platform/x86/intel/speed_select_if/isst_tpmi_c ore.c 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 Blocks: 106358 Target Milestone: --- drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c: In function ‘isst_if_get_tpmi_instance_count’: drivers/platform/x86/intel/speed_select_if/isst_tpmi_core.c:1118:47: warning: use of attacker-controlled value as offset without upper-bounds checking [CWE-823] [-Wanalyzer-tainted-offset] 1118 | tpmi_inst.count = isst_common.sst_inst[tpmi_inst.socket_id]->number_of_power_domains; | ^ ‘isst_if_get_tpmi_instance_count’: events 1-5 | | 1112 | if (copy_from_user(_inst, argp, sizeof(tpmi_inst))) | |^ | || | |(1) following ‘false’ branch (when ‘n == 0’)... |.. | 1115 | if (tpmi_inst.socket_id >= topology_max_packages()) | | ~~ ~ | | | | | | | (3) following ‘false’ branch... | | (2) ...to here |.. | 1118 | tpmi_inst.count = isst_common.sst_inst[tpmi_inst.socket_id]->number_of_power_domains; | | ~ ~ | | | | | | (4) ...to here(5) use of attacker-controlled value as offset without upper-bounds checking | Value is sanitized at (3); am about to attach a reduced reproducer. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358 [Bug 106358] [meta-bug] tracker bug for building the Linux kernel with -fanalyzer
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #22 from Andrew Pinski --- (In reply to Sergey Fedorov from comment #21) > Any chance of having it fixed in gcc14? It is too late to be included in GCC 14, GCC is in stage 3 already, that is no new features can be included that was not posted before a specific date. See https://gcc.gnu.org/pipermail/gcc/2023-November/242898.html and https://gcc.gnu.org/develop.html about the timing there.
[Bug c/78352] GCC lacks support for the Apple "blocks" extension to the C family of languages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352 --- Comment #21 from Sergey Fedorov --- (In reply to Iain Sandoe from comment #20) > > I recently brought my patches forward from GCC-5 => GCC-10 (easier to avoid > the .c => .cc file renaming). Since we now face some problems with > sanitiser support without blocks, this is moved up the TODO. Any chance of having it fixed in gcc14?
[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112963 --- Comment #13 from Jakub Jelinek --- I've already started testing the: 2023-12-11 Jakub Jelinek PR libquadmath/112963 * configure.ac (LIBM): Readd AC_CHECK_LIBM-like check without doing AC_CHECK_LIB in it. * configure: Regenerated. * Makefile.in: Regenerated. --- libquadmath/configure.ac.jj 2023-11-02 07:49:22.120795297 +0100 +++ libquadmath/configure.ac2023-12-11 19:03:50.823783215 +0100 @@ -122,6 +122,20 @@ esac AC_SUBST(toolexecdir) AC_SUBST(toolexeclibdir) +# AC_CHECK_LIBM variant which avoids AC_CHECK_LIB which doesn't work +# on bare metal. In the past we've used -lm in Makefile.am unconditionally, +# let's use it there unless target knows it doesn't need that. +LIBM= +case $host in +*-*-beos* | *-*-cegcc* | *-*-cygwin* | *-*-haiku* | *-*-pw32* | *-*-darwin*) + # These system don't have libm, or don't need it + ;; +*) + LIBM=-lm + ;; +esac +AC_SUBST([LIBM]) + AC_CHECK_HEADERS(fenv.h langinfo.h locale.h wchar.h wctype.h limits.h ctype.h printf.h errno.h) LIBQUAD_CHECK_MATH_H_SIGNGAM --- libquadmath/configure.jj2023-11-02 07:49:22.119795311 +0100 +++ libquadmath/configure 2023-12-11 19:04:04.239598274 +0100 @@ -644,6 +644,7 @@ LIBQUAD_USE_SYMVER_GNU_FALSE LIBQUAD_USE_SYMVER_GNU_TRUE LIBQUAD_USE_SYMVER_FALSE LIBQUAD_USE_SYMVER_TRUE +LIBM toolexeclibdir toolexecdir MAINT @@ -10921,7 +10922,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 10924 "configure" +#line 10925 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -11027,7 +11028,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 11030 "configure" +#line 11031 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -12260,6 +12261,20 @@ esac +# AC_CHECK_LIBM variant which avoids AC_CHECK_LIB which doesn't work +# on bare metal. In the past we've used -lm in Makefile.am unconditionally, +# let's use it there unless target knows it doesn't need that. +LIBM= +case $host in +*-*-beos* | *-*-cegcc* | *-*-cygwin* | *-*-haiku* | *-*-pw32* | *-*-darwin*) + # These system don't have libm, or don't need it + ;; +*) + LIBM=-lm + ;; +esac + + for ac_header in fenv.h langinfo.h locale.h wchar.h wctype.h limits.h ctype.h printf.h errno.h do : as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh` --- libquadmath/Makefile.in.jj 2023-11-02 07:49:22.108795464 +0100 +++ libquadmath/Makefile.in 2023-12-11 19:04:57.971857555 +0100 @@ -355,6 +355,7 @@ INSTALL_SCRIPT = @INSTALL_SCRIPT@ INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@ LD = @LD@ LDFLAGS = @LDFLAGS@ +LIBM = @LIBM@ LIBOBJS = @LIBOBJS@ LIBS = @LIBS@ LIBTOOL = @LIBTOOL@ version.
[Bug libquadmath/112963] [14 Regression] Incorrect linking of libquadmath since r14-4863
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112963 --- Comment #12 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #10) > BTW, yet another option would be to just > LIBM= > case $host in > *-*-beos* | *-*-cegcc* | *-*-cygwin* | *-*-haiku* | *-*-pw32* | *-*-darwin*) > # These system don't have libm, or don't need it > ;; > *) > LIBM=-lm > ;; > esac > AC_SUBST([LIBM]) I tested this patch on x86_64-darwin and powerpc64le-linux where it correctly omits the '-lm' from the libquadmath link line on Darwin, but includes it on powerpc64le-linux (where it is also currently omitted in an unpatched build). So, I can also test the patch at comment #2 or we could go with this one.
[Bug c/112972] ambiguity in specification for cast to union types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112972 Stephan Stiller changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Stephan Stiller --- I disagree; the documentation overall is contradictory with respect to whether reading from a different member with the same type is also considered "type punning". Given the example of union datum p, it wouldn't make sense for any compiler to not produce code with the intended effect for something like the following: p.height = 3.4; double d = p.weight; However, the point is that this is not explicitly documented for the case of different members having identical types. For the example from the GCC webpage, if union foo were replaced by union datum, it would be unclear what the "equivalence" would be. (The choice of latitute/longitude/height/weight as the designated member of type double wouldn't matter in practice, but again, this needs to be said explicitly.)
[Bug c/112972] ambiguity in specification for cast to union types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112972 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- >and this should be stated somewhere in the documentation Actually it is documented. https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Optimize-Options.html#Type-punning The practice of reading from a different union member than the one most recently written to (called “type-punning”) is common. Even with -fstrict-aliasing, type-punning is allowed, provided the memory is accessed through the union type.
[Bug target/112973] New: Documentation for __builtin_preserve_access_index is not wrapped in extend.texi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112973
Bug ID: 112973
Summary: Documentation for __builtin_preserve_access_index is
not wrapped in extend.texi
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: documentation, internal-improvement
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: bpf
This is not wrapped to around 80 characters unlike the rest of the document:
```
@defbuiltin{{void *} __builtin_preserve_access_index (@var{expr})}
BPF Compile Once-Run Everywhere (CO-RE) support. Instruct GCC to generate CO-RE
relocation records for any accesses to aggregate data structures (struct,
union, array types) in @var{expr}. This builtin is otherwise transparent, the
return value is whatever @var{expr} evaluates to. It is also overloaded:
@var{expr} may be of any type (not necessarily a pointer), the return type is
the same. Has no effect if @code{-mco-re} is not in effect (either specified or
implied).
@enddefbuiltin
```
[Bug web/112972] New: ambiguity in specification for cast to union types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112972
Bug ID: 112972
Summary: ambiguity in specification for cast to union types
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: stephan.stiller at outlook dot com
Target Milestone: ---
On this page of the GCC documentation
https://gcc.gnu.org/onlinedocs/gcc/Cast-to-Union.html
the statement that
the following assignments
z = (union foo) x;
z = (union foo) y;
are shorthand equivalents of these
z = (union foo) { .i = x };
z = (union foo) { .d = y };
doesn't give the full picture.
While the statement is accurate about
union foo
x
y
z
as defined just above, unions with multiple members of the same type would lead
to a potential ambiguity. For example, for Richard Stallman's example of a
union
union datum {
double latitude;
double longitude;
double height;
double weight;
int continent;
}
(taken from: "GNU C Language Introduction and Reference Manual", Edition 0.0,
section 15.14 (Unions)), casting to this union would be indeterminate with
respect to which of the 4 members of type double is being assigned to.
That is, either (1) first writing to and then reading from identically typed
but differently named members is *not* undefined behavior (and this should be
stated somewhere in the documentation) or (2) a simple "equivalence" between
assignments of the form
p = (union foo) q;
and assignments of the form
p = (union foo) { .m = q };
can't exist (due to the ambiguity of which m applies in the case of there being
multiple members of type typeof(q)).
[Bug tree-optimization/37239] peeling last iteration of a <= loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37239
--- Comment #10 from Andrew Pinski ---
lsplit reports:
Found potential split point: if (maxIdx_171 <= qty_7)
{ i_6 * 2 + I*-2 } le_expr qty_7
But nothing else ...
[Bug c/112488] [14 Regression] ICE in make_ssa_name_fn with VLA inside type and inlining since r14-1142
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112488 --- Comment #11 from GCC Commits --- The master branch has been updated by Martin Uecker : https://gcc.gnu.org/g:6cf9654c3b06c076502a39a3bfdd6e43b73b commit r14-6436-g6cf9654c3b06c076502a39a3bfdd6e43b73b Author: Martin Uecker Date: Wed Nov 15 09:22:55 2023 +0100 Fix regression causing ICE for structs with VLAs [PR 112488] A previous patch that fixed several ICEs related to size expressions of VM types (PR c/70418, ...) caused a regression for structs where a DECL_EXPR is not generated anymore although reqired. We now call add_decl_expr introduced by the previous patch from finish_struct. The function is revised with a new argument to not set the TYPE_NAME for the type to the DECL_EXPR in this specific case. PR c/112488 gcc/c * c-decl.cc (add_decl_expr): Revise. (finish_struct): Create DECL_EXPR. * c-parser.cc (c_parser_struct_or_union_specifier): Call finish_struct with expression for VLA sizes. * c-tree.h (finish_struct): Add argument. gcc/testsuite * gcc.dg/pr112488-1.c: New test. * gcc.dg/pr112488-2.c: New test. * gcc.dg/pr112898.c: New test. * gcc.misc-tests/gcov-pr85350.c: Adapt.
[Bug target/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971 --- Comment #1 from JuzheZhong --- I think it is the same issue that I asked Robin to take care of. Robin, could you confirm whether they are same issue (infinite loop due to SUBREG)?
[Bug preprocessor/110558] __has_include argument expansion results in unexpected filename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110558
Lewis Hyatt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2023-12-11
CC||lhyatt at gcc dot gnu.org
--- Comment #4 from Lewis Hyatt ---
__has_include was added I think in GCC 5, and re-implemented in GCC 10, but
this issue with padding in the macro expansion was never handled correctly it
seems. I am testing the below which will fix it, will submit it soon with a
testcase. Not sure if it would be eligible for backport or not, but it would
apply cleanly to all active branches also.
diff --git a/libcpp/macro.cc b/libcpp/macro.cc
index 6f24a9d6f3a..15140c60023 100644
--- a/libcpp/macro.cc
+++ b/libcpp/macro.cc
@@ -398,6 +398,8 @@ builtin_has_include (cpp_reader *pfile, cpp_hashnode *op,
bool has_next)
NODE_NAME (op));
pfile->state.angled_headers = true;
+ const auto sav_padding = pfile->state.directive_wants_padding;
+ pfile->state.directive_wants_padding = true;
const cpp_token *token = cpp_get_token_no_padding (pfile);
bool paren = token->type == CPP_OPEN_PAREN;
if (paren)
@@ -406,6 +408,7 @@ builtin_has_include (cpp_reader *pfile, cpp_hashnode *op,
bool has_next)
cpp_error (pfile, CPP_DL_ERROR,
"missing '(' before \"%s\" operand", NODE_NAME (op));
pfile->state.angled_headers = false;
+ pfile->state.directive_wants_padding = sav_padding;
bool bracket = token->type != CPP_STRING;
char *fname = NULL;
[Bug target/112597] RISC-V regression testsuite errors with rv64gcv_zvl256b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112597 Patrick O'Neill changed: What|Removed |Added Attachment #56793|0 |1 is obsolete|| --- Comment #12 from Patrick O'Neill --- Created attachment 56853 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56853=edit rv64gcv_zvl256b testsuite failures 2023-12-10 Tested with hash fbfe43daec6443978df65530dc5f7f3f8a4e6f9e CI run: https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7158896306 Comparison with zvl128b (pr112583): Resolved failures (present on zvl128b but not zvl256b): XPASS: g++.dg/tree-ssa/pr83518.C -std=gnu++14 scan-tree-dump optimized "return 15;" XPASS: g++.dg/tree-ssa/pr83518.C -std=gnu++17 scan-tree-dump optimized "return 15;" XPASS: g++.dg/tree-ssa/pr83518.C -std=gnu++20 scan-tree-dump optimized "return 15;" XPASS: g++.dg/tree-ssa/pr83518.C -std=gnu++98 scan-tree-dump optimized "return 15;" FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.avlprop, -O3 -g comparison FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.reload, -O3 -g comparison FAIL: gcc.dg/vect/bb-slp-cond-1.c -flto -ffat-lto-objects scan-tree-dump-times vect "loop vectorized" 2 FAIL: gcc.dg/vect/bb-slp-cond-1.c scan-tree-dump-times vect "loop vectorized" 2 FAIL: gcc.dg/vect/bb-slp-pr65935.c -flto -ffat-lto-objects scan-tree-dump-times slp1 "optimized: basic block" 11 FAIL: gcc.dg/vect/bb-slp-pr65935.c scan-tree-dump-times slp1 "optimized: basic block" 11 FAIL: gcc.dg/vect/bb-slp-subgroups-2.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "optimized: basic block" 1 FAIL: gcc.dg/vect/bb-slp-subgroups-2.c scan-tree-dump-times slp2 "optimized: basic block" 1 XPASS: gcc.dg/vect/bb-slp-subgroups-3.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "optimized: basic block" 2 XPASS: gcc.dg/vect/bb-slp-subgroups-3.c scan-tree-dump-times slp2 "optimized: basic block" 2 FAIL: gcc.dg/vect/pr66251.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 2 FAIL: gcc.dg/vect/pr66251.c scan-tree-dump-times vect "vectorized 1 loops" 2 New failures (present on zvl256b but not zvl128b): FAIL: gfortran.dg/matmul_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/matmul_1.f90 -O3 -g execution test FAIL: gfortran.dg/vect/pr83232.f90 -O scan-tree-dump-times slp1 "vectorizing stmts using SLP" 3 FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.avlprop, -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions comparison FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.reload, -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions comparison FAIL: gcc.dg/pr30957-1.c execution test FAIL: gcc.dg/pr30957-1.c scan-rtl-dump loop2_unroll "Expanding Accumulator" FAIL: gcc.dg/tree-ssa/ivopts-lt-2.c scan-tree-dump-times ivopts "PHI
[Bug c++/60512] would be useful if gcc implemented __has_feature similarly to clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #24 from Eric Gallager --- (In reply to Alex Coplan from comment #23) > Implemented for GCC 14. Thanks! Could you add a note to gcc-14/changes.html in gcc-wwwdocs so that people can be aware of it?
[Bug target/112971] New: [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971
Bug ID: 112971
Summary: [14] RISC-V rv64gcv_zvl256b vector -O3: internal
compiler error: Segmentation fault signal terminated
program cc1
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick at rivosinc dot com
Target Milestone: ---
> /scratch/tc-testing/tc-dec-11-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64gcv_zvl256b -mabi=lp64d -O3 red.c -S
riscv64-unknown-linux-gnu-gcc: internal compiler error: Segmentation fault
signal terminated program cc1
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <https://gcc.gnu.org/bugs/> for instructions.
Testcase:
int a;
short b[9];
char c, d;
void e() {
d = 0;
for (;; d++) {
if (b[d])
break;
a = 8;
for (; a >= 0; a--) {
char *f =
*f &= d == (a & d);
}
}
}
-freport bug doesn't seem to be working, so here's the GCC -v output:
> /scratch/tc-testing/tc-dec-11-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> -v
Using built-in specs.
COLLECT_GCC=/scratch/tc-testing/tc-dec-11-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/scratch/tc-testing/tc-dec-11-trunk/build-rv64gcv/libexec/gcc/riscv64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with:
/scratch/tc-testing/tc-dec-11-trunk/build-rv64gcv/../gcc/configure
--target=riscv64-unknown-linux-gnu
--prefix=/scratch/tc-testing/tc-dec-11-trunk/build-rv64gcv
--with-sysroot=/scratch/tc-testing/tc-dec-11-trunk/build-rv64gcv/sysroot
--with-pkgversion=geea25179d8d --with-system-zlib --enable-shared --enable-tls
--enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp
--disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap
--src=../../gcc --enable-multilib --with-abi=lp64d --with-arch=rv64imafdc
--with-tune=rocket --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2
-mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2-mcmodel=medlow'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231211 (experimental) (geea25179d8d)
The issue goes away if I use --param=riscv-autovec-preference=fixed-vlmax.
Godbolt: https://godbolt.org/z/4ovbT6d77
[Bug analyzer/112955] Valgrind error in ana::feasibility_state::maybe_update_for_edge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112955 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above patch.
[Bug analyzer/112955] Valgrind error in ana::feasibility_state::maybe_update_for_edge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112955 --- Comment #2 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:6008b80b25d71827fb26ce49f49aae02b645bb12 commit r14-6434-g6008b80b25d71827fb26ce49f49aae02b645bb12 Author: David Malcolm Date: Mon Dec 11 16:18:56 2023 -0500 analyzer: fix uninitialized bitmap [PR112955] In r14-5566-g841008d3966c0f I added a new ctor for feasibility_state, but failed to call bitmap_clear on m_snodes_visited. Fixed thusly. gcc/analyzer/ChangeLog: PR analyzer/112955 * engine.cc (feasibility_state::feasibility_state): Initialize m_snodes_visited. Signed-off-by: David Malcolm
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #15 from Steve Kargl --- On Mon, Dec 11, 2023 at 07:53:01PM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 > > --- Comment #13 from Jerry DeLisle --- > (In reply to anlauf from comment #12) > > > Jerry or myself can do the commit later. > > > > Looking at my addition again, I think that this change to invoke.texi: > > > > "... These functions are now GNU extensions." > > > > should correctly read: "These functions are now either part of Fortran 2023 > > or GNU extensions." > > > > Note to myself to fix this. > > Hi Harald and Steve, please let me commit this for the practice. I will fix > that last comment you made and see how this goes. > Jerry, are you starting with the patch submitted by Harald that fixes the doc issue. It seems 'gmake pdf', which is what I use to check doc changes, works while 'gmake info' fails. I assume that this is how Harald found the issue. Thanks for taking up the commit.
[Bug target/112970] New: LoongArch: Suboptimal code when the address and the value of an array element are both used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112970
Bug ID: 112970
Summary: LoongArch: Suboptimal code when the address and the
value of an array element are both used
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at gcc dot gnu.org
Target Milestone: ---
int d[2];
struct r { int *p, v; };
struct r test() { return (struct r){[1], d[1]}; }
is compiled to:
la.local$r12,.LANCHOR0
ld.wu $r5,$r12,4
la.local$r4,.LANCHOR0+4
But it's better to be:
la.local$r4,.LANCHOR0+4
ld.wu $r5,$r4,0
[Bug fortran/111291] ASAN error: heap-use-after-free gcc/fortran/parse.cc:359 in decode_statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111291 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- *** Bug 112967 has been marked as a duplicate of this bug. ***
[Bug fortran/112967] Valgrind error on gfortran.dg/unexpected_interface.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112967 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from anlauf at gcc dot gnu.org --- Same traceback as by the ASAN instrumented compiler, see pr111291. Marking as duplicate, assuming this is fine with you. *** This bug has been marked as a duplicate of bug 111291 ***
[Bug fortran/112964] ICE for recursive subroutine with assumed rank class(*) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112964 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed||2023-12-11 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. All versions of gfortran fail.
[Bug target/101929] [12/13/14 Regression] r12-7319 regress x264_r by 4% on CLX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101929 Andrew Pinski changed: What|Removed |Added Depends on||98138 --- Comment #14 from Andrew Pinski --- PR 98138 is exactly the same loop ... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138 [Bug 98138] BB vect fail to SLP one case
[Bug analyzer/112969] New: -Wanalyzer-exposure-through-uninit-copy false positive seen on Linux kernel's drivers/net/ethernet/intel/ice/ice_ptp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112969
Bug ID: 112969
Summary: -Wanalyzer-exposure-through-uninit-copy false positive
seen on Linux kernel's
drivers/net/ethernet/intel/ice/ice_ptp.c
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
Blocks: 106358
Target Milestone: ---
Created attachment 56852
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56852=edit
Patch adding reproducer
False positive here:
src/gcc/testsuite/gcc.dg/plugin/infoleak-drivers-net-ethernet-intel-ice-ice_ptp.c:46:7:
warning: potential exposure of sensitive information by copying uninitialized
data from stack across trust boundary [CWE-200]
[-Wanalyzer-exposure-through-uninit-copy]
46 | if (copy_to_user(ifr->ifr_ifru.ifru_data, , sizeof(config)))
| ^~
‘ice_ptp_set_ts_config’: events 1-5
|
| 39 | struct hwtstamp_config config;
| | ^~
| | |
| | (1) region created on stack here
| | (2) capacity: 12 bytes
| 40 | int err;
| 41 | if (copy_from_user(, ifr->ifr_ifru.ifru_data,
sizeof(config)))
| | ~
| | |
| | (3) following ‘false’ branch...
| 42 | return -14;
| 43 | pf->ptp.tstamp_config.tx_type = 0;
| | ~
| | |
| | (4) ...to here
|..
| 46 | if (copy_to_user(ifr->ifr_ifru.ifru_data, ,
sizeof(config)))
| |
~~
| | |
| | (5) uninitialized data copied from stack here
|
src/gcc/testsuite/gcc.dg/plugin/infoleak-drivers-net-ethernet-intel-ice-ice_ptp.c:46:7:
note: 4 bytes are uninitialized
46 | if (copy_to_user(ifr->ifr_ifru.ifru_data, , sizeof(config)))
| ^~
src/gcc/testsuite/gcc.dg/plugin/infoleak-drivers-net-ethernet-intel-ice-ice_ptp.c:21:7:
note: field ‘flags’ is uninitialized (4 bytes)
21 | int flags;
| ^
src/gcc/testsuite/gcc.dg/plugin/infoleak-drivers-net-ethernet-intel-ice-ice_ptp.c:39:26:
note: suggest forcing zero-initialization by providing a ‘{0}’ initializer
39 | struct hwtstamp_config config;
| ^~
| = {0}
Looks like it doesn't notice that the copy here:
config = pf->ptp.tstamp_config;
initializes config.flag
Also, config was fully initialized at the copy_from_user.
Reduced from examples seen on drivers/net/ethernet/intel/ice/ice_ptp.c
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106358
[Bug 106358] [meta-bug] tracker bug for building the Linux kernel with
-fanalyzer
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #14 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #12) > Note to myself to fix this. Comparing the documentation of the degree trigonometric intrinsics with F2023, I see that these need only support real arguments. Currently intrinsic.texi claims that these accept also complex arguments, but these are rejected, as intrinsic.cc invokes gfc_check_fn_r/gfc_check_fn_d for argument checking. This was likely an oversight we can fix in passing. (COTAN accepts real and complex and is a GNU extension, thus it is fine.)
[Bug target/112583] RISC-V regression testsuite errors with rv64gcv_zvl128b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112583 Patrick O'Neill changed: What|Removed |Added Attachment #56792|0 |1 is obsolete|| --- Comment #15 from Patrick O'Neill --- Created attachment 56851 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56851=edit rv64gcv_zvl128b testsuite failures 2023-12-10 Tested with hash fbfe43daec6443978df65530dc5f7f3f8a4e6f9e CI run: https://github.com/patrick-rivos/gcc-postcommit-ci/actions/runs/7158896306 Resolved failures (improved from 806789e6daa39ab0503d91c71b3faeb5d5cdd317) FAIL: gfortran.dg/vect/pr83232.f90 -O scan-tree-dump-times slp1 "vectorizing stmts using SLP" 3 XPASS: gcc.dg/tree-ssa/ssa-fre-3.c scan-tree-dump fre1 "Replaced \\(int\\) aa_.*with a_" FAIL: gcc.target/riscv/rvv/autovec/pr112552.c -O3 -ftree-vectorize (test for excess errors) New failures (regression from 806789e6daa39ab0503d91c71b3faeb5d5cdd317) FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.avlprop, -O3 -g comparison FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.reload, -O3 -g comparison FAIL: gcc.dg/debug/btf/btf-datasec-3.c scan-assembler-times bts_type 3 FAIL: gcc.dg/debug/btf/btf-datasec-3.c scan-assembler-times bts_type: \\(BTF_KIND_VAR 'test_bss2'\\) 1 FAIL: gcc.dg/debug/btf/btf-datasec-3.c scan-assembler-times bts_type: \\(BTF_KIND_VAR 'test_data2'\\) 1 FAIL: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 72) FAIL: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 77) FAIL: gcc.dg/Wstringop-overflow-47.c pr97027 note (test for warnings, line 68) XPASS: gcc.dg/vect/bb-slp-68.c -flto -ffat-lto-objects scan-tree-dump-not slp2 "from scalars" XPASS: gcc.dg/vect/bb-slp-68.c scan-tree-dump-not slp2 "from scalars" FAIL: gcc.dg/vect/bb-slp-cond-1.c -flto -ffat-lto-objects scan-tree-dump-times vect "loop vectorized" 2 FAIL: gcc.dg/vect/bb-slp-cond-1.c scan-tree-dump-times vect "loop vectorized" 2 FAIL: gcc.dg/vect/bb-slp-pr65935.c -flto -ffat-lto-objects scan-tree-dump-times slp1 "optimized: basic block" 11 FAIL: gcc.dg/vect/bb-slp-pr65935.c scan-tree-dump-times slp1 "optimized: basic block" 11 FAIL: gcc.dg/vect/bb-slp-subgroups-2.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "optimized: basic block" 1 FAIL: gcc.dg/vect/bb-slp-subgroups-2.c scan-tree-dump-times slp2 "optimized: basic block" 1 XPASS: gcc.dg/vect/bb-slp-subgroups-3.c -flto -ffat-lto-objects scan-tree-dump-times slp2 "optimized: basic block" 2 XPASS: gcc.dg/vect/bb-slp-subgroups-3.c scan-tree-dump-times slp2 "optimized: basic block" 2 FAIL: gcc.dg/vect/pr66251.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 2 FAIL: gcc.dg/vect/pr66251.c scan-tree-dump-times vect "vectorized 1 loops" 2 FAIL: gcc.dg/vect/slp-reduc-sad-2.c -flto -ffat-lto-objects scan-tree-dump-not vect "access with gaps requires scalar epilogue loop" FAIL: gcc.dg/vect/slp-reduc-sad-2.c scan-tree-dump-not vect "access with gaps requires scalar epilogue loop" FAIL: gcc.target/riscv/rvv/autovec/pr111751.c -O3 -ftree-vectorize scan-assembler-not vset FAIL: gcc.target/riscv/rvv/autovec/pr111751.c -O3 -ftree-vectorize scan-assembler-times li\\s+[a-x0-9]+,0\\s+ret 2 FAIL: gcc.target/riscv/rvv/base/cpymem-1.c check-function-bodies f3 FAIL: gcc.target/riscv/rvv/base/cpymem-2.c check-function-bodies f2 FAIL: gcc.target/riscv/rvv/base/cpymem-2.c check-function-bodies f3 None of these new failures are ICEs, execution, or excess errors. FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.avlprop, -O3 -g comparison FAIL: gcc.c-torture/unsorted/dump-noaddr.c.*r.reload, -O3 -g comparison These are flaky failures that Edwin is looking at/bisecting now.
[Bug middle-end/112822] [14 regression] ICE: invalid RHS for gimple memory store after r14-5831-gaae723d360ca26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112822 --- Comment #8 from Peter Bergner --- (In reply to Peter Bergner from comment #7) > This fixes the ICE on the large original test case and the smaller test > cases. I'll bootstrap and regtest it and report back on the results. I did a normal bootstrap and regtest on powerpc64le-linux and a --with-cpu=power10 powerpc64le-linux bootstrap and regtest and both were clean with no regressions.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #13 from Jerry DeLisle --- (In reply to anlauf from comment #12) > Jerry or myself can do the commit later. > > Looking at my addition again, I think that this change to invoke.texi: > > "... These functions are now GNU extensions." > > should correctly read: "These functions are now either part of Fortran 2023 > or GNU extensions." > > Note to myself to fix this. Hi Harald and Steve, please let me commit this for the practice. I will fix that last comment you made and see how this goes.
[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929 --- Comment #17 from Patrick O'Neill --- I also tried making m an array and printing every element to try to detect the overwriting that way. Once m gets too large (~10 elements) the issue disappears.
[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929
--- Comment #16 from Patrick O'Neill ---
This version with printf reproduces the problem on both the old and new
versions of QEMU:
int printf(char *, ...);
int a, l, i, p, q, t, n, o;
int *volatile c;
static int j;
static struct pack_1_struct d;
long e;
char m = 5;
short s;
#pragma pack(1)
struct pack_1_struct {
long c;
int d;
int e;
int f;
int g;
int h;
int i;
} h, r = {1}, *f = , *volatile g;
void add_em_up(int count, ...) {
__builtin_va_list ap;
__builtin_va_start(ap, count);
__builtin_va_end(ap);
}
int main() {
int u;
j = 0;
for (; j < 9; ++j) {
u = ++t ? a : 0;
if (u) {
int *v =
*v = g || e;
*c = 0;
*f = h;
}
s = l && c;
o = i;
d.f || (p = 0);
q |= n;
}
r = *f;
add_em_up(1, 1);
printf("%d\n", m);
}
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #12 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #11) > On Sun, Dec 10, 2023 at 09:45:33PM +, anlauf at gcc dot gnu.org wrote: > > The flag -fdec-math now seems fully dysfunctional, i.e. it does nothing. > > I adjusted the documentation (intrinsic.texi, invoke.texi) declaring it > > obsolete. > > In looking (briefly) at -fdec-math, I'm not sure it ever had > an effect. I left -fdec-math in options.cc for backwards > compatibilities in Makefiles as it should be a no-opt. I think it is fine to leave the switch in options.cc. Just updating the documentation should suffice, no bothering of users. Apparently Fritz implemented -fdec-math in r7-3677-g8e8c2744faa0cf, and this part of code was rewritten later. > > Can you have a look? If you think everything is fine, please submit to the > > ML so that others have a chance to have a look. Or should I do it? > > I'll give your updated patch a scan early next week. I can submit > the patch to both fortran@ and gcc-patches@. AS you know, I won't > be committing it as I am too git incompetent to do so. Jerry or myself can do the commit later. Looking at my addition again, I think that this change to invoke.texi: "... These functions are now GNU extensions." should correctly read: "These functions are now either part of Fortran 2023 or GNU extensions." Note to myself to fix this.
[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929 --- Comment #15 from Robin Dapp --- I think we need to make sure that we're not writing out of bounds. In that case anything might happen and if we just don't happen to overwrite this variable we might hit another one but the test can still pass "by accident". If my analysis is correct (it was just done very quickly) the vl should be 32 at that point and we should not write past that size. We could have printf output a larger chunk of memory. Maybe this way we could see whether something was clobbered even with the newer qemu.
[Bug c++/112968] Valgrind error on libstdc++-v3/testsuite/18_support/comparisons/object/93479.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112968 --- Comment #2 from Jakub Jelinek --- The above listed failures are all FAILs in libstdc++, except for a couple of compilation timed out ones (caused by valgrind being too slow and the box being busy). So yes, it is just -std=c++26.
[Bug c++/112968] Valgrind error on libstdc++-v3/testsuite/18_support/comparisons/object/93479.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112968 --- Comment #1 from Andrew Pinski --- Is the failure only with -std=gnu++26 ?
[Bug target/112778] ICE in ppc64-linux-gnu crosscompiler in store_by_pieces since r14-5946-g1ff6d9f7428b06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112778 Alexandre Oliva changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Alexandre Oliva --- Fixed
[Bug middle-end/112784] ICE in smallest_mode_for_size, at stor-layout.cc:356 | -finline-stringops -mavx512cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112784 Alexandre Oliva changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Alexandre Oliva --- Fixed
[Bug target/112804] ICE in aarch64 crosscompiler in plus_constant, at explow.cc:102 with -mabi=ilp32 and -finline-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112804 --- Comment #4 from Alexandre Oliva --- Fixed. Thanks for the notes and testing, Andrew, here and in the mailing list.
[Bug c++/112968] New: Valgrind error on libstdc++-v3/testsuite/18_support/comparisons/object/93479.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112968 Bug ID: 112968 Summary: Valgrind error on libstdc++-v3/testsuite/18_support/comparisons/object/9 3479.cc Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- With --enable-checking=release,valgrind --disable-bootstrap --enable-valgrind-annotations build I'm seeing: /home/jakub/src/gcc/obj88/./gcc/xg++ -shared-libgcc -B/home/jakub/src/gcc/obj88/./gcc -nostdinc++ -L/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/libstdc++-v3/sr c -L/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-pc-linux-gnu /bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -B/home/jakub/src/gcc/obj88/x86_64-pc- linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -fcf-protection -mshstk -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I /home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/jakub/src/gcc/libs tdc++-v3/libsupc++ -I/home/jakub/src/gcc/libstdc++-v3/include/backward -I/home/jakub/src/gcc/libstdc++-v3/testsuite/util /home/jakub/src/gcc/libstdc++-v3/testsuite/18_support/compari sons/object/93479.cc -std=gnu++26 -include bits/stdc++.h -fdiagnostics-plain-output -S -o 93479.s ... ==2009913== Conditional jump or move depends on uninitialised value(s) ==2009913==at 0x914C59: gt_ggc_mx_lang_tree_node(void*) (gt-cp-tree.h:107) ==2009913==by 0x8AB7A5: gt_ggc_mx_tinst_level(void*) (gt-cp-pt.h:32) ==2009913==by 0xB89B25: ggc_mark_root_tab(ggc_root_tab const*) (ggc-common.cc:75) ==2009913==by 0xB89DF4: ggc_mark_roots() (ggc-common.cc:104) ==2009913==by 0x9D6311: ggc_collect(ggc_collect) (ggc-page.cc:2227) ==2009913==by 0xDB70F6: execute_one_pass(opt_pass*) (passes.cc:2738) ==2009913==by 0xDB721F: execute_pass_list_1(opt_pass*) (passes.cc:2755) ==2009913==by 0xDB7258: execute_pass_list(function*, opt_pass*) (passes.cc:2766) ==2009913==by 0xA55525: cgraph_node::analyze() (cgraphunit.cc:695) ==2009913==by 0xA57CC7: analyze_functions(bool) (cgraphunit.cc:1248) ==2009913==by 0xA5890D: symbol_table::finalize_compilation_unit() (cgraphunit.cc:2555) ==2009913==by 0xEB02A1: compile_file() (toplev.cc:473) ==2009913== ==2009913== Conditional jump or move depends on uninitialised value(s) ==2009913==at 0x914C63: gt_ggc_mx_lang_tree_node(void*) (gt-cp-tree.h:109) ==2009913==by 0x8AB7A5: gt_ggc_mx_tinst_level(void*) (gt-cp-pt.h:32) ==2009913==by 0xB89B25: ggc_mark_root_tab(ggc_root_tab const*) (ggc-common.cc:75) ==2009913==by 0xB89DF4: ggc_mark_roots() (ggc-common.cc:104) ==2009913==by 0x9D6311: ggc_collect(ggc_collect) (ggc-page.cc:2227) ==2009913==by 0xDB70F6: execute_one_pass(opt_pass*) (passes.cc:2738) ==2009913==by 0xDB721F: execute_pass_list_1(opt_pass*) (passes.cc:2755) ==2009913==by 0xDB7258: execute_pass_list(function*, opt_pass*) (passes.cc:2766) ==2009913==by 0xA55525: cgraph_node::analyze() (cgraphunit.cc:695) ==2009913==by 0xA57CC7: analyze_functions(bool) (cgraphunit.cc:1248) ==2009913==by 0xA5890D: symbol_table::finalize_compilation_unit() (cgraphunit.cc:2555) ==2009913==by 0xEB02A1: compile_file() (toplev.cc:473) ... +FAIL: 18_support/comparisons/object/93479.cc -std=gnu++26 (test for excess errors) +FAIL: 23_containers/span/101411.cc -std=gnu++26 (test for excess errors) +FAIL: 24_iterators/range_access/range_access_cpp20_neg.cc -std=gnu++26 (test for errors, line ) +FAIL: 24_iterators/range_access/range_access_cpp20_neg.cc -std=gnu++26 (test for errors, line 46) +FAIL: 24_iterators/range_access/range_access_cpp20_neg.cc -std=gnu++26 (test for excess errors) +FAIL: 26_numerics/numbers/nonfloat_neg.cc -std=gnu++26 (test for excess errors) +FAIL: std/ranges/adaptors/100577.cc -std=gnu++26 (test for excess errors) +FAIL: std/ranges/adaptors/lazy_split_neg.cc -std=gnu++26 (test for excess errors) +FAIL: std/ranges/adaptors/lwg3325_neg.cc -std=gnu++26 (test for excess errors) +FAIL: std/ranges/subrange/lwg3282_neg.cc -std=gnu++26 (test for excess errors) trigger same or similar diagnostics.
[Bug fortran/112967] New: Valgrind error on gfortran.dg/unexpected_interface.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112967 Bug ID: 112967 Summary: Valgrind error on gfortran.dg/unexpected_interface.f90 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- With --enable-checking=release,valgrind --disable-bootstrap --enable-valgrind-annotations build I'm seeing: /home/jakub/src/gcc/obj88/gcc/testsuite/gfortran14/../../gfortran -B/home/jakub/src/gcc/obj88/gcc/testsuite/gfortran14/../../ -B/home/jakub/src/gcc/obj88/x86_64-pc -linux-gnu/./libgfortran/ /home/jakub/src/gcc/gcc/testsuite/gfortran.dg/unexpected_interface.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output-O -pedantic-errors -B /home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/./libatomic/ -B/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/./libatomic/.libs -S -o unexpected_interface.s(timeout = 300) spawn -ignore SIGHUP /home/jakub/src/gcc/obj88/gcc/testsuite/gfortran14/../../gfortran -B/home/jakub/src/gcc/obj88/gcc/testsuite/gfortran14/../../ -B/home/jakub/src/gcc/obj88/x86_64- pc-linux-gnu/./libgfortran/ /home/jakub/src/gcc/gcc/testsuite/gfortran.dg/unexpected_interface.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output -O -pedantic-errors -B/home/j akub/src/gcc/obj88/x86_64-pc-linux-gnu/./libatomic/ -B/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/./libatomic/.libs -S -o unexpected_interface.s /home/jakub/src/gcc/gcc/testsuite/gfortran.dg/unexpected_interface.f90:7:74: Error: Unexpected INTERFACE statement in INTERFACE block at (1) ==3209268== Invalid read of size 8 ==3209268==at 0x7C0ADF: decode_statement() (parse.cc:359) ==3209268==by 0x7C981C: next_free (parse.cc:1597) ==3209268==by 0x7C981C: next_statement() (parse.cc:1829) ==3209268==by 0x7CB70D: parse_interface (parse.cc:3996) ==3209268==by 0x7CB70D: parse_spec(gfc_statement) (parse.cc:4352) ==3209268==by 0x7CE92C: parse_progunit(gfc_statement) (parse.cc:6586) ==3209268==by 0x7CFD56: gfc_parse_file() (parse.cc:7172) ==3209268==by 0x82924F: gfc_be_parse_file() (f95-lang.cc:239) ==3209268==by 0xDA8B2D: compile_file() (toplev.cc:446) ==3209268==by 0x71D233: do_compile (toplev.cc:2150) ==3209268==by 0x71D233: toplev::main(int, char**) (toplev.cc:2306) ==3209268==by 0x71E9FA: main (main.cc:39) ==3209268== Address 0x50f5b78 is 120 bytes inside a block of size 336 free'd ==3209268==at 0x48480E4: free (vg_replace_malloc.c:872) ==3209268==by 0x8128C0: gfc_free_symbol(gfc_symbol*&) (symbol.cc:3103) ==3209268==by 0x812965: gfc_release_symbol(gfc_symbol*&) (symbol.cc:3132) ==3209268==by 0x812A4E: delete_symbol_from_ns(gfc_symbol*, gfc_namespace*) (symbol.cc:3673) ==3209268==by 0x812BD7: gfc_restore_last_undo_checkpoint() (symbol.cc:3731) ==3209268==by 0x7BFB01: reject_statement() (parse.cc:3108) ==3209268==by 0x7CBCEA: parse_interface (parse.cc:4041) ==3209268==by 0x7CBCEA: parse_spec(gfc_statement) (parse.cc:4352) ==3209268==by 0x7CE92C: parse_progunit(gfc_statement) (parse.cc:6586) ==3209268==by 0x7CFD56: gfc_parse_file() (parse.cc:7172) ==3209268==by 0x82924F: gfc_be_parse_file() (f95-lang.cc:239) ==3209268==by 0xDA8B2D: compile_file() (toplev.cc:446) ==3209268==by 0x71D233: do_compile (toplev.cc:2150) ==3209268==by 0x71D233: toplev::main(int, char**) (toplev.cc:2306) ==3209268== Block was alloc'd at ==3209268==at 0x484A464: calloc (vg_replace_malloc.c:1328) ==3209268==by 0x1EC8A14: xcalloc (xmalloc.c:164) ==3209268==by 0x81171E: gfc_new_symbol (symbol.cc:3144) ==3209268==by 0x81171E: gfc_get_sym_tree(char const*, gfc_namespace*, gfc_symtree**, bool) (symbol.cc:3384) ==3209268==by 0x811A73: gfc_get_symbol(char const*, gfc_namespace*, gfc_symbol**) (symbol.cc:3437) ==3209268==by 0x768BB5: gfc_match_interface() (interface.cc:292) ==3209268==by 0x7BFB71: match_word(char const*, match (*)(), locus*) (parse.cc:75) ==3209268==by 0x7C2695: decode_statement() (parse.cc:566) ==3209268==by 0x7C981C: next_free (parse.cc:1597) ==3209268==by 0x7C981C: next_statement() (parse.cc:1829) ==3209268==by 0x7CB70D: parse_interface (parse.cc:3996) ==3209268==by 0x7CB70D: parse_spec(gfc_statement) (parse.cc:4352) ==3209268==by 0x7CE92C: parse_progunit(gfc_statement) (parse.cc:6586) ==3209268==by 0x7CFD56: gfc_parse_file() (parse.cc:7172) ==3209268==by 0x82924F: gfc_be_parse_file() (f95-lang.cc:239) ==3209268==
[Bug fortran/112966] New: Valgrind errors on gfortran.dg/finalize_*.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112966 Bug ID: 112966 Summary: Valgrind errors on gfortran.dg/finalize_*.f90 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- With --enable-checking=release,valgrind --disable-bootstrap --enable-valgrind-annotations build I'm seeing: /home/jakub/src/gcc/obj88/gcc/testsuite/gfortran8/../../gfortran -B/home/jakub/src/gcc/obj88/gcc/testsuite/gfortran8/../../ -B/home/jakub/src/gcc/obj88/x86_64-pc -linux-gnu/./libgfortran/ /home/jakub/src/gcc/gcc/testsuite/gfortran.dg/finalize_46.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output -O0 -pedantic-errors -B/home/jakub/src/g cc/obj88/x86_64-pc-linux-gnu/./libatomic/ -B/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/./libatomic/.libs -B/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/./libgfortran/.libs -L/hom e/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/./libgfortran/.libs -L/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/./libgfortran/.libs -L/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/./li batomic/.libs -B/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/./libquadmath/.libs -L/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/./libquadmath/.libs -L/home/jakub/src/gcc/obj88/x86_ 64-pc-linux-gnu/./libquadmath/.libs -lm -o ./finalize_46.exe ==2680311== Invalid read of size 1 ==2680311==at 0x7F0654: generate_component_assignments(gfc_code**, gfc_namespace*) (resolve.cc:11873) ==2680311==by 0x7EFB68: gfc_resolve_code(gfc_code*, gfc_namespace*) (resolve.cc:12525) ==2680311==by 0x7F142B: resolve_codes(gfc_namespace*) (resolve.cc:18102) ==2680311==by 0x7F14FE: gfc_resolve(gfc_namespace*) [clone .part.0] (resolve.cc:18137) ==2680311==by 0x7D0250: resolve_all_program_units (parse.cc:6973) ==2680311==by 0x7D0250: gfc_parse_file() (parse.cc:7229) ==2680311==by 0x82924F: gfc_be_parse_file() (f95-lang.cc:239) ==2680311==by 0xDA8B2D: compile_file() (toplev.cc:446) ==2680311==by 0x71D233: do_compile (toplev.cc:2150) ==2680311==by 0x71D233: toplev::main(int, char**) (toplev.cc:2306) ==2680311==by 0x71E9FA: main (main.cc:39) ==2680311== Address 0x5527292 is in a rw- anonymous segment Similarly with different optimization levels: +FAIL: gfortran.dg/finalize_46.f90 -O0 (test for excess errors) +FAIL: gfortran.dg/finalize_46.f90 -O1 (test for excess errors) +FAIL: gfortran.dg/finalize_46.f90 -O2 (test for excess errors) +FAIL: gfortran.dg/finalize_46.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) +FAIL: gfortran.dg/finalize_46.f90 -O3 -g (test for excess errors) +FAIL: gfortran.dg/finalize_46.f90 -Os (test for excess errors) Another one is on finalize_38a.f90: /home/jakub/src/gcc/obj88/gcc/testsuite/gfortran6/../../gfortran -B/home/jakub/src/gcc/obj88/gcc/testsuite/gfortran6/../../ -B/home/jakub/src/gcc/obj88/x86_64-pc -linux-gnu/./libgfortran/ /home/jakub/src/gcc/gcc/testsuite/gfortran.dg/finalize_38a.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output -O0 -std=f2008 -B/home/jakub/src/gcc/ob j88/x86_64-pc-linux-gnu/./libgfortran/.libs -L/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/./libgfortran/.libs -L/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/./libgfortran/.libs -L /home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/./libatomic/.libs -B/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/./libquadmath/.libs -L/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/./ libquadmath/.libs -L/home/jakub/src/gcc/obj88/x86_64-pc-linux-gnu/./libquadmath/.libs -lm -o ./finalize_38a.exe /home/jakub/src/gcc/gcc/testsuite/gfortran.dg/finalize_38a.f90:76:96: Warning: The structure constructor at (1) has been finalized. This feature was removed by f08/0011. Use -std=f20 18 or -std=gnu to eliminate the finalization. /home/jakub/src/gcc/gcc/testsuite/gfortran.dg/finalize_38a.f90:151:73: Warning: The structure constructor at (1) has been finalized. This feature was removed by f08/0011. Use -std=f2 018 or -std=gnu to eliminate the finalization. /home/jakub/src/gcc/gcc/testsuite/gfortran.dg/finalize_38a.f90:156:61: Warning: The structure constructor at (1) has been finalized. This feature was removed by f08/0011. Use -std=f2 018 or -std=gnu to eliminate the finalization. ==2678885== Use of uninitialised value of size 8 ==2678885==at 0x8BF9C6: gfc_get_array_descriptor_base(int, int, bool) (trans-types.cc:1877) ==2678885==by 0x8C086F: gfc_get_array_type_bounds(tree_node*, int, int, tree_node**, tree_node**, int, gfc_array_kind, bool) (trans-types.cc:1959) ==2678885==by 0x85E9AB: gfc_conv_scalar_to_descriptor(gfc_se*, tree_node*, symbol_attribute) (trans-expr.cc:111) ==2678885==by 0x82E685: gfc_finalize_tree_expr(gfc_se*, gfc_symbol*, symbol_attribute, int) (trans.cc:1683) ==2678885==by
[Bug middle-end/112784] ICE in smallest_mode_for_size, at stor-layout.cc:356 | -finline-stringops -mavx512cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112784 --- Comment #2 from GCC Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:a8a3d832e609501002dee54150abfd96a28fe532 commit r14-6431-ga8a3d832e609501002dee54150abfd96a28fe532 Author: Alexandre Oliva Date: Mon Dec 11 15:09:28 2023 -0300 -finline-stringops: avoid too-wide smallest_int_mode_for_size [PR112784] smallest_int_mode_for_size may abort when the requested mode is not available. Call int_mode_for_size instead, that signals the unsatisfiable request in a more graceful way. for gcc/ChangeLog PR middle-end/112784 * expr.cc (emit_block_move_via_loop): Call int_mode_for_size for maybe-too-wide sizes. (emit_block_cmp_via_loop): Likewise. for gcc/testsuite/ChangeLog PR middle-end/112784 * gcc.target/i386/avx512cd-inline-stringops-pr112784.c: New.
[Bug target/112804] ICE in aarch64 crosscompiler in plus_constant, at explow.cc:102 with -mabi=ilp32 and -finline-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112804 --- Comment #3 from GCC Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:76ca5ab4ef95c41c1ed67edfb34a1a455a602192 commit r14-6429-g76ca5ab4ef95c41c1ed67edfb34a1a455a602192 Author: Alexandre Oliva Date: Mon Dec 11 15:09:22 2023 -0300 -finline-stringops: don't assume ptr_mode ptr in memset [PR112804] On aarch64 -milp32, and presumably on other such targets, ptr can be in a different mode than ptr_mode in the testcase. Cope with it. for gcc/ChangeLog PR target/112804 * builtins.cc (try_store_by_multiple_pieces): Use ptr's mode for the increment. for gcc/testsuite/ChangeLog PR target/112804 * gcc.target/aarch64/inline-mem-set-pr112804.c: New.
[Bug target/112778] ICE in ppc64-linux-gnu crosscompiler in store_by_pieces since r14-5946-g1ff6d9f7428b06
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112778 --- Comment #3 from GCC Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:1e2ea685bdea9aa65da2bf4137264d14f38a6f0b commit r14-6430-g1e2ea685bdea9aa65da2bf4137264d14f38a6f0b Author: Alexandre Oliva Date: Mon Dec 11 15:09:25 2023 -0300 -finline-stringops: check base blksize for memset [PR112778] The recently-added logic for -finline-stringops=memset introduced an assumption that doesn't necessarily hold, namely, that can_store_by_pieces of a larger size implies can_store_by_pieces by smaller sizes. Checks for all sizes the by-multiple-pieces machinery might use before committing to an expansion pattern. for gcc/ChangeLog PR target/112778 * builtins.cc (can_store_by_multiple_pieces): New. (try_store_by_multiple_pieces): Call it. for gcc/testsuite/ChangeLog PR target/112778 * gcc.dg/inline-mem-cmp-pr112778.c: New.
[Bug analyzer/112965] Valgrind error on gcc.dg/analyzer/fd-dup-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112965 --- Comment #1 from Jakub Jelinek --- gcc.dg/analyzer/fd-leak-pr108252.c, gcc.dg/analyzer/fd-access-mode-macros.c, gcc.dg/analyzer/fd-4.c, gcc.dg/analyzer/named-constants-Wunused-macros.c etc. fail the same.
[Bug analyzer/112965] New: Valgrind error on gcc.dg/analyzer/fd-dup-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112965 Bug ID: 112965 Summary: Valgrind error on gcc.dg/analyzer/fd-dup-1.c Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- With valgrind checking I'm seeing Executing on host: /home/jakub/src/gcc/obj88/gcc/xgcc -B/home/jakub/src/gcc/obj88/gcc/ /home/jakub/src/gcc/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c -fdiagnostics-plain-output - fanalyzer -Wanalyzer-too-complex -Wanalyzer-symbol-too-complex -fanalyzer-call-summaries -S -o fd-dup-1.s(timeout = 300) spawn -ignore SIGHUP /home/jakub/src/gcc/obj88/gcc/xgcc -B/home/jakub/src/gcc/obj88/gcc/ /home/jakub/src/gcc/gcc/testsuite/gcc.dg/analyzer/fd-dup-1.c -fdiagnostics-plain-output -fana lyzer -Wanalyzer-too-complex -Wanalyzer-symbol-too-complex -fanalyzer-call-summaries -S -o fd-dup-1.s ==395421== Conditional jump or move depends on uninitialised value(s) ==395421==at 0x1DC5D3E: search_line_sse42(unsigned char const*, unsigned char const*) (lex.cc:467) ==395421==by 0x1DC6944: _cpp_clean_line (lex.cc:960) ==395421==by 0x1DC6DD2: bool get_fresh_line_impl(cpp_reader*) (lex.cc:3747) ==395421==by 0x1DCB6FC: _cpp_get_fresh_line (lex.cc:3785) ==395421==by 0x1DCB6FC: _cpp_lex_direct (lex.cc:3838) ==395421==by 0x1DCD428: _cpp_lex_token (lex.cc:3670) ==395421==by 0x1DD3A97: cpp_get_token_1(cpp_reader*, unsigned int*) (macro.cc:2936) ==395421==by 0x7DD20A: get_token (c-lex.cc:311) ==395421==by 0x7DD20A: c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) (c-lex.cc:552) ==395421==by 0x785BFA: consider_macro (c-parser.cc:1854) ==395421==by 0x785BFA: ana::c_translation_unit::lookup_constant_by_id(tree_node*) const (c-parser.cc:1789) ==395421==by 0x10540A5: ana::maybe_stash_named_constant(ana::logger*, ana::translation_unit const&, char const*) (analyzer-language.cc:73) ==395421==by 0x105449E: stash_named_constants (analyzer-language.cc:96) ==395421==by 0x105449E: ana::on_finish_translation_unit(ana::translation_unit const&) (analyzer-language.cc:124) ==395421==by 0x785442: c_parser_translation_unit (c-parser.cc:1935) ==395421==by 0x785442: c_parse_file() (c-parser.cc:26713) ==395421==by 0x7F6331: c_common_parse_file() (c-opts.cc:1301) ==395421== ==395421== Use of uninitialised value of size 8 ==395421==at 0x1DC6948: _cpp_clean_line (lex.cc:962) ==395421==by 0x1DC6DD2: bool get_fresh_line_impl(cpp_reader*) (lex.cc:3747) ==395421==by 0x1DCB6FC: _cpp_get_fresh_line (lex.cc:3785) ==395421==by 0x1DCB6FC: _cpp_lex_direct (lex.cc:3838) ==395421==by 0x1DCD428: _cpp_lex_token (lex.cc:3670) ==395421==by 0x1DD3A97: cpp_get_token_1(cpp_reader*, unsigned int*) (macro.cc:2936) ==395421==by 0x7DD20A: get_token (c-lex.cc:311) ==395421==by 0x7DD20A: c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) (c-lex.cc:552) ==395421==by 0x785BFA: consider_macro (c-parser.cc:1854) ==395421==by 0x785BFA: ana::c_translation_unit::lookup_constant_by_id(tree_node*) const (c-parser.cc:1789) ==395421==by 0x10540A5: ana::maybe_stash_named_constant(ana::logger*, ana::translation_unit const&, char const*) (analyzer-language.cc:73) ==395421==by 0x105449E: stash_named_constants (analyzer-language.cc:96) ==395421==by 0x105449E: ana::on_finish_translation_unit(ana::translation_unit const&) (analyzer-language.cc:124) ==395421==by 0x785442: c_parser_translation_unit (c-parser.cc:1935) ==395421==by 0x785442: c_parse_file() (c-parser.cc:26713) ==395421==by 0x7F6331: c_common_parse_file() (c-opts.cc:1301) ==395421==by 0xCFF87D: compile_file() (toplev.cc:446) I vaguely remember the buffers for libcpp need to be aligned at the end so that the lex.cc fastpath can read it 8 bytes at a time, but I coiuld be wrong.
[Bug middle-end/112822] [14 regression] ICE: invalid RHS for gimple memory store after r14-5831-gaae723d360ca26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112822
--- Comment #7 from Peter Bergner ---
(In reply to Martin Jambor from comment #5)
> diff --git a/gcc/tree-sra.cc b/gcc/tree-sra.cc
> index 3bd0c7a9af0..99a1b0a6d17 100644
> --- a/gcc/tree-sra.cc
> +++ b/gcc/tree-sra.cc
> @@ -4219,11 +4219,15 @@ load_assign_lhs_subreplacements (struct access *lacc,
> if (racc && racc->grp_to_be_replaced)
> {
> rhs = get_access_replacement (racc);
> + bool vce = false;
> if (!useless_type_conversion_p (lacc->type, racc->type))
> - rhs = fold_build1_loc (sad->loc, VIEW_CONVERT_EXPR,
> - lacc->type, rhs);
> + {
> + rhs = fold_build1_loc (sad->loc, VIEW_CONVERT_EXPR,
> +lacc->type, rhs);
> + vce = true;
> + }
>
> - if (racc->grp_partial_lhs && lacc->grp_partial_lhs)
> + if (lacc->grp_partial_lhs && (vce || racc->grp_partial_lhs))
> rhs = force_gimple_operand_gsi (>old_gsi, rhs, true,
> NULL_TREE, true,
> GSI_SAME_STMT);
> }
This fixes the ICE on the large original test case and the smaller test cases.
I'll bootstrap and regtest it and report back on the results.
[Bug c++/112737] [14 Regression] g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112737 Patrick Palka changed: What|Removed |Added Target Milestone|--- |14.0 CC||ppalka at gcc dot gnu.org
[Bug middle-end/112822] [14 regression] ICE: invalid RHS for gimple memory store after r14-5831-gaae723d360ca26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112822
--- Comment #6 from Peter Bergner ---
(In reply to Martin Jambor from comment #5)
> The following should fix it. I'll try a bit more to come up with a testcase
> that would not require __builtin_vec_vsx_st but so far my simple attempts
> failed.
This patch to the small test case I attached still ICEs for me using the same
compiler options:
@@ -84,7 +84,7 @@
template cj cp;
template void cl(bu *cr, cj cs) { ct(cr, cs);
}
typedef __attribute__((altivec(vector__))) double co;
-void ct(double *cr, co cs) { __builtin_vec_vsx_st(cs, 0, cr); }
+void ct(double *cr, co cs) { *(co *)cr = cs; }
struct cq {
co q;
};
I'll give your patch a try.
[Bug c++/64002] Braced initialization of unknown bound array of nondependent type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64002 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104302 Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #2 from Patrick Palka --- Fixed for GCC 12+ by r12-7010-g501c4ee9fad687 whose testcase array36.C is very similar to this one.
[Bug target/112929] [14] RISC-V vector: Variable clobbered at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929
--- Comment #14 from Patrick O'Neill ---
I've reproduced the same failure on tip-of-tree using an old QEMU but cannot
reproduce with a freshly built QEMU:
GCC hash: eea25179d8d1406685b8b0995ba841605f895283 (tip-of-tree)
Qemu hash: 78385bc738108a9b5b20e639520dc60425ca2a5a (v8.1.2)
Glibc hash: a704fd9a133bfb10510e18702f48a6a9c88dbbd5 (v2.37)
My QEMU was built with GCC hash: 8b5cd6c4519cc120badd2b35a9e30d4deb82c012
If I use the tip-of-tree to build QMEU the failure does not exist anymore.
Your modified testcase does not produce the failure since it's missing the
variadic function call. Here is a version that works for me and does not use
printf:
int a, l, i, p, q, t, n, o;
int *volatile c;
static int j;
static struct pack_1_struct d;
long e;
char m = 5;
short s;
#pragma pack(1)
struct pack_1_struct {
long c;
int d;
int e;
int f;
int g;
int h;
int i;
} h, r = {1}, *f = , *volatile g;
void add_em_up(int count, ...) {
__builtin_va_list ap;
__builtin_va_start(ap, count);
__builtin_va_end(ap);
}
int main() {
int u;
j = 0;
for (; j < 9; ++j) {
u = ++t ? a : 0;
if (u) {
int *v =
*v = g || e;
*c = 0;
*f = h;
}
s = l && c;
o = i;
d.f || (p = 0);
q |= n;
}
r = *f;
add_em_up(1, 1);
if (m != 5)
return 1;
return 0;
}
Commands (Note that I used the old QEMU build):
gcv:
> /scratch/tc-testing/tc-dec-11-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64gcv -mabi=lp64d -O3 red.c -o rv64gcv.out
> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0
> /scratch/tc-testing/tc-dec-8-trunk/build-rv64gcv/bin/qemu-riscv64 rv64gcv.out
> echo $?
1
gc:
> /scratch/tc-testing/tc-dec-11-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64gc -mabi=lp64d -O3 red.c -o rv64gc.out
> QEMU_CPU=rv64,vlen=128,v=true,vext_spec=v1.0
> /scratch/tc-testing/tc-dec-8-trunk/build-rv64gcv/bin/qemu-riscv64 rv64gc.out
>
> echo $?
0
I think you're right Robin - it has some interaction with QMEU. The QEMU with
GCC r14-6339-g8b5cd6c4519 produces the error but the QEMU with the tip-of-tree
GCC r14-6417-geea25179d8d does not produce the error.
[Bug rtl-optimization/112380] [14 regression] ICE when building Mesa (in combine, internal compiler error: in simplify_subreg) since r14-2526-g8911879415d6c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112380 --- Comment #13 from GCC Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:624e274ca3a4405a55662fa72d1163120df0e03d commit r14-6424-g624e274ca3a4405a55662fa72d1163120df0e03d Author: Roger Sayle Date: Mon Dec 11 17:30:20 2023 + PR rtl-optimization/112380: Defend against CLOBBERs in combine.cc This patch addresses PR rtl-optimization/112380, an ICE-on-valid regression where a (clobber (const_int 0)) encounters a sanity checking gcc_assert (at line 7554) in simplify-rtx.cc. These CLOBBERs are used internally by GCC's combine pass much like error_mark_node is used by various language front-ends. The solutions are either to handle/accept these CLOBBERs through-out (or in more places in) the middle-end's RTL optimizers, including functions in simplify-rtx.cc that are used by passes other than combine, and/or attempt to prevent these CLOBBERs escaping from try_combine into the RTX/RTL stream. The benefit of the second approach is that it actually allows for better optimization: when try_combine fails to simplify an expression instead of substituting a CLOBBER to avoid the instruction pattern being recognized, noticing the CLOBBER often allows combine to attempt alternate simplifications/transformations looking for those that can be recognized. This first alternative is the minimal fix to address the CLOBBER encountered in the bugzilla PR. 2023-12-11 Roger Sayle gcc/ChangeLog PR rtl-optimization/112380 * combine.cc (expand_field_assignment): Check if gen_lowpart returned a CLOBBER, and avoid calling gen_simplify_binary with it if so. gcc/testsuite/ChangeLog PR rtl-optimization/112380 * gcc.dg/pr112380.c: New test case.
[Bug target/112932] [14] RISC-V rv64gcv_zvl256b vector: Incorrect behavior with nested loop array writing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112932 Patrick O'Neill changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Patrick O'Neill --- Confirmed fixed. Thanks!
[Bug c++/112580] [14 Regression]: g++.dg/modules/xtreme-header-4_b.C et al; ICE tree check: expected class 'type', have 'declaration'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112580 --- Comment #3 from Hans-Peter Nilsson --- All mentioned except g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors) seem to be fixed. Thanks!
