[Bug middle-end/109840] [14 Regression] internal compiler error: in expand_fn_using_insn, at internal-fn.cc:153 when building graphite2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109840 --- Comment #3 from Andrew Pinski --- Now the aarch64 backend could add hi and qi patterns for popcount. For the TARGET_CSSC case, it would need to zero extend to SImode. For the !TARGET_CSSC case, it would also zero extend but instead to DImode (just like SImode case). But I am not 100% sure there might be other backends that would need this. Now the expansion of the popcount Internal function could do the zero extend but that is not what the internal function is for ...
[Bug tree-optimization/107855] gcc.dg/vect/vect-ifcvt-18.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107855
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-05-13
CC||xry111 at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #6 from Xi Ruoyao ---
Hmm, the test contains
"/* { dg-additional-options "-Ofast -mavx" { target avx_runtime } } */"
So it passes on AVX capable native builds, but fails otherwise.
[Bug tree-optimization/109841] New: [12/13/14 Regression] ranger ICE in operator_bitwise_not::fold_range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109841 Bug ID: 109841 Summary: [12/13/14 Regression] ranger ICE in operator_bitwise_not::fold_range Product: gcc Version: 12.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amonakov at gcc dot gnu.org Target Milestone: --- Created attachment 55076 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55076&action=edit compressed testcase Reduced from gcc-12 LTO ICE on LLVM source code in PR 106943. g++-12 -O2 -fPIC -fno-semantic-interposition -fvisibility-inlines-hidden -std=c++14 -fno-exceptions -fno-rtti -S rbi.ii during GIMPLE pass: thread /tmp/llvm-project-llvmorg-13.0.1/llvm/lib/CodeGen/GlobalISel/RegisterBankInfo.cpp: In member function 'bool llvm::RegisterBankInfo::ValueMapping::verify(unsigned int) const': /tmp/llvm-project-llvmorg-13.0.1/llvm/lib/CodeGen/GlobalISel/RegisterBankInfo.cpp:61:6: internal compiler error: Segmentation fault 61 | #ifndef NDEBUG | ^ 0xda951f crash_signal ../../gcc-12.3.0/gcc/toplev.cc:322 0x1a65ff7 operator_bitwise_not::fold_range(irange&, tree_node*, irange const&, irange const&, tree_code) const ../../gcc-12.3.0/gcc/range-op.cc:3479 0x1a65ff7 operator_bitwise_not::fold_range(irange&, tree_node*, irange const&, irange const&, tree_code) const ../../gcc-12.3.0/gcc/range-op.cc:3465 0x198a38a fold_using_range::range_of_range_op(irange&, gimple*, fur_source&) ../../gcc-12.3.0/gcc/gimple-range-fold.cc:608 0x198be60 fold_using_range::fold_stmt(irange&, gimple*, fur_source&, tree_node*) ../../gcc-12.3.0/gcc/gimple-range-fold.cc:554 0x198c1cc fold_range(irange&, gimple*, range_query*) ../../gcc-12.3.0/gcc/gimple-range-fold.cc:315 0xf0af5d path_range_query::range_of_stmt(irange&, gimple*, tree_node*) ../../gcc-12.3.0/gcc/gimple-range-path.cc:771 0xf0c524 path_range_query::range_defined_in_block(irange&, tree_node*, basic_block_def*) ../../gcc-12.3.0/gcc/gimple-range-path.cc:356 0xf0c73e path_range_query::internal_range_of_expr(irange&, tree_node*, gimple*) ../../gcc-12.3.0/gcc/gimple-range-path.cc:209 0xf0c73e path_range_query::internal_range_of_expr(irange&, tree_node*, gimple*) ../../gcc-12.3.0/gcc/gimple-range-path.cc:193 0xf0c850 path_range_query::range_of_expr(irange&, tree_node*, gimple*) ../../gcc-12.3.0/gcc/gimple-range-path.cc:225 0x198a13f fold_using_range::range_of_range_op(irange&, gimple*, fur_source&) ../../gcc-12.3.0/gcc/gimple-range-fold.cc:602 0x198be60 fold_using_range::fold_stmt(irange&, gimple*, fur_source&, tree_node*) ../../gcc-12.3.0/gcc/gimple-range-fold.cc:554 0x198c1cc fold_range(irange&, gimple*, range_query*) ../../gcc-12.3.0/gcc/gimple-range-fold.cc:315 0xf0af5d path_range_query::range_of_stmt(irange&, gimple*, tree_node*) ../../gcc-12.3.0/gcc/gimple-range-path.cc:771 0xf0c524 path_range_query::range_defined_in_block(irange&, tree_node*, basic_block_def*) ../../gcc-12.3.0/gcc/gimple-range-path.cc:356 0xf0c73e path_range_query::internal_range_of_expr(irange&, tree_node*, gimple*) ../../gcc-12.3.0/gcc/gimple-range-path.cc:209 0xf0c73e path_range_query::internal_range_of_expr(irange&, tree_node*, gimple*) ../../gcc-12.3.0/gcc/gimple-range-path.cc:193 0xf0c850 path_range_query::range_of_expr(irange&, tree_node*, gimple*) ../../gcc-12.3.0/gcc/gimple-range-path.cc:225 0x198a32b fold_using_range::range_of_range_op(irange&, gimple*, fur_source&) ../../gcc-12.3.0/gcc/gimple-range-fold.cc:602
[Bug c++/106943] GCC building clang/llvm with LTO flags causes ICE in clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943 --- Comment #32 from Alexander Monakov --- Ranger ICE is PR 109841 (reduced so it doesn't need LTO).
[Bug tree-optimization/109841] [12/13/14 Regression] ranger ICE in operator_bitwise_not::fold_range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109841 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.4
[Bug tree-optimization/109841] [12/13/14 Regression] ranger ICE in operator_bitwise_not::fold_range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109841 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106878 --- Comment #1 from Andrew Pinski --- Hmm, this might actually be fixed in GCC 13 ...
[Bug tree-optimization/109841] [12/13/14 Regression] ranger ICE in operator_bitwise_not::fold_range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109841 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- /tmp/llvm-project-llvmorg-13.0.1/llvm/lib/CodeGen/GlobalISel/RegisterBankInfo.cpp:61:6: error: invalid types for ‘bit_not_expr’ uint64_t * uint64_t * _92 = ~pretmp_188; during GIMPLE pass: pre Yes it is a dup and already fixed in GCC 13. *** This bug has been marked as a duplicate of bug 106878 ***
[Bug tree-optimization/106878] [11/12 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106878 Andrew Pinski changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #16 from Andrew Pinski --- *** Bug 109841 has been marked as a duplicate of this bug. ***
[Bug libgcc/109712] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #6 from Carlos Galvez --- Hi again! I realized there is still one more problem missing, so I suspect the linker was not the only culprit. It does not segfault, but it gets stuck in an infinite loop, once again when mixing exceptions and libcudart_static.a. @Richard you mentioned: > Does libcudart_static.a by chance contain any symbols from the libgcc runtime > (of an old toolchain)? Do you know how I could verify this? I'm pretty new when it comes to troubleshooting these things. My understanding is that libstdc++.so and libgcc_s.so are always backwards compatible so using "the latest" ensures you can use the newest features and also run older built code. Is there a flaw/pitfall in that reasoning? Thanks!
[Bug target/109825] [14 Regression] ICE in ix86_widen_mult_cost, at config/i386/i386.cc:20442 since r14-666-g608e7f3ab47fe7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109825 Uroš Bizjak changed: What|Removed |Added CC||haochen.jiang at intel dot com --- Comment #7 from Uroš Bizjak --- *** Bug 109807 has been marked as a duplicate of this bug. ***
[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807 Uroš Bizjak changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #9 from Uroš Bizjak --- *** This bug has been marked as a duplicate of bug 109825 ***
[Bug middle-end/109842] New: GCC-12 hangs on simple piece of inline assembly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109842
Bug ID: 109842
Summary: GCC-12 hangs on simple piece of inline assembly code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: 141242068 at smail dot nju.edu.cn
Target Milestone: ---
The bug-triggering testcase:
```
$ cat c.c
static int t;
int f_tt;
int f(void) {
int tt1;
asm("" : "=r"(f_tt), "=r"(tt1));
t = tt1;
return f_tt;
}
```
When compiled with `gcc-12 -O2`, gcc hangs
```
-> tmp $ gcc-12 -O2 c.c
^C
```
My gcc version:
```
-> tmp $ gcc-12 -v
Using built-in specs.
COLLECT_GCC=gcc-12
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12.1.0-2ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Ubuntu 12.1.0-2ubuntu1~22.04)
```
[Bug middle-end/109842] GCC-12 hangs on simple piece of inline assembly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109842 Xi Ruoyao changed: What|Removed |Added Known to fail||12.1.0, 12.2.0 Known to work||11.1.0, 12.3.0, 13.1.0 CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- Looks like a duplicate of some bug fixed in 12.3.
[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818 --- Comment #25 from Jonathan Wakely --- I think the simplest solution for this bug is just use and call trunc instead of trying to use std::trunc. If you use the functions in the global namespace then you get exactly the set that is supported by djgpp, not the incomplete set that gets imported into namespace std. It's not ideal, but there's only so much we can do when the underlying is incomplete.
[Bug tree-optimization/109842] GCC-12 hangs on simple piece of inline assembly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109842 Xi Ruoyao changed: What|Removed |Added Resolution|--- |FIXED Component|middle-end |tree-optimization Target Milestone|--- |12.3 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108684 CC||pinskia at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from Xi Ruoyao --- It's fixed by r12-9239. I'm not sure if it's a duplicate of PR108684 though, so mark it FIXED. If this is a duplicate please modify the field.
[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807 --- Comment #10 from David Binderman --- (In reply to Uroš Bizjak from comment #8) > Fixed. I don't think so. The code I gave seems still to crash the compiler: $ ~/gcc/results/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/dcb38/gcc/results/bin/gcc COLLECT_LTO_WRAPPER=/home/dcb38/gcc/results.20230513.asan.ubsan/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../trunk.year/configure --prefix=/home/dcb38/gcc/results.20230513.asan.ubsan --disable-multilib --disable-bootstrap --with-build-config=bootstrap-asan --with-build-config=bootstrap-ubsan --with-pkgversion=1d339ce8d002920f --enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20230513 (experimental) (1d339ce8d002920f) $ ~/gcc/results/bin/gcc -c -O2 -march=znver1 bug919.c during GIMPLE pass: slp edid-parse.c: In function ‘decode_edid’: edid-parse.c:521:14: internal compiler error: in ix86_widen_mult_cost, at config /i386/i386.cc:20444 0x11f3ab1 ix86_widen_mult_cost(processor_costs const*, machine_mode, bool) ../../trunk.year/gcc/config/i386/i386.cc:20444 I thought at first I hadn't picked up Uros's change, but: $ git log | fgrep V4HI fgrep: warning: fgrep is obsolescent; using grep -F i386: Handle V4HI and V2SImode in ix86_widen_mult_cost [PR109807] a widening mul operation to V4HI or V2SImode. Handle V4HImode and V2SImode. The operation ADDHN on V4SI, for example, is represented as (truncate:V4HI ((src1:V4SI + src2:V4SI) >> 16)) and RADDHN as (truncate:V4HI ((src1:V4SI + src2:V4SI + (1 << 15)) >> 16)). $
[Bug target/109807] [14 Regression] sse2-mmx-pmaddwd.c met ICE after commit r14-666-g608e7f3ab47 with march=cascadelake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109807 --- Comment #11 from Uroš Bizjak --- (In reply to David Binderman from comment #10) > (In reply to Uroš Bizjak from comment #8) > > Fixed. > > I don't think so. The code I gave seems still to crash the compiler: Yes, the cost function is ICEing on unhandled modes (that is *not* a good approach). Please look at the PR109825 how it will be solved.
[Bug ipa/109817] internal error in ICF pass on Ada interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109817 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Version|unknown |14.0 Component|ada |ipa CC||ebotcazou at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2023-05-13 Summary|-O2 and |internal error in ICF pass |./gnat.dg/sync_iface_call_p |on Ada interfaces |kg2.adb don't mix | --- Comment #1 from Eric Botcazou --- Yes, the ICF pass is not run at -O2 and -fno-ipa-icf is a workaround.
[Bug tree-optimization/94911] Failure to optimize comparisons of VLA sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911 --- Comment #5 from Gabriel Ravier --- Also, as an extra note, w.r.t. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911#c3, I've just noticed that I had indeed made a separate bug report at https://gcc.gnu.org/PR94912 (which ended up being closed as a duplicate of https://gcc.gnu.org/PR68531) - just wanted to clarify that so nobody ends up filing more duplicates like I almost just did
[Bug libstdc++/109818] std::trunc() requires a hack after building DJGPP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818 --- Comment #26 from Janez Zemva --- I am a c++ user, so I don't like using c header files if at all possible. I am pleased with how things are: I now compile/link a replacement libm and replace the sloppy djgpp header files, but I haven't tested this arrangement yet. Maybe it works.
[Bug tree-optimization/109842] GCC-12 hangs on simple piece of inline assembly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109842 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Andrew Pinski --- Yes it is a dup. In this case, the "Check all ssa names " part of the patch fixes it. *** This bug has been marked as a duplicate of bug 108684 ***
[Bug tree-optimization/108684] [12 Regression] ICE: verify_ssa failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108684 Andrew Pinski changed: What|Removed |Added CC||141242068 at smail dot nju.edu.cn --- Comment #17 from Andrew Pinski --- *** Bug 109842 has been marked as a duplicate of this bug. ***
[Bug c/109835] -Wincompatible-function-pointer-types as a subset of -Wincompatible-pointer-types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- I thought that there was already a separate bug for this, but it turns out that I was thinking of bug 87379, which is for something different...
[Bug c/109836] -Wpointer-sign should be enabled by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109836 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #4 from Eric Gallager --- How about: diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt index 0d0ad0a6374..f046d91d03b 100644 --- a/gcc/c-family/c.opt +++ b/gcc/c-family/c.opt @@ -1178,7 +1178,7 @@ C ObjC C++ ObjC++ Var(warn_pointer_arith) Warning LangEnabledBy(C ObjC C++ ObjC+ Warn about function pointer arithmetic. Wpointer-sign -C ObjC Var(warn_pointer_sign) Warning LangEnabledBy(C ObjC,Wall || Wpedantic) +C ObjC Var(warn_pointer_sign) Warning LangEnabledBy(C ObjC,Wall || Wpedantic || Wextra) Warn when a pointer differs in signedness in an assignment. Wpointer-compare
[Bug c/109826] Incompatible pointer types in ?: not covered by -Wincompatible-pointer-types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109826 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Blocks||44209 --- Comment #3 from Eric Gallager --- (In reply to Andrew Pinski from comment #2) > The warning is not even controlled by an option either so only -Werror turns > it into an error. Thus, this fits under bug 44209 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209 [Bug 44209] [meta-bug] Some warnings are not linked to diagnostics options
[Bug tree-optimization/109829] Optimizing __builtin_signbit(x) ? -x : x or abs for FP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Pinski from comment #6) > I need to double check if == 1 will show up here though. The only thing we know about __builtin_signbit is that is 0 or non-zero. The exact value is unspecified for the non-zero case. So we can only optimize the !=/== 0 cases.
[Bug tree-optimization/109843] New: signbit comparisons -> copysign optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109843
Bug ID: 109843
Summary: signbit comparisons -> copysign optimization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
float copysign1(float x, float y)
{
bool t = __builtin_signbit(x) == 0;
bool t1 = __builtin_signbit(y) == 0;
return (t == t1) ? y : -y;
}
float copysign2(float x, float y)
{
bool t = __builtin_signbit(x) != 0;
bool t1 = __builtin_signbit(y) != 0;
return (t == t1) ? y : -y;
}
float copysign3(float x, float y)
{
bool t = __builtin_signbit(x) != 0;
bool t1 = __builtin_signbit(y) == 0;
return (t != t1) ? y : -y;
}
float copysign4(float x, float y)
{
bool t = __builtin_signbit(x) == 0;
bool t1 = __builtin_signbit(y) != 0;
return (t != t1) ? y : -y;
}
float copysign5(float x, float y)
{
return __builtin_copysignf(x, y);
}
These all should end up being the same code.
Hopefully I didn't mess these up.
[Bug middle-end/109844] New: Unnecessary basic block with single jmp instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109844
Bug ID: 109844
Summary: Unnecessary basic block with single jmp instruction
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
The code
void err(void);
void merge_bb(int y) {
if (y)
return err();
}
is
merge_bb:
testedi, edi
jne .L4
ret
.L4:
jmp err
but could be
merge_bb:
testedi, edi
jne err
ret
https://godbolt.org/z/eafPa4o4T
[Bug target/47253] Conditional jump to tail function is not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47253 Andrew Pinski changed: What|Removed |Added CC||chfast at gmail dot com --- Comment #7 from Andrew Pinski --- *** Bug 109844 has been marked as a duplicate of this bug. ***
[Bug target/109844] Unnecessary basic block with single jmp instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109844 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of much older issue, PR 47253. *** This bug has been marked as a duplicate of bug 47253 ***
[Bug rtl-optimization/49054] useless cmp+jmp generated for switch when "default:" is unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49054 Paweł Bylica changed: What|Removed |Added CC||chfast at gmail dot com --- Comment #7 from Paweł Bylica --- GCC 13 generates optimal decision tree for the mentioned modified case. if id == 3: i() elif id <= 3: if id == 0: f() else: # 1 g() else: if id == 4: j() else: # 23456 h() https://godbolt.org/z/9j6b88qKE So I think this issue is fixed.
[Bug rtl-optimization/109845] New: Addition overflow/carry flag unnecessarily put in a temporary register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109845 Bug ID: 109845 Summary: Addition overflow/carry flag unnecessarily put in a temporary register Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: chfast at gmail dot com Target Milestone: --- When we have an addition and an overflow check and the overflow flag is combined with some other condition the codegen may generate variant when the overflow flag is temporary register. unsigned s = y + z; _Bool ov = s < y; if (x || ov) return; This produces add esi, edx setcal testedi, edi jne .L1 testeax, eax jne .L1 while it could be add esi, edx jc .L6 testedi, edi jne .L6 There are easy workaround to the C code which make the assembly optimal: 1. Change the order of checks if (ov || x) 2. Split if into two if (x) return; if (ov) return; https://godbolt.org/z/rxsrnhPdc
[Bug rtl-optimization/109845] Addition overflow/carry flag unnecessarily put in a temporary register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109845 --- Comment #1 from Andrew Pinski --- Created attachment 55077 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55077&action=edit full testcase Next time please attach the full compilable testcase or paste it inline rather than just including a godbolt link.
[Bug middle-end/109845] Addition overflow/carry flag unnecessarily put in a temporary register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109845 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-05-13 Status|UNCONFIRMED |NEW Severity|normal |enhancement Component|rtl-optimization|middle-end Keywords||missed-optimization Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- So the difference between good1 and bad1 at the gimple level is the order of operands of the bit_ior: good1: ov_8 = _13 != 0; _9 = x_2(D) != 0; _10 = ov_8 | _9; if (_10 != 0) bad1: ov_7 = _13 != 0; _1 = x_8(D) != 0; _2 = _1 | ov_7; if (_2 != 0)
[Bug debug/109805] LTO affecting -fdebug-prefix-map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
--- Comment #9 from Sergio Durigan Junior ---
at(In reply to Richard Biener from comment #8)
> This works for me. The consistency check is not fully implemented and
> instead
> of passing down no -fdebug-prefix-map the patch passes the first but warns:
>
> > ./xgcc -B. t.o t2.o -o t
> lto-wrapper: warning: option
> -fdebug-prefix-map=/home/rguenther/obj-trunk-g/gcc=/bbb with different
> values, using /home/rguenther/obj-trunk-g/gcc=/aaa
>
> to make consistency checking work we need to record -fcanon-prefix-map
> and the full set of -f{file,debug}-prefix-map options in order (I think
> file and debug variants can be considered the same) of the first TU and
> compare that to each of the following TUs.
Thanks a lot for the patch. I tried it locally, and it indeed works for the
simple example I posted in the description of this bug. However, for some
reason it doesn't seem to make a difference for the vim compilation. I'm still
seeing a directory table like the following:
Directory table:
[path(line_strp)]
0 /home/ubuntu/vim/vim-9.0.1378/src/vim-basic (0)
1 /usr/include/x86_64-linux-gnu/bits (57)
2 /usr/include (92)
whereas if I pass -fdebug-prefix-map to LDFLAGS, the directory table becomes:
Directory table:
[path(line_strp)]
0 /usr/src/vim-2:9.0.1378-2ubuntu2~ppa1/src/vim-basic (0)
1 /usr/include/x86_64-linux-gnu/bits (65)
2 /usr/include (100)
which is what I expected to see.
> Note a link-time specified option will simply ignore all options from the
> compile-time (but only for the link-time unit, the compile-time debug info
> has already been generated with the originally specified options).
FWIW, I think this bug is related to #108534 (and the related discussion at
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606205.html).
[Bug libfortran/107068] Run-time error when reading logical arrays with a namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- I will get looking at this since it is namelist related.
[Bug c++/106943] GCC building clang/llvm with LTO flags causes ICE in clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943 Xi Ruoyao changed: What|Removed |Added Resolution|--- |MOVED Status|WAITING |RESOLVED URL||https://github.com/llvm/llv ||m-project/commit/94f7c961c7 ||8d8fdbc05898cfbbf88094de45c ||1ad --- Comment #33 from Xi Ruoyao --- -fno-lifetime-dse has been added into LLVM building system as a workaround.
[Bug fortran/109846] New: [rejects valid] Pointer-valued function reference rejected as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 Bug ID: 109846 Summary: [rejects valid] Pointer-valued function reference rejected as actual argument Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- Gfortran rejects the following example. module foo type :: parameter_list contains procedure :: sublist end type contains function sublist(this) result(slist) class(parameter_list), intent(inout) :: this class(parameter_list), pointer :: slist allocate(slist) end function end module program example use foo type(parameter_list) :: plist call sub(plist%sublist()) contains subroutine sub(plist) type(parameter_list), intent(inout) :: plist end subroutine end program With this error: 17 | call sub(plist%sublist()) | 1 Error: ‘sublist’ in variable definition context (actual argument to INTENT = OUT/INOUT) at (1) is not a variable It is accepted by both Intel OneAPI and NAG compilers. The sublist function returns a polymorphic pointer, which seems to be the source of the error. If it is modified to return a non-polymorphic pointer the example compiles without error. Alternatively, if the dummy argument intent is changed to intent(in) it also compiles without error. It is valid for a class(parameter_list) variable to be the actual argument for a type(parameter_list), intent(inout) dummy argument. So in light of 9.2/C902 (2018) I think this is a gfortran bug.
[Bug analyzer/109847] New: -Wanalyzer-out-of-bounds false positive with Emacs tagged pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109847
Bug ID: 109847
Summary: -Wanalyzer-out-of-bounds false positive with Emacs
tagged pointers
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: eggert at cs dot ucla.edu
Target Milestone: ---
Created attachment 55078
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55078&action=edit
compile with 'gcc -O2 -fanalyzer' to illustrate the false positive
I ran into this problem when compiling GNU Emacs with GCC 13.1.1 20230426 (Red
Hat 13.1.1-1) on x86-64. The attached file contains stripped-down source code
to illustrate the problem. Compile it with:
gcc -O2 -fanalyzer -S analyzer-bounds-bug.i
The output is shown below. This output is incorrect, since it is complaining
about the access to the 'size' member, but that access is never executed as the
previous condition '! (((unsigned) (long) a - 5) & 7)' is false.
If you change line 51 from 'CHECK_STRING (buffer_or_name);' to 'if (0)
CHECK_STRING (buffer_or_name);' the warning goes away. But line 51 is executed
after the line being warned about. It looks like line 51 is confusing the
analyzer into thinking that line 50 can be executed in an impossible way.
As can be seen below, GCC also issues an incorrect
-Wanalyzer-use-of-uninitialized-value diagnostic, but since that may be
cascading from the earlier bug I am not reporting it separately.
In function ‘PSEUDOVECTORP’,
inlined from ‘BUFFERP’ at analyzer-bounds-bug.i:44:10,
inlined from ‘Fget_buffer’ at analyzer-bounds-bug.i:50:9:
analyzer-bounds-bug.i:39:50: warning: stack-based buffer under-read [CWE-127]
[-Wanalyzer-out-of-bounds]
39 | && ((struct buffer *) ((char *) a - 5))->size == code);
| ^~
‘init_buffer’: events 1-2
|
| 56 | init_buffer (void)
| | ^~~
| | |
| | (1) entry to ‘init_buffer’
|..
| 60 | Fget_buffer (scratch);
| | ~
| | |
| | (2) calling ‘Fget_buffer’ from ‘init_buffer’
|
+--> ‘Fget_buffer’: events 3-4
|
| 48 | Fget_buffer (Lisp_Object buffer_or_name)
| | ^~~
| | |
| | (3) entry to ‘Fget_buffer’
| 49 | {
| 50 | if (! BUFFERP (buffer_or_name))
| | ~
| | |
| | (4) inlined call to ‘BUFFERP’ from ‘Fget_buffer’
|
+--> ‘BUFFERP’: event 5
|
| 44 | return PSEUDOVECTORP (a, 13);
| | ^
| | |
| | (5) inlined call to ‘PSEUDOVECTORP’ from
‘BUFFERP’
|
+--> ‘PSEUDOVECTORP’: events 6-8
|
| 38 | return (! (((unsigned) (long) a - 5) & 7)
| | ~~
| 39 | && ((struct buffer *) ((char *) a -
5))->size == code);
| |
^~
| | |
|
| | |
(7) ...to here
| | (6) following ‘true’ branch...
(8) out-of-bounds read at byte -1 but ‘’ starts at byte 0
|
analyzer-bounds-bug.i:39:50: warning: use of uninitialized value ‘((struct
buffer *)((char *)buffer_or_name + 3))[2305843009213693951].size’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
39 | && ((struct buffer *) ((char *) a - 5))->size == code);
| ^~
‘init_buffer’: events 1-3
|
| 56 | init_buffer (void)
| | ^~~
| | |
| | (1) entry to ‘init_buffer’
|..
| 59 | (&(struct Lisp_String) {{{9, "*scratch*"}}}, 4);
| |~
| ||
| |(2) region created on stack here
| 60 | Fget_buffer (scratch);
| | ~
| | |
| | (3) calling ‘Fget_buffer’ from ‘init_buffer’
|
+--> ‘Fget_buffer’: events 4-5
|
| 48 | Fget_buffer (Lisp_Object buffer_or_name)
| | ^~~
| | |
| | (4) entry to ‘Fget_buffer’
| 49 | {
| 50 | if (! BUFFERP (buffer_or_name))
| |
[Bug tree-optimization/109848] New: [14 Regression] Recent change causing testsuite ICE on csky port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109848 Bug ID: 109848 Summary: [14 Regression] Recent change causing testsuite ICE on csky port Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- This patch: commit cc0e22b3f25d4b2a326322bce711179c02377e6c Author: Richard Biener Date: Fri May 12 13:43:27 2023 +0200 tree-optimization/64731 - extend store-from CTOR lowering to TARGET_MEM_REF The following also covers TARGET_MEM_REF when decomposing stores from CTORs to supported elementwise operations. This avoids spilling and cleans up after vector lowering which doesn't touch loads or stores. It also mimics what we already do for loads. PR tree-optimization/64731 * tree-ssa-forwprop.cc (pass_forwprop::execute): Also handle TARGET_MEM_REF destinations of stores from vector CTORs. * gcc.target/i386/pr64731.c: New testcase. Is causing the csky port to abort in forwprop with an verify_ssa failure FAIL: gcc.dg/torture/pr52407.c -O2 (internal compiler error: verify_ssa failed) FAIL: gcc.dg/torture/pr52407.c -O2 (test for excess errors) Excess errors: /home/jlaw/test/gcc/gcc/testsuite/gcc.dg/torture/pr52407.c:22:1: error: definition in block 3 follows the use for SSA_NAME: _38 in statement: _24 = &MEM[(vl_t *)_38]; during GIMPLE pass: forwprop /home/jlaw/test/gcc/gcc/testsuite/gcc.dg/torture/pr52407.c:22:1: internal compiler error: verify_ssa failed 0x11a93bf verify_ssa(bool, bool) /home/jlaw/test/gcc/gcc/tree-ssa.cc:1203 0xe5f8a5 execute_function_todo /home/jlaw/test/gcc/gcc/passes.cc:2105 0xe5e4de do_per_function /home/jlaw/test/gcc/gcc/passes.cc:1694 0xe5fa4e execute_todo /home/jlaw/test/gcc/gcc/passes.cc:2152 Testsuite is gcc.dg/torture/pr52407 can can be seen with just a cross compiler.
[Bug fortran/109846] [rejects valid] Pointer-valued function reference rejected as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Confirmed. Workaround seems to be to not use a RESULT variable. This change seems to work function sublist(this) class(parameter_list), intent(inout) :: this class(parameter_list), pointer :: sublist allocate(sublist) end function
[Bug middle-end/109849] New: suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Bug ID: 109849
Summary: suboptimal code for vector walking loop
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
jan@localhost:/tmp> cat t.C
#include
typedef unsigned int uint32_t;
std::vector> stack;
void
test()
{
while (!stack.empty()) {
std::pair cur = stack.back();
stack.pop_back();
if (cur.second)
break;
}
}
jan@localhost:/tmp> gcc t.C -O3 -S
yields to:
_Z4testv:
.LFB1264:
.cfi_startproc
movqstack(%rip), %rcx
movqstack+8(%rip), %rax
jmp .L5
.p2align 4,,10
.p2align 3
.L6:
movl-4(%rax), %edx
subq$8, %rax
movq%rax, stack+8(%rip)
testl %edx, %edx
jne .L4
.L5:
cmpq%rax, %rcx
jne .L6
.L4:
ret
We really should order the basic blocks putting cmpq before L6 saving a jump.
Moreover clang does
.p2align4, 0x90
.LBB1_1:# =>This Inner Loop Header: Depth=1
cmpq%rax, %rcx
je .LBB1_3
# %bb.2:# in Loop: Header=BB1_1 Depth=1
cmpl$0, -4(%rcx)
leaq-8(%rcx), %rcx
movq%rcx, stack+8(%rip)
je .LBB1_1
.LBB1_3:
retq
saving an instruction. Why we do not move stack+8 updating out of the loop?
[Bug fortran/109846] [rejects valid] Pointer-valued function reference rejected as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 --- Comment #2 from Neil Carlson --- Amusing! I have a regression in 13.1 (which I need to create a reproducer for) where the workaround for a segfault is to use a RESULT variable -- just the opposite :-)
[Bug tree-optimization/109829] Optimizing __builtin_signbit(x) ? -x : x or abs for FP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829 --- Comment #8 from Andrew Pinski --- Created attachment 55079 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55079&action=edit Patch which I am testing
[Bug c++/109850] New: ICE compiling ccache 4.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850
Bug ID: 109850
Summary: ICE compiling ccache 4.8
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: psmith at gnu dot org
Target Milestone: ---
I've started working with GCC 12.3.0 I've built myself and I've gotten an ICE
trying to compile ccache 4.8. The preprocessor output is attached. I'm
building using a sysroot from a Rocky Linux 8.4 x86_64 system with glibc 2.28.
I'm using my own binutils 2.40.
I was able to reduce the command line to just: g++ -o LocalStorage.o -c
LocalStorage.i
I attached the .i file.
Output from my build:
$ /data/src/tooldir/bin/x86_64-tools-linux-gnu-g++ -o LocalStorage.o -c
LocalStorage.i
/data/src/ccache/ccache-4.8/src/storage/local/LocalStorage.cpp: In
instantiation of 'storage::local::LocalStorage::recompress(std::optional, uint32_t, const storage::local::ProgressReceiver&):: [with auto:39 = unsigned char; auto:40 =
std::function]':
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/12.3.0/type_traits:2559:26:
required by substitution of 'template static
std::__result_of_success()((declval<_Args>)()...)),
std::__invoke_other> std::__result_of_other_impl::_S_test(int) [with _Fn =
storage::local::LocalStorage::recompress(std::optional, uint32_t,
const storage::local::ProgressReceiver&)::&; _Args = {unsigned char, const std::function&}]'
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/12.3.0/type_traits:2570:55:
required from 'struct std::__result_of_impl, uint32_t,
const storage::local::ProgressReceiver&)::&, unsigned char, const std::function&>'
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/12.3.0/bits/std_function.h:348:9:
recursively required by substitution of 'template
struct std::__is_invocable_impl<_Result, _Ret, true, std::__void_t > [with _Result =
std::__invoke_result, uint32_t, const storage::local::ProgressReceiver&)::&, unsigned char, const
std::function&>; _Ret = void]'
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/12.3.0/bits/std_function.h:348:9:
required from 'struct std::function&)>::_Callable, uint32_t, const storage::local::ProgressReceiver&)::,
storage::local::LocalStorage::recompress(std::optional, uint32_t,
const storage::local::ProgressReceiver&)::,
std::__invoke_result, uint32_t, const storage::local::ProgressReceiver&)::&, unsigned char, const std::function&>
>'
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/12.3.0/bits/std_function.h:353:8:
required by substitution of 'template
template using _Requires =
std::__enable_if_t<_Cond::value, _Tp> [with _Cond = std::function&)>::_Callable, uint32_t, const storage::local::ProgressReceiver&)::,
storage::local::LocalStorage::recompress(std::optional, uint32_t,
const storage::local::ProgressReceiver&)::,
std::__invoke_result, uint32_t, const storage::local::ProgressReceiver&)::&, unsigned char, const std::function&>
>; _Tp = void; _Res = void; _ArgTypes = {unsigned char, const
std::function&}]'
/data/src/build/x86_64-linux/cc/unknown/x86_64-unknown-linux-gnu/include/c++/12.3.0/bits/std_function.h:434:9:
required by substitution of 'template
std::function&)>::function(_Functor&&) [with _Functor =
storage::local::LocalStorage::recompress(std::optional, uint32_t,
const storage::local::ProgressReceiver&)::; _Constraints = ]'
/data/src/ccache/ccache-4.8/src/storage/local/LocalStorage.cpp:701:24:
required from here
/data/src/ccache/ccache-4.8/src/storage/local/LocalStorage.cpp:710:44: internal
compiler error: Segmentation fault
710 | LOG("Failed to acquire content lock for {}/{}", l1_index,
l2_index);
|^~~
0x7f1399b2c08f ???
/build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x7f1399b0d082 __libc_start_main
../csu/libc-start.c:308
I tried to use -freport-bug but it said "The bug is not reproducible, so it is
likely a hardware or OS problem." But I don't think it's a hardware or OS
problem. It could be related to how I compiled GCC maybe? The crash is
completely repeatable on my system.
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #1 from Andrew Pinski --- Actually why didn't we copy the loop header in the first place?
[Bug c++/109850] ICE compiling ccache 4.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850 Paul Smith changed: What|Removed |Added CC||psmith at gnu dot org --- Comment #1 from Paul Smith --- Created attachment 55080 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55080&action=edit LocalStorage.i compressed
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #2 from Andrew Pinski ---
(In reply to Jan Hubicka from comment #0)
> saving an instruction. Why we do not move stack+8 updating out of the loop?
Maybe because of a clobber:
cur$second_5 = MEM[(const struct pairD.26349 &)_7 +
18446744073709551608].secondD.27577;
# PT = nonlocal escaped
_4 = _7 + 18446744073709551608;
# .MEM_9 = VDEF <.MEM_1>
stackD.26352.D.27437._M_implD.26667.D.26744._M_finishD.26670 = _4;
# .MEM_10 = VDEF <.MEM_9>
MEM[(struct pairD.26349 *)_7 + -8B] ={v} {CLOBBER};
[Bug c++/109850] ICE compiling ccache 4.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850 --- Comment #2 from Paul Smith --- I don't know if this is of any use but I ran under valgrind and get this result: ==3019683== Command: /data/src/build/x86_64-linux/cc/unknown/bin/../libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus -fpreprocessed LocalStorage.i -quiet -dumpbase LocalStorage.i -dumpbase-ext .i -m64 -mtune=generic -march=x86-64 -o /tmp/ccaQvBYi.s ==3019683== ==3019683== Invalid read of size 4 ==3019683==at 0x7B5503: ??? (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x1390609: walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x1390A11: walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x148A6C3: ??? (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x1390609: walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x13906DD: walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x1390730: walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x139096F: walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x1484986: check_for_bare_parameter_packs(tree_node*, unsigned int) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x157004A: finish_expr_stmt(tree_node*) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x1689186: tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683==by 0x1689087: tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) (in /data/src/build/x86_64-linux/cc/unknown/libexec/gcc/x86_64-unknown-linux-gnu/12.3.0/cc1plus) ==3019683== Address 0x5c is not stack'd, malloc'd or (recently) free'd ==3019683==
[Bug c++/109241] [12/13 Regression] ICE Segmentation fault for statement expression with a local type inside inside a generic lambda inside a generic lambda since r13-6722-gb323f52ccf966800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241 Andrew Pinski changed: What|Removed |Added Known to fail||12.3.0, 13.0 Target Milestone|13.0|12.4 Known to work||12.2.0
[Bug c++/109850] ICE compiling ccache 4.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 109241. *** This bug has been marked as a duplicate of bug 109241 ***
[Bug c++/109241] [12/13 Regression] ICE Segmentation fault for statement expression with a local type inside inside a generic lambda inside a generic lambda since r13-6722-gb323f52ccf966800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241 Andrew Pinski changed: What|Removed |Added CC||psmith at gnu dot org --- Comment #7 from Andrew Pinski --- *** Bug 109850 has been marked as a duplicate of this bug. ***
[Bug c++/109850] ICE compiling ccache 4.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109850
--- Comment #4 from Andrew Pinski ---
And yes it is a dup:
void
LocalStorage::recompress
{
[&](const auto& l1_index, const auto& l1_progress_receiver) {
[&](const auto& l2_index, const auto& l2_progress_receiver) {
[] { struct ... FMT_COMPILE_STRING
[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 #4 from Sam James --- (In reply to Eric Gallager from comment #3) > I thought that there was already a separate bug for this, but it turns out > that I was thinking of bug 87379, which is for something different... Good catch. I think that'd actually address some (not all, ofc) of the concerns I have about these.
[Bug c/87379] Warn about function pointer casts which differ in variadic-ness [-Wcast-variadic-function-type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87379 --- Comment #3 from Sam James --- This is a bit of (not entirely, but a lot of) what I was reaching for in PR109835. I knew there was a ppc64 example in my head but I couldn't find it. It's also a good argument for just doing it entirely for func. ptrs (rather than special-casing it more), IMO, given the cases I've listed over there.
[Bug libgcc/109670] [13/14 regression] Exception handling broken for 32-bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109670 --- Comment #15 from Christoph Reiter --- (In reply to Thomas Neumann from comment #12) > Created attachment 55037 [details] > radix sort fix > > I could reproduce the problem, the radix sort did not behave correctly when > we ran out of bits, which can happen on 32bit platforms. The attached patch > fixes the problem. I can confirm that this fixes the issue for me.
[Bug analyzer/109851] New: False positive va_arg when iterating through format string with for-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109851
Bug ID: 109851
Summary: False positive va_arg when iterating through format
string with for-loop
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: nvinson234+gcc-bugs at gmail dot com
Target Milestone: ---
Created attachment 55081
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55081&action=edit
analzyer warning output
When compiling the following code:
#include
#include
#include
void foo(char *fmt, ...) {
int i = 0;
char c;
va_list ap;
va_start(ap, fmt);
for (i = 0; (c = fmt[i]) != 0; i++) {
c = fmt[i];
if (c == '%') {
printf("Saw %%");
}
if (c == 'd') {
i = va_arg(ap, int);
}
}
va_end(ap);
}
int main(int argc, char **argv) {
foo("%s.lt", argv[0]);
return 0;
}
with the command: gcc -O2 -fanalyzer test.c
The analyzer gives the warning:
test.c:17:15: warning: ‘va_arg’ expected ‘int’ but received ‘char *’ for
variadic argument 1 of ‘ap’
However, the condition "c == 'd'" is never true and va_arg() is never called.
This is a reduced case based on the lemon_vsnprintf() code found in
sqlite-3.41.2'a tool/lemon.c.
Full warning output attached.
[Bug libfortran/107068] Run-time error when reading logical arrays with a namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068 --- Comment #6 from Jerry DeLisle --- What is happening here is that in the name list input, the variable flp is also a legal LOGICAL value, so our read is interpreting it as the second value of the array flc and trying to continue to read values for flc. It encounters the ( and throws the error. To resolve this, I think I will have to check for a valid variable name for each value. [aside: A lot of these issues stem from the weaknesses in how namelists are interpreted. There are ambiguities in the specification.] My next step here is to go through the F2018 standard just to make sure what we do is valid or invalid. (cheers)
[Bug libfortran/107068] Run-time error when reading logical arrays with a namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068 --- Comment #7 from Jerry DeLisle --- In list_read.c we have this comment: /* To read a logical we have to look ahead in the input stream to make sure there is not an equal sign indicating a variable name. To do this we use line_buffer to point to a temporary buffer, pushing characters there for possible later reading. */ I remember creating this line_buffer for the purpose. Now to figure out why it is not working. This was quite a while ago!
[Bug tree-optimization/109829] Optimizing __builtin_signbit(x) ? -x : x or abs for FP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109829 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-May/618 ||435.html --- Comment #9 from Andrew Pinski --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618435.html
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #3 from Alexander Monakov --- Rather, because store-motion out of a loop that might iterate zero times would create a data race.
