[Bug c/114430] New: False positive for -Wformat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114430
Bug ID: 114430
Summary: False positive for -Wformat
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
Using GCC 13.2.1, with:
#include
struct WWPerson
{
char Name[12];
};
struct WWPerson WWPersons[] = {
{"Bill R"},
{"Bill R"},
{"Barry G"},
};
char item[12 + 1];
void test()
{
for (size_t i = 0; i < sizeof(WWPersons) / sizeof(struct WWPerson); i++) {
sprintf(item, "%s", WWPersons[i].Name);
}
}
When compiling with -O2, i get:
bla.c: In function ‘test’:
bla.c:18:24: warning: ‘%s’ directive writing up to 35 bytes into a region of
size 13 [-Wformat-overflow=]
18 | sprintf(item, "%s", WWPersons[i].Name);
|^~
bla.c:18:9: note: ‘sprintf’ output between 1 and 36 bytes into a destination of
size 13
18 | sprintf(item, "%s", WWPersons[i].Name);
| ^~
I get the same warning with version 10.5.0, but not with version 9.5.0
The warning disappears when i remove one element from the array.
[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426 --- Comment #4 from Andrew Pinski --- (In reply to Sam James from comment #2) > Any idea why this only happened on arm btw? because arm is the only target that returns true for `targetm.cxx.cdtor_returns_this()`.
[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #15 from Richard Biener ---
the problem is in dependence analysis itself - by design classic dependence
analysis relies on a[i] and a[i+1] not aliasing but for DRs like
Creating dr for MEM[(U * {ref-all})_1]
analyze_innermost: success.
base_address: &c
offset from base address: 0
constant offset from base address: 0
step: 8
base alignment: 32
base misalignment: 0
offset alignment: 128
step alignment: 8
base_object: MEM[(U * {ref-all})&c]
Access function 0: {0B, +, 8}_1
The access function evolves in a way that this doesn't hold.
It might be tempting to fail data-ref analysis itself but it's really
subscript dependence testing that doesn't work. OTOH we already
have code in dr_analyze_indices to deal with similar cases concerning
overlap by adjusted base offset.
Note in theory we handle non-constant increments, so we eventually
would have to ditch support for those at all.
[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #16 from Richard Biener ---
Created attachment 57766
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57766&action=edit
patch
Oddly enough the following patch doesn't fix it but it correctly prevents us
from recording the access functions and data dependence analysis now says
(Data Dep:
#(Data Ref:
# bb: 3
# stmt: _2 = MEM[(U * {ref-all})_1];
# ref: MEM[(U * {ref-all})_1];
# base_object: MEM[(U * {ref-all})_1];
#)
#(Data Ref:
# bb: 3
# stmt: _7 = MEM[(U * {ref-all})_6];
# ref: MEM[(U * {ref-all})_6];
# base_object: MEM[(U * {ref-all})_6];
#)
(don't know)
but predictive commoning still does
Store-loads chain 0x48229b0
max distance 2, may reuse first
inits MEM[(U * {ref-all})&c] MEM[(U * {ref-all})&c + 8B]
references:
MEM[(U * {ref-all})_6] (id 3, write)
offset -2
distance 0
MEM[(U * {ref-all})_1] (id 0)
offset 0
distance 2
Executing predictive commoning without unrolling.
predcom has its own analysis it seems and it makes a similar mistake.
[Bug target/114194] ICE when using std::unique_ptr with xtheadvector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114194 Christoph Müllner changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Christoph Müllner --- Closing as resolved (the fix has been pushed on master).
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 --- Comment #33 from Ajit Kumar Agarwal --- Sent the patch for review. Here is the patch: PATCH] rs6000: Stackoverflow in optimized code on PPC (PR100799) When using FlexiBLAS with OpenBLAS we noticed corruption of the parameters passed to OpenBLAS functions. FlexiBLAS basically provides a BLAS interface where each function is a stub that forwards the arguments to a real BLAS lib, like OpenBLAS. Fixes the corruption of caller frame checking number of arguments is less than equal to GP_ARG_NUM_REG (8) excluding hidden unused DECLS. 2024-03-22 Ajit Kumar Agarwal gcc/ChangeLog: PR rtk-optimization/100799 * config/rs600/rs600-calls.cc (rs6000_function_arg): Don't generate parameter save area if number of arguments passed less than equal to GP_ARG_NUM_REG (8) excluding hidden paramter. * function.cc (assign_parms_initialize_all): Check for hidden parameter in fortran code and set the flag hidden_string_length and actual paramter passed excluding hidden unused DECLS. * function.h: Add new field hidden_string_length and actual_parm_length in function structure.
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 --- Comment #34 from Ajit Kumar Agarwal --- Sent the patch for review. Here is the patch: PATCH] rs6000: Stackoverflow in optimized code on PPC (PR100799) When using FlexiBLAS with OpenBLAS we noticed corruption of the parameters passed to OpenBLAS functions. FlexiBLAS basically provides a BLAS interface where each function is a stub that forwards the arguments to a real BLAS lib, like OpenBLAS. Fixes the corruption of caller frame checking number of arguments is less than equal to GP_ARG_NUM_REG (8) excluding hidden unused DECLS. 2024-03-22 Ajit Kumar Agarwal gcc/ChangeLog: PR rtk-optimization/100799 * config/rs600/rs600-calls.cc (rs6000_function_arg): Don't generate parameter save area if number of arguments passed less than equal to GP_ARG_NUM_REG (8) excluding hidden paramter. * function.cc (assign_parms_initialize_all): Check for hidden parameter in fortran code and set the flag hidden_string_length and actual paramter passed excluding hidden unused DECLS. * function.h: Add new field hidden_string_length and actual_parm_length in function structure.
[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683 --- Comment #17 from Jakub Jelinek --- Created attachment 57767 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57767&action=edit gcc14-pr111683.patch Patch I've tested overnight for this.
[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683 --- Comment #18 from Jakub Jelinek --- Using wi::multiple_of_p is what I've tried first but that regressed the generated code for pr71083.c (the test still PASSed, but predcom no longer triggered on it). I think it has access size 3 and step 4, so step is not a multiple of access size, but that is not a problem, all we actually care about is just if access size isn't bigger than step.
[Bug c++/104282] Copy elision when initializing a base-class subobject with aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104282
--- Comment #8 from Fedor Chelnokov ---
One more inconsistency here:
struct A {
A() {}
A(A&&) = delete;
};
struct B : A { };
int main() {
// ok in GCC
B{ A{} };
// error in GCC
B b{ A{} };
}
GCC allows temporary creation B{ A{} }, but prohibits variable creation B b{
A{} }. Online demo: https://gcc.godbolt.org/z/YGjYYqo6M
It looks like both must be prohibited as in Clang (or both allowed as in MSVC).
Related discussion: https://stackoverflow.com/q/70898525/7325599
[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #5 from Sam James ---
Reduced:
```
struct Object {
virtual ~Object();
};
struct Configurator : virtual Object {
virtual void doConfigure() = 0;
};
struct DOMConfigurator : Configurator {
DOMConfigurator() {}
};
```
[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065 --- Comment #4 from Eric Botcazou --- > is that the correct approach? most likely has to be guarded with a configure > option. The conditional setting is very likely superfluous, i.e. you can use the POSIX 2008 version whatever the multilib on Linux.
[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #19 from Richard Biener ---
But note that {0, +, 3 } and {2, + , 3} with size 2 will still eventually
overlap. See dr_analyze_indices where we attempt to make DR_INIT a
multiple of the element size (probably also not a perfect solution).
In the end representing the access function for the pointer with byte
granularity is a mistake and it should be translated to be based on
the access size. That of course makes a byte step of 3 with an access
size of 2 not representable (but it avoids these kind of issues).
The other possibility is to filter the remaining problematic cases
during dependence analysis itself where we see both DR_INITs. As said
the index based dependence analysis doesn't know about such thing as
partial element overlaps.
For the PR at hand your patch looks reasonable, but I think there's
a problem in how we handle the pointer-based access functions.
[Bug target/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 Richard Biener changed: What|Removed |Added Known to fail||14.0 Ever confirmed|0 |1 Last reconfirmed||2024-03-22 Status|UNCONFIRMED |NEW --- Comment #42 from Richard Biener --- I checked with a cross btw, and with -O1 we use 10s and 900MB memory for the testcase for comment #22. With -O2 it's 160s and 11GB as reported. It might of course that with -O1 we simply do not confront combine with the opportunity to blow up. So IMHO this is a non-issue and the reporter should use -O1 for such a TU. Still confirmed as a s390x specific problem and confirmed on trunk. Statistics with the -O2 combines: 305 combine "successes" 9425 305 combine "three-insn combine" 1 305 combine "four-insn combine" 1 305 combine "merges" 40418007 305 combine "extras" 9110287 305 combine "two-insn combine" 9423 305 combine "attempts" 40440004 With -O1: 305 combine "successes" 1861 305 combine "three-insn combine" 1732 305 combine "merges" 191051 305 combine "extras" 9274 305 combine "two-insn combine" 129 305 combine "attempts" 192434
[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683 --- Comment #20 from Jakub Jelinek --- That is true. I've been also wondering whether e.g. for the pr71083.c case we couldn't just look through all COMPONENT_REFs of the DR_REF (and maybe ARRAY_REFs with constant indexes) and check type size of the aggregate it is in against the size. That could perhaps fix the predcom of pr71083.c, because it is a 24-bit bitfield in 4 byte structure. Will you take this over, or should I tweak my patch? Note, statistics I've gathered with the above posted patch was that the patch did something in /home/jakub/src/gcc/gcc/testsuite/c-c++-common/torture/pr101636.c bar /home/jakub/src/gcc/gcc/testsuite/gcc.c-torture/compile/pr32399.c f /home/jakub/src/gcc/gcc/testsuite/gcc.dg/autopar/pr69109-2.c f /home/jakub/src/gcc/gcc/testsuite/gcc.dg/graphite/pr71575-2.c fn1 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/loop-versioning-6.c f1 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr111683-1.c main /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr111683-2.c main but only changed the generated code in the last 2 (those are intentional). The older patch with wi::multiple_of_p affected /home/jakub/src/gcc/gcc/testsuite/c-c++-common/torture/pr101636.c bar /home/jakub/src/gcc/gcc/testsuite/gcc.c-torture/compile/pr32399.c f /home/jakub/src/gcc/gcc/testsuite/gcc.c-torture/execute/pr71083.c bar /home/jakub/src/gcc/gcc/testsuite/gcc.dg/autopar/pr69109-2.c f /home/jakub/src/gcc/gcc/testsuite/gcc.dg/graphite/pr71575-2.c fn1 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/loop-versioning-6.c f1 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr111683-1.c main /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr111683-2.c main /home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/pr112736.c fn1 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/torture/pr68379.c fn1 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr87022.c main /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr101445.c foo /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr68502-2.c reset_nodes /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/pr81740-2.c main /home/jakub/src/gcc/gcc/testsuite/gcc.dg/vect/vect-avg-16.c f /home/jakub/src/gcc/gcc/testsuite/g++.dg/vect/pr95297.cc test and changed code generation of the 2 expected tests and pr71083.c. All this statistics was solely from make check-gcc check-g++.
[Bug tree-optimization/114405] ICE: in min_value, at wide-int.cc:344 with _BitInt() bitfield arithmetics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114405 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:982250b230967776f0da708a1572b78a38561e08 commit r14-9609-g982250b230967776f0da708a1572b78a38561e08 Author: Jakub Jelinek Date: Fri Mar 22 09:22:04 2024 +0100 bitint: Some bitint store fixes [PR114405] The following patch fixes some bugs in the handling of stores to large/huge _BitInt bitfields. In the first 2 hunks we are processing the most significant limb of the actual type (not necessarily limb in the storage), and so we know it is either partial or full limb, so [1, limb_prec] bits rather than [0, limb_prec - 1] bits as the code actually assumed. So, those 2 spots are fixed by making sure if tprec is a multiple of limb_prec we actually use limb_prec bits rather than 0. Otherwise, it e.g. happily could create and use 0 precision INTEGER_TYPE even when it actually should have processed 64 bits, or for non-zero bo_bit could handle just say 1 bit rather than 64 bits plus 1 bit in the last hunk spot. In the last hunk we are dealing with the extra bits in the last storage limb, and the code was e.g. happily creating 65 bit precision INTEGER_TYPE, even when we really should use 1 bit precision in that case. Also, it used a wrong offset in that case. The large testcase covers all these cases. 2024-03-22 Jakub Jelinek PR tree-optimization/114405 * gimple-lower-bitint.cc (bitint_large_huge::lower_mergeable_stmt): Set rprec to limb_prec rather than 0 if tprec is divisible by limb_prec. In the last bf_cur handling, set rprec to (tprec + bo_bit) % limb_prec rather than tprec % limb_prec and use just rprec instead of rprec + bo_bit. For build_bit_field_ref offset, divide (tprec + bo_bit) by limb_prec rather than just tprec. * gcc.dg/torture/bitint-66.c: New test.
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #25 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ddd4a3ca87410886b039cc225907b4f6e650082e commit r14-9610-gddd4a3ca87410886b039cc225907b4f6e650082e Author: Jakub Jelinek Date: Fri Mar 22 09:23:44 2024 +0100 ubsan: Don't -fsanitize=null instrument __seg_fs/gs pointers [PR111736] On x86 and avr some address spaces allow 0 pointers (on avr actually even generic as, but libsanitizer isn't ported to it and I'm not convinced we should completely kill -fsanitize=null in that case). The following patch makes sure those aren't diagnosed for -fsanitize=null, though they are still sanitized for -fsanitize=alignment. 2024-03-22 Jakub Jelinek PR sanitizer/111736 * ubsan.cc (ubsan_expand_null_ifn, instrument_mem_ref): Avoid SANITIZE_NULL instrumentation for non-generic address spaces for which targetm.addr_space.zero_address_valid (as) is true. * gcc.dg/ubsan/pr111736.c: New test.
[Bug tree-optimization/114405] ICE: in min_value, at wide-int.cc:344 with _BitInt() bitfield arithmetics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114405 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug target/114150] gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114150 --- Comment #1 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:3d406af2008a19914305966dddbc02ae980b8cd7 commit r14-9611-g3d406af2008a19914305966dddbc02ae980b8cd7 Author: Rainer Orth Date: Fri Mar 22 09:55:03 2024 +0100 testsuite: i386: Skip gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c etc. with Solaris as [PR114150] Two avx512cd tests FAIL to assemble with the Solaris/x86 assembler: FAIL: gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c (test for excess errors) UNRESOLVED: gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c compilation failed to produce executable FAIL: gcc.target/i386/avx512cd-vpbroadcastmw2d-2.c (test for excess errors) UNRESOLVED: gcc.target/i386/avx512cd-vpbroadcastmw2d-2.c compilation failed to produce executable Excess errors: Assembler: avx512cd-vpbroadcastmb2q-2.c "/var/tmp//ccs_9lod.s", line 42 : Invalid instruction argument Near line: "vpbroadcastmb2q %k0, %zmm0" Assembler: avx512cd-vpbroadcastmw2d-2.c "/var/tmp//ccevT6Rd.s", line 35 : Invalid instruction argument Near line: "vpbroadcastmw2d %k0, %zmm0" This seems to be an as bug, but given that this rarely if ever gets any fixes these days, this test just skips the affected tests. Adjuststing check_effective_target_avx512cd instead doesn't seem sensible since it would disable quite a number of working tests. Tested on i386-pc-solaris2.11 (as and gas) and x86_64-pc-linux-gnu. 2024-03-19 Rainer Orth gcc/testsuite: PR target/114150 * gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c: Skip on Solaris/x86 with as. * gcc.target/i386/avx512cd-vpbroadcastmw2d-2.c: Likewise.
[Bug target/114150] gcc.target/i386/avx512cd-vpbroadcastmb2q-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114150 Rainer Orth changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-March/6 ||48140.html Target Milestone|--- |14.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #2 from Rainer Orth --- Fixed for GCC 14.0.1.
[Bug tree-optimization/96147] [11 regression] gcc.dg/vect/slp-43.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96147 --- Comment #13 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:644a7033cc09b79a5cfefe1fe9b307d835009b17 commit r14-9612-g644a7033cc09b79a5cfefe1fe9b307d835009b17 Author: Rainer Orth Date: Fri Mar 22 10:07:05 2024 +0100 testsuite: vect: Remove dg-final in gcc.dg/vect/bb-slp-32.c [PR96147] gcc.dg/vect/bb-slp-32.c currently XPASSes on 32 and 64-bit Solaris/SPARC: XPASS: gcc.dg/vect/bb-slp-32.c -flto -ffat-lto-objects scan-tree-dump slp2 "vectorization is not profitable" XPASS: gcc.dg/vect/bb-slp-32.c scan-tree-dump slp2 "vectorization is not profitable" Richard suggested to remove the dg-final, so this is what the patch does. Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11. 2024-03-19 Rainer Orth gcc/testsuite: PR tree-optimization/96147 * gcc.dg/vect/bb-slp-32.c (dg-final): Remove.
[Bug tree-optimization/96147] [11 regression] gcc.dg/vect/slp-43.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96147 Rainer Orth changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #14 from Rainer Orth --- gcc.dg/vect/bb-slp-32.c XPASSes avoided as discussed in https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648142.html and followups.
[Bug c/109619] [12/13/14 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in fold_const_call_1, at fold-const-call.cc after r12-3278-g823685221de986.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109619 --- Comment #5 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:dbe9062ce070c861cd3fa6435187618413b1b3d1 commit r14-9613-gdbe9062ce070c861cd3fa6435187618413b1b3d1 Author: Andrew Pinski Date: Thu Mar 21 16:29:20 2024 -0700 Another ICE after conflicting types of redeclaration [PR109619] This another one of these ICE after error issues with the gimplifier and a fallout from r12-3278-g823685221de986af. This case happens when we are trying to fold memcpy/memmove. There is already code to try to catch ERROR_MARKs as arguments to the builtins so just need to change them to use error_operand_p which checks the type of the expression to see if it was an error mark also. Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog: PR c/109619 * builtins.cc (fold_builtin_1): Use error_operand_p instead of checking against ERROR_MARK. (fold_builtin_2): Likewise. (fold_builtin_3): Likewise. gcc/testsuite/ChangeLog: PR c/109619 * gcc.dg/redecl-26.c: New test. Signed-off-by: Andrew Pinski
[Bug c/109619] [12/13/14 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in fold_const_call_1, at fold-const-call.cc after r12-3278-g823685221de986.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109619 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|12.4|14.0 --- Comment #6 from Andrew Pinski --- Fixed.
[Bug c++/112724] C++ "'excess_precision_expr' not supported by dump_expr"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112724 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ca27c3b3a09fa051c0112769ba680e43b197aa97 commit r14-9614-gca27c3b3a09fa051c0112769ba680e43b197aa97 Author: Jakub Jelinek Date: Fri Mar 22 10:20:11 2024 +0100 testsuite: Fix up depobj-3.c test on i686-linux [PR112724] While I've posted a patch to handle EXCESS_PRECISION_EXPR in C/C++ pretty printing, still we'd need to handle (a + (float)5) and (float)(((long double)a) + (long double)5) and possibly (float)(((double)a) + (double)5) too for s390?, so the following patch just uses -fexcess-precision=fast, so that the expression is always the same. 2024-03-22 Jakub Jelinek PR c++/112724 * c-c++-common/gomp/depobj-3.c: Add -fexcess-precision=fast as dg-additional-options.
[Bug target/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #43 from Richard Biener ---
The interesting bit is that there are only 12026 overall loglinks, the
number of combine attempts is way higher than that would suggest also
given the few successful combinations. So something is odd here.
There's one interesting machinery in try_combine through added_links_insn
and added_notes_insn we can end up re-processing a large swat of insns
(even though we should need to only re-process the link target insns, not
all insns inbetween). There might be the opportunity, for the "reprocessing",
to use a worklist instead of resetting the insn walk.
I added statistics to note the "distance" we travel there by taking
DF_INSN_LUID (ret) - DF_INSN_LUID (added_{notes,links}_insn) as that.
This shows 48 such jumps with seemingly large distances:
305 combine "restart earlier == 143" 3
305 combine "restart earlier == 254" 1
305 combine "restart earlier == 684" 1
305 combine "restart earlier == 726" 1
305 combine "restart earlier == 777" 1
305 combine "restart earlier == 1158" 1
305 combine "restart earlier == 1421" 1
305 combine "restart earlier == 2073" 1
305 combine "restart earlier == 2130" 1
...
305 combine "restart earlier == 49717" 1
305 combine "restart earlier == 49763" 1
305 combine "restart earlier == 49866" 1
305 combine "restart earlier == 50010" 1
305 combine "restart earlier == 50286" 1
305 combine "restart earlier == 50754" 1
305 combine "restart earlier == 50809" 1
killing this feature doesn't improve things to -O1 levels though so it's
more likely the fact that we also do
rtx_insn *ret = newi2pat ? i2 : i3;
thus re-start at i2 when we altered i2. We re-start through this 6910
times. Always re-starting at i3 helps a lot and gets us -O1 performance
back. From comment#1 it suggests that newi2pat might in fact be equal
to the old, so I tried to count how many times this happens with a stupid
diff --git a/gcc/combine.cc b/gcc/combine.cc
index a4479f8d836..acd176d3185 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -4435,6 +4435,8 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1,
rtx_insn *i0,
propagate_for_debug (i2, last_combined_insn, i2dest, i2src,
this_basic_block);
INSN_CODE (i2) = i2_code_number;
+ if (rtx_equal_p (PATTERN (i2), newi2pat))
+ statistics_counter_event (cfun, "equal newi2pat", 1);
PATTERN (i2) = newi2pat;
}
else
and indeed this shows this to be the case 9211 times.
The following improves compile-time to 20s and 460MB memory use. In general
the algorithmic deficiency with the "restarting" remains and a proper fix
is to use a worklist for those that you'd drain before advancing in the
instruction chain (so not have a single 'ret' insn to reprocess but add
to the worklist).
I'm not sure whether identifying a not changed "new" i2 can be done better.
I'll leave it all to Segher of course - he'll be fastest to produce something
he likes.
diff --git a/gcc/combine.cc b/gcc/combine.cc
index a4479f8d836..0c61dcedaa1 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -4276,6 +4276,7 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1,
rtx
_insn *i0,
}
}
+ bool newi2pat_not_new = false;
{
rtx i3notes, i2notes, i1notes = 0, i0notes = 0;
struct insn_link *i3links, *i2links, *i1links = 0, *i0links = 0;
@@ -4435,6 +4436,8 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1,
rtx_insn *i0,
propagate_for_debug (i2, last_combined_insn, i2dest, i2src,
this_basic_block);
INSN_CODE (i2) = i2_code_number;
+ if (rtx_equal_p (PATTERN (i2), newi2pat))
+ newi2pat_not_new = true;
PATTERN (i2) = newi2pat;
}
else
@@ -4752,7 +4755,7 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1,
rtx_insn *i0,
combine_successes++;
undo_commit ();
- rtx_insn *ret = newi2pat ? i2 : i3;
+ rtx_insn *ret = newi2pat && !newi2pat_not_new ? i2 : i3;
if (added_links_insn && DF_INSN_LUID (added_links_insn) < DF_INSN_LUID
(ret))
ret = added_links_insn;
if (added_notes_insn && DF_INSN_LUID (added_notes_insn) < DF_INSN_LUID
(ret))
[Bug target/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 --- Comment #44 from Sam James --- I'm really curious as to if there's other test cases which could be shared, as Andreas mentioned distributions were complaining about this even. That's unlikely if it's a single degenerate case. Even listing some example package names could help.
[Bug target/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 --- Comment #45 from Sam James --- (ah, not andreas, but sarah)
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #6 from Sam James ---
Modifying llvm/include/llvm/ADT/iterator.h like so helps (!):
```
#pragma GCC push_options
#pragma GCC optimize ("O0")
friend bool operator==(const iterator_adaptor_base &LHS,
const iterator_adaptor_base &RHS) {
return LHS.I == RHS.I;
}
#pragma GCC pop_options
```
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 --- Comment #7 from Sam James --- I'll go back to trying to see which specific loop it is.
[Bug target/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523 --- Comment #46 from Richard Biener --- Maybe combine already knows that it just "keeps i2" rather than replacing it? When !newi2pat we seem to delete i2. Anyway, somebody more familiar with combine should produce a good(TM) patch.
[Bug target/114431] New: bpf: GCC generates unverifiable code for systemd restrict_fs_bpf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431 Bug ID: 114431 Summary: bpf: GCC generates unverifiable code for systemd restrict_fs_bpf Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jemarch at gcc dot gnu.org Target Milestone: --- GCC generates unverifiable code for systemd restrict_fs_bpf and the kernel verifier complains with the error log below. The corresponding systemd issue is https://github.com/systemd/systemd/issues/31888. Mär 21 11:01:44 H systemd[1]: bpf-firewall: Got EBADF when using BPF_F_ALLOW_MULTI, which indicates it is supported. Yay! Mär 21 11:01:44 H systemd[1]: libbpf: elf: skipping section(3) .data (size 0) Mär 21 11:01:44 H systemd[1]: libbpf: elf: skipping unrecognized data section(9) .comment Mär 21 11:01:44 H systemd[1]: libbpf: prog 'sd_bind4': failed to attach to cgroup: Bad file descriptor Mär 21 11:01:44 H systemd[1]: libbpf: elf: skipping section(3) .data (size 0) Mär 21 11:01:44 H systemd[1]: libbpf: elf: skipping unrecognized data section(10) .comment Mär 21 11:01:44 H systemd[1]: libbpf: prog 'sd_restrictif_e': BPF program load failed: Permission denied Mär 21 11:01:44 H systemd[1]: libbpf: prog 'sd_restrictif_e': -- BEGIN PROG LOAD LOG -- Mär 21 11:01:44 H systemd[1]: 0: R1=ctx(off=0,imm=0) R10=fp0 Mär 21 11:01:44 H systemd[1]: 0: (61) r0 = *(u32 *)(r1 +40) ; R0_w=scalar(smin=0,smax=umax=4294967295,var_off=(0x0; 0x)) R1=ctx(off=0,imm=0) Mär 21 11:01:44 H systemd[1]: 1: (bf) r2 = r10 ; R2_w=fp0 R10=fp0 Mär 21 11:01:44 H systemd[1]: 2: (18) r1 = 0x992d011eec00 ; R1_w=map_ptr(off=0,ks=4,vs=1,imm=0) Mär 21 11:01:44 H systemd[1]: 4: (07) r2 += -4 ; R2_w=fp-4 Mär 21 11:01:44 H systemd[1]: 5: (63) *(u32 *)(r10 -4) = r0 ; R0_w=scalar(smin=0,smax=umax=4294967295,var_off=(0x0; 0x)) R10=fp0 fp-8= Mär 21 11:01:44 H systemd[1]: 6: (85) call bpf_map_lookup_elem#1; R0_w=map_value_or_null(id=1,off=0,ks=4,vs=1,imm=0) Mär 21 11:01:44 H systemd[1]: 7: (18) r1 = 0xbf18005c2000 ; R1_w=map_value(off=0,ks=4,vs=1,imm=0) Mär 21 11:01:44 H systemd[1]: 9: (69) r3 = *(u16 *)(r1 +0) Mär 21 11:01:44 H systemd[1]: invalid access to map value, value_size=1 off=0 size=2 Mär 21 11:01:44 H systemd[1]: R1 min value is outside of the allowed memory range Mär 21 11:01:44 H systemd[1]: processed 8 insns (limit 100) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 Mär 21 11:01:44 H systemd[1]: -- END PROG LOAD LOG -- Mär 21 11:01:44 H systemd[1]: libbpf: prog 'sd_restrictif_e': failed to load: -13 Mär 21 11:01:44 H systemd[1]: libbpf: failed to load object 'restrict_ifaces_bpf' Mär 21 11:01:44 H systemd[1]: libbpf: failed to load BPF skeleton 'restrict_ifaces_bpf': -13 Mär 21 11:01:44 H systemd[1]: restrict-interfaces: Failed to load BPF object: Permission denied Mär 21 11:01:44 H systemd[1]: restrict-interfaces: Failed to load BPF object: Permission denied Mär 21 11:01:44 H systemd[1]: Controller 'cpu' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'cpuacct' supported: no Mär 21 11:01:44 H systemd[1]: Controller 'cpuset' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'io' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'blkio' supported: no Mär 21 11:01:44 H systemd[1]: Controller 'memory' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'devices' supported: no Mär 21 11:01:44 H systemd[1]: Controller 'pids' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'bpf-firewall' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'bpf-devices' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'bpf-foreign' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'bpf-socket-bind' supported: yes Mär 21 11:01:44 H systemd[1]: Controller 'bpf-restrict-network-interfaces' supported: no Mär 21 11:01:44 H systemd[1]: Set up TFD_TIMER_CANCEL_ON_SET timerfd. Mär 21 11:01:44 H systemd[1]: libbpf: elf: skipping section(3) .data (size 0) Mär 21 11:01:44 H systemd[1]: libbpf: elf: skipping unrecognized data section(8) .comment Mär 21 11:01:44 H systemd[1]: libbpf: prog 'restrict_filesystems': missing .BTF.ext function info for the main program, skipping all of .BTF.ext func info. Mär 21 11:01:44 H systemd[1]: libbpf: prog 'restrict_filesystems': missing .BTF.ext line info for the main program, skipping all of .BTF.ext line info. Mär 21 11:01:44 H systemd[1]: libbpf: prog 'restrict_filesystems': BPF program load failed: Permission denied Mär 21 11:01:44 H systemd[1]: libbpf: prog 'restrict_filesystems': -- BEGIN PROG LOAD LOG -- Mär 21 11:01:44 H systemd[1]: 0: R1=ctx(off=0,imm=0) R10=fp0 Mär 21 11:01:44 H systemd[1]: 0: (62) *(u32 *)(r10 -20) = 0 ; R10=fp0 fp-24= Mär 21 11:01:44 H systemd[1]: 1: (bf) r0 = r1
[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683 --- Comment #21 from Jakub Jelinek --- Created attachment 57768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57768&action=edit gcc14-pr111683.patch Updated patch which uses wi::multiple_of_p but doesn't regress pr71083.c. To be precise, it actually wasn't about foo with the bitfield, that used to be optimized before/after, but bar which uses packed struct with char and short members, step was 3 but the short access had size 2. But given that the 2 sized access is a COMPONENT_REF of the 3 byte sized struct, if step is a multiple of 3, that is fine as well.
[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683 Jakub Jelinek changed: What|Removed |Added Attachment #57768|0 |1 is obsolete|| --- Comment #22 from Jakub Jelinek --- Created attachment 57769 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57769&action=edit gcc14-pr111683.patch Actually for bit-fields, TREE_TYPE on the ref is the underlying type, so either we'd need to somehow better try to understand the actual reference size in that case, or simply look throught the BIT_FIELD_REF COMPONENT_REFs.
[Bug tree-optimization/59429] Missed optimization opportunity in qsort-style comparison functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59429 --- Comment #16 from Mathias Stearn --- Trunk still generates different code for all cases (in some cases subtly so) for both aarch64 and x86_64: https://www.godbolt.org/z/1s6sxrMWq. For both arches, it seems like LE and LG generate the best code. On aarch64, they probably all have the same throughput, but EL and EG have a size penalty with an extra instruction. On x86_64, there is much more variety. EL and EG both get end up with a branch rather than being branchless, which is probably bad since comparison functions are often called in ways that the result branches are unpredictable. GE and GL appear to have regressed since this ticket was created. They now do the comparison twice rather than reusing the flags from the first comparison: comGL(int, int): xor eax, eax cmp edi, esi mov edx, 1 setlal neg eax cmp edi, esi cmovg eax, edx ret comGE(int, int): xor eax, eax cmp edi, esi mov edx, 1 setne al neg eax cmp edi, esi cmovg eax, edx ret
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 --- Comment #8 from Sam James --- Created attachment 57770 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57770&action=edit EarlyCSE.cpp.cpp.179t.vect.diff (In reply to Sam James from comment #7) > I'll go back to trying to see which specific loop it is. tamar and richi both suggested separately debug counters. lbound: 6 ubound: 7 Attached the diff for EarlyCSE.cpp.cpp.179t.vect. Further suggestions?
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 --- Comment #9 from Richard Biener --- Nothing obviously suspicious here ... I wonder if you can attach 177t.ch_vect, 178t.ifcvt and 179t.vect for the case with the single vectorized bad loop? Maybe we're running into a latent issue downstream? What happens if you disable most followup passes?
[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683 --- Comment #23 from Richard Biener --- It looks like this could go to suitable_reference_p instead? That said, I do wonder why with my patch split_data_refs_to_components doesn't fixup. I think it's supposed to handle the case where dependences are unknown conservatively...
[Bug tree-optimization/114425] wrong code with _BitInt() __builtin_add_overflow_p() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425 --- Comment #1 from Zdenek Sojka --- Created attachment 57771 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57771&action=edit another testcase, using __builtin_mul_overflow_p Output for second testcase: $ x86_64-pc-linux-gnu-gcc -O2 testcase2.c $ ./a.out Aborted
[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683 --- Comment #24 from Jakub Jelinek --- (In reply to Richard Biener from comment #23) > It looks like this could go to suitable_reference_p instead? You mean return false for those making them not suitable at all? I thought without a write such references would act more like RS_ANY, but a reason I didn't just treat such references as RS_ANY rather than RS_NONZERO in suitable_reference_p was because of the assert that all refs in a component have the same ref_step_type but nothing actually comparing it before the assertion. But if you think I should just return false from suitable_reference_p if the step isn't a multiple of the sizes, I can surely try that. > That said, I do wonder why with my patch split_data_refs_to_components > doesn't fixup. I think it's supposed to handle the case where > dependences are unknown conservatively... I'm afraid I'm not familiar with data refs enough to know what was going on.
[Bug tree-optimization/114425] wrong code with _BitInt() __builtin_add_overflow_p() and __builtin_mul_overflow_p() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425
--- Comment #2 from Jakub Jelinek ---
Strangely it is dependent on the printf loop, without that it works fine.
Slightly adjusted testcase:
#if __BITINT_MAXWIDTH__ >= 2000
_BitInt(8) a;
_BitInt(300) b;
_BitInt(2000) c;
unsigned
foo (_BitInt(2000) d)
{
int o = __builtin_add_overflow_p (d, 0, b);
_BitInt(2000) m = c * a;
unsigned u = m;
return u + o;
}
__attribute__((noipa)) void
bar (int x)
{
(void) x;
}
#endif
int
main ()
{
#if __BITINT_MAXWIDTH__ >= 2000
unsigned x = foo
(0xfa7ac16f2613255eeb217e871c1f02221e26ce11f82d6a33206ec0ad5d4414722019933c0e2wb);
for (unsigned i = 0; i < sizeof (x); i++)
bar (((volatile unsigned char *) &x)[i]);
if (x != 1)
__builtin_abort ();
#endif
}
[Bug tree-optimization/114425] wrong code with _BitInt() __builtin_add_overflow_p() and __builtin_mul_overflow_p() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425 --- Comment #3 from Zdenek Sojka --- Created attachment 57772 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57772&action=edit unreduced testcase ; output differs between -O0 and -O2
[Bug tree-optimization/114425] wrong code with _BitInt() __builtin_add_overflow_p() and __builtin_mul_overflow_p() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425 --- Comment #4 from Zdenek Sojka --- Created attachment 57773 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57773&action=edit another unreduced testcase ; output differs between -O0 and -O2
[Bug fortran/111781] Fortran compiler complains about variable bound in array dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781 --- Comment #10 from GCC Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:44c0398e65347def316700911a51ca8b4ec0a411 commit r14-9618-g44c0398e65347def316700911a51ca8b4ec0a411 Author: Mikael Morin Date: Fri Mar 22 12:32:34 2024 +0100 fortran: Fix specification expression error with dummy procedures [PR111781] This fixes a spurious invalid variable in specification expression error. The error was caused on the testcase from the PR by two different bugs. First, the call to is_parent_of_current_ns was unable to recognize correct host association and returned false. Second, an ad-hoc condition coming next was using a global variable previously improperly restored to false (instead of restoring it to its initial value). The latter happened on the testcase because one dummy argument was a procedure, and checking that argument what causing a check of all its arguments with the (improper) reset of the flag at the end, and that preceded the check of the next argument. For the first bug, the wrong result of is_parent_of_current_ns is fixed by correcting the namespaces that function deals with, both the one passed as argument and the current one tracked in the gfc_current_ns global. Two new functions are introduced to select the right namespace. Regarding the second bug, the problematic condition is removed, together with the formal_arg_flag associated with it. Indeed, that condition was (wrongly) allowing local variables to be used in array bounds of dummy arguments. PR fortran/111781 gcc/fortran/ChangeLog: * symbol.cc (gfc_get_procedure_ns, gfc_get_spec_ns): New functions. * gfortran.h (gfc_get_procedure_ns, gfc_get_spec ns): Declare them. (gfc_is_formal_arg): Remove. * expr.cc (check_restricted): Remove special case allowing local variable in dummy argument bound expressions. Use gfc_get_spec_ns to get the right namespace. * resolve.cc (gfc_is_formal_arg, formal_arg_flag): Remove. (gfc_resolve_formal_arglist): Set gfc_current_ns. Quit loop and restore gfc_current_ns instead of early returning. (resolve_symbol): Factor common array spec resolution code to... (resolve_symbol_array_spec): ... this new function. Additionnally set and restore gfc_current_ns. gcc/testsuite/ChangeLog: * gfortran.dg/spec_expr_8.f90: New test. * gfortran.dg/spec_expr_9.f90: New test.
[Bug target/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #47 from Richard Biener ---
The rtx_equal_p change gets us 50% improvement only, it's necessary to also
disable the added_{links,notes}_insn extra re-processing to get us all the
way to -O1 speed. We'd need the worklist to avoid combine regressions there
(though for the actual testcase it doesn't make a difference).
[Bug target/114414] [14 Regression] 15-18% exec time slowdown of 433.milc on Zen2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114414 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug target/114412] [14 Regression] 7% slowdown of 436.cactusADM on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114412 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug target/114411] [14 Regression] 12% exec time slowdown of 433.milc on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114411 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug analyzer/114408] [13/14 Regression] ICE when invoking strcmp multiple times with -fsanitize=undefined -O1 -fanalyzer -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114408 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P1
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at gcc dot gnu.org
[Bug c++/114426] [14 regression] ICE when building log4cxx on arm (cxx_eval_call_expression, at cp/constexpr.cc:3242)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P1
[Bug target/101523] Huge number of combine attempts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #48 from Richard Biener ---
So another "simple" way is to keep the redundant insn walking ("it's O(1)") but
remember processsed insns and only re-process those we mark as such.
There might be a free "visited" bit on rtx_insn, who knows, the following uses
a bitmap to track this. Likely where we set/update added_links_insn we
should mark insns for re-processing.
A worklist, if it were to be processed in instruction order, would need to
be kept ordered and DF docs say DF_INSN_LUID isn't to be trusted after
adding/removing insns.
diff --git a/gcc/combine.cc b/gcc/combine.cc
index a4479f8d836..c2f04e6b86e 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -1106,6 +1106,8 @@ insn_a_feeds_b (rtx_insn *a, rtx_insn *b)
return false;
}
^L
+static bitmap processed;
+
/* Main entry point for combiner. F is the first insn of the function.
NREGS is the first unused pseudo-reg number.
@@ -1211,6 +1213,8 @@ combine_instructions (rtx_insn *f, unsigned int nregs)
setup_incoming_promotions (first);
last_bb = ENTRY_BLOCK_PTR_FOR_FN (cfun);
int max_combine = param_max_combine_insns;
+ processed = BITMAP_ALLOC (NULL);
+ bitmap_tree_view (processed);
FOR_EACH_BB_FN (this_basic_block, cfun)
{
@@ -1231,6 +1235,7 @@ combine_instructions (rtx_insn *f, unsigned int nregs)
label_tick_ebb_start = label_tick;
last_bb = this_basic_block;
+ bitmap_clear (processed);
rtl_profile_for_bb (this_basic_block);
for (insn = BB_HEAD (this_basic_block);
insn != NEXT_INSN (BB_END (this_basic_block));
@@ -1240,6 +1245,9 @@ combine_instructions (rtx_insn *f, unsigned int nregs)
if (!NONDEBUG_INSN_P (insn))
continue;
+ if (!bitmap_set_bit (processed, INSN_UID (insn)))
+ continue;
+
while (last_combined_insn
&& (!NONDEBUG_INSN_P (last_combined_insn)
|| last_combined_insn->deleted ()))
@@ -1427,6 +1435,7 @@ retry:
;
}
}
+ BITMAP_FREE (processed);
default_rtl_profile ();
clear_bb_flags ();
@@ -4758,6 +4767,14 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn *i1,
rtx_insn *i0,
if (added_notes_insn && DF_INSN_LUID (added_notes_insn) < DF_INSN_LUID
(ret))
ret = added_notes_insn;
+ bitmap_clear_bit (processed, INSN_UID (i3));
+ if (newi2pat)
+bitmap_clear_bit (processed, INSN_UID (newi2pat));
+ if (added_links_insn)
+bitmap_clear_bit (processed, INSN_UID (added_links_insn));
+ if (added_notes_insn)
+bitmap_clear_bit (processed, INSN_UID (added_notes_insn));
+
return ret;
}
^L
[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683 --- Comment #25 from rguenther at suse dot de --- On Fri, 22 Mar 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683 > > --- Comment #24 from Jakub Jelinek --- > (In reply to Richard Biener from comment #23) > > It looks like this could go to suitable_reference_p instead? > > You mean return false for those making them not suitable at all? > I thought without a write such references would act more like RS_ANY, but > a reason I didn't just treat such references as RS_ANY rather than RS_NONZERO > in suitable_reference_p was because of the assert that all refs in a component > have the same ref_step_type but nothing actually comparing it before the > assertion. Hmm, true. > But if you think I should just return false from suitable_reference_p if the > step isn't a multiple of the sizes, I can surely try that. > > > That said, I do wonder why with my patch split_data_refs_to_components > > doesn't fixup. I think it's supposed to handle the case where > > dependences are unknown conservatively... > > I'm afraid I'm not familiar with data refs enough to know what was going on. I tried to follow what happens there and I'm also somewhat lost. Anyway, I think fixing this in predcom in a convenient place even if it might be not the true fix is OK. You might want to put a comment before any such fix indicating there might be more latent issues in predcom or dependence analysis in general.
[Bug middle-end/112697] [14 Regression] 30-40% exec time regression of 433.milc on zen2 since r14-4972-g8aa47713701b1f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #11 from Jeffrey A. Law --- Per c#10.
[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 112697, which changed state. Bug 112697 Summary: [14 Regression] 30-40% exec time regression of 433.milc on zen2 since r14-4972-g8aa47713701b1f https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #10 from Sam James ---
Created attachment 57774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57774&action=edit
EarlyCSE.cpp.cpp.177t.ch_vect-bad
optimize("O2") on `template
hash_code hash_combine_range_impl(InputIteratorT first, InputIteratorT last)
works,` but O3 is broken.
Unfortunately, novector pragmas don't work on the while()s in there. I get a
ignored warning.
Attached those dumps w/ -fdbg-cnt=vect_loop:7 (so just the one bad loop). I can
tarball up the 6 vs 7 if useful.
Thanks. Will try disabling those passes next..
[Bug target/114432] New: [13 Regression] ICE in connect_traces, at dwarf2cfi.cc:3079 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114432 Bug ID: 114432 Summary: [13 Regression] ICE in connect_traces, at dwarf2cfi.cc:3079 on s390x-linux-gnu Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen with the gcc-13 branch on s390x-linux-gnu, didn't try trunk yet, fails in Ubuntu with --with-arch=z13 --with-tune=z16, but succeeds in Debian with --with-arch=z196. [...] during RTL pass: dwarf2 +===GNAT BUG DETECTED==+ | 13.2.0 (s390x-linux-gnu) in connect_traces, at dwarf2cfi.cc:3079 | | Error detected around /<>/src/alog-protected_containers.adb:69:11| | Compiling /<>/src/alog-protected_containers.adb| | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug. | | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). /<>/src/alog-protected_containers.adb /<>/src/alog-protected_containers.ads /<>/src/alog.ads /<>/src/alog-log_request.ads raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:414 compilation of alog-protected_containers.adb failed full build log at https://launchpad.net/ubuntu/+source/libalog/0.6.2-5/+build/27944112
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 --- Comment #11 from Sam James --- Created attachment 57775 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57775&action=edit EarlyCSE.cpp.cpp.178t.ifcvt-bad
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 --- Comment #12 from Sam James --- Created attachment 57776 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57776&action=edit EarlyCSE.cpp.cpp.179t.vect-bad
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 --- Comment #13 from Sam James --- Created attachment 5 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=5&action=edit valgrind output when broken
[Bug tree-optimization/114433] New: ICE: verify_ssa failed: definition in block 9 does not dominate use in block 8 with _BitInt() bitfield shift at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114433 Bug ID: 114433 Summary: ICE: verify_ssa failed: definition in block 9 does not dominate use in block 8 with _BitInt() bitfield shift at -O1 and above Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57778 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57778&action=edit reduced testcase Similar to PR114365 Compiler output: $ x86_64-pc-linux-gnu-gcc -O testcase.c testcase.c: In function 'foo': testcase.c:7:1: error: definition in block 9 does not dominate use in block 8 7 | foo() | ^~~ for SSA_NAME: _12 in statement: _38 = _12 >> 31; during GIMPLE pass: bitintlower testcase.c:7:1: internal compiler error: verify_ssa failed 0x177a70f verify_ssa(bool, bool) /repo/gcc-trunk/gcc/tree-ssa.cc:1203 0x13cbd45 execute_function_todo /repo/gcc-trunk/gcc/passes.cc:2095 0x13cc1ae execute_todo /repo/gcc-trunk/gcc/passes.cc:2142 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9610-20240322092442-gddd4a3ca874-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-9610-20240322092442-gddd4a3ca874-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240322 (experimental) (GCC)
[Bug c++/114377] [13/14 Regression] GCC crashes on an example of CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114377 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at gcc dot gnu.org
[Bug tree-optimization/114374] [12/13/14 Regression] snprintf Wformat-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug fortran/107426] [12/13/14 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426 --- Comment #8 from GCC Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:a44d7e8a52007c2d45217709ca02947c6600de87 commit r14-9619-ga44d7e8a52007c2d45217709ca02947c6600de87 Author: Mikael Morin Date: Thu Mar 21 17:27:54 2024 +0100 fortran: Ignore use statements on error [PR107426] This fixes an access to freed memory on the testcase from the PR. The problem comes from an invalid subroutine statement in an interface, which is ignored and causes the following statements forming the procedure body to be rejected. One of them use-associates the intrinsic ISO_C_BINDING module, which imports new symbols in a namespace that is freed at the time the statement is rejected. However, this creates dangling pointers as ISO_C_BINDING is special and its import creates a reference to the imported C_PTR symbol in the return type of the global intrinsic symbol for C_LOC (see the function create_intrinsic_function). This change saves and restores the list of use statements, so that rejected use statements are removed before they have a chance to be applied to the current namespace and create dangling pointers. PR fortran/107426 gcc/fortran/ChangeLog: * gfortran.h (gfc_save_module_list, gfc_restore_old_module_list): New declarations. * module.cc (old_module_list_tail): New global variable. (gfc_save_module_list, gfc_restore_old_module_list): New functions. (gfc_use_modules): Set module_list and old_module_list_tail. * parse.cc (next_statement): Save module_list before doing any work. (reject_statement): Restore module_list to its saved value. gcc/testsuite/ChangeLog: * gfortran.dg/pr89943_3.f90: Update error pattern. * gfortran.dg/pr89943_4.f90: Likewise. * gfortran.dg/use_31.f90: New test.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #55 from Jeffrey A. Law --- Per c#54. If it turns out we're wrong, we can always reopen or file a new report.
[Bug middle-end/111655] [11/12/13/14 Regression] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at gcc dot gnu.org
[Bug analyzer/111305] [13/14 Regression] GCC Static Analyzer -Wanalyzer-out-of-bounds false postive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111305 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2
[Bug target/111231] [12/13/14 regression] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P1
[Bug middle-end/111151] [12/13/14 Regression] Wrong code at -O0 on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 CC||law at gcc dot gnu.org
[Bug fortran/110987] [13/14 Regression] Segmentation fault after finalization of a temporary variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at gcc dot gnu.org
[Bug libgomp/110842] [14 Regression] Openmp loops with KIND=16 DO loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110842 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P4
[Bug c++/110401] [11/12/13/14 Regression] Unhelpful "goto is not a constant expression" in ill-formed pre c++20 constexpr function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110401 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug analyzer/110285] [13/14 Regression] -Wanalyzer-infinite-recursion false positive involving floating-point values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110285 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug target/110273] [12/13/14 Regression] i686-w64-mingw32 with -mavx512f generates AVX instructions without stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug middle-end/109990] [12/13/14 Regression] Bogus -Wuse-after-free warning after realloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #14 from Richard Biener ---
There are a few vectorizations in the dumps but only one early-exit where
we vectorize
[local count: 102053600]:
first$I_39 = MEM[(struct value_op_iterator *)&first];
last$I_40 = MEM[(struct value_op_iterator *)&last];
seed_15 = llvm::hashing::detail::get_execution_seed ();
if (first$I_39 != last$I_40)
goto ; [94.50%]
[local count: 96440652]:
[local count: 179229733]:
# buffer_ptr_22 = PHI <_20(24), &buffer(22)>
# first$I_24 = PHI <_29(24), first$I_39(22)>
# ivtmp_226 = PHI
_20 = buffer_ptr_22 + 8;
ivtmp_216 = ivtmp_226 - 1;
if (ivtmp_216 == 0)
goto ; [51.12%]
else
goto ; [48.88%]
[local count: 87607493]:
_30 = MEM[(const struct Use *)first$I_24].Val;
_35 = (unsigned long) _30;
MEM [(char * {ref-all})buffer_ptr_22] = _35;
_29 = first$I_24 + 32;
if (_29 != last$I_40)
goto ; [94.50%]
else
goto ; [5.50%]
[local count: 82789081]:
goto ; [100.00%]
[local count: 96440652]:
# buffer_ptr_248 = PHI <_20(4), buffer_ptr_22(3)>
# first$I_175 = PHI
if (last$I_40 == first$I_175)
...
as far as I can see that's a non-peeled case and from what I see it looks
OK how we process that.
[Bug c++/112652] g++.dg/cpp26/literals2.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from Jakub Jelinek --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #8) >> FWIW, the iconv conversion tables in /usr/lib/iconv can be regenerated >> from the OpenSolaris sources, modified not to do that '?' conversion. >> Worked for a quick check for the UTF-8 -> ASCII example, but the '?' is >> more prevalent and would need to be eradicated upstream. > > If it is always '?' used instead of unknown character, we could also have some > hack on the libcpp side for it. It took me a bit to get back to you here since I had to check with both Solaris engineering and dig up our old Solaris 9 sources (which, unlike, OpenSolaris, have no relevant parts missing due to copyright issues). Both what I found in the iconv conversion tables and what's documented in unicode_iconv(7) confirms the consistent use of '?'. The manpage has If the source character code value is not within a range defined by the source codeset standard, it is considered as an illegal character. If the source character code value is within the range(s) defined by the standard, it will be considered as non-identical, even if the source character code value maps to an undefined or a reserved location within the valid range. The non-identical character will map to either ? (0x3f in ASCII-compatible codesets) if the target codeset is a non-Unicode codeset or to Unicode replacement character (U+FFFD) if the target codeset is an Unicode codeset. It will of course be in the respective charset's encoding (0x3f for ASCII, 0x6f for EBCDIC), but that's all I could find. This is not a complete guarantee (I may well have missed something), but seems plausible enough... > Like (but limited to Solaris hosts) in convert_using_iconv when converting > from > SOURCE_CHARSET to some other character set don't try to convert the whole > UTF-8 > string at once, but split it into chunks at u'?' characters, so > foo???bar?baz?qux > would be iconv converted as > foo > ??? > bar > ? > baz > ? > qux > chunks. And when converting the non-? chunks, it would after the conversion > check for the '?' character (in the destination character set - that is > something that perhaps could be queried during initialization after > iconv_open) > and treat it as an error if it appeared there. Or always convert also back to > UTF-8 and check if it has more '?' characters than the source. Unless we want to take the easy way out and just require GNU libiconv on Solaris, that seems like a plausible way of handling the issue.
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 --- Comment #15 from Richard Biener --- The valgrind output might be because we vectorize the loads a[i], a[i+8], ... as full vector loads at a[i], a[i+8] but the last we access as scalar. So the uninit load might be harmless.
[Bug target/113357] [14 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 --- Comment #5 from Jeffrey A. Law --- So given my bootstraps (qemu) are working the most likely scenarios are either a difference in the emulators or a difference in the configure setup. The first thing I would suggest would be to put the stage2 compiler under a debugger and find out why it faulted. That might help with understanding the problem. ie, are we segfaulting because we dereferenced a NULL pointer, or perhaps faulting because we did an unaligned access, or whatever. The next thing I would suggest would be extracting the .i file and confirming you can feed that to the stage2 cc1 and see the fault. Assuming you can, then you ought to be able to do an object bisection. ie, replace .o files for the failing stage with those from a previous stage, relink, retest. It'll take a while. But this usually results in finding a single trigger file. Once that's narrowed down we can figure out the next steps.
[Bug analyzer/108708] [13/14 Regression] __analyzer_dump_named_constant fails with derived values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108708 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at gcc dot gnu.org
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 108278, which changed state. Bug 108278 Summary: [13/14 Regression] runtime error with -O1 -Wall https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug middle-end/108278] [13/14 Regression] runtime error with -O1 -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #20 from Jeffrey A. Law --- Per c#16.
[Bug c++/107058] [11/12/13/14 Regression] ICE in dwarf2out_die_ref_for_decl, at dwarf2out.cc:6038 since r11-5003-gd50310408f54e380
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107058 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug tree-optimization/114425] wrong code with _BitInt() __builtin_add_overflow_p() and __builtin_mul_overflow_p() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-03-22 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #5 from Jakub Jelinek --- Created attachment 57779 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57779&action=edit gcc14-pr114425.patch Untested fix.
[Bug debug/106955] [13/14 Regression] '-fcompare-debug' failure w/ -std=c++20 -O1 -ftree-parallelize-loops=2 -fno-ipa-sra --param ggc-min-expand=55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106955 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug c++/105760] [11/12/13/14 Regression] ICE: in build_function_type, at tree.cc:7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105760 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug target/105275] [12/13/14 regression] 525.x264_r and 538.imagick_r regressed on x86_64 at -O2 with PGO after r12-7319-g90d693bdc9d718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug c++/104995] [11/12/13/14 Regression] access checking for function pointer template parameters takes place at call site inside a templated (generic) lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104995 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug middle-end/104088] [12/13/14 Regression] '-O2' (or higher) GCN offloading (only) 'libgomp.oacc-c-c++-common/vprop.c' excess errors: 'warning: writing 1 byte into a region of size 0 [-Wstringop-ov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104088 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug c++/99599] [11/12/13 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599 --- Comment #23 from Patrick Palka --- (In reply to Jonathan Wakely from comment #22) > Here we go, this still fails on trunk, just by making the data member > private: That's because for a non-dependent conversion to a class type we only check it before constraints if it's an aggregate class (otherwise it might have a constructor template, which means the conversion might instantiate things making it unsafe to check before constraints). Maybe we should consider refining the heuristic further. I believe the code is strictly speaking invalid though.
[Bug target/102264] [11/12/13/14 Regression] extra spilling when using inline-asm and all registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102264 Jeffrey A. Law changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #12 from Jeffrey A. Law --- Per c#7.
[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731 --- Comment #20 from GCC Commits --- The master branch has been updated by Thomas Neumann : https://gcc.gnu.org/g:a364148530c28645ce87adbc58a66c9f32a325ab commit r14-9620-ga364148530c28645ce87adbc58a66c9f32a325ab Author: Thomas Neumann Date: Mon Mar 11 14:35:20 2024 +0100 handle unwind tables that are embedded within unwinding code [PR111731] Original bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731 The unwinding mechanism registers both the code range and the unwind table itself within a b-tree lookup structure. That data structure assumes that is consists of non-overlappping intervals. This becomes a problem if the unwinding table is embedded within the code itself, as now the intervals do overlap. To fix this problem we now keep the unwind tables in a separate b-tree, which prevents the overlap. libgcc/ChangeLog: PR libgcc/111731 * unwind-dw2-fde.c: Split unwind ranges if they contain the unwind table.
[Bug c++/101463] [11/12/13/14 Regression] Using a constexpr variable template specialization as default argument for non-type template parameter of reference type leads gcc to reject function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101463 Jeffrey A. Law changed: What|Removed |Added CC||law at gcc dot gnu.org Priority|P3 |P2
[Bug tree-optimization/95185] [11/12/13/14 Regression] Failure to optimize specific kind of sign comparison check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2 CC||law at gcc dot gnu.org
[Bug c/109835] -Wincompatible-function-pointer-types as a subset of -Wincompatible-pointer-types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835 --- Comment #5 from Sam James --- FWIW, after doing more of this work, I've decided I don't really care that much about this one. I still think FP mismatches are often worse, but there's enough junk pointer type mismatches that I'm not sure we should provide this (it's not like one case is OK and the other is way less scary or something).
[Bug tree-optimization/114425] wrong code with _BitInt() __builtin_add_overflow_p() and __builtin_mul_overflow_p() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425
--- Comment #6 from Jakub Jelinek ---
Though, guess it would help if evrp avoided undesirable propagation here:
It is changing:
:
# DEBUG BEGIN_STMT
_8 = .ADD_OVERFLOW (d_7(D), 0);
_1 = IMAGPART_EXPR <_8>;
_2 = (_Bool) _1;
# DEBUG o => (int) _2
# DEBUG BEGIN_STMT
a.0_3 = a;
_4 = (_BitInt(2000)) a.0_3;
c.1_5 = c;
m_11 = _4 * c.1_5;
# DEBUG m => m_11
# DEBUG BEGIN_STMT
u_12 = (unsigned int) m_11;
# DEBUG u => u_12
# DEBUG BEGIN_STMT
- o.2_6 = (unsigned int) _2;
+ o.2_6 = (unsigned int) _1;
_13 = o.2_6 + u_12;
return _13;
}
which is surely possible because IMAGPART_EXPR of .{ADD,SUB,MUL}_OVERFLOW has
[0, 1]
range, but for such large/huge _BitInt IMAGPART_EXPR it extends the lifetime of
an expensive large variable rather than just being a boolean.
[Bug target/114432] [13 Regression] ICE in connect_traces, at dwarf2cfi.cc:3079 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114432 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.3
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 --- Comment #16 from Sam James --- -fdisable-tree-cunroll seems to help.
[Bug tree-optimization/114403] [14 regression] LLVM miscompiled with -O3 -march=znver2 -fno-vect-cost-model since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403 --- Comment #17 from Sam James --- Created attachment 57780 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57780&action=edit EarlyCSE.cpp.cpp.182t.cunroll-bad
[Bug libstdc++/114101] FAIL: 26_numerics/headers/cmath/functions_std_c++17.cc -std=gnu++17 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101 --- Comment #9 from John David Anglin --- These two fails are different and not addressed by patch: FAIL: std/text_encoding/cons.cc -std=gnu++26 (test for excess errors) UNRESOLVED: std/text_encoding/cons.cc -std=gnu++26 compilation failed to produce executable FAIL: std/text_encoding/requirements.cc -std=gnu++26 (test for excess errors) FAIL: std/text_encoding/cons.cc -std=gnu++26 (test for excess errors) Excess errors: /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/std/text_encoding/cons.cc:12: erro r: 'text_encoding' is not a member of 'std' /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/std/text_encoding/cons.cc:13: erro r: 'e0' was not declared in this scope; did you mean 'y0'? [...]
