[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #20 from Xi Ruoyao --- >From Mayshao (Zhaoxin engineer): "On Zhaoxin CPUs with AVX, the VMOVDQA instruction is atomic if the accessed memory is Write Back, but it's not guaranteed for other memory types." Is it allowed to use VMOVDQA then?
[Bug lto/107829] Trivial compile time tracking code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107829 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Version|unknown |13.0 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-11-23 Target Milestone|--- |13.0 --- Comment #1 from Martin Liška --- Sure, it's bad, lemme send a patch for it.
[Bug lto/107829] Trivial compile time tracking code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107829 Martin Liška changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Liška --- Patch candidate: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607100.html
[Bug tree-optimization/107828] tree-inlining would generate SSA with incorrect def stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107828 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-11-23 CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- @Honza?
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #21 from Jakub Jelinek --- What about loads? That is even more important than the stores. While atomic store can be worst case done through cmpxchg16b, even when it is slower, we can't use cmpxchg16b on atomic load because we don't know if the memory isn't read-only. As for the Write Back only vs. other types, doesn't that match the " for cacheable" in the AMD statement?
[Bug tree-optimization/107823] [13 Regression] Dead Code Elimination Regression at -Os (trunk vs. 12.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107823 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-11-23 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug tree-optimization/107826] ice during GIMPLE pass: slp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107826 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Martin Liška --- Yep, fixed with r13-4226-g1a06ae6f2f4f292f.
[Bug libstdc++/107814] [13 regression] experimental/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107814 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Jonathan Wakely --- > Are you sure this is a regression? Isn't it the same case as PR104731, but > that > was only fixed for 27_io/filesystem/iterators/error_reporting.cc and not > experimental/filesystem/iterators/error_reporting.cc ? I'd only checked the sparc and x86 results for the current gcc-12 branch where the test PASSes on both. However, the fact that the test on trunk FAILs on x86, but PASSes on sparc seems to show that the results are pretty unreliable. So yea, very much looks like PR104731.
[Bug libstdc++/107814] [13 regression] experimental/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107814 --- Comment #4 from Jonathan Wakely --- I think I'll push the patch in comment 2 and we can see if it helps :-)
[Bug libstdc++/107814] [13 regression] experimental/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107814 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Jonathan Wakely --- > I think I'll push the patch in comment 2 and we can see if it helps :-) I've just tried it on sparc and x86, 32 and 64-bit: the test PASSes everywhere now. Thanks a lot.
[Bug c/107831] New: Missed optimization: -fclash-stack-protection causes unnecessary code generation for dynamic stack allocations that are clearly less than a page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831 Bug ID: 107831 Summary: Missed optimization: -fclash-stack-protection causes unnecessary code generation for dynamic stack allocations that are clearly less than a page Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pskocik at gmail dot com Target Milestone: --- I'm talking allocations such as char buf [ (uint8_t)size ]; The resulting code for this should ideally be the same with or without -fstack-clash-protection as this can clearly never skip a whole page. But gcc generates a big loop trying to touch every page-sized subpart of that allocation. https://godbolt.org/z/G8EbzbshK
[Bug libstdc++/107814] [13 regression] experimental/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107814 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Jonathan Wakely --- > I'm unable to access the Solaris/x86 host in the compile farm (gcc210) so I > can't test if this fixes it. It passes on Solaris/sparc. According to https://cfarm.tetaneutral.net/machines/list/, gcc210 is a Solaris 10/SPARC system, so useless for trunk testing. AFAIK we still don't have a Solaris 11/x86 system in the cfarm, which is a shame. I tried to provide one myself, but failed for various administrative reasons ;-(
[Bug target/107830] [13 Regression] ICE in gen_aarch64_bitmask_udiv3, at ./insn-opinit.h:813
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107830 Martin Liška changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-11-23 --- Comment #1 from Martin Liška --- Likely started with r13-4028-gd758d1908899cf.
[Bug libstdc++/107814] [13 regression] experimental/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107814 --- Comment #7 from Jonathan Wakely --- (In reply to r...@cebitec.uni-bielefeld.de from comment #6) > According to https://cfarm.tetaneutral.net/machines/list/, gcc210 is a > Solaris 10/SPARC system, so useless for trunk testing. Oh right, yes. For some reason I misremembered that gcc210 was Solaris 11 x86 and gcc211 was Solaris 11 sparc, but of course gcc210 is 10 and gcc211 is 11 ... that should be easy to remember!
[Bug libstdc++/104731] 27_io/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104731 --- Comment #13 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1cac00d013856fea4cee0f13c4959c8e21afd2d9 commit r13-4262-g1cac00d013856fea4cee0f13c4959c8e21afd2d9 Author: Jonathan Wakely Date: Tue Nov 22 19:15:53 2022 + libstdc++: Fix unsafe use of dirent::d_name [PR107814] Copy the fix for PR 104731 to the equivalent experimental::filesystem test. libstdc++-v3/ChangeLog: PR libstdc++/107814 * testsuite/experimental/filesystem/iterators/error_reporting.cc: Use a static buffer with space after it.
[Bug libstdc++/107814] [13 regression] experimental/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107814 --- Comment #8 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1cac00d013856fea4cee0f13c4959c8e21afd2d9 commit r13-4262-g1cac00d013856fea4cee0f13c4959c8e21afd2d9 Author: Jonathan Wakely Date: Tue Nov 22 19:15:53 2022 + libstdc++: Fix unsafe use of dirent::d_name [PR107814] Copy the fix for PR 104731 to the equivalent experimental::filesystem test. libstdc++-v3/ChangeLog: PR libstdc++/107814 * testsuite/experimental/filesystem/iterators/error_reporting.cc: Use a static buffer with space after it.
[Bug libstdc++/107814] [13 regression] experimental/filesystem/iterators/error_reporting.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107814 Jonathan Wakely changed: What|Removed |Added Target Milestone|13.0|10.5 --- Comment #9 from Jonathan Wakely --- Thanks for testing the patch. It's pushed to trunk now. I'll backport it as well, because causing a buffer overflow in those filesystem calls isn't a good idea.
[Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD CPUs with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #22 from Xi Ruoyao --- (In reply to Jakub Jelinek from comment #21) > What about loads? That is even more important than the stores. While > atomic store can be worst case done through cmpxchg16b, even when it is > slower, we can't use cmpxchg16b on atomic load because we don't know if the > memory isn't read-only. Loads are also atomic for WB. > As for the Write Back only vs. other types, doesn't that match the > " for cacheable" in the AMD statement? If I read the manual correctly, Write Back, Write Through, and Write Protected are all "cacheable". Mayshao told me VMOVDQA is atomic for WB, but not atomic for UC and WC (they are not cacheable so I think we don't need to take care). So how about WT and WP?
[Bug target/107830] [13 Regression] ICE in gen_aarch64_bitmask_udiv3, at ./insn-opinit.h:813
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107830 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- I think it's more likely Tamar's recent patches for that optab
[Bug target/107830] [13 Regression] ICE in gen_aarch64_bitmask_udiv3, at ./insn-opinit.h:813
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107830 Tamar Christina changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Tamar Christina --- hmm Indeed, it seems it crashes at -Os. Will take a look.
[Bug libstdc++/107811] libstdc++-v3/src/c++17/floating_from_chars.cc:787:9: error: 'fast_float' has not been declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107811 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e6a32c12b4ef87c084d29863c79503344126d101 commit r13-4263-ge6a32c12b4ef87c084d29863c79503344126d101 Author: Jakub Jelinek Date: Wed Nov 23 11:53:54 2022 +0100 libstdc++: Fix libstdc++ build on some targets [PR107811] fast_float library relies on size_t being 32-bit or larger and float/double being IEEE single/double. Otherwise we only use strtod/strtof. In 3 spots I've used fast_float namespace stuff unconditionally in one function, which breaks the build if fast_float is disabled. 2022-11-23 Jakub Jelinek PR libstdc++/107811 * src/c++17/floating_from_chars.cc (__floating_from_chars_hex): Guard fast_float uses with #if USE_LIB_FAST_FLOAT and for mantissa_bits and exponent_bits provide a fallback.
[Bug libstdc++/107811] libstdc++-v3/src/c++17/floating_from_chars.cc:787:9: error: 'fast_float' has not been declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107811 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed then.
[Bug debug/107832] New: '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 -fno-gcse-lm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107832 Bug ID: 107832 Summary: '-fcompare-debug' failure w/ -O2 -ftree-parallelize-loops=2 -fno-gcse-lm Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: compare-debug-failure Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: aarch64-linux-gnu Created attachment 53951 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53951&action=edit Testcase gcc 13.0.0 20221120 snapshot (g:a16a5460447eaaff0b4468064e4d7b1cc8fc42eb) fails -fcompare-debug when compiling the attached testcase w/ -O2 -ftree-parallelize-loops=2 -fno-gcse-lm: % aarch64-linux-gnu-gfortran-13 -O2 -fcompare-debug -ftree-parallelize-loops=2 -fno-gcse-lm -c ebqijrx1.f90 aarch64-linux-gnu-gfortran-13: error: ebqijrx1.f90: '-fcompare-debug' failure --- ebqijrx1.f90.gkd2022-11-23 18:26:10.937790540 +0700 +++ ebqijrx1.gk.f90.gkd 2022-11-23 18:26:10.986790649 +0700 @@ -,7 +,7 @@ 4: integer(kind=8) D.; 5: integer(kind=8) D.; -;; Function main._loopfn.0 (main._loopfn.0, funcdef_no=6, cgraph_uid=13, symbol_order=19) +;; Function main._loopfn.0 (main._loopfn.0, funcdef_no=6, cgraph_uid=13, symbol_order=20) (note # 0 0 NOTE_INSN_DELETED) (note # 0 0 [bb 2] NOTE_INSN_BASIC_BLOCK)
[Bug c++/107558] [10/11/12/13 Regression] ICE in fld_incomplete_type_of with -fmerge-all-constants and openmp and LTO since r11-16-ga2f32550a085984f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107558
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
The reason is that omp-low.cc creates a pointer to reference type, because an
automatic variable with REFERENCE_TYPE is not TREE_READONLY.
While we perhaps could tweak all spots in omp-low.cc that reference
TREE_READONLY to check also for REFERENCE_TYPE, I think the reason mentioned in
r11-16-ga2f32550a085984f is never the case for non-aggregate types.
So perhaps instead:
--- gcc/cp/decl.cc.jj 2022-11-19 09:21:14.662439877 +0100
+++ gcc/cp/decl.cc 2022-11-23 13:12:31.866553152 +0100
@@ -8679,8 +8679,10 @@ cp_finish_decl (tree decl, tree init, bo
if (var_definition_p
/* With -fmerge-all-constants, gimplify_init_constructor
-might add TREE_STATIC to the variable. */
- && (TREE_STATIC (decl) || flag_merge_constants >= 2))
+might add TREE_STATIC to aggregate variables. */
+ && (TREE_STATIC (decl)
+ || (flag_merge_constants >= 2
+ && AGGREGATE_TYPE_P (type
{
/* If a TREE_READONLY variable needs initialization
at runtime, it is no longer readonly and we need to
?
[Bug c/107831] Missed optimization: -fclash-stack-protection causes unnecessary code generation for dynamic stack allocations that are clearly less than a page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831 --- Comment #1 from Petr Skocik --- Sidenote regarding the stack-allocating code for cases when the size is not known to be less than pagesize: the code generated for those cases is quite large. It could be replaced (at least under -Os) with a call to a special assembly function that'd pop the return address (assuming the target machine pushes return addresses to the stack), allocate adjust and allocate the stack size in a piecemeal fashion so as to not skip guard pages, the repush the return address and return to caller with the stacksize expanded.
[Bug fortran/107317] [10/11/12/13 Regression] ICE in emit_redzone_byte, at asan.cc:1508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107317 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Priority|P3 |P4 Keywords||error-recovery
[Bug tree-optimization/107833] New: wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
Bug ID: 107833
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/Tc8vbearG
It appears to be a regression from 11.3.
[561] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221123 (experimental) [master r13-4262-g1cac00d0138] (GCC)
[562] %
[562] % gcctk -O1 small.c; ./a.out
[563] %
[563] % gcctk -Os small.c
[564] % ./a.out
Segmentation fault
[565] %
[565] % cat small.c
int printf(const char *, ...);
int a, b[1] = {0}, c, *d = b, e, *f, g;
int main() {
int h = 0;
for (; a < 2; a++) {
int i;
for (g = 0; g < 2; g++)
if (a < h) {
e = i % 2;
c = *f;
}
for (h = 0; h < 3; h++) {
if (d)
break;
i--;
printf("0");
}
}
return 0;
}
[Bug c++/107329] [13 Regression] ICE in gimplify_expr, at gimplify.cc:17118 since r13-2978-g43faf3e5445b5717
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107329 --- Comment #1 from Martin Liška --- @Jason: May I ping this please?
[Bug fortran/107317] [10/11/12/13 Regression] ICE in emit_redzone_byte, at asan.cc:1508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107317
--- Comment #4 from Jakub Jelinek ---
Corresponding C testcase:
-m32 -O2 -fsanitize=address
void bar (float *, float *);
void
foo (void)
{
float a[4];
float b[2];
bar (a, b);
}
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Jakub Jelinek --- >> The line before the assertion failure is >> >> 1.18973e+4932 1e+4932 >> /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/ >> float128_c++23.cc:66: void test(std::chars_format): Assertion 'ec2 == >> std::errc() && ptr2 - str2 == ptr1 - str1' failed. >> >> i.e. LDBL_MAX. One thing that is also weird is that gdb prints u as infinity here, but that may well a gdb quirk. (gdb) p/x u $2 = 0x7ffe (gdb) ptype u type = _Float128 > This is weird. If line 66 is reached, fmt must be std::chars_format::fixed > and in that case ptr1 - str1 should be 4933 and str1 should be that many chars > long string starting with > 11897314953572317650857593266280070161964690526416940455296988842121635797553123923249740128484620735259020335647491268597552654335738044626726987519452614908534619587250212628458657994054044935746815 > If you get just 1e+4932 when asked for fixed format, something is just wrong, > that is scientific or general format. I found that sprintf_ld returns 7 for the value above. It is called with Thread 2 hit Breakpoint 1, 0xff0efd9c in std::(anonymous namespace)::sprintf_ld (value=infinity, format_string=0xfefcec38 "%.0Lf", length=4934, buffer=0xffbfe8c8 "\177\376", '\377' ) at /vol/gcc/src/hg/master/local/libstdc++-v3/src/c++17/floating_to_chars.cc:1052 and a simple sprintf (buf, "%.0Lf", (long double) LDBL_MAX); indeed returns 7.
[Bug tree-optimization/107833] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-11-23 Target Milestone|--- |12.3 Summary|wrong code at -Os and above |wrong code at -Os and above |on x86_64-linux-gnu |on x86_64-linux-gnu since ||r12-5138-ge82c382971664d6f CC||aldyh at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Keywords||wrong-code Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r12-5138-ge82c382971664d6f.
[Bug c++/107834] New: #pragma GCC diagnostic ignored "-Wno-psabi" doe not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107834 Bug ID: 107834 Summary: #pragma GCC diagnostic ignored "-Wno-psabi" doe not work Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: shihyente at hotmail dot com Target Milestone: --- Code: #pragma GCC diagnostic ignored "-Wno-psabi" Output: warning: unknown option after '#pragma GCC diagnostic' kind [-Wpragmas] 1 | #pragma GCC diagnostic ignored "-Wno-psabi" Thanks.
[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304
Rainer Orth changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #29 from Rainer Orth ---
(In reply to Alexandre Oliva from comment #28)
> Thanks for the fix. I'm missing something like this (untested) for
> x86_64-elf:
>
> diff --git a/gcc/testsuite/gcc.target/i386/pr107304.c
> b/gcc/testsuite/gcc.target/i386/pr107304.c
> index 24d68795e7f1c..0043b7b21a32f 100644
> --- a/gcc/testsuite/gcc.target/i386/pr107304.c
> +++ b/gcc/testsuite/gcc.target/i386/pr107304.c
> @@ -1,5 +1,6 @@
> /* { dg-do compile } */
> /* { dg-options "-O0 -march=tigerlake" } */
> +/* { dg-require-ifunc "" } */
>
> #include
I'm seeing the same on Solaris/x86. Tested both there and on Linux/x86_64.
Ok for trunk, thanks.
[Bug c++/107834] #pragma GCC diagnostic ignored "-Wno-psabi" doe not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107834 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- That is because you should be using #pragma GCC diagnostic ignored "-Wpsabi" instead.
[Bug bootstrap/107722] [13 Regression] Bootstrap failure for some locales starting with r13-4070
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107722 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #5 from Lewis Hyatt --- Thanks for the fix, and sorry for missing this case.
[Bug modula2/107233] gm2 build hardcodes python3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107233 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Gaius Mulley --- > ok, thanks for the suggestion. I've changed gcc/configure.ac to use > AM_PATH_PYTHON and AM_CONDITIONAL: > > # Python3? > AM_PATH_PYTHON(,, [:]) > AM_CONDITIONAL([HAVE_PYTHON], [test "$PYTHON" != :]) But wouldn't this pick up a version of python < 3.0 if nothing else is present? If the python code inside gcc/m2 does require 3.x, shouldn't this be AM_PATH_PYTHON([3.0],, [:]) (or whatever is the minimum) instead?
[Bug bootstrap/107722] [13 Regression] Bootstrap failure for some locales starting with r13-4070
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107722
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d601708870ad8dc3ef935e440bf03394891d42e2
commit r13-4265-gd601708870ad8dc3ef935e440bf03394891d42e2
Author: Jakub Jelinek
Date: Wed Nov 23 14:43:48 2022 +0100
diagnostics: Fix selftest ICE in certain locales [PR107722]
As reported in the PR, since special_fname_builtin () call has been
introduced, the diagnostics code compares filename against _("")
rather than "", which means that if self tests are performed
with the string being translated, one self-test fails.
The following patch fixes that.
2022-11-23 Jakub Jelinek
PR bootstrap/107722
* diagnostic.cc (test_diagnostic_get_location_text): Test
special_fname_builtin () rather than "" and expect
special_fname_builtin () concatenated with ":" for it.
[Bug bootstrap/107722] [13 Regression] Bootstrap failure for some locales starting with r13-4070
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107722 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/107835] New: [13 Regression] ICE in build2, at tree.cc:5020 since r13-254-gdd3c7873a61019e9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107835
Bug ID: 107835
Summary: [13 Regression] ICE in build2, at tree.cc:5020 since
r13-254-gdd3c7873a61019e9
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: sayle at gcc dot gnu.org
Target Milestone: ---
The following crashes:
$ cat test-loop2.ii
template struct __new_allocator;
template struct allocator_traits;
template struct allocator_traits<__new_allocator<_Tp>> {
using pointer = _Tp *;
};
struct __alloc_traits : allocator_traits<__new_allocator> {};
template
_ForwardIterator __uninitialized_default_n_a(_ForwardIterator __first, _Size,
_Tp) {
unsigned __n;
for (; __n; --__n, ++__first)
;
return __first;
}
struct _Vector_impl_data {
__alloc_traits::pointer _M_finish;
_Vector_impl_data() : _M_finish() {}
};
struct _Vector_base {
~_Vector_base();
_Vector_impl_data _M_impl;
} resize___new_size;
struct Trans_NS_std_vector : _Vector_base {
void resize() {
_M_impl._M_finish =
__uninitialized_default_n_a(_M_impl._M_finish, resize___new_size, 0);
}
};
template using vector = Trans_NS_std_vector;
struct Platform {
static void get(vector *platforms) { platforms->resize(); }
};
main() {
vector platformList;
Platform::get(&platformList);
}
$ g++ test-loop2.ii -O2 -fwhole-program -c -w
during GIMPLE pass: sccp
test-loop2.ii: In function ‘int main()’:
test-loop2.ii:33:1: internal compiler error: in build2, at tree.cc:5008
33 | main() {
| ^~~~
0x86bfa2 build2(tree_code, tree_node*, tree_node*, tree_node*)
/home/marxin/Programming/gcc/gcc/tree.cc:5008
0xe0528f build2_loc
/home/marxin/Programming/gcc/gcc/tree.h:4606
0xe0528f fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/marxin/Programming/gcc/gcc/fold-const.cc:13820
0xe0526a fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/marxin/Programming/gcc/gcc/fold-const.cc:13818
0x1fe6a65 chrec_apply(unsigned int, tree_node*, tree_node*)
/home/marxin/Programming/gcc/gcc/tree-chrec.cc:632
0x1252b8b compute_overall_effect_of_inner_loop(loop*, tree_node*)
/home/marxin/Programming/gcc/gcc/tree-scalar-evolution.cc:471
0x1256635 final_value_replacement_loop(loop*)
/home/marxin/Programming/gcc/gcc/tree-scalar-evolution.cc:3759
0x1305915 execute
/home/marxin/Programming/gcc/gcc/tree-ssa-loop.cc:411
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/107835] [13 Regression] ICE in build2, at tree.cc:5020 since r13-254-gdd3c7873a61019e9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107835 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-11-23 Ever confirmed|0 |1 Target Milestone|--- |13.0 Status|UNCONFIRMED |NEW
[Bug tree-optimization/107833] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #2 from Aldy Hernandez ---
(In reply to Zhendong Su from comment #0)
> Compiler Explorer: https://godbolt.org/z/Tc8vbearG
>
> It appears to be a regression from 11.3.
>
> [561] % gcctk -v
> Using built-in specs.
> COLLECT_GCC=gcctk
> COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/
> x86_64-pc-linux-gnu/13.0.0/lto-wrapper
> Target: x86_64-pc-linux-gnu
> Configured with: ../gcc-trunk/configure --disable-bootstrap
> --enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
> --enable-sanitizers --enable-languages=c,c++ --disable-werror
> --enable-multilib --with-system-zlib
> Thread model: posix
> Supported LTO compression algorithms: zlib
> gcc version 13.0.0 20221123 (experimental) [master r13-4262-g1cac00d0138]
> (GCC)
> [562] %
> [562] % gcctk -O1 small.c; ./a.out
> [563] %
> [563] % gcctk -Os small.c
> [564] % ./a.out
> Segmentation fault
> [565] %
> [565] % cat small.c
> int printf(const char *, ...);
> int a, b[1] = {0}, c, *d = b, e, *f, g;
> int main() {
> int h = 0;
> for (; a < 2; a++) {
> int i;
> for (g = 0; g < 2; g++)
> if (a < h) {
> e = i % 2;
Isn't there an uninitialized read from "i" here? At least on the second time
through the outer loop, if (a < h) is true since 1 < 0.
> c = *f;
> }
> for (h = 0; h < 3; h++) {
> if (d)
> break;
d is nonzero so h will always be 0 in this function.
> i--;
> printf("0");
> }
> }
> return 0;
> }
Unless I'm missing something
[Bug tree-optimization/107833] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #3 from Martin Liška ---
> Isn't there an uninitialized read from "i" here?
Yes ...
> At least on the second
> time through the outer loop, if (a < h) is true since 1 < 0.
>
> > c = *f;
> > }
> > for (h = 0; h < 3; h++) {
> > if (d)
> > break;
>
> d is nonzero so h will always be 0 in this function.
... but as you correctly said, it's never executed as 'a < h' is always false.
>
> > i--;
> > printf("0");
> > }
> > }
> > return 0;
> > }
>
> Unless I'm missing something
[Bug c++/107834] #pragma GCC diagnostic ignored "-Wno-psabi" doe not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107834 SHIH YEN-TE changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from SHIH YEN-TE --- Oops! Sorry, my bad!
[Bug modula2/105392] SEGV compiling gm2-libs-pim/BitBlockOps.mod on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105392 --- Comment #3 from Gaius Mulley --- Many thanks! I've changed all definition modules in gcc/m2/gm2-gcc for consistency.
[Bug c/107836] New: x86_64 inline functions -O2/-O3 optimization error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107836
Bug ID: 107836
Summary: x86_64 inline functions -O2/-O3 optimization error
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: czx211355007 at gmail dot com
Target Milestone: ---
Target: x86_64-linux-gnu
Created attachment 53952
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53952&action=edit
full assembly for function "matrix_mul"
When compiling the following two functions with -O2 or -O3 options, the
assembly code generated is wrong.
int dot_product(short* a, short* b, int len){
int result;
asm("pandn %%mm5,%%mm5;"::);
for(int i=0; i < len; i += 4){
asm(
"movq %0,%%mm0;"
"movq %1,%%mm1;"
"pmaddwd %%mm1,%%mm0;"
"paddd %%mm0,%%mm5;"
:
: "m" (a[i]), "m" (b[i])
);
}
asm("movq %%mm5, %%mm0;"
"psrlq $32,%%mm5;"
"paddd %%mm0, %%mm5;"
"movd %%mm5,%0;"
"emms"
:"=r" (result)
:);
return result;
}
}
void matrix_mul(int d, short a[d][d], short b[d][d], int c[d][d]){
for(int i=0;i
[Bug tree-optimization/107833] wrong code at -Os and above on x86_64-linux-gnu since r12-5138-ge82c382971664d6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107833
--- Comment #4 from Aldy Hernandez ---
(In reply to Martin Liška from comment #3)
> > Isn't there an uninitialized read from "i" here?
>
> Yes ...
>
> > At least on the second
> > time through the outer loop, if (a < h) is true since 1 < 0.
> >
> > > c = *f;
> > > }
> > > for (h = 0; h < 3; h++) {
> > > if (d)
> > > break;
> >
> > d is nonzero so h will always be 0 in this function.
>
> ... but as you correctly said, it's never executed as 'a < h' is always
> false.
Huh... me thinking 1 < 0 is true is a clear sign I need to go on vacation.
/me hides in shame
[Bug c/107836] x86_64 inline functions -O2/-O3 optimization error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107836 Andrew Pinski changed: What|Removed |Added Keywords||inline-asm --- Comment #1 from Andrew Pinski --- Your inline-asm is missing some clubbers and I don't think you use inline-asm this way where you keep around a value inside mm5 since the compiler does not know you did that.
[Bug modula2/105392] SEGV compiling gm2-libs-pim/BitBlockOps.mod on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105392 Gaius Mulley changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Gaius Mulley --- seen it build and regression tests run - so closing this PR.
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
Jakub Jelinek changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org,
||redi at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
You're right.
This is the:
else if (fmt == chars_format::fixed && fd.exponent >= 0)
{
// The Ryu exponent is positive, and so this number's shortest
// representation is a whole number, to be formatted in fixed instead
// of scientific notation "as if by std::printf". This means we may
// need to print more digits of the IEEE mantissa than what the
// shortest scientific form given by Ryu provides.
//
// For instance, the exactly representable number
// 12301048576.0 has as its shortest scientific
// representation 123e+22, so in this case fd.mantissa is 123 and
// fd.exponent is 22, which doesn't have enough information to format
// the number exactly. So we defer to Ryu's d2fixed_buffered_n with
// precision=0 to format the number in the general case here.
case for which ryu doesn't handle d2fixed_buffered_n for wider than double and
so use
const int output_length = sprintf_ld(buffer,
expected_output_length + 1,
"%.0Lf", value);
and Solaris apparently violates ISO C99 in producing for the last 3 printf
calls scientifix values rather than fixed:
#include
int
main ()
{
printf ("%.0f\n", __DBL_MAX__);
printf ("%.0Lf\n", (long double) __DBL_MAX__);
printf ("%.0Lf\n", 2.0L * __DBL_MAX__);
printf ("%.0Lf\n", 1e+202L * __DBL_MAX__);
printf ("%.0Lf\n", 1e+203L * __DBL_MAX__);
printf ("%.0Lf\n", (long double) __DBL_MAX__ * (long double) __DBL_MAX__);
printf ("%.0Lf\n", __LDBL_MAX__);
}
The 1e+202L * __DBL_MAX__ number is:
1797693134862315708145274237317043363780293901488132670510305396153274401107450252964067353821542098883610426262810674725334159395885309388675990127492090757713383689567223448511120723139743573688679064280172265585993927318314820133831157520860190820700571151387146478495139447053313076754655788391539857757373041885363113533243178943928496535556954517148959372706003524689906194839868952331046086040494963209033312113173876118835007579814542996644987978064090838995977878567921521624960885877081515358704107520
which is 511 bytes long excluding '\0' terminator, so bet they have somewhere
fixed length temporary buffer or what.
Jonathan, shall we just #ifdef out the
std::numeric_limits::max()
test in that test for Solaris and maybe HP-UX if it suffers from the same bug?
[Bug tree-optimization/107837] New: Missed optimization: Using memcpy to load a struct unnecessary uses stack space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107837
Bug ID: 107837
Summary: Missed optimization: Using memcpy to load a struct
unnecessary uses stack space
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: chfast at gmail dot com
Target Milestone: ---
I have a simple struct with array uint64_t[4]. When using memcpy() load it from
a storage of bytes and then performing some additional operations, a temporary
object on the stack is created.
struct uint256
{
unsigned long v[4];
};
void load_bad(uint256* o, const char* src) noexcept
{
uint256 x;
__builtin_memcpy(&x, src, sizeof(x));
uint256 y;
y.v[0] = __builtin_bswap64(x.v[3]);
y.v[1] = __builtin_bswap64(x.v[2]);
y.v[2] = __builtin_bswap64(x.v[1]);
y.v[3] = __builtin_bswap64(x.v[0]);
*o = y;
}
load_bad(uint256*, char const*):
movdqu xmm0, XMMWORD PTR [rsi]
movdqu xmm1, XMMWORD PTR [rsi+16]
movaps XMMWORD PTR [rsp-40], xmm0
mov rdx, QWORD PTR [rsp-32]
mov rax, QWORD PTR [rsp-40]
movaps XMMWORD PTR [rsp-24], xmm1
mov rsi, QWORD PTR [rsp-16]
mov rcx, QWORD PTR [rsp-24]
bswap rdx
bswap rax
mov QWORD PTR [rdi+16], rdx
bswap rsi
bswap rcx
mov QWORD PTR [rdi], rsi
mov QWORD PTR [rdi+8], rcx
mov QWORD PTR [rdi+24], rax
ret
The workaround is to use reinterpret_cast.
https://godbolt.org/z/WevYch8nv
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #6 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #5) > Jonathan, shall we just #ifdef out the > std::numeric_limits::max() > test in that test for Solaris and maybe HP-UX if it suffers from the same > bug? Yes, I don't see any point trying to fix the output here. Let's just skip those tests that are known to fail (with a comment mentioning this PR).
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #7 from Jakub Jelinek ---
Ah, we even have PR98384 for that.
So either we add
// { dg-xfail-run-if "Non-conforming printf (see PR98384)" { *-*-solaris*
*-*-darwin* } }
to the test and thus xfail it all, or just ifdef out the max case if everything
else is fine.
Would that be
+// Solaris and Darwin have non-conforming printf, see PR98384 and PR107815.
+#if !(defined(__sun__) && defined(__svr4__)) && !defined(__MACH__)
std::numeric_limits::max()
+#endif
?
[Bug c/107836] x86_64 inline functions -O2/-O3 optimization error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107836 Andreas Schwab changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andreas Schwab --- There is no dependency whatsoever between the asm statements, thus they can be moved around freely. Especially the third one is producing a constant output as seen by the compiler, thus moving it to the top of the function is perfectly valid.
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Jakub Jelinek --- > The 1e+202L * __DBL_MAX__ number is: > 1797693134862315708145274237317043363780293901488132670510305396153274401107450252964067353821542098883610426262810674725334159395885309388675990127492090757713383689567223448511120723139743573688679064280172265585993927318314820133831157520860190820700571151387146478495139447053313076754655788391539857757373041885363113533243178943928496535556954517148959372706003524689906194839868952331046086040494963209033312113173876118835007579814542996644987978064090838995977878567921521624960885877081515358704107520 > which is 511 bytes long excluding '\0' terminator, so bet they have somewhere > fixed length temporary buffer or what. It certainly seems so: the libc conversion functions use a buffer of length DECIMAL_STRING_LENGTH, which is defined as /* * Definitions for base conversion. */ #define DECIMAL_STRING_LENGTH 512 /* Size of buffer in decimal_record. */ in . I'll file a bug about this.
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #9 from Jakub Jelinek --- Created attachment 53953 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53953&action=edit gcc13-pr107815.patch Untested workaround. I've left out Darwin there for now, because I think it just doesn't support _Float128 right now - powerpc*-darwin* has long double in IBM double double format, x86_64-darwin* has long double probably Intel extended format and aarch64*-darwin*, which probably doesn't have support in GCC yet at all, I think has long double in IEEE double format. And _Float128 in libstdc++ is supported only if long double is IEEE quad or of libc provides *f128 APIs (currently only glibc 2.26 does).
[Bug tree-optimization/107838] New: spurious "may be used uninitialized" warning on variable initialized at the first iteration of a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107838
Bug ID: 107838
Summary: spurious "may be used uninitialized" warning on
variable initialized at the first iteration of a loop
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider
int f(void);
void g(int *t)
{
int i, v;
for (i = 0; i < 9; i++)
{
if (i == 0)
v = f();
if (v + t[i])
f();
}
}
$ gcc-test -O -Wmaybe-uninitialized -c tst3.c
tst3.c: In function ‘g’:
tst3.c:9:13: warning: ‘v’ may be used uninitialized [-Wmaybe-uninitialized]
9 | if (v + t[i])
| ~~^~
tst3.c:4:10: note: ‘v’ was declared here
4 | int i, v;
| ^
The variable v is initialized at the first iteration (i == 0). Therefore the
warning is incorrect.
This occurs with GCC 4.8, 6.5.0, 8.4.0, 9.5.0, 12.2.0, and 13.0.0 20220906
(experimental) from the master branch. But there are no warnings with GCC 4.9,
5.5.0, 10.4.0 and 11.3.0.
Note to myself (to check once this bug is fixed): this testcase is derived from
tmd/binary32/hrcases.c (warning on variable b).
[Bug tree-optimization/107839] New: spurious "may be used uninitialized" warning while all uses are under "if (c)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107839
Bug ID: 107839
Summary: spurious "may be used uninitialized" warning while all
uses are under "if (c)"
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
Consider
int f (int);
void g (int c)
{
int v;
if (c)
v = f(0);
while (1)
if (c)
f(v + v);
}
$ gcc-test -O -Wmaybe-uninitialized -c tst2.c
tst2.c: In function ‘g’:
tst2.c:4:7: warning: ‘v’ may be used uninitialized [-Wmaybe-uninitialized]
4 | int v;
| ^
All uses of v are under "if (c)", so the warning is incorrect. Note that
replacing "v + v" by "v" makes the warning disappear.
This occurs with GCC 8.4.0 and above up to at least 13.0.0 20220906
(experimental) from the master branch. No warnings with GCC 6.5.0 and below.
Note to myself (to check once this bug is fixed): this testcase is derived from
tmd/binary32/hrcases.c (warning on variable t0).
[Bug c/107840] New: ICE when compiling cursed setjmp/longjmp that uses __builtin_call_with_static_chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107840
Bug ID: 107840
Summary: ICE when compiling cursed setjmp/longjmp that uses
__builtin_call_with_static_chain
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
typedef __UINT16_TYPE__ uint16_t;
typedef __UINT32_TYPE__ uint32_t;
typedef __INTPTR_TYPE__ intptr_t;
#define unreachable __builtin_unreachable
typedef struct{
const uint16_t mov1;
const uint32_t addr;
const uint16_t mov2;
const void * const chain;
} __attribute__((packed)) thunk_struct;
#define NESTED_CHAIN(p) ({\
thunk_struct *__t = (void*)p; \
__t->chain; \
})
#define NESTED_ADDR(p) ({ \
auto __p = (p); \
thunk_struct *__t = (void*)__p; \
(typeof(__p))(intptr_t)__t->addr; \
})
#define NESTED_UPGRADE(self, ptr, args) ({\
if(self != ptr) \
__builtin_call_with_static_chain( \
NESTED_ADDR((typeof(self)*)ptr) args, \
NESTED_CHAIN(ptr) \
);\
})
typedef struct{
// can't apply standard [[noreturn]] to function pointers
[[gnu::noreturn]] void(*fun)(void*, int);
}xjmp_buf[1];
#define xsetjmp(env) ({ \
__label__ trgt; \
int __xsetjmp_ret = 0; \
[[noreturn]] void __jmp(void *self, int r){ \
NESTED_UPGRADE(__jmp, self, (self, r)); \
__xsetjmp_ret = r ?: 1; \
goto trgt; \
} \
env[0].fun = __jmp; \
trgt:; \
int tmp = __xsetjmp_ret;\
__xsetjmp_ret = 0; \
tmp;\
})
[[noreturn, gnu::always_inline]] inline void xlongjmp(xjmp_buf env, int r){
((void(*)(void*, int))NESTED_ADDR(env[0].fun))(env[0].fun, r);
unreachable();
}
int main(){
int a = 0;
xjmp_buf test;
void foo(xjmp_buf ctx){
if(!xsetjmp(ctx)){
(volatile void)0;
}
}
foo(test);
xlongjmp(test, ++a);
}
Compiling this code with `-std=c2x` results in the following error:
: In function 'foo':
:60:14: error: label '({anonymous})' has incorrect context in bb 4
60 | void foo(xjmp_buf ctx){
| ^~~
during GIMPLE pass: cfg
dump file: /app/output.c.015t.cfg
:60:14: internal compiler error: verify_flow_info failed
0x2008dee internal_error(char const*, ...)
???:0
0xaf90d7 verify_flow_info()
???:0
0x10447c7 cleanup_tree_cfg(unsigned int)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/106155] [12/13 Regression] spurious "may be used uninitialized" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106155 --- Comment #10 from Vincent Lefèvre --- A similar bug (all uses of the variable are under some condition) with a simpler testcase I've just reported: PR107839.
[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 --- Comment #12 from Vincent Lefèvre --- (In reply to Jeffrey A. Law from comment #11) > As I said in my previous comment, the best way forward is to get those two > new instances filed as distinct bugs in BZ. See PR107838 and PR107839.
[Bug middle-end/107317] [10/11/12/13 Regression] ICE in emit_redzone_byte, at asan.cc:1508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107317 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 53954 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53954&action=edit gcc13-pr107317.patch Untested fix.
[Bug c/107841] New: Incorrect generation of the function's epilogue code when there is a _builtin_alloca call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107841
Bug ID: 107841
Summary: Incorrect generation of the function's epilogue code
when there is a _builtin_alloca call.
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: avo2000 at mail dot ru
Target Milestone: ---
Incorrect generation of the function's epilogue code when there is a
_builtin_alloca call. The stack pointer is being restored incorrectly. The
function of the epilogue code generator pdp11_expand_epilogue () does not
handle the situation of having an alloca call.
Proposed solution:
--- pdp11.cc.bak2022-08-19 11:09:52.684663800 +0300
+++ pdp11.cc2022-11-23 19:09:11.908916500 +0300
@@ -392,7 +392,10 @@
HOST_WIDE_INT fsize = get_frame_size ();
unsigned regno;
rtx x, reg, via_ac = NULL;
+ int can_trust_sp_p = !cfun->calls_alloca;
+ if (can_trust_sp_p)
+{
/* Deallocate the local variables. */
if (fsize)
{
@@ -405,6 +408,14 @@
emit_insn (gen_addhi3 (stack_pointer_rtx, stack_pointer_rtx,
GEN_INT (fsize)));
}
+}
+ else
+ /* Deallocate the areas allocated using the alloca call and local variables.
*/
+ {
+ /* Deallocate the frame with a single move. */
+ gcc_assert (frame_pointer_needed);
+ emit_move_insn (stack_pointer_rtx, frame_pointer_rtx);
+ }
/* Restore the FPU registers. */
if (pdp11_saved_regno (AC4_REGNUM) || pdp11_saved_regno (AC5_REGNUM))
[Bug middle-end/107840] ICE when compiling cursed setjmp/longjmp nested function calls and non-local jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107840 --- Comment #1 from Andrew Pinski --- I don't think it is directly __builtin_call_with_static_chain but rather the non-local jump causing issues.
[Bug target/107841] Incorrect generation of the function's epilogue code when there is a _builtin_alloca call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107841 --- Comment #1 from Andrew Pinski --- Patches are submitted to gcc-patches@ after reading https://gcc.gnu.org/contribute.html
[Bug c/107831] Missed optimization: -fclash-stack-protection causes unnecessary code generation for dynamic stack allocations that are clearly less than a page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- (In reply to Petr Skocik from comment #1) > Sidenote regarding the stack-allocating code for cases when the size is not > known to be less than pagesize: the code generated for those cases is quite > large. It could be replaced (at least under -Os) with a call to a special > assembly function that'd pop the return address (assuming the target machine > pushes return addresses to the stack), allocate adjust and allocate the > stack size in a piecemeal fashion so as to not skip guard pages, the repush > the return address and return to caller with the stacksize expanded. You certainly don't want to kill the return stack the CPU has, even if it results in a few saved bytes for -Os.
[Bug c/107831] Missed optimization: -fclash-stack-protection causes unnecessary code generation for dynamic stack allocations that are clearly less than a page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831 Jakub Jelinek changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- We could use range information I guess to find out if a dynamic allocation must be small enough, but because it is a dynamic allocation, we also need a guarantee there won't be too many small dynamic allocations in the same frame.
[Bug middle-end/107840] ICE when compiling cursed setjmp/longjmp nested function calls and non-local jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107840 --- Comment #2 from Andrew Pinski --- Created attachment 53955 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53955&action=edit testcase not using C23 features
[Bug middle-end/107840] ICE when compiling cursed setjmp/longjmp nested function calls and non-local jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107840 --- Comment #3 from Andrew Pinski --- With the testcase that does not use C23 features (which was only implemented in GCC 13), we can get the ICE happening all the way back to at least GCC 6 with -fchecking. GCC 5 didn't have -fchecking so I cannot check further back.
[Bug target/107842] New: [avr] Set --param=min-pagesize=0 in the backend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107842
Bug ID: 107842
Summary: [avr] Set --param=min-pagesize=0 in the backend
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
The AVR backend should set --param=min-pagesize=0 in v12+, or otherwise we will
see warnings for each and every SFR access like:
typedef __UINT8_TYPE__ uint8_t;
#define SREG (*(volatile uint8_t*) (0x3F + __AVR_SFR_OFFSET__ ))
void bar (void)
{
SREG = 0;
}
> avr-gcc -c foo-i.c -mmcu=atmega8 -Os -Wall
foo-i.c: In function 'bar':
foo-i.c:7:6: warning: array subscript 0 is outside array bounds of 'volatile
uint8_t[0]' {aka 'volatile unsigned char[]'} [-Warray-bounds]
7 | SREG = 0;
| ~^~~~
[Bug target/107843] New: error: incompatible type for argument in ___bpf_ctx_cast2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107843 Bug ID: 107843 Summary: error: incompatible type for argument in ___bpf_ctx_cast2 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: james.hilliard1 at gmail dot com Target Milestone: --- I'm seeing this error which does not occur in llvm for a bpf test(bpf_cubic.c) in bpf-next: In file included from /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_tcp_helpers.h:9, from progs/bpf_cubic.c:20: progs/bpf_cubic.c: In function 'bpf_cubic_cwnd_event': /home/buildroot/bpf-next/tools/bpf/resolve_btfids/libbpf/include/bpf/bpf_tracing.h:399:63: error: incompatible type for argument 3 of 'bpf_cubic_cwnd_event' 399 | #define ___bpf_ctx_cast2(x, args...) ___bpf_ctx_cast1(args), (void *)ctx[1] | ^~ | | | void * /home/buildroot/bpf-next/tools/bpf/resolve_btfids/libbpf/include/bpf/bpf_helpers.h:187:29: note: in expansion of macro '___bpf_ctx_cast2' 187 | #define ___bpf_concat(a, b) a ## b | ^ /home/buildroot/bpf-next/tools/bpf/resolve_btfids/libbpf/include/bpf/bpf_helpers.h:190:29: note: in expansion of macro '___bpf_concat' 190 | #define ___bpf_apply(fn, n) ___bpf_concat(fn, n) | ^ /home/buildroot/bpf-next/tools/bpf/resolve_btfids/libbpf/include/bpf/bpf_tracing.h:410:39: note: in expansion of macro '___bpf_apply' 410 | #define ___bpf_ctx_cast(args...) ___bpf_apply(___bpf_ctx_cast, ___bpf_narg(args))(args) | ^~~~ /home/buildroot/bpf-next/tools/bpf/resolve_btfids/libbpf/include/bpf/bpf_tracing.h:435:27: note: in expansion of macro '___bpf_ctx_cast' 435 | return ##name(___bpf_ctx_cast(args)); \ | ^~~ progs/bpf_cubic.c:189:6: note: in expansion of macro 'BPF_PROG' 189 | void BPF_PROG(bpf_cubic_cwnd_event, struct sock *sk, enum tcp_ca_event event) | ^~~~ progs/bpf_cubic.c:189:72: note: expected 'enum tcp_ca_event' but argument is of type 'void *' 189 | void BPF_PROG(bpf_cubic_cwnd_event, struct sock *sk, enum tcp_ca_event event) | ~~^ /home/buildroot/bpf-next/tools/bpf/resolve_btfids/libbpf/include/bpf/bpf_tracing.h:430:39: note: in definition of macro 'BPF_PROG' 430 | ##name(unsigned long long *ctx, ##args); \ | ^~~~ /home/buildroot/bpf-next/tools/bpf/resolve_btfids/libbpf/include/bpf/bpf_tracing.h:435:16: error: 'return' with a value, in function returning void [-Werror] 435 | return ##name(___bpf_ctx_cast(args)); \ |^~~~ progs/bpf_cubic.c:189:6: note: in expansion of macro 'BPF_PROG' 189 | void BPF_PROG(bpf_cubic_cwnd_event, struct sock *sk, enum tcp_ca_event event) | ^~~~ progs/bpf_cubic.c:189:15: note: declared here 189 | void BPF_PROG(bpf_cubic_cwnd_event, struct sock *sk, enum tcp_ca_event event) | ^~~~ /home/buildroot/bpf-next/tools/bpf/resolve_btfids/libbpf/include/bpf/bpf_tracing.h:431:17: note: in definition of macro 'BPF_PROG' 431 | typeof(name(0)) name(unsigned long long *ctx) \ |
[Bug c/107831] Missed optimization: -fclash-stack-protection causes unnecessary code generation for dynamic stack allocations that are clearly less than a page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831
--- Comment #4 from Jakub Jelinek ---
Say for
void bar (char *);
void
foo (int x, int y)
{
__attribute__((assume (x < 64)));
for (int i = 0; i < y; ++i)
bar (__builtin_alloca (x));
}
all the alloca calls are known to be small, yet they can quickly cross pages.
Similarly:
void
baz (int x)
{
if (x >= 512) __builtin_unreachable ();
char a[x];
bar (a);
char b[x];
bar (b);
char c[x];
bar (c);
char d[x];
bar (d);
char e[x];
bar (e);
char f[x];
bar (f);
char g[x];
bar (g);
char h[x];
bar (h);
char i[x];
bar (i);
char j[x];
bar (j);
}
All the VLAs here are small, yet together they can cross a page.
So, we'd need to punt for dynamic allocations in loops and for others estimate
the maximum size of all the allocations together (+ __builtin_alloca overhead +
normal frame size).
[Bug target/107844] New: error: argument is not a field access for __builtin_preserve_field_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107844 Bug ID: 107844 Summary: error: argument is not a field access for __builtin_preserve_field_info Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: james.hilliard1 at gmail dot com Target Milestone: --- I'm seeing this error which does not occur in llvm for a bpf test(test_core_reloc_existence.c) in bpf-next: In file included from progs/test_core_reloc_existence.c:7: progs/test_core_reloc_existence.c: In function 'test_core_existence': /home/buildroot/bpf-next/tools/bpf/resolve_btfids/libbpf/include/bpf/bpf_core_read.h:132:9: error: argument is not a field access 132 | __builtin_preserve_field_info(___bpf_field_ref(field), BPF_FIELD_EXISTS) | ^ progs/test_core_reloc_existence.c:66:13: note: in expansion of macro 'bpf_core_field_exists' 66 | if (bpf_core_field_exists(struct core_reloc_existence, arr)) | ^
[Bug c/107845] New: __builtin_init_trampoline ICEs on invalid arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107845
Bug ID: 107845
Summary: __builtin_init_trampoline ICEs on invalid arguments
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void f()
{
__builtin_init_trampoline(0, 0, 0);
}
This crashes GCC with the following error:
during RTL pass: expand
: In function 'f':
:3:5: internal compiler error: in expand_builtin_init_trampoline, at
builtins.cc:5683
3 | __builtin_init_trampoline(0, 0, 0);
| ^~
0x2008dee internal_error(char const*, ...)
???:0
0x95c468 fancy_abort(char const*, int, char const*)
???:0
0xac9c55 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
???:0
0xc1031c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/107846] New: error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107846 Bug ID: 107846 Summary: error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: james.hilliard1 at gmail dot com Target Milestone: --- I'm seeing this error which does not occur in llvm for a bpf test(test_tc_tunnel.c) in bpf-next, I'm not sure if this is an upstream bug in the test itself or a bug in gcc: In function '__encap_ipv4': cc1: error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits [-Werror=shift-overflow=] cc1: error: result of '2 << 8' requires 24 bits to represent, but 'short int' only has 16 bits [-Werror=shift-overflow=] progs/test_tc_tunnel.c:228:31: warning: taking address of packed member of 'struct v4hdr' may result in an unaligned pointer value [-Waddress-of-packed-member] 228 | set_ipv4_csum((void *)&h_outer.ip); | ^~~ In function '__encap_ipv6': cc1: error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits [-Werror=shift-overflow=] cc1: error: result of '2 << 8' requires 24 bits to represent, but 'short int' only has 16 bits [-Werror=shift-overflow=]
[Bug target/107842] [avr] Set --param=min-pagesize=0 in the backend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107842 Georg-Johann Lay changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Georg-Johann Lay --- Dupe, but I don't know wheter only AVR is annoyed by this. *** This bug has been marked as a duplicate of bug 105523 ***
[Bug target/105523] Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523 Georg-Johann Lay changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #7 from Georg-Johann Lay --- *** Bug 107842 has been marked as a duplicate of this bug. ***
[Bug target/107847] New: error: integer overflow in expression in bpf-next test_xdp_vlan.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107847 Bug ID: 107847 Summary: error: integer overflow in expression in bpf-next test_xdp_vlan.c Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: james.hilliard1 at gmail dot com Target Milestone: --- I'm seeing this error which does not occur in llvm for a bpf test(test_xdp_vlan.c) in bpf-next, I'm not sure if this is an upstream bug in the test itself or a bug in gcc: progs/test_xdp_vlan.c: In function 'xdp_prognum1': progs/test_xdp_vlan.c:163:25: error: integer overflow in expression '(short int)(((__builtin_constant_p((int)vlan_hdr->h_vlan_TCI)) != 0 ? (int)(short unsigned int)((short int)((int)vlan_hdr->h_vlan_TCI << 8 >> 8) << 8 | (short int)((int)vlan_hdr->h_vlan_TCI << 0 >> 8 << 0)) & 61440 : (int)__builtin_bswap16(vlan_hdr->h_vlan_TCI) & 61440) << 8 >> 8) << 8' of type 'short int' results in '0' [-Werror=overflow] 163 | bpf_htons((bpf_ntohs(vlan_hdr->h_vlan_TCI) & 0xf000) | ^
[Bug target/105523] Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-11-23 Status|UNCONFIRMED |NEW --- Comment #8 from Andrew Pinski --- (In reply to LIU Hao from comment #6) > Apparently GCC thinks we are dereferencing `0x30` which is a dangling > pointer however that is exactly what we want to do, so GCC shouldn't have > warned in this case. That inline-asm is not correct and GCC does not understand segments if you don't use named address space feature. The original issue is confirmed.
[Bug target/106307] error when I do a test on a pointer on Arduino 1.8.19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106307 --- Comment #1 from Georg-Johann Lay --- We'd need at least a test case so we can reproduce th issue. Thanks.
[Bug target/105523] Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523 --- Comment #9 from Andrew Pinski --- (In reply to rudi from comment #5) > Compiling atf with gcc-12.1.0 for the NXP iMX8 target results in the same > error. > > CFLAGS=+“ --param=min-pagesize=0” allows the build to complete. Yes ATF needs to have that addded to their makefile as it is a firmware which has memory at 0. Note this PR is about AVR only as that target always have memory at 0. Most other targets should not set --param=min-pagesize=0 by default (there are a few others); it is up to the firmware software to get set this option to tell GCC there is memory at location 0; because we want to warn about the normal user case. Firmware is a special case and all.
[Bug c/107831] Missed optimization: -fclash-stack-protection causes unnecessary code generation for dynamic stack allocations that are clearly less than a page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107831 --- Comment #5 from Jeffrey A. Law --- Right. You also have to know the distance from the last probe (possibly an implicit one) to the start of the alloca space before you can contemplate eliding the probes in alloca space. There's a hook we can use, but it was more meant for AArch64 IIRC, but we might be able to use it for this purpose. You also have to worry about dynamic allocations in a loop. A single byte alloca could jump the stack if it's inside loop with a suitable number of iterations. In general, the model taken was to try and minimize explicit probes in the common case (ie, function entry) at the expense of taking additional probes in the uncommon case (dynamic allocations).
[Bug libstdc++/104875] libstdc++-v3/src/c++11/codecvt.cc:312:24: warning: left shift count >= width of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104875 --- Comment #3 from Georg-Johann Lay --- Is this fixed now?
[Bug target/105523] Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #10 from LIU Hao ---
(In reply to Andrew Pinski from comment #8)
> That inline-asm is not correct and GCC does not understand segments if you
> don't use named address space feature.
>
Named address space is not supported unless a GNU standard is selected.
https://gcc.godbolt.org/z/nbEMz6xMq
```
int
read_gs_30(void)
{
return *(int* __seg_gs) 0x30;
}
```
With `-std=c99`:
```
: In function 'read_gs_30':
:4:18: error: expected ')' before '__seg_gs'
4 | return *(int* __seg_gs) 0x30;
| ~^
| )
Compiler returned: 1
```
[Bug tree-optimization/107837] [10/11/12/13 Regression] Missed optimization: Using memcpy to load a struct unnecessary uses stack space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107837
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-11-23
Summary|Missed optimization: Using |[10/11/12/13 Regression]
|memcpy to load a struct |Missed optimization: Using
|unnecessary uses stack |memcpy to load a struct
|space |unnecessary uses stack
||space
Keywords||needs-bisection
Known to work||4.5.3, 4.7.3, 5.1.0, 7.5.0
Target Milestone|--- |10.5
Known to fail||8.1.0
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed, GCC 7 did the right thing ...
Even on the gimple level:
x$v$0_8 = MEM[(char * {ref-all})src_6(D)];
x$v$1_9 = MEM[(char * {ref-all})src_6(D) + 8B];
x$v$2_10 = MEM[(char * {ref-all})src_6(D) + 16B];
x$v$3_11 = MEM[(char * {ref-all})src_6(D) + 24B];
_1 = __builtin_bswap64 (x$v$3_11);
_2 = __builtin_bswap64 (x$v$2_10);
_3 = __builtin_bswap64 (x$v$1_9);
_4 = __builtin_bswap64 (x$v$0_8);
MEM[(struct uint256 *)o_7(D)] = _1;
MEM[(struct uint256 *)o_7(D) + 8B] = _2;
MEM[(struct uint256 *)o_7(D) + 16B] = _3;
MEM[(struct uint256 *)o_7(D) + 24B] = _4;
[Bug libstdc++/104875] libstdc++-v3/src/c++11/codecvt.cc:312:24: warning: left shift count >= width of type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104875 --- Comment #4 from Jonathan Wakely --- Only for gcc-12 and trunk.
[Bug target/105523] Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523 --- Comment #11 from Andrew Pinski --- (In reply to LIU Hao from comment #10) > (In reply to Andrew Pinski from comment #8) > > That inline-asm is not correct and GCC does not understand segments if you > > don't use named address space feature. > > > > Named address space is not supported unless a GNU standard is selected. Yes but the inline-asm is just broken. Anyways this is not related to the original issue reported here.
[Bug c/107127] [11/12/13 Regression] Long compile times on code with C complex since r11-3299-gcba079f354a55363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107127 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8a0fce6a51915c29584427fd376b40073c328090 commit r13-4268-g8a0fce6a51915c29584427fd376b40073c328090 Author: Jakub Jelinek Date: Wed Nov 23 19:09:31 2022 +0100 c: Fix compile time hog in c_genericize [PR107127] The complex multiplications result in deeply nested set of many SAVE_EXPRs, which takes even on fast machines over 5 minutes to walk. This patch fixes that by using walk_tree_without_duplicates where it is instant. 2022-11-23 Andrew Pinski Jakub Jelinek PR c/107127 * c-gimplify.cc (c_genericize): Use walk_tree_without_duplicates instead of walk_tree for c_genericize_control_r. * gcc.dg/pr107127.c: New test.
[Bug c/107127] [11/12 Regression] Long compile times on code with C complex since r11-3299-gcba079f354a55363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107127 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13 Regression] Long |[11/12 Regression] Long |compile times on code with |compile times on code with |C complex since |C complex since |r11-3299-gcba079f354a55363 |r11-3299-gcba079f354a55363 --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/105523] Wrong warning array subscript [0] is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523 --- Comment #12 from Konrad Rosenbaum --- It would be super helpful if the AVR target (and all its sub-architectures) could have the min-pagesize=0 option(*) set implicitly. This architecture has ONLY firmware - firmware is not special in that architecture. checks. The first memory mapped page on AVR is actually the register/IO-port file that leads to all the IO devices and "peripherals" that are inside these chips. It's impossible to write any software for AVR without touching this page. (*) or something else that excludes the register file from range
[Bug middle-end/107845] __builtin_init_trampoline ICEs on invalid arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107845 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Last reconfirmed||2022-11-23 Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug target/107846] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107846 --- Comment #1 from David Faust --- I think this is a bug in the test itself (or with these macros from libbpf). libbpf/src/bpf_endian.h #define ___bpf_mvb(x, b, n, m) ((__u##b)(x) << (b-(n+1)*8) >> (b-8) << (m*8)) #define ___bpf_swab16(x) ((__u16)( \ ___bpf_mvb(x, 16, 0, 1) | \ ___bpf_mvb(x, 16, 1, 0))) # define __bpf_constant_htons(x)___bpf_swab16(x) In tools/testing/selftests/bpf/progs/test_tc_tunnel.c: static const int cfg_port = 8000; static const int cfg_udp_src = 2; ... then at e.g. line 276 if (tcph.dest != __bpf_constant_htons(cfg_port)) return TC_ACT_OK; Expanding this __bpf_constant_htons macro: __bpf_constant_htons (cfg_port) __bpf_constant_htons (8000) ((__u16)(8000) << (16-(0+1)*8) >> (16-8) << (1*8) ((__u16)(8000) << (16-(1)*8) >> (8) << 8) ((__u16)(8000) << (8) >> 8 << 8 ((__u16)(8000) << 8) ...which raises the shift-overflow warning.
[Bug fortran/107577] [13 Regression] ICE in find_array_spec, at fortran/resolve.cc:5008 since r13-1757-gf838d15641d256e2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107577 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2eaa0cc45e8eae0fc4a440d28c602964bcb1014d commit r13-4269-g2eaa0cc45e8eae0fc4a440d28c602964bcb1014d Author: Steve Kargl Date: Tue Nov 22 22:31:51 2022 +0100 Fortran: error recovery on associate with bad selector [PR107577] gcc/fortran/ChangeLog: PR fortran/107577 * resolve.cc (find_array_spec): Choose appropriate locus either of bad array reference or of non-array entity in error message. gcc/testsuite/ChangeLog: PR fortran/107577 * gfortran.dg/pr107577.f90: New test.
[Bug target/107848] New: libbpf: ELF relo #0 in section #7 has unexpected type 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107848 Bug ID: 107848 Summary: libbpf: ELF relo #0 in section #7 has unexpected type 12 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: james.hilliard1 at gmail dot com Target Milestone: --- GCC gen object appears to not be working correctly in the bpf test bpf_dctcp_release.c GCC gen object failure: $ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool --debug gen object /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/bpf_dctcp_release.bpf.linked1.o /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/bpf_dctcp_release.bpf.o libbpf: linker: adding object file '/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/bpf_dctcp_release.bpf.o'... libbpf: ELF relo #0 in section #7 has unexpected type 12 in /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/bpf_dctcp_release.bpf.o Error: failed to link '/home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/bpf_dctcp_release.bpf.o': Invalid argument (22) GCC BTF dump: $ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool --debug btf dump file /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/bpf_dctcp_release.bpf.o format raw [1] INT 'long int' size=8 bits_offset=0 nr_bits=64 encoding=SIGNED [2] INT 'long unsigned int' size=8 bits_offset=0 nr_bits=64 encoding=(none) [3] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED [4] INT 'long long int' size=8 bits_offset=0 nr_bits=64 encoding=SIGNED [5] FLOAT 'long double' size=8 [6] INT 'signed char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED [7] INT 'unsigned char' size=1 bits_offset=0 nr_bits=8 encoding=(none) [8] TYPEDEF '__u8' type_id=7 [9] INT 'short int' size=2 bits_offset=0 nr_bits=16 encoding=SIGNED [10] INT 'short unsigned int' size=2 bits_offset=0 nr_bits=16 encoding=(none) [11] TYPEDEF '__u16' type_id=10 [12] TYPEDEF '__s32' type_id=3 [13] INT 'unsigned int' size=4 bits_offset=0 nr_bits=32 encoding=(none) [14] TYPEDEF '__u32' type_id=13 [15] TYPEDEF '__s64' type_id=4 [16] INT 'long long unsigned int' size=8 bits_offset=0 nr_bits=64 encoding=(none) [17] TYPEDEF '__u64' type_id=16 [18] TYPEDEF '__be16' type_id=11 [19] TYPEDEF '__be32' type_id=14 [20] TYPEDEF '__sum16' type_id=11 [21] TYPEDEF '__wsum' type_id=14 [22] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED [23] ARRAY '(anon)' type_id=22 index_type_id=2 nr_elems=16 [24] CONST '(anon)' type_id=22 [25] UNION '(anon)' size=8 vlen=1 'flow_keys' type_id=31 bits_offset=0 [26] STRUCT 'bpf_flow_keys' size=56 vlen=13 'nhoff' type_id=11 bits_offset=0 'thoff' type_id=11 bits_offset=16 'addr_proto' type_id=11 bits_offset=32 'is_frag' type_id=8 bits_offset=48 'is_first_frag' type_id=8 bits_offset=56 'is_encap' type_id=8 bits_offset=64 'ip_proto' type_id=8 bits_offset=72 'n_proto' type_id=18 bits_offset=80 'sport' type_id=18 bits_offset=96 'dport' type_id=18 bits_offset=112 '(anon)' type_id=27 bits_offset=128 'flags' type_id=14 bits_offset=384 'flow_label' type_id=19 bits_offset=416 [27] UNION '(anon)' size=32 vlen=2 '(anon)' type_id=28 bits_offset=0 '(anon)' type_id=29 bits_offset=0 [28] STRUCT '(anon)' size=8 vlen=2 'ipv4_src' type_id=19 bits_offset=0 'ipv4_dst' type_id=19 bits_offset=32 [29] STRUCT '(anon)' size=32 vlen=2 'ipv6_src' type_id=30 bits_offset=0 'ipv6_dst' type_id=30 bits_offset=128 [30] ARRAY '(anon)' type_id=14 index_type_id=2 nr_elems=4 [31] PTR '(anon)' type_id=26 [32] UNION '(anon)' size=8 vlen=1 'sk' type_id=34 bits_offset=0 [33] STRUCT 'bpf_sock' size=80 vlen=14 'bound_dev_if' type_id=14 bits_offset=0 'family' type_id=14 bits_offset=32 'type' type_id=14 bits_offset=64 'protocol' type_id=14 bits_offset=96 'mark' type_id=14 bits_offset=128 'priority' type_id=14 bits_offset=160 'src_ip4' type_id=14 bits_offset=192 'src_ip6' type_id=30 bits_offset=224 'src_port' type_id=14 bits_offset=352 'dst_port' type_id=18 bits_offset=384 'dst_ip4' type_id=14 bits_offset=416 'dst_ip6' type_id=30 bits_offset=448 'state' type_id=14 bits_offset=576 'rx_queue_mapping' type_id=12 bits_offset=608 [34] PTR '(anon)' type_id=33 [35] STRUCT '__sk_buff' size=192 vlen=34 'len' type_id=14 bits_offset=0 'pkt_type' type_id=14 bits_offset=32 'mark' type_id=14 bits_offset=64 'queue_mapping' type_id=14 bits_offset=96 'protocol' type_id=14 bits_offset=128 'vlan_present' type_id=14 bits_offset=160 'vlan_tci' type_id=14 bits_offset=192 'vlan_proto' type_id=14 bits_o
[Bug target/107848] libbpf: ELF relo #0 in section #7 has unexpected type 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107848 --- Comment #1 from James Hilliard --- Working LLVM BTF Dump: $ /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/sbin/bpftool --debug btf dump file /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_dctcp_release.bpf.o format raw [1] PTR '(anon)' type_id=2 [2] INT 'unsigned long long' size=8 bits_offset=0 nr_bits=64 encoding=(none) [3] FUNC_PROTO '(anon)' ret_type_id=0 vlen=1 'ctx' type_id=1 [4] FUNC 'dctcp_nouse_release' type_id=3 linkage=global [5] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED [6] ARRAY '(anon)' type_id=5 index_type_id=7 nr_elems=4 [7] INT '__ARRAY_SIZE_TYPE__' size=4 bits_offset=0 nr_bits=32 encoding=(none) [8] VAR '_license' type_id=6, linkage=global [9] CONST '(anon)' type_id=5 [10] ARRAY '(anon)' type_id=9 index_type_id=7 nr_elems=6 [11] VAR 'cubic' type_id=10, linkage=global [12] STRUCT 'tcp_congestion_ops' size=128 vlen=15 'name' type_id=13 bits_offset=0 'flags' type_id=14 bits_offset=128 'init' type_id=16 bits_offset=192 'release' type_id=16 bits_offset=256 'ssthresh' type_id=25 bits_offset=320 'cong_avoid' type_id=27 bits_offset=384 'set_state' type_id=29 bits_offset=448 'cwnd_event' type_id=32 bits_offset=512 'in_ack_event' type_id=35 bits_offset=576 'undo_cwnd' type_id=25 bits_offset=640 'pkts_acked' type_id=37 bits_offset=704 'min_tso_segs' type_id=25 bits_offset=768 'sndbuf_expand' type_id=25 bits_offset=832 'cong_control' type_id=44 bits_offset=896 'owner' type_id=52 bits_offset=960 [13] ARRAY '(anon)' type_id=5 index_type_id=7 nr_elems=16 [14] TYPEDEF '__u32' type_id=15 [15] INT 'unsigned int' size=4 bits_offset=0 nr_bits=32 encoding=(none) [16] PTR '(anon)' type_id=17 [17] FUNC_PROTO '(anon)' ret_type_id=0 vlen=1 '(anon)' type_id=18 [18] PTR '(anon)' type_id=19 [19] STRUCT 'sock' size=24 vlen=3 '__sk_common' type_id=20 bits_offset=0 'sk_pacing_rate' type_id=24 bits_offset=64 'sk_pacing_status' type_id=14 bits_offset=128 [20] STRUCT 'sock_common' size=4 vlen=2 'skc_state' type_id=21 bits_offset=0 'skc_num' type_id=22 bits_offset=16 [21] INT 'unsigned char' size=1 bits_offset=0 nr_bits=8 encoding=(none) [22] TYPEDEF '__u16' type_id=23 [23] INT 'unsigned short' size=2 bits_offset=0 nr_bits=16 encoding=(none) [24] INT 'unsigned long' size=8 bits_offset=0 nr_bits=64 encoding=(none) [25] PTR '(anon)' type_id=26 [26] FUNC_PROTO '(anon)' ret_type_id=14 vlen=1 '(anon)' type_id=18 [27] PTR '(anon)' type_id=28 [28] FUNC_PROTO '(anon)' ret_type_id=0 vlen=3 '(anon)' type_id=18 '(anon)' type_id=14 '(anon)' type_id=14 [29] PTR '(anon)' type_id=30 [30] FUNC_PROTO '(anon)' ret_type_id=0 vlen=2 '(anon)' type_id=18 '(anon)' type_id=31 [31] TYPEDEF '__u8' type_id=21 [32] PTR '(anon)' type_id=33 [33] FUNC_PROTO '(anon)' ret_type_id=0 vlen=2 '(anon)' type_id=18 '(anon)' type_id=34 [34] ENUM 'tcp_ca_event' encoding=UNSIGNED size=4 vlen=6 'CA_EVENT_TX_START' val=0 'CA_EVENT_CWND_RESTART' val=1 'CA_EVENT_COMPLETE_CWR' val=2 'CA_EVENT_LOSS' val=3 'CA_EVENT_ECN_NO_CE' val=4 'CA_EVENT_ECN_IS_CE' val=5 [35] PTR '(anon)' type_id=36 [36] FUNC_PROTO '(anon)' ret_type_id=0 vlen=2 '(anon)' type_id=18 '(anon)' type_id=14 [37] PTR '(anon)' type_id=38 [38] FUNC_PROTO '(anon)' ret_type_id=0 vlen=2 '(anon)' type_id=18 '(anon)' type_id=39 [39] PTR '(anon)' type_id=40 [40] CONST '(anon)' type_id=41 [41] STRUCT 'ack_sample' size=12 vlen=3 'pkts_acked' type_id=14 bits_offset=0 'rtt_us' type_id=42 bits_offset=32 'in_flight' type_id=14 bits_offset=64 [42] TYPEDEF '__s32' type_id=43 [43] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED [44] PTR '(anon)' type_id=45 [45] FUNC_PROTO '(anon)' ret_type_id=0 vlen=2 '(anon)' type_id=18 '(anon)' type_id=46 [46] PTR '(anon)' type_id=47 [47] CONST '(anon)' type_id=48 [48] STRUCT 'rate_sample' size=56 vlen=13 'prior_mstamp' type_id=49 bits_offset=0 'prior_delivered' type_id=14 bits_offset=64 'delivered' type_id=42 bits_offset=96 'interval_us' type_id=50 bits_offset=128 'snd_interval_us' type_id=14 bits_offset=192 'rcv_interval_us' type_id=14 bits_offset=224 'rtt_us' type_id=50 bits_offset=256 'losses' type_id=43 bits_offset=320 'acked_sacked' type_id=14 bits_offset=352 'prior_in_flight' type_id=14 bits_offset=384 'is_app_limited' type_id=51 bits_offset=416 'is_retrans' type_id=51 bits_offset=424 'is_ack_delayed' type_id=51 bits_offset=432 [49] TYPEDEF '__u64' type_id=2 [50] INT 'long' size=8 bits_offset=0 nr_bits=64 encoding=SIGNED [51] INT '_Bool' size=1 bits_offset=0 nr_bits=8 encoding=BOOL [52] PTR '(anon)' type_id=0 [53] VAR 'dctc
[Bug target/107848] libbpf: ELF relo #0 in section #7 has unexpected type 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107848 --- Comment #2 from Jose E. Marchesi --- This is likely due to the fact they added new BPF relocations: https://reviews.llvm.org/D102712 Or course not bothering telling us.
[Bug target/107846] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107846 --- Comment #2 from Andrew Pinski --- (In reply to David Faust from comment #1) > I think this is a bug in the test itself (or with these macros from libbpf). No I think there might be a bug in GCC though I have to double check. cc1: error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits [-Werror=shift-overflow=] ((__u16)(8000) << 8) Hmm, we should have prompted that to int and not warned about it ...
[Bug c/107846] [13 Regression] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107846
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic, needs-bisection
Last reconfirmed||2022-11-23
Status|UNCONFIRMED |NEW
Known to work||11.1.0, 12.1.0, 12.2.0,
||9.1.0
Component|target |c
Target Milestone|--- |13.0
Ever confirmed|0 |1
Summary|error: result of '8000 << |[13 Regression] error:
|8' requires 22 bits to |result of '8000 << 8'
|represent, but 'short int' |requires 22 bits to
|only has 16 bits|represent, but 'short int'
||only has 16 bits
Target|bpf |
--- Comment #3 from Andrew Pinski ---
Short testcase:
typedef unsigned short __u16;
#define ___bpf_mvb(x, b, n, m) ((__u##b)(x) << (b-(n+1)*8) >> (b-8) << (m*8))
#define ___bpf_swab16(x) ((__u16)( \
___bpf_mvb(x, 16, 0, 1) | \
___bpf_mvb(x, 16, 1, 0)))
# define __bpf_constant_htons(x)___bpf_swab16(x)
static const int cfg_port = 8000;
unsigned short f(int t)
{
if (t != __bpf_constant_htons (cfg_port))
return 1;
return 0;
}
--- CUT ---
This is definitely a bug in GCC though there might be a dup.
the line info is also missing ...
Note this only happens at -O1 and also a regression from GCC 12 even.
[Bug c/107846] [13 Regression] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107846 --- Comment #4 from Andrew Pinski --- #0 warning_at (location=0, opt=765, gmsgid=0x30ecaf8 "result of %qE requires %u bits to represent, but %qT only has %u bits") at /home/apinski/src/upstream-gcc-git/gcc/gcc/diagnostic.cc:1845 #1 0x00d3a2e2 in maybe_warn_shift_overflow (loc=0, op0=0x76e949c0, op1=0x76e94960) at /home/apinski/src/upstream-gcc-git/gcc/gcc/c-family/c-warn.cc:2645 #2 0x00c62e14 in c_fully_fold_internal (expr=0x76e84cf8, in_init=false, maybe_const_operands=0x7fffce5b, maybe_const_itself=0x7fffce5a, for_int_const=false, lval=false) at /home/apinski/src/upstream-gcc-git/gcc/gcc/c/c-fold.cc:429 #3 0x00c62358 in c_fully_fold_internal (expr=0x76e84d20, in_init=false, maybe_const_operands=0x7fffce5b, maybe_const_itself=0x7fffce5a, for_int_const=false, lval=false) at /home/apinski/src/upstream-gcc-git/gcc/gcc/c/c-fold.cc:354 #4 0x00c63089 in c_fully_fold_internal (expr=0x76e96420, in_init=false, maybe_const_operands=0x7fffce5b, maybe_const_itself=0x7fffce5a, for_int_const=false, lval=false) at /home/apinski/src/upstream-gcc-git/gcc/gcc/c/c-fold.cc:473 #5 0x00c614ab in c_fully_fold (expr=0x76e96420, in_init=false, maybe_const=0x7fffce5b, lval=false) at /home/apinski/src/upstream-gcc-git/gcc/gcc/c/c-fold.cc:125
[Bug analyzer/100705] RFE: warn about dead store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100705 --- Comment #3 from David Malcolm --- See also: PR 80066
[Bug c/107846] [13 Regression] error: result of '8000 << 8' requires 22 bits to represent, but 'short int' only has 16 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107846 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org, ||sayle at gcc dot gnu.org Keywords|needs-bisection | --- Comment #5 from Jakub Jelinek --- Started with r13-1100-gacb1e6f43dc2bbedd1248ea61c7ab537a11fe59b So, either we should limit that new match.pd folding to GIMPLE, or should take into account such narrowing vs. integral promotion.
