[Bug middle-end/116933] internal error on basic Ada program with -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116933 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-10-02 Component|ada |middle-end Summary|Ada FE incompatible with|internal error on basic Ada |-ftrivial-auto-var-init=zer |program with |o (__builtin_clear_padding |-ftrivial-auto-var-init=zer |not folded) |o CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Eric Botcazou --- It's the implementation of __builtin_clear_padding though, not the Ada FE.
[Bug tree-optimization/116596] [15 Regression] gcc.dg/vect/slp-11a.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116596 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Richard Biener --- Should be fixed now.
[Bug tree-optimization/116578] vectorizer SLP transition issues / dependences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116578 Bug 116578 depends on bug 116596, which changed state. Bug 116596 Summary: [15 Regression] gcc.dg/vect/slp-11a.c FAILs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116596 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/114855] ICE: Segfault when compiling large autogenerated C source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 --- Comment #58 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4ba4165d66b18d7c5b8af02ecdf38bfa0690c106 commit r15-4017-g4ba4165d66b18d7c5b8af02ecdf38bfa0690c106 Author: Richard Biener Date: Thu Sep 26 11:43:21 2024 +0200 tree-optimiztation/114855 - profile prediction slowness The testcase in PR114855 shows profile prediction to evaluate the same SSA def via expr_expected_value for each condition or switch in a function. The following patch caches the expected value (and probability/predictor) for each visited SSA def, also protecting against recursion and thus obsoleting the visited bitmap. This reduces the time spent in branch prediction from 1.2s to 0.3s, though callgrind which was how I noticed this seems to be comparatively very much happier about the change than this number suggests. PR tree-optimization/114855 * predict.cc (ssa_expected_value): New global. (expr_expected_value): Do not take bitmap. (expr_expected_value_1): Likewise. Use ssa_expected_value to cache results for a SSA def. (tree_predict_by_opcode): Adjust. (tree_estimate_probability): Manage ssa_expected_value. (tree_guess_outgoing_edge_probabilities): Likewise.
[Bug ipa/113197] [12/13/14/15 Regression] ICE in in handle_call_arg, at tree-ssa-structalias.cc:4119 since r12-5177-g494bdadf28d0fb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113197 --- Comment #12 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:02f4efe3c12cf7ef54e5a71b11044c15be5c7fab commit r15-4018-g02f4efe3c12cf7ef54e5a71b11044c15be5c7fab Author: Richard Biener Date: Mon Sep 30 09:07:36 2024 +0200 tree-optimization/113197 - bougs assert in PTA PTA asserts that EAF_NO_DIRECT_READ is not set when flags are set consistently which doesn't make sense. The following removes the assert. PR tree-optimization/113197 * tree-ssa-structalias.cc (handle_call_arg): Remove bougs assert. * gcc.dg/lto/pr113197_0.c: New testcase. * gcc.dg/lto/pr113197_1.c: Likewise.
[Bug libstdc++/112808] Consider enabling _GLIBCXX_ASSERTIONS checks by default for debug builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112808 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #2 from Jonathan Wakely --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664289.html
[Bug tree-optimization/116596] [15 Regression] gcc.dg/vect/slp-11a.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116596 --- Comment #3 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:61d87f27916dd1bddb0f38d0eb53d4cf59fa5a0a commit r15-4019-g61d87f27916dd1bddb0f38d0eb53d4cf59fa5a0a Author: Richard Biener Date: Wed Oct 2 13:00:45 2024 +0200 testsuite/116596 - fix gcc.dg/vect/slp-11a.c The condition on "vectorizing stmts using SLP" needs to match that of "vectorized 1 loops", obviously. PR testsuite/116596 * gcc.dg/vect/slp-11a.c: Fix.
[Bug other/116936] [UBSAN] gcc/diagnostic.cc: null pointer passed as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116936 Filip Kastl changed: What|Removed |Added Target Milestone|--- |15.0
[Bug other/116936] New: [UBSAN] gcc/diagnostic.cc: null pointer passed as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116936 Bug ID: 116936 Summary: [UBSAN] gcc/diagnostic.cc: null pointer passed as argument Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: pheeck at gcc dot gnu.org Blocks: 63426 Target Milestone: --- Host: x86_64-linux Target: x86_64-linux Running an UBSAN-instrumented GCC (for example on the g++.dg/header.C GCC testcase) results in /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/diagnostic.cc:168:17: runtime error: null pointer passed as argument 1, which is declared to never be null /home/worker/buildworker/tiber-gcc-ubsan/build/gcc/diagnostic.cc:171:17: runtime error: null pointer passed as argument 1, which is declared to never be null Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug other/116936] [UBSAN] gcc/diagnostic.cc: null pointer passed as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116936 --- Comment #1 from Filip Kastl --- This is the configuration of the UBSAN-instrumented GCC: Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/worker/buildworker/tiber-gcc-ubsan/build/configure --enable-languages=default,jit,lto,go,d --enable-host-shared --enable-checking=release --disable-multilib --with-build-config=bootstrap-ubsan Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.0 20240928 (experimental) (GCC)
[Bug target/116571] [15 Regression] GCN vs. "lower SLP load permutation to interleaving"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116571 Richard Biener changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #9 from Richard Biener --- I've adjusted testcases - can you update the current state?
[Bug other/116936] [UBSAN] gcc/diagnostic.cc: null pointer passed as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116936 --- Comment #2 from Filip Kastl --- To replicate this bug, you can do for example gcc -x c++-header ./gcc/testsuite/g++.dg/header.C or gcc -x c-header ./gcc/testsuite/gcc.dg/header.c There are many more GCC testsuite testcases that produce this error. Looks like the error happens only when one of the input files is a header.
[Bug tree-optimization/116583] vectorizable_slp_permutation cannot handle even/odd extract from VLA vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116583 --- Comment #8 from Richard Biener --- This is now also the only reason gcc.dg/vect/slp-12a.c FAILs to SLP on aarch64 when SVE is enabled (riscv handles it with load-lanes for the group size of 8).
[Bug target/116655] RISC-V: ICE with -mrvv-max-lmul=dynamic in compute_nregs_for_mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116655 Richard Biener changed: What|Removed |Added Last reconfirmed||2024-10-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- I can now confirm it also for FAIL: gcc.target/riscv/rvv/autovec/binop/vwsll-run.c (internal compiler error: in compute_nregs_for_mode, at config/riscv/riscv-vector-costs.cc:457) FAIL: gcc.target/riscv/rvv/autovec/binop/vwsll-run.c (test for excess errors)
[Bug ada/116916] improve wording for predefined packages in messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116916 Eric Botcazou changed: What|Removed |Added Summary|Confusing error message |improve wording for ||predefined packages in ||messages Severity|normal |enhancement --- Comment #3 from Eric Botcazou --- To be honest, the message looks quite clear to me, but feel free to suggest a better one.
[Bug middle-end/116933] internal error on basic Ada program with -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116933 Eric Botcazou changed: What|Removed |Added Severity|normal |enhancement
[Bug rtl-optimization/116919] extra zext for bitwise operations with a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116919 --- Comment #2 from Artemiy Volkov --- (In reply to Jeffrey A. Law from comment #1) > Confirmed. I see that you're looking at the crcu8 code. If you're looking > to optimize that function, you *really* want Mariam's code that detects CRC > loops and can generate a table lookup or clmul sequence (when zbc is > enabled). It'll optimize that function and the points where it gets inlined > to synthesize crcu16. Thank you, that's some outstanding work. I was able to install v1 of the series and it's safe to say that it beats this patch when it comes to optimizing that function. :) > > Your patch may still well be useful since I suspect this shows up elsewhere. > It's probably worth submitting upstream. > > I think the big question is whether or not forcing zero extension for that > case is going to hurt others where we rely on the sign extension of > constants to produce a constant that is more readily handled by li. Though > if the code is strictly handling cases where we have a sub-word op and we > want to widen it to a word sized op, then it may not be that big of a deal. Yeah, I think the scope here is slightly broader than just coremark; and yes, the idea is to strictly only handle widening to word size to eliminate the zext. Could you please help me understand how to construct a (RISC-V) counterexample that this approach could potentially affect negatively? > > The other way to approach this (and I'm not convinced it's actually better) > would be to have a define_insn_and_split pattern to match this: > > Trying 14 -> 15: >14: r141:SI=r138:SI|0x8000 > REG_DEAD r138:SI > REG_EQUAL r138:SI|0x8000 >15: r138:SI=zero_extend(r141:SI#0) > REG_DEAD r141:SI > Failed to match this instruction: > (set (reg/v:SI 138 [ crc ]) > (ior:SI (reg/v:SI 138 [ crc ]) > (const_int 32768 [0x8000]))) > > But I'm generally not a fan of using define_insn_and_split for this kind of > case (2 insn -> 2 insn split) as it mucks up the costing model in combine.cc. To add to your argument a bit against handling this in combine: will this also work when the loop is unrolled? To my best knowledge, if instead of 1 user insn 14 has 8 (as it would in case of crcu8()), then combine will have a much harder time converting the negative constant to the positive one. Besides, wouldn't the split pattern have to be added for many different arches?
[Bug ipa/110057] Missed devirtualization opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057
--- Comment #23 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #14)
> So something like this, and then use it in containers instead of
> _Alloc_traits::destroy
>
> template
> _GLIBCXX20_CONSTEXPR
> void
> _Destroy_static_type(_Tp* __p, _Allocator& __alloc)
> {
> #if __cplusplus >= 201103L
> if constexpr (__allocator_traits_base::__has_destroy<_Allocator, _Tp>)
> allocator_traits<_Allocator>::destroy(__alloc, __p);
> else
> #endif
> __p->_Tp::~_Tp();
> }
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664288.html
[Bug libstdc++/61458] std::aligned_storage is bigger than expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61458 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #12 from Jonathan Wakely --- Patch posted to fix this for the unstable ABI only: https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664287.html
[Bug lto/116907] [14/15 regression] ICE when building kakoune-2024.05.18 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907 --- Comment #21 from Eric Botcazou --- > So the TREE_BLOCK (expr) has been free'd. Right. The TREE_BLOCK for an expression is: if (IS_EXPR_CODE_CLASS (c)) return LOCATION_BLOCK (t->exp.locus); and "locus" is just an integer so the GC marking probably stops there.
[Bug target/116934] [15 Regression] ICE building 526.blender_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116934 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |15.0
[Bug target/116934] New: [15 Regression] ICE building 526.blender_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116934
Bug ID: 116934
Summary: [15 Regression] ICE building 526.blender_r
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
blender from SPEC2017 ICEs with current trunk. The reduced testcase is:
int a;
float *b;
void c() {
for (; a; a--, b += 4) {
b[0] = b[1] = b[2] = b[2] > 0 ?: 0;
if (b[3] < 0)
b[3] = 0;
}
}
-Ofast -mcpu=neoverse-v2 crashes with an unrecognizable insn:
(insn 40 39 41 6 (set (reg:VNx4SF 163 [ vect__52.30_104 ])
(unspec:VNx4SF [
(subreg:VNx4BI (reg:VNx16BI 164) 0)
(const_int 0 [0])
(reg:VNx4SF 135 [ vect__2.24 ])
(const_vector:VNx4SF repeat [
(const_double:SF 0.0 [0x0.0p+0])
])
] UNSPEC_COND_SMAX)) "rendercore.i":7:12 -1
(expr_list:REG_EQUAL (smax:VNx4SF (reg:VNx4SF 135 [ vect__2.24 ])
(const_vector:VNx4SF repeat [
(const_double:SF 0.0 [0x0.0p+0])
]))
(nil)))
during RTL pass: vregs
[Bug target/116923] ICE: in extract_insn, at recog.cc:2882 (unrecognizable insn) with -mavx10.2-512 -mno-avx10.2-256 and __bf16 vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116923 --- Comment #1 from Richard Biener --- I wonder what -mavx10.2-512 -mno-avx10.2-256 should do ...
[Bug target/116934] [15 Regression] ICE building 526.blender_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116934 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||saurabh.jha at arm dot com --- Comment #1 from ktkachov at gcc dot gnu.org --- Bisected to g:ac4cdf5cb43c0b09e81760e2a1902ceebcf1a135
[Bug middle-end/116926] [15 Regression] Recent changes in dot-product causing ICE on c6x port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116926 --- Comment #1 from Richard Biener --- There's an assert doing gcc_checking_assert (GET_MODE_CLASS (from_mode) == GET_MODE_CLASS (to_mode) && from_mode < to_mode); so the issue is likely in the caller.
[Bug target/116934] [15 Regression] ICE building 526.blender_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116934 --- Comment #2 from Saurabh Jha --- I will take a look. Thanks for bisecting it.
[Bug middle-end/116926] [15 Regression] Recent changes in dot-product causing ICE on c6x port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116926 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Version|unknown |15.0 Target Milestone|--- |15.0
[Bug target/116927] [14/15 Regression] during RTL pass: early_ra: ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 4 with -fnon-call-exceptions -fno-delete-dead-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116927 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug other/116613] RFE: support outputting diagnostics in *multiple* formats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613 --- Comment #14 from Kamil Dudka --- I think that the above described interface looks reasonable. A few questions: 1. Will `file=` work with absolute paths? 2. If a file with the specified name exists, will it be overwritten? 3. Will the file always be created, even if no diagnostics is produced by gcc? 4. Will the SARIF data contain absolute paths to source code files? If not will the working directory be recorded in each SARIF file?
[Bug tree-optimization/116922] [12/13/14/15 Regression] ICE: in op_iter_init, at ssa-iterators.h:604 with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116922 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:cea87c84eacdb422caeada734ba5138c994d7022 commit r15-4008-gcea87c84eacdb422caeada734ba5138c994d7022 Author: Andrew Pinski Date: Tue Oct 1 14:48:19 2024 -0700 backprop: Fix deleting of a phi node [PR116922] The problem here is remove_unused_var is called on a name that is defined by a phi node but it deletes it like removing a normal statement. remove_phi_node should be called rather than gsi_remove for phinodes. Note there is a possibility of using simple_dce_from_worklist instead but that is for another day. Bootstrapped and tested on x86_64-linux-gnu. PR tree-optimization/116922 gcc/ChangeLog: * gimple-ssa-backprop.cc (remove_unused_var): Handle phi nodes correctly. gcc/testsuite/ChangeLog: * gcc.dg/torture/pr116922.c: New test. Signed-off-by: Andrew Pinski
[Bug libstdc++/116903] c++ regex accepts } and ] as a literal character.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116903 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2024-10-02 Resolution|INVALID |--- Ever confirmed|0 |1
[Bug tree-optimization/116616] [15 Regression] Linux kernel fails to build on aarch64 due to r15-3256-g1c4b9826bd0d5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116616 --- Comment #4 from GCC Commits --- The master branch has been updated by Filip Kastl : https://gcc.gnu.org/g:ffc389cb11a2a61fb89b6034d3f3fe0896b29064 commit r15-4024-gffc389cb11a2a61fb89b6034d3f3fe0896b29064 Author: Filip Kastl Date: Wed Oct 2 14:14:44 2024 +0200 gimple ssa: Don't use __builtin_popcount in switch exp transform [PR116616] Switch exponential transformation in the switch conversion pass currently generates tmp1 = __builtin_popcount (var); tmp2 = tmp1 == 1; when inserting code to determine if var is power of two. If the target doesn't support expanding the builtin as special instructions switch conversion relies on this whole pattern being expanded as bitmagic. However, it is possible that other GIMPLE optimizations move the two statements of the pattern apart. In that case the builtin becomes a libgcc call in the final binary. The call is slow and in case of freestanding programs can result in linking error (this bug was originally found while compiling Linux kernel). This patch modifies switch conversion to insert the bitmagic (var ^ (var - 1)) > (var - 1) instead of the builtin. gcc/ChangeLog: PR tree-optimization/116616 * tree-switch-conversion.cc (can_pow2p): Remove this function. (gen_pow2p): Generate bitmagic instead of a builtin. Remove the TYPE parameter. (switch_conversion::is_exp_index_transform_viable): Don't call can_pow2p. (switch_conversion::exp_index_transform): Call gen_pow2p without the TYPE parameter. * tree-switch-conversion.h: Remove m_exp_index_transform_pow2p_type. gcc/testsuite/ChangeLog: PR tree-optimization/116616 * gcc.target/i386/switch-exp-transform-1.c: Don't test for presence of the POPCOUNT internal fn call. Signed-off-by: Filip Kastl
[Bug tree-optimization/116616] [15 Regression] Linux kernel fails to build on aarch64 due to r15-3256-g1c4b9826bd0d5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116616 --- Comment #5 from Filip Kastl --- The patch I pushed to trunk should fix this issue. I will wait a bit and then close this PR. Btw, as a follow-up to this, one could modify some RTL pass to pattern match (var ^ (var - 1)) > (var - 1) to some sort of popcount instruction (I think the RTL pass for this is combine but I don't have any experience with RTL). This way we would get the fast popcount instruction but wouldn't run into problems such as this PR. I intend to look into that.
[Bug middle-end/116878] [15 regression] libcall emitted unnecessarily for __popcountdi2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116878 --- Comment #2 from Filip Kastl --- Yeah, sorry about that. I just pushed the patch that Andrew linked. That should fix this. I'll close this PR if no one objects.
[Bug tree-optimization/116583] vectorizable_slp_permutation cannot handle even/odd extract from VLA vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116583 --- Comment #10 from Richard Sandiford --- I have a proof-of-concept hack (far from submission quality). But it looks like some cases will also require us to extend aarch64_evpc_reencode to handle SVE modes, which is also worthwhile for its own sake. Have a hack for that too.
[Bug tree-optimization/116937] New: Look better handling of phis in gsi_remove (via remove_phi_node)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116937 Bug ID: 116937 Summary: Look better handling of phis in gsi_remove (via remove_phi_node) Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: internal-improvement Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- As mentioned in the review https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664272.html : "maybe we can work towards removing remove_phi_node and make PHI node handling in gsi_* better"
[Bug tree-optimization/116098] [14/15 Regression] _Bool value from tagged union is incorrect when built with optimization since r14-1597-g64d90d06d2db43
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116098 --- Comment #23 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:1f619fe25925a5f79b9c33962e7a72e1f9fa commit r15-4033-g1f619fe25925a5f79b9c33962e7a72e1f9fa Author: Andrew Pinski Date: Tue Oct 1 18:34:00 2024 + phiopt: Fix VCE moving by rewriting it into cast [PR116098] Phiopt match_and_simplify might move a well defined VCE assign statement from being conditional to being uncondtitional; that VCE might no longer being defined. It will need a rewrite into a cast instead. This adds the rewriting code to move_stmt for the VCE case. This is enough to fix the issue at hand. It should also be using rewrite_to_defined_overflow but first I need to move the check to see a rewrite is needed into its own function and that is causing issues (see https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663938.html). Plus this version is easiest to backport. Bootstrapped and tested on x86_64-linux-gnu. PR tree-optimization/116098 gcc/ChangeLog: * tree-ssa-phiopt.cc (move_stmt): Rewrite VCEs from integer to integer types to case. gcc/testsuite/ChangeLog: * c-c++-common/torture/pr116098-2.c: New test. * g++.dg/torture/pr116098-1.C: New test. Signed-off-by: Andrew Pinski
[Bug c++/116907] [14/15 regression] ICE when building kakoune-2024.05.18 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907 --- Comment #23 from Andrew Pinski --- Created attachment 59266 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59266&action=edit A different reduced testcase ` -std=c++20 --param ggc-min-expand=0 --param ggc-min-heapsize=0 -O3 -flto` This one requires =0/=0 but I can't reproduce it locally with =0, only =1.
[Bug testsuite/52641] Test cases fail for 16-bit int targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 --- Comment #29 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:77c3ef08e946306329070ea6415abe7d9e328cd6 commit r15-4032-g77c3ef08e946306329070ea6415abe7d9e328cd6 Author: Georg-Johann Lay Date: Wed Oct 2 19:09:18 2024 +0200 testsuite/52641 - Make gcc.dg/strict-flex-array-3.c work on int != 32 bits. PR testsuite/52641 gcc/testsuite/ * gcc.dg/strict-flex-array-3.c (expect) [AVR]: Use custom version due to AVR-LibC limitations. (stuff): Use __SIZEOF_INT__ instead of hard-coded values.
[Bug tree-optimization/116098] [14 Regression] _Bool value from tagged union is incorrect when built with optimization since r14-1597-g64d90d06d2db43
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116098 Andrew Pinski changed: What|Removed |Added Summary|[14/15 Regression] _Bool|[14 Regression] _Bool value |value from tagged union is |from tagged union is |incorrect when built with |incorrect when built with |optimization since |optimization since |r14-1597-g64d90d06d2db43|r14-1597-g64d90d06d2db43 --- Comment #24 from Andrew Pinski --- Fixed fully on the trunk. Will wait a week or 2 before backporting it.
[Bug tree-optimization/116938] New: move_stmt in phiopt should use rewrite_to_defined_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116938 Bug ID: 116938 Summary: move_stmt in phiopt should use rewrite_to_defined_overflow Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: internal-improvement Severity: enhancement Priority: P3 Component: tree-optimization Assignee: pinskia at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Depends on: 111276 Target Milestone: --- As mentioned in https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664260.html . Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111276 [Bug 111276] rewrite_to_defined_overflow rewrites already defined code
[Bug tree-optimization/116939] New: rewrite_to_defined_overflow/gimple_with_undefined_signed_overflow should also rewrite VCEs (from/to integral types) into casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116939 Bug ID: 116939 Summary: rewrite_to_defined_overflow/gimple_with_undefined_sign ed_overflow should also rewrite VCEs (from/to integral types) into casts Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: internal-improvement Severity: enhancement Priority: P3 Component: tree-optimization Assignee: pinskia at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Blocks: 116938 Target Milestone: --- as mentioned in https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664260.html and as implemented in phiopt's move_stmt . Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116938 [Bug 116938] move_stmt in phiopt should use rewrite_to_defined_overflow
[Bug c++/115361] "possibly dangling reference to a temporary" when object is_empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115361 --- Comment #9 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #8) > Giving a -Wdangling-ref warning for f7 and f9 is correct, s/f7 and f9/f9/
[Bug c++/115361] "possibly dangling reference to a temporary" when object is_empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115361 --- Comment #8 from Jonathan Wakely --- Giving a -Wdangling-ref warning for f7 and f9 is correct, but that warning is just based on simple heuristics in the front end. The -Wunitialized warning comes from the middle end and correctly detects a read of a variable outside its lifetime. That's a real bug, but the fact that it could be worded better is a separate issue from "-Wdangling-ref has too many false positives".
[Bug tree-optimization/116938] move_stmt in phiopt should use rewrite_to_defined_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116938 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-10-02 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- .
[Bug tree-optimization/116939] rewrite_to_defined_overflow/gimple_with_undefined_signed_overflow should also rewrite VCEs (from/to integral types) into casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116939 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-10-02 --- Comment #1 from Andrew Pinski --- .
[Bug c++/115361] "possibly dangling reference to a temporary" when object is_empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115361 --- Comment #7 from Jonathan Wakely --- I think that's a completely separate issue.
[Bug pch/116936] [UBSAN] gcc/diagnostic.cc: null pointer passed as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116936 --- Comment #4 from Jakub Jelinek --- Created attachment 59268 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59268&action=edit gcc15-pr116936.patch Untested fix.
[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116550 --- Comment #11 from Georg-Johann Lay --- There's PR116778 that also produces wrong code; maybe it's the same issue -- but easier to analyse. At least for that PR the bad insn is already known.
[Bug preprocessor/96842] enhancement: copy clang Wheader-guard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96842 --- Comment #4 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5943a2fa1bc5407332a91976c145446cdb8ded7b commit r15-4010-g5943a2fa1bc5407332a91976c145446cdb8ded7b Author: Jakub Jelinek Date: Wed Oct 2 10:53:35 2024 +0200 libcpp: Implement clang -Wheader-guard warning [PR96842] The following patch implements the clang -Wheader-guard warning, which warns if a valid multiple inclusion header guard's #ifndef/#if !defined directive is immediately (no other non-line directives nor other (non-comment) tokens in between) followed by #define directive for some different macro, which in get_suggestion rules is close enough to the actual header guard macro (i.e. likely misspelling), the #define is object-like with empty definition (I've followed what clang implements) and the macro isn't defined later on (at least not on the final #endif at the end of a header). In this case it emits a warning, so that #ifndef STDIO_H #define STDOI_H ... #endif or similar misspellings can be caught. clang enables this warning by default, but I've put it into -Wall instead as it still seems to be a style warning, nothing more severe; if a header doesn't survive multiple inclusion because of the misspelling, users will get different diagnostics. 2024-10-02 Jakub Jelinek PR preprocessor/96842 libcpp/ * include/cpplib.h (struct cpp_options): Add warn_header_guard member. (enum cpp_warning_reason): Add CPP_W_HEADER_GUARD enumerator. * internal.h (struct cpp_reader): Add mi_def_cmacro, mi_loc and mi_def_loc members. (_cpp_defined_macro_p): Constify type pointed by argument type. Formatting fix. * init.cc (cpp_create_reader): Clear CPP_OPTION (pfile, warn_header_guard). * directives.cc (struct if_stack): Add def_loc and mi_def_cmacro members. (DIRECTIVE_TABLE): Add IF_COND flag to define. (do_define): Set ifs->mi_def_cmacro on a define immediately following #ifndef directive for the guard. Clear pfile->mi_valid. Formatting fix. (do_endif): Copy over pfile->mi_def_cmacro and pfile->mi_def_loc if ifs->mi_def_cmacro is set and pfile->mi_cmacro isn't a defined macro. (push_conditional): Clear mi_def_cmacro and mi_def_loc members. * files.cc (_cpp_pop_file_buffer): Emit -Wheader-guard diagnostics. gcc/ * doc/invoke.texi (Wheader-guard): Document. gcc/c-family/ * c.opt (Wheader-guard): New option. * c.opt.urls: Regenerated. * c-ppoutput.cc (init_pp_output): Initialize also cb->get_suggestion. gcc/testsuite/ * c-c++-common/cpp/Wheader-guard-1.c: New test. * c-c++-common/cpp/Wheader-guard-1-1.h: New test. * c-c++-common/cpp/Wheader-guard-1-2.h: New test. * c-c++-common/cpp/Wheader-guard-1-3.h: New test. * c-c++-common/cpp/Wheader-guard-1-4.h: New test. * c-c++-common/cpp/Wheader-guard-1-5.h: New test. * c-c++-common/cpp/Wheader-guard-1-6.h: New test. * c-c++-common/cpp/Wheader-guard-1-7.h: New test. * c-c++-common/cpp/Wheader-guard-1-8.h: New test. * c-c++-common/cpp/Wheader-guard-1-9.h: New test. * c-c++-common/cpp/Wheader-guard-1-10.h: New test. * c-c++-common/cpp/Wheader-guard-1-11.h: New test. * c-c++-common/cpp/Wheader-guard-1-12.h: New test. * c-c++-common/cpp/Wheader-guard-2.c: New test. * c-c++-common/cpp/Wheader-guard-2.h: New test. * c-c++-common/cpp/Wheader-guard-3.c: New test. * c-c++-common/cpp/Wheader-guard-3.h: New test.
[Bug c++/116929] ICE in write_unnamed_type_name when building redumper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116929 Richard Biener changed: What|Removed |Added Known to work||15.0 Keywords||ice-on-valid-code Target Milestone|14.3|--- --- Comment #2 from Richard Biener --- Does any earlier released GCC version work?
[Bug tree-optimization/112358] [14/15 Regression] glibc -Wstringop-overflow= build failure on hppa since r14-4089-gd45ddc2c04e471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112358
--- Comment #9 from John David Anglin ---
This change suppresses warning:
diff --git a/elf/dl-find_object.c b/elf/dl-find_object.c
index 449302eda3..a2ba667dd4 100644
--- a/elf/dl-find_object.c
+++ b/elf/dl-find_object.c
@@ -662,6 +662,9 @@ _dl_find_object_update_1 (struct link_map **loaded, size_t
count)
= _dlfo_loaded_mappings[!active_idx];
size_t remaining_to_add = current_used + count;
+ if (target_seg == NULL)
+return false;
+
/* Ensure that the new segment chain has enough space. */
{
size_t new_allocated
[Bug driver/116941] New: Corrupted argv[0] with modules?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116941 Bug ID: 116941 Summary: Corrupted argv[0] with modules? Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- ``` sam 906591 0.0 0.0 287460 52492 pts/18 S+ 20:30 0:00 | \_ /usr/bin/python3.12 /usr/bin/cvise test.sh hex_bin.ixx.ii --print-diff sam 906845 0.0 0.0 7076 3384 pts/18 S+ 20:30 0:00 | \_ /bin/bash /tmp/modules/redumper-testcase/test.sh sam 906847 0.0 0.0 5468 2772 pts/18 S+ 20:30 0:00 | \_ g++-14 -flto=auto -ggdb -march=native -mtune=native -std=gnu++20 -fmodules-ts -fmodule-mapper=hex_bin.ixx.o.modmap -MD -fdeps-format=p1689r5 -x c++ -c hex_bin.ixx.ii -freport-bug sam 907123 100 0.4 399892 287480 pts/18 R+ 20:30 0:01 | \_ -quiet -MD hex_bin.ixx.d -D_GNU_SOURCE hex_bin.ixx.ii -fdeps-file=hex_bin.ixx.ddi -fdeps-target=hex_bin.ixx.o -march=znver2 -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -msse4a -mno-fma4 -mno-xop -mfma -mno-avx512f -mbmi -mbmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd -mno-avx512vbmi -mno-avx512ifma -mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt -mclwb -mclzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mmwaitx -mno-pconfig -mno-pku -mprfchw -mno-ptwrite -mrdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize -mno-sgx -msha -mno-shstk -mno-tbm -mno-tsxldtrk -mno-vaes -mno-waitpkg -mwbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mno-avxvnni -mno-avx512fp16 -mno-avxifma -mno-avxvnniint8 -mno-avxneconvert -mno-cmpccxadd -mno-amx-fp16 -mno-prefetchi -mno-raoint -mno-amx-complex -mno-avxvnniint16 -mno-sm3 -mno-sha512 -mno-sm4 -mno-apxf -mno-usermsr --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=znver2 -quiet -dumpbase hex_bin.ixx.ii -dumpbase-ext .ii -ggdb -std=gnu++20 -flto=auto -fmodules-ts -fmodule-mapper=hex_bin.ixx.o.modmap -fdeps-format=p1689r5 -freport-bug -o - -frandom-seed=0 -fdump-noaddr ``` Are we corrupting argv[0] somewhere?
[Bug driver/116941] Corrupted argv[0] with modules?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116941 Sam James changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=116929 --- Comment #1 from Sam James --- This is from reducing PR116929.
[Bug c++/116907] [14/15 regression] ICE when building kakoune-2024.05.18 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907 --- Comment #24 from Eric Botcazou --- I think the line should simply be removed: DFS_follow_tree_edge (TREE_BLOCK (expr)); There is (no longer) a tree edge in this case.
[Bug lto/116907] [14/15 regression] ICE when building kakoune-2024.05.18 with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116907 Andrew Pinski changed: What|Removed |Added Component|c++ |lto Keywords|c++-lambda | --- Comment #25 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-patches/2013-June/364471.html looks like it introduces that line.
[Bug target/116927] [14/15 Regression] during RTL pass: early_ra: ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 4 with -fnon-call-exceptions -fno-delete-dead-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116927 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #5 from Andrew Pinski --- Mine should be easy to fix as I already gave the outline of what needs to be done.
[Bug tree-optimization/116922] [12/13/14 Regression] ICE: in op_iter_init, at ssa-iterators.h:604 with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116922 Andrew Pinski changed: What|Removed |Added Known to work||15.0 Summary|[12/13/14/15 Regression]|[12/13/14 Regression] ICE: |ICE: in op_iter_init, at|in op_iter_init, at |ssa-iterators.h:604 with|ssa-iterators.h:604 with |-Ofast |-Ofast Known to fail|15.0| --- Comment #5 from Andrew Pinski --- Fixed on the trunk so far.
[Bug tree-optimization/116566] SLP induction unsupported for variable-length vectors (even for group_size == 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116566 --- Comment #2 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ba7632674a2a9ba8193f082c8ca9614c642de3b7 commit r15-4012-gba7632674a2a9ba8193f082c8ca9614c642de3b7 Author: Richard Biener Date: Mon Sep 30 17:06:24 2024 +0200 tree-optimization/116566 - single lane SLP for VLA inductions The following adds SLP support for vectorizing single-lane inductions with variable length vectors. PR tree-optimization/116566 * tree-vect-loop.cc (vectorizable_induction): Handle single-lane SLP for VLA vectors. * gcc.dg/tree-ssa/reassoc-46.c: When using partial vectors the dump-scan doesn't look for the required .COND_ADD so skip for partial vectors.
[Bug target/69374] install.texi is bit-rotten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374 --- Comment #24 from GCC Commits --- The trunk branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:56d0ee7a8652a212f23148038c6c0c8afcdb66ad commit r15-4011-g56d0ee7a8652a212f23148038c6c0c8afcdb66ad Author: Gerald Pfeifer Date: Wed Oct 2 17:10:33 2024 +0800 doc: Drop h8300-hms reference to binaries downloads gcc: PR target/69374 * doc/install.texi (Specific) : Drop obsolete reference to binaries download docs.
[Bug tree-optimization/116566] SLP induction support limited for variable-length vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116566 Richard Biener changed: What|Removed |Added Summary|SLP induction unsupported |SLP induction support |for variable-length vectors |limited for variable-length |(even for group_size == 1) |vectors Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org Blocks|116578 |53947 Status|ASSIGNED|NEW --- Comment #3 from Richard Biener --- Now supported for single-lane SLP thus no longer blocks PR116578. Still enhancing should be possible, at least for a power-of-two number of induction lanes or the case of uniform inductions. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116578 [Bug 116578] vectorizer SLP transition issues / dependences
[Bug c++/116931] False "duplicate 'const'" errors when typedefs used on pointer types in function definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116931 --- Comment #6 from Jonathan Wakely --- [dcl.type.general] p2: As a general rule, at most one defining-type-specifier is allowed in the complete decl-specifier-seq of a declaration or in a defining-type-specifier-seq, and at most one type-specifier is allowed in a type-specifier-seq. The only exceptions to this rule are the following: — const can be combined with any type specifier except itself. — [...] So you can't have const const T or const T const. const T* const is of course not the same as const const T* and so is OK.
[Bug c/116935] New: [OpenMP] Suggest '' header inclusion for OpenMP's omp_* routines and other definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116935
Bug ID: 116935
Summary: [OpenMP] Suggest '' header inclusion for
OpenMP's omp_* routines and other definitions
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: diagnostic, openmp
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
It would be useful to add #include hints when using omp_… without having a
#include
It could be based on the reserved omp_ (ompx_?) prefix for the identifier
instead of listening all combinations.
→ Actually, likewise for Fortran (omp_lib), if it is just based on the prefix?
As that would be guarded by -fopenmp, checking for startswith('omp_') should be
safe.
* * *
Clang has the following – interestingly, it suddenly requires the handle type
not the enum value that the user entered, which seems to be slightly bogus.
4 | #pragma omp allocate(A1) align(128) allocator(omp_default_mem_alloc)
| ^
allocate-static.c:4:47: error: 'omp_allocator_handle_t' type not found; include
[Bug c++/116449] Miscompilation and missing bounds check with UBSAN with pointer to member functions and array accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116449
--- Comment #11 from Franz Sirl ---
The fix works nicely here, thanks!
As a fun fact, we gain a warning for this likely undefined code:
```
class BaseC {
public:
virtual ~BaseC() {}
};
class C : public BaseC {
public:
virtual ~C() override;
};
C::~C()
{
BaseC::~BaseC();
}
```
```
g++-14 -O2 -W -Wall test-manual-destructor.cpp -fsanitize=undefined -c
test-manual-destructor.cpp: In destructor 'C::~C()':
test-manual-destructor.cpp:15:1: warning: '*(BaseC*)this.BaseC::_vptr.BaseC' is
used uninitialized [-Wuninitialized]
15 | }
| ^
```
It's nice there is some warning for this coding error, but the text could nicer
:-)
[Bug tree-optimization/116660] [15 regression] gcc.dg/vect/no-scevccp-outer-12.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116660 --- Comment #6 from Richard Biener --- (In reply to Rainer Orth from comment #1) > Created attachment 59085 [details] > 32-bit sparc-sun-solaris2.11 no-scevccp-outer-12.c.180t.vect missed: not vectorized: relevant stmt not supported: _1 = (short int) sum_20; gcc.dg/vect/slp-19c.c fails everywhere right now. +FAIL: gcc.dg/vect/vect-multitypes-6.c -flto -ffat-lto-objects scan-tree-dump-times vect "Alignment of access forced using versioning" 6 +FAIL: gcc.dg/vect/vect-multitypes-6.c scan-tree-dump-times vect "Alignment of access forced using versioning" 6 needs char math: not vectorized: relevant stmt not supported: _18 = _15 + _17; it also needs short add but there's no effective target for that.
[Bug tree-optimization/116660] [15 regression] gcc.dg/vect/no-scevccp-outer-12.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116660 --- Comment #7 from Richard Biener --- (In reply to Richard Biener from comment #6) > (In reply to Rainer Orth from comment #1) > > Created attachment 59085 [details] > > 32-bit sparc-sun-solaris2.11 no-scevccp-outer-12.c.180t.vect > > missed: not vectorized: relevant stmt not supported: _1 = (short int) > sum_20; > > gcc.dg/vect/slp-19c.c fails everywhere right now. > > +FAIL: gcc.dg/vect/vect-multitypes-6.c -flto -ffat-lto-objects > scan-tree-dump-times vect "Alignment of access forced using versioning" 6 > +FAIL: gcc.dg/vect/vect-multitypes-6.c scan-tree-dump-times vect "Alignment > of access forced using versioning" 6 > > needs char math: > >not vectorized: relevant stmt not supported: _18 = _15 + _17; > > it also needs short add but there's no effective target for that. I'll note the "vectorized 1 loops" for the latter testcase is XFAILed for 32bit sparc but 64bit sparc isn't in vect_char_add either (maybe that's a missed thing).
[Bug libstdc++/109889] [13/14/15 Regression] Segfault in __run_exit_handlers since r13-5309-gc3c6c307792026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #17 from Jonathan Wakely --- I can no longer reproduce this either. I tried current trunk and r13-5309-gc3c6c307792026 on POWER9 systems with both glibc-2.36-18.fc37.ppc64le and glibc-2.34-100.el9.ppc64le. I think we might as well close this then, thanks to everybody who spent time trying to track it down.
[Bug middle-end/111875] With -Og ubsan check inserted even though __builtin_assume_aligned guarantees no UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111875 Filip Kastl changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #5 from Filip Kastl --- Marking as RESOLVED INVALID.
[Bug debug/82738] [meta-bug] issues with the -Og optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738 Bug 82738 depends on bug 111875, which changed state. Bug 111875 Summary: With -Og ubsan check inserted even though __builtin_assume_aligned guarantees no UB https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111875 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug tree-optimization/116660] [15 regression] gcc.dg/vect/no-scevccp-outer-12.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116660 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #9 from Richard Biener --- The gcc.dg/vect/slp-19c.c FAIL is tracked elsewhere.
[Bug tree-optimization/116578] vectorizer SLP transition issues / dependences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116578 Bug 116578 depends on bug 116660, which changed state. Bug 116660 Summary: [15 regression] gcc.dg/vect/no-scevccp-outer-12.c etc. FAIL https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116660 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/116660] [15 regression] gcc.dg/vect/no-scevccp-outer-12.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116660 --- Comment #8 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:79ea0aab75732c26c38d4b64f1d97acedf80155a commit r15-4013-g79ea0aab75732c26c38d4b64f1d97acedf80155a Author: Richard Biener Date: Wed Oct 2 11:27:09 2024 +0200 testsuite/116660 - adjust testcases unexpectedly failing on 32bit sparc Both testcases miss some effective target requires. PR testsuite/116660 * gcc.dg/vect/no-scevccp-outer-12.c: Add vect_pack_trunc. * gcc.dg/vect/vect-multitypes-6.c: Add vect_char_add, remove explicit 32bit sparc XFAIL.
[Bug target/115856] [15 Regression] 7% slowdown of 433.milc on Zen3 since r15-1735-ge62ea4fb8ffcab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115856 Filip Kastl changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Filip Kastl --- Marking as RESOLVED FIXED.
[Bug middle-end/112549] [14/15 Regression] 9% exec time regression of 436.cactusADM on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112549 Filip Kastl changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Filip Kastl --- Marking as RESOLVED FIXED.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 112549, which changed state. Bug 112549 Summary: [14/15 Regression] 9% exec time regression of 436.cactusADM on Aarch64 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112549 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 115856, which changed state. Bug 115856 Summary: [15 Regression] 7% slowdown of 433.milc on Zen3 since r15-1735-ge62ea4fb8ffcab https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115856 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/113832] [14/15 Regression] 6% exec time regression of 464.h264ref on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113832 Filip Kastl changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #9 from Filip Kastl --- Marking as RESOLVED FIXED.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 113832, which changed state. Bug 113832 Summary: [14/15 Regression] 6% exec time regression of 464.h264ref on aarch64 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113832 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 112916, which changed state. Bug 112916 Summary: [14/15 Regression] ~4-7% exec time regression of 433.milc on AMD Zen2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112916 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug ada/116916] Confusing error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116916 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-10-02 Status|UNCONFIRMED |NEW CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- A predefined spec is the spec of a predefined package like System.
[Bug target/112916] [14/15 Regression] ~4-7% exec time regression of 433.milc on AMD Zen2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112916 Filip Kastl changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #6 from Filip Kastl --- Marking as RESOLVED INVALID.
[Bug target/116309] ICE unrecognizable insn while compiling pr111821.c for s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116309 Filip Kastl changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Filip Kastl --- Marking as RESOLVED FIXED.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 115966, which changed state. Bug 115966 Summary: [15 Regression] Miscompilation of 403.gcc with -Ofast -march=native on x86_64 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115966 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/115966] [15 Regression] Miscompilation of 403.gcc with -Ofast -march=native on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115966 Filip Kastl changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from Filip Kastl --- Marking as RESOLVED FIXED.
[Bug target/116940] [15 Regression] wrong code with -O -mavx512vl and vector compare and negation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116940 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |15.0 Last reconfirmed||2024-10-02 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. Looks related to the removal of the VCONDU patterns.
[Bug libstdc++/116942] New: Behavior of std::regex compilation of character ranges inconsistent based on char type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116942 Bug ID: 116942 Summary: Behavior of std::regex compilation of character ranges inconsistent based on char type Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ddolan at lutron dot com Target Milestone: --- When compiling a regular expression that defines a character range using hexadecimal values greater than 0x7F, a std::regex_error is thrown if the char type of the target platform is signed. This exception is not thrown if the char type is unsigned. This behavior can similarly be turned on and off by providing -fsigned-char and -funsigned-char respectively, regardless of the target platform. The expectation is that this library would behave the same regardless of platform. I have confirmed that this example behaves as expected when using boost::regex with both char type configurations. See the attached preprocessed file that triggers this behavior. Output of gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/aarch64-linux-gnu/14.2.0/lto-wrapper Target: aarch64-linux-gnu Configured with: /usr/src/gcc/configure --build=aarch64-linux-gnu --disable-multilib --enable-languages=c,c++,fortran,go Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.2.0 (GCC) Command line used: g++ -std=c++17 -fsigned-char -o main main.cpp Compiler output: None
[Bug c++/111608] Cannot declare partial specialization after full specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111608 mauro russo changed: What|Removed |Added CC||ing.russomauro at gmail dot com --- Comment #5 from mauro russo --- If I may contribute, I am completely in line with the explanation by Jonathan Wakely, and I believe gcc is correct, but I guess the standard text might be more clear about it. In particular, let me contribute referring the final part of the clause §13.7.5-1 in n4849 draft for C++20 (part of [temp.class.spec]), as it reads "A partial specialization shall be declared before the first use of a class template specialization that would make use of the partial specialization as the result of an implicit or explicit instantiation in every translation unit in which such a use occurs; no diagnostic is required.", supporting the answer by Jonathan Wakely. About the implicit instantiation, there is §13.9.3-16 of n4849 (part of [temp.expl.spec])... I don't really like it is so late within §13.9.3, as it is really important, together the aforementioned §13.7.5-1, as well as §13.9.3-7 that similarly forbids to introduce the explicit specialization after the points where it would have been used. However, when you refine a member of the implicit instantiation, you cannot freely re-define the class members, but they have to 'correspond' to the member declaration of the specialization selected for the implicit instantiation, and in this case you satisfy this rule as you have 'f' function with no parameters and void return type. What I dislike is that I did not find in the standard explicit rules for such correspondence, expect the implicit examples in §13.9.3-6, but practical tests on gcc seems to indicate that common sense applies, as functions must remain functions, with the same involved types, classes must remain classes (struct/class ?), member templates must remain as such, and so on.
[Bug target/116927] [14/15 Regression] during RTL pass: early_ra: ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 4 with -fnon-call-exceptions -fno-delete-dead-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116927 --- Comment #6 from Andrew Pinski --- Created attachment 59271 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59271&action=edit Patch which I am testing
[Bug ada/52280] FAIL: c974013 -- C974013 Abortable part did not execute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52280 John David Anglin changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #5 from John David Anglin --- Target removed.
[Bug libstdc++/116942] Behavior of std::regex compilation of character ranges inconsistent based on char type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116942 --- Comment #1 from David Dolan --- Created attachment 59270 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59270&action=edit (gzipped) preprocessed file that triggers the behavior
[Bug c++/116943] New: wrong(?) indication of specialization after (implicit) instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116943
Bug ID: 116943
Summary: wrong(?) indication of specialization after (implicit)
instantiation
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ing.russomauro at gmail dot com
Target Milestone: ---
On godbolt, with gcc 14.2, the following program gets
"error: specialization of 'S::Q' after instantiation".
Adding the data member in the primary template class is what triggers the
problem.
However, a different version with the explicit specialization first, makes the
problem disappearing.
As similar reported problems, I found PR 111608, but it is different (and is
not a bug).
template struct S{
struct Q{};
Q q; // removing this line, the problem disappears
};
/* non-working version where class member Q is refined for the implicit
specialization S */
template<> struct S::Q {
int x;
};
/* working version where explicit specialization is declared first
template<> struct S{
struct Q;
};
struct S::Q {
int x;
};
*/
Is it really forbidden redefining 'Q' which is a class member which another
member (i.e., 'q') depends on ?
Cannot the checks be postponed ? (e.g., when objects for S will be
effectively constructed)
... otherwise, if the implicit instantiation of S referred by "template<>
struct S::Q" really wants to fully generate the class based on the
primary template, it should not even make sense to have the option to redefine
any of its parts, so invalidating the ability to provide redefinition of
members for implicit specializations, as well as to provide multiple
definitions of (different) members for the same implicit specialization,
isn't it ?
Well, as I was studying standard details on this aspects, IMHO there is lack of
details in [temp.expl.spec] about such stuff.
[Bug libstdc++/116944] New: [15 Regression] 17_intro/headers/c++2011/parallel_mode.cc fails on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116944 Bug ID: 116944 Summary: [15 Regression] 17_intro/headers/c++2011/parallel_mode.cc fails on aarch64 Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: testsuite-fail Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org CC: redi at gcc dot gnu.org Target Milestone: --- Target: aarch64-linux-gnu We get: ``` In file included from /home/apinski/src/upstream-cross-aarch64/gcc/objdir-stage2/aarch64-linux-gnu/libstdc++-v3/include/parallel/algobase.h:40,^M from /home/apinski/src/upstream-cross-aarch64/gcc/objdir-stage2/aarch64-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:2324,^M from /home/apinski/src/upstream-cross-aarch64/gcc/objdir-stage2/aarch64-linux-gnu/libstdc++-v3/include/algorithm:62,^M from /home/apinski/src/upstream-cross-aarch64/gcc/objdir-stage2/aarch64-linux-gnu/libstdc++-v3/include/aarch64-linux-gnu/bits/stdc++.h:51,^M from /home/apinski/src/upstream-cross-aarch64/gcc/objdir-stage2/aarch64-linux-gnu/libstdc++-v3/include/aarch64-linux-gnu/bits/extc++.h:32,^M from /home/apinski/src/upstream-cross-aarch64/gcc/libstdc++-v3/testsuite/17_intro/headers/c++2011/parallel_mode.cc:24:^M /home/apinski/src/upstream-cross-aarch64/gcc/objdir-stage2/aarch64-linux-gnu/libstdc++-v3/include/parallel/base.h:157: warning: 'template struct std::binary_function' is deprecated [-Wdeprecated-declarations]^M In file included from /home/apinski/src/upstream-cross-aarch64/gcc/objdir-stage2/aarch64-linux-gnu/libstdc++-v3/include/parallel/base.h:36:^M /home/apinski/src/upstream-cross-aarch64/gcc/objdir-stage2/aarch64-linux-gnu/libstdc++-v3/include/bits/stl_function.h:131: note: declared here^M ``` This is with r15-4033 .
[Bug libstdc++/116944] [15 Regression] 17_intro/headers/c++2011/parallel_mode.cc fails on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116944 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0
[Bug c++/116943] wrong(?) indication of specialization after (implicit) instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116943 --- Comment #1 from Andrew Pinski --- clang, MSVC and EDG all reject the code for the same reason.
[Bug ada/116945] New: Valgrind reports uninitialized memory use in sem_ch12.adb (sem_ch12__instance_context__save_and_reset)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116945
Bug ID: 116945
Summary: Valgrind reports uninitialized memory use in
sem_ch12.adb
(sem_ch12__instance_context__save_and_reset)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
CC: dkm at gcc dot gnu.org
Target Milestone: ---
hello.adb:
```
with Text_IO; use Text_IO;
procedure hello is
begin
Put_Line("Hello world!");
end hello;
```
```
$ valgrind -q --track-origins=yes --exit-on-first-error=yes --error-exitcode=2
--trace-children=yes /home/sam/build/bisect-gcc-pfx/bin/gnatmake hello.adb -f
--GCC=/home/sam/build/bisect-gcc-pfx/bin/gcc
/home/sam/build/bisect-gcc-pfx/bin/gcc -c hello.adb
==3711124== Conditional jump or move depends on uninitialised value(s)
==3711124==at 0xB88C0F: sem_ch12__instance_context__save_and_reset
(sem_ch12.adb:18574)
==3711124==by 0xB52C51: rtsfind__load_rtu (rtsfind.adb:1191)
==3711124==by 0xB540BA: rtsfind__rte (rtsfind.adb:1561)
==3711124==by 0xA3820B: exp_ch11__expand_n_exception_declaration
(exp_ch11.adb:1192)
==3711124==by 0xADD00F: expander__expand (expander.adb:252)
==3711124==by 0xB5A928: sem__analyze (sem.adb:830)
==3711124==by 0xBCEC85: sem_ch3__analyze_declarations (sem_ch3.adb:2761)
==3711124==by 0xC10919: sem_ch7__analyze_package_specification
(sem_ch7.adb:1711)
==3711124==by 0xB5A4C7: sem__analyze (sem.adb:466)
==3711124==by 0xC10451: sem_ch7__analyze_package_declaration
(sem_ch7.adb:1227)
==3711124==by 0xB5A4A3: sem__analyze (sem.adb:457)
==3711124==by 0xB8166E: sem_ch10__analyze_compilation_unit
(sem_ch10.adb:1152)
==3711124== Uninitialised value was created by a heap allocation
==3711124==at 0x4A95A43: malloc (vg_replace_malloc.c:446)
==3711124==by 0x2DCF7E3: __gnat_malloc (s-memory.adb:79)
==3711124==by 0xB87039: sem_ch12__generic_renamings__reallocateX
(table.adb:208)
==3711124==by 0xB87101: sem_ch12__generic_renamings__initX (table.adb:147)
==3711124==by 0xB9E13C: sem_ch12___elabb (table.adb:393)
==3711124==by 0xD14551: adainit (b_gnat1.adb:744)
==3711124==by 0x9227CF: gnat_parse_file() (misc.cc:117)
==3711124==by 0x13137BC: compile_file() (toplev.cc:452)
==3711124==by 0x1314D2A: do_compile() (toplev.cc:2210)
==3711124==by 0x13156B5: toplev::main(int, char**) (toplev.cc:2370)
==3711124==by 0x2CD89EA: main (main.cc:39)
==3711124==
==3711124==
==3711124== Exit program on first error (--exit-on-first-error=yes)
gnatmake: "hello.adb" compilation error
```
GCC was built with --enable-valgrind-annotations and -Og.
[Bug target/116725] operand size mismatch for vfpclasssd and vfpclassss when using -masm=intel for AVX512 builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116725 --- Comment #4 from Antoni --- It seems like this bug might already be fixed on master (my branch is old and I just rebased). I'll do more tests to confirm.
[Bug target/116725] operand size mismatch for vfpclasssd and vfpclassss when using -masm=intel for AVX512 builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116725 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #5 from Sam James --- (In reply to Andrew Pinski from comment #1) > -masm=intel is definitely not well tested ... I've considered testing it for kicks but I'm not sure I'm prepared for the slew of bugs.
[Bug target/113954] Finish LRA transition for arc by removing -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113954 --- Comment #9 from Segher Boessenkool --- Add a RejectNegative perhaps, because -mno-lra no longer does what the user expects? And/or WarnRemoved? And the ;; lra is still unproven for ARC, so allow to fall back to reload with -mno-lra. line needs some tuning :-)
[Bug other/116613] RFE: support outputting diagnostics in *multiple* formats
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #15 from David Malcolm ---
(In reply to Kamil Dudka from comment #14)
> I think that the above described interface looks reasonable. A few
> questions:
Thanks for the feedback.
> 1. Will `file=` work with absolute paths?
Yes. There might be some issues with expressing paths/filenames containing
whitespace, '=', or ',' due to the way the option-parsing works, but hopefully
that's acceptable.
> 2. If a file with the specified name exists, will it be overwritten?
Short answer: yes
Longer answer: My plan is to do:
fopen (path, "w")
on any specified outputs as cc1 starts up, and to fail with a hard error if any
of the fopen fail, telling you why. Hence it could fail if a file with the
specified name exists, but e.g. you don't have write permissions on it.
Perhaps we need a specific exit code for the case of "can't open diagnostic
output stream"?
> 3. Will the file always be created, even if no diagnostics is produced by
> gcc?
Yes, with the caveat that if cc1 can't fopen a diagnostic output file it will
fail immediately (as above), and obviously the file won't be created in such a
case.
> 4. Will the SARIF data contain absolute paths to source code files? If not
> will the working directory be recorded in each SARIF file?
GCC's current behavior is (as of GCC 13):
* for absolute paths, the GCC SARIF output for the "artifact" will have an
absolute value in its "uri".
"artifacts": [{"location": {"uri": "/tmp/test.c"},
* for relative paths, the GCC SARIF output for the "artifact" will have a
relative uri, and a "uriBaseId" of "PWD":
"artifacts": [{"location": {"uri":
"../../src/gcc/testsuite/gcc.dg/analyzer/malloc-1.c",
"uriBaseId": "PWD"},
and the "run" will have this giving the absolute path for "PWD":
"originalUriBaseIds": {"PWD": {"uri":
"file:///home/david/coding-3/gcc-newgit-path-revamp/build/gcc/"}},
As of GCC 15 the "run"'s "invocation" also has the "workingDirectory" property:
"workingDirectory": {"uri":
"/home/david/coding-3/gcc-newgit-path-revamp/build/gcc"},
Re my idea of:
> -fdiagnostics-add-output=sarif:file={output-filename}.sarif
>
> where e.g. {output-filename} would be substituted with the output filename
> from the gcc invocation.
note that I don't have that working yet, or a precise set of "substitution"
names and their semantics (I plan to work on it today). What "substitutions"
might you need for your use-cases?
Does the above support all your use-cases?
[Bug c++/113968] ICE: in create_tmp_var, at gimple-expr.cc:488 with -fcontracts and invalid member in contract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113968 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Sandoe --- fixed on trunk, no back port planned.
