[Bug fortran/112834] Class array function selector causes chain of syntax and other spurious errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112834 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Last reconfirmed||2023-12-06 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Paul Thomas --- Created attachment 56814 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56814=edit Fix for this PR I will be submitting this to the list this evening. Paul
[Bug middle-end/88345] -Os overrides -falign-functions=N on the command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345 --- Comment #19 from Michael Matz --- (In reply to Jan Hubicka from comment #18) > Reading all the discussion again, I am leaning towards -falign-all-functions > + documentation update explaining that -falign-functions/-falign-loops are > optimizations and ignored for -Os. > > I do use -falign-functions/-falign-loops when tuning for new generations of > CPUs and I definitely want to have way to specify alignment that is ignored > for cold functions (as perforance optimization) and we have this behavior > since profile code was introduced in 2002. > > As an optimization, we also want to have hot functions aligned more than 8 > byte boundary needed for patching. > > I will prepare patch for this and send it for disucssion. Pehraps we want > -flive-patching to also imply FUNCTION_BOUNDARY increase on x86-64? Or is > live patching useful if function entries are not aligned? Live patching (user-space) doesn't depend on any particular alignment of functions, on x86-64 at least. (The plan for other architectures wouldn't need any specific alignment either). Note that the above complaints about missing alignment is for kernel (!) ftrace/livepatching on arm64 (!), not on x86_64.
[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109289 Thomas Schwinge changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Thomas Schwinge --- (In reply to myself from comment #2) > Similarly seen for GCN target, and this is now fatal Actually, sorry, that's not accurate; the "warning: conflicting types" didn't turn fatal. Anyway: 'libgcc/emutls.c' should now be clean to build; please re-open if not.
[Bug target/112762] [14 Regression] Cannot build crosscompilers for some uclinux targets since r14-5791-g24592abd68e6ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112762 --- Comment #6 from GCC Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:e0eca4a55bd14d506708fb0396b31e7f7383160c commit r14-6220-ge0eca4a55bd14d506708fb0396b31e7f7383160c Author: Marek Polacek Date: Tue Dec 5 13:39:49 2023 -0500 build: unbreak bootstrap on uclinux targets [PR112762] Currently, cross-compiling with --target=c6x-uclinux (and several other) fails due to: ../../src/gcc/config/linux.h:221:45: error: 'linux_fortify_source_default_level' was not declared in this scope #define TARGET_FORTIFY_SOURCE_DEFAULT_LEVEL linux_fortify_source_default_level In the PR Andrew mentions that another fix would be in config.gcc, but really, here I meant to use the target hook for glibc only, not uclibc. This trivial patch fixes the build problem. It means that -fhardened with uclibc will use -D_FORTIFY_SOURCE=2 and not =3. PR target/112762 gcc/ChangeLog: * config/linux.h: Redefine TARGET_FORTIFY_SOURCE_DEFAULT_LEVEL for glibc only.
[Bug target/112855] [14] RISC-V vector: vsetivli clobbers variable value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112855 --- Comment #2 from GCC Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:c9d5b46a25547035e381b0246de5cb553ca8b02d commit r14-6222-gc9d5b46a25547035e381b0246de5cb553ca8b02d Author: Juzhe-Zhong Date: Wed Dec 6 22:26:46 2023 +0800 RISC-V: Fix VSETVL PASS bug As PR112855 mentioned, the VSETVL PASS insert vsetvli in unexpected location. Due to 2 reasons: 1. incorrect transparant computation LCM data. We need to check VL operand defs and uses. 2. incorrect fusion of unrelated edge which is the edge never reach the vsetvl expression. PR target/112855 gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (pre_vsetvl::compute_lcm_local_properties): Fix transparant LCM data. (pre_vsetvl::earliest_fuse_vsetvl_info): Disable earliest fusion for unrelated edge. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/pr112855.c: New test.
[Bug libstdc++/112480] optional::reset emits inefficient code when T is trivially-destructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112480 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |13.3 --- Comment #11 from Jonathan Wakely --- Fixed for 13.3, thanks for the report and analysis of the codegen.
[Bug c++/98531] [modules] g++.dg/modules/xtreme-header-2_a.H etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98531 --- Comment #20 from John David Anglin --- The fails have changed on hppa with gcc-14 trunk: FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2b (test for excess errors) Excess errors: /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/format:3524:28: error: invalid use of non-static data member 'std::basic_format_args, wchar_t> >::__as_base ::' /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/format:3527:19: error: invalid use of non-static data member 'std::basic_format_args, wchar_t> >::__as_base ::' FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess errors) Excess errors: /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/format:3524:28: error: invalid use of non-static data member 'std::basic_format_args, wchar_t> >::__as_base ::' /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/format:3527:19: error: invalid use of non-static data member 'std::basic_format_args, wchar_t> >::__as_base ::' FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors) Excess errors: /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/format:3524:28: error: invalid use of non-static data member 'std::basic_format_args, wchar_t> >::__as_base ::' /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/format:3527:19: error: invalid use of non-static data member 'std::basic_format_args, wchar_t> >::__as_base ::' FAIL: g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors) Excess errors: /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header_a.H: error: conflicting global module declaration 'template class _Cont, class _Rg, class ... _Args> using std::ranges::__detail::_DeduceExpr1 = decltype (_Cont<...auto...>(declval<_Rg>(), (declval<_Args>)()...))' /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header_a.H: error: conflicting global module declaration 'template class _Cont, class _Rg, class ... _Args> using std::ranges::__detail::_DeduceExpr2 = decltype (_Cont<...auto...>(std::from_range, declval<_Rg>(), (declval<_Args>)()...))' /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header_a.H: error: conflicting global module declaration 'template class _Cont, class _Rg, class ... _Args> using std::ranges::__detail::_DeduceExpr3 = decltype (_Cont<...auto...>(declval >(), declval >(), (declval<_Args>)()...))' /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header_a.H: error: conflicting global module declaration 'using std::ranges::__detail::_DeduceExpr1 = decltype (_Cont<...auto...>(declval<_Rg>(), (declval<_Args>)()...))' /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header_a.H: error: conflicting global module declaration 'using std::ranges::__detail::_DeduceExpr2 = decltype (_Cont<...auto...>(std::from_range, declval<_Rg>(), (declval<_Args>)()...))' /home/dave/gnu/gcc/gcc/gcc/testsuite/g++.dg/modules/xtreme-header_a.H: error: conflicting global module declaration 'using std::ranges::__detail::_DeduceExpr3 = decltype (_Cont<...auto...>(declval >(), declval >(), (declval<_Args>)()...))' The latter fail looks like PR112737.
[Bug tree-optimization/112880] ICE: in smallest_mode_for_size, at stor-layout.cc:356 with __builtin_mul_overflow() of _BitInt(1024)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112880 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2023-12-06 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jakub Jelinek --- Created attachment 56815 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56815=edit gcc14-pr112880.patch Untested fix.
[Bug libstdc++/112882] [14 Regression] std::clamp no longer usable in header only mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112882
--- Comment #2 from Jonathan Wakely ---
That change was broken anyway: when _GLIBCXX_ASSERTIONS was not defined, the
condition in the assertion is if constexpr (is_constant_evaluated()) which is
always true, even when not actually doing constant eval.
I'll test this:
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -538,6 +538,7 @@ namespace std
// This can be used without checking if the compiler supports the feature.
// The macro _GLIBCXX_HAVE_IS_CONSTANT_EVALUATED can be used to check if
// the compiler support is present to make this function work as expected.
+ __attribute__((__always_inline__))
_GLIBCXX_CONSTEXPR inline bool
__is_constant_evaluated() _GLIBCXX_NOEXCEPT
{
@@ -589,19 +590,28 @@ namespace std
#endif
#if defined(_GLIBCXX_ASSERTIONS)
-# define _GLIBCXX_DO_ASSERT true
-#elif _GLIBCXX_HAVE_IS_CONSTANT_EVALUATED
-# define _GLIBCXX_DO_ASSERT std::__is_constant_evaluated()
-#else
-# define _GLIBCXX_DO_ASSERT false
-#endif
-
# define __glibcxx_assert(cond)
\
do { \
-if _GLIBCXX17_CONSTEXPR (_GLIBCXX_DO_ASSERT) \
- if (__builtin_expect(!bool(cond), false))
\
- _GLIBCXX_ASSERT_FAIL(cond); \
+if (__builtin_expect(!bool(cond), false)) \
+ _GLIBCXX_ASSERT_FAIL(cond); \
} while (false)
+#elif _GLIBCXX_HAVE_IS_CONSTANT_EVALUATED
+namespace std
+{
+ __attribute__((__always_inline__,visibility("default")))
+ inline void
+ __glibcxx_compile_time_assert_fail()
+ { }
+}
+# define __glibcxx_assert(cond)
\
+ do { \
+if (std::__is_constant_evaluated())
\
+ if (__builtin_expect(!bool(cond), false))
\
+ __glibcxx_compile_time_assert_fail(); \
+ } while (false)
+#else
+# define __glibcxx_assert(cond)
+#endif
// Macro indicating that TSAN is in use.
#if __SANITIZE_THREAD__
[Bug libstdc++/112882] [14 Regression] std::clamp no longer usable in header only mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112882
--- Comment #3 from Jonathan Wakely ---
This minimal fix is enough to remove the reference to __glibcxx_assert_fail
when optimization is enabled (at any level):
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -598,7 +598,7 @@ namespace std
# define __glibcxx_assert(cond)
\
do { \
-if _GLIBCXX17_CONSTEXPR (_GLIBCXX_DO_ASSERT) \
+if (_GLIBCXX_DO_ASSERT)\
if (__builtin_expect(!bool(cond), false))
\
_GLIBCXX_ASSERT_FAIL(cond); \
} while (false)
But we still need the more complete fix for -O0.
[Bug fortran/112834] Class array function selector causes chain of syntax and other spurious errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112834 Paul Thomas changed: What|Removed |Added Blocks||87477 --- Comment #2 from Paul Thomas --- Flagging as a blocker to PR87477. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477 [Bug 87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement
[Bug libstdc++/112477] Assignment of value-initialized iterators differs from value-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112477 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2023-12-06 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Jonathan Wakely --- I agree this should work.
[Bug libstdc++/112882] New: [14 Regression] std::clamp no longer usable in header only mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112882 Bug ID: 112882 Summary: [14 Regression] std::clamp no longer usable in header only mode Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: tnfchris at gcc dot gnu.org CC: redi at gcc dot gnu.org Target Milestone: --- I know this is not a supported scenario, but I'm wondering if it's still easy to support. We have some libraries that use C++ mostly as an abstraction layer and try to ensure that it needs no runtime support from libstdc++. A recent commit: g:5e8a30d8b8f4d7ea0a8340b46c1e0c865dbde781 changed how `__glibcxx_assert` is defined and now always calls `std::__glibcxx_assert_fail`. This means that now you always need libstdc++ even in contex where things would have been folded away before. Similarly we're getting the same thing through usage of `std::unique_ptr`. It seems that undefining `_GLIBCXX_VERBOSE_ASSERT` gets it to go to `__builtin_abort()` which makes it work again. If this change was intentional, would it be possible to make `_GLIBCXX_VERBOSE_ASSERT` user configurable?
[Bug debug/112726] Sometimes incorrect DW_AT_decl_file with -gdwarf-5 and -fdebug-prefix-map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112726 --- Comment #1 from Giuliano Procida --- Much of the initial report can be ignored, `llvm-dwarfdump` is buggy for DWARF 5 before version 15. Here's a much simpler statement: gcc -gdwarf-5 -fdebug-prefix-map=$(pwd)= -c foo.c is broken and the prefix is not removed from the DWARF compilation directory / directory used for DW_AT_decl_file. For Clang, DWARF 4, a slightly shorter prefix or a source file in subdirectory, things work better.
[Bug target/112762] [14 Regression] Cannot build crosscompilers for some uclinux targets since r14-5791-g24592abd68e6ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112762 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Should be fixed, sorry.
[Bug target/112762] [14 Regression] Cannot build crosscompilers for some uclinux targets since r14-5791-g24592abd68e6ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112762 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/53499] Incorrect partial ordering result with member vs non-member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53499 --- Comment #5 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:c1e54c82a9e1855499ef7bb8827540e6a097532b commit r14-6221-gc1e54c82a9e1855499ef7bb8827540e6a097532b Author: Jason Merrill Date: Tue Dec 5 15:28:16 2023 -0500 c++: partial ordering of object parameter [PR53499] Looks like we implemented option 1 (skip the object parameter) for CWG532 before the issue was resolved, and never updated to the final resolution of option 2 (model it as a reference). More recently CWG2445 extended this handling to static member functions; I think that's wrong, and have opened CWG2834 to address that and how explicit object member functions interact with it. The FIXME comments are to guide how the explicit object member function support should change the uses of DECL_NONSTATIC_MEMBER_FUNCTION_P. The library testsuite changes are to make partial ordering work again between the generic operator- in the testcase and _Pointer_adapter::operator-. DR 532 PR c++/53499 gcc/cp/ChangeLog: * pt.cc (more_specialized_fn): Fix object parameter handling. gcc/testsuite/ChangeLog: * g++.dg/template/partial-order4.C: New test. * g++.dg/template/spec26.C: Adjust for CWG532. libstdc++-v3/ChangeLog: * testsuite/23_containers/vector/ext_pointer/types/1.cc * testsuite/23_containers/vector/ext_pointer/types/2.cc (N::operator-): Make less specialized.
[Bug libstdc++/111948] subrange modifies a const size object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111948 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jonathan Wakely --- Fixed for 13.3, thanks for the report.
[Bug middle-end/112881] ICE: in count_type_elements, at expr.cc:7034 when initializing struct with a _BitInt(64) member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112881 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2023-12-06 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jakub Jelinek --- Created attachment 56816 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56816=edit gcc14-pr112881.patch Untested fix. Zdenek, thanks for all your work on these bugreports, it is very much appreciated.
[Bug libstdc++/112882] [14 Regression] std::clamp no longer usable in header only mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112882 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |14.0
[Bug preprocessor/111965] -fno-debug-cpp does not disable -fdebug-cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111965 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Jakub Jelinek --- Created attachment 56817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56817=edit gcc14-pr111965.patch Full lightly tested patch.
[Bug middle-end/88345] -Os overrides -falign-functions=N on the command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345 --- Comment #20 from Jan Hubicka --- > > Live patching (user-space) doesn't depend on any particular alignment of > functions, on x86-64 at least. (The plan for other architectures wouldn't > need > any specific alignment either). Note that the above complaints about missing > alignment is for kernel (!) ftrace/livepatching on arm64 (!), not on x86_64. I had impression that x86-64 also needs forced alignment so the patching can be always done atomically. But it is not a big practical difference if we go with a flag specifying minimal function alignment.
[Bug target/112411] ICE: SIGSEGV with --param=min-nondebug-insn-uid=2147483647 on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- I'm using this param all the time, but typically with low values (like 1000 or 1 depending on how large a problematic function is). I guess enforcing a range to be [1, INT_MAX / 2] or so wouldn't hurt anything and the likelyhood of overflow in that case is low (and likelyhood of needing more than INT_MAX / 2 debug insns in one function is also low).
[Bug libstdc++/109536] Failure to compile constexpr std::vector with -D_GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109536 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #4 from Jonathan Wakely --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639592.html
[Bug c++/112737] [14 Regression] g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112737 John David Anglin changed: What|Removed |Added CC||danglin at gcc dot gnu.org Target|cris-elf|cris-elf ||hppa-unknown-linux-gnu --- Comment #2 from John David Anglin --- Same errors occur on hppa-linux-gnu.
[Bug libstdc++/112314] Missing index assertions in basic_string_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112314 --- Comment #9 from GCC Commits --- The releases/gcc-12 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c5c57aa7e63da2e769f4fda6e2ec9e8bd0c7b344 commit r12-10029-gc5c57aa7e63da2e769f4fda6e2ec9e8bd0c7b344 Author: Jonathan Wakely Date: Wed Nov 1 15:01:22 2023 + libstdc++: Add assertion to std::string_view::remove_suffix [PR112314] libstdc++-v3/ChangeLog: PR libstdc++/112314 * include/std/string_view (string_view::remove_suffix): Add debug assertion. * testsuite/21_strings/basic_string_view/modifiers/remove_prefix/debug.cc: New test. * testsuite/21_strings/basic_string_view/modifiers/remove_suffix/debug.cc: New test. (cherry picked from commit 6afa984f47e16e8bd958646d7407b74e61041f5d)
[Bug target/112445] [14 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.cc:1861 unable to find a register to spill: {*umulditi3_1} with -O -march=cascadelake -fwrapv since r14-4968-g89e5d90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112445 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Thanks for the fix.
[Bug libstdc++/112882] [14 Regression] std::clamp no longer usable in header only mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112882 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-12-06 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- (In reply to Tamar Christina from comment #0) > I know this is not a supported scenario, but I'm wondering if it's still > easy to support. > > We have some libraries that use C++ mostly as an abstraction layer and try > to ensure that it needs no runtime support from libstdc++. > > A recent commit: g:5e8a30d8b8f4d7ea0a8340b46c1e0c865dbde781 changed how > `__glibcxx_assert` is defined and now always calls > `std::__glibcxx_assert_fail`. > > This means that now you always need libstdc++ even in contex where things > would have been folded away before. Similarly we're getting the same thing > through usage of `std::unique_ptr`. Ugh, that's undesirable. It should only depend on that symbol when _GLIBCXX_ASSERTIONS is defined, but the change means we also use that symbol for constexpr checks. I'm surprised it doesn't get folded away though, since the code looks like: if (std::__is_constant_evaluated()) if (__builtin_expect(COND, false)) __glibcxx_assert_fail(...); Since __is_constant_evaluated is always false at runtime, that function can never be called. Either it's needed during compile-time and makes the program ill-formed, or it's not needed at all. Ah, __is_constant_evaluated() is not marked always_inline, so at -O0 it just looks like a normal function call. > It seems that undefining `_GLIBCXX_VERBOSE_ASSERT` gets it to go to > `__builtin_abort()` which makes it work again. > > If this change was intentional, would it be possible to make > `_GLIBCXX_VERBOSE_ASSERT` user configurable? You can use --disable-libstdcxx-verbose for that, or do you need to control it during preprocessing?
[Bug middle-end/110639] [OpenMP][5.1] Predefined firstprivate for pointers - attachment missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110639 --- Comment #4 from Tobias Burnus --- There are *two* independent issues: (A) Predefined firstprivate does not find mappings done in the same directive, e.g. int a[100]; int *p = [0]; #pragma omp target teams distribute map(a) p[0] = 5; (B) The base pointer is not stored, hence, the following fails: int a[100]; int *p = [0]; // #pragma omp target enter data map(a[10:]) /* same result */ #pragma omp target teams distribute map(a[10:]) p[15] = 5; Here, map(a[10:]) /* or: map(a[start:n]) */ gives: map(tofrom:a[start] [len: _7]) map(firstprivate:a [pointer assign, bias: D.2943]) But then the basepointer is gone. Thus, any later lookup of an address that falls between basepointer and first mapped storage location is not found.
[Bug libstdc++/112480] optional::reset emits inefficient code when T is trivially-destructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112480 --- Comment #10 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:866870c51d58881819db6db76dcdfe3f43d89903 commit r13-8132-g866870c51d58881819db6db76dcdfe3f43d89903 Author: Jonathan Wakely Date: Sat Nov 11 00:35:18 2023 + libstdc++: Micro-optimization for std::optional [PR112480] This small change removes a branch when clearing a std::optional for types with no-op destructors. For types where the destructor can be optimized away (e.g. because it's trivial, or empty and can be inlined) the _M_destroy() function does nothing but set _M_engaged to false. Setting _M_engaged=false unconditionally is cheaper than only doing it when initially true, because it allows the compiler to remove a branch. The compiler thinks it would be incorrect to unconditionally introduce a store there, because it could conflict with reads in other threads, so it won't do that optimization itself. We know it's safe to do because we're in a non-const member function, so the standard forbids any potentially concurrent calls to other member functions of the same object. Making the store unconditional can't create a data race that isn't already present in the program. libstdc++-v3/ChangeLog: PR libstdc++/112480 * include/std/optional (_Optional_payload_base::_M_reset): Set _M_engaged to false unconditionally. (cherry picked from commit 2c492f99fc1fcb5f598286c3f3a21a05bca69d9e)
[Bug libstdc++/112832] [std::format] Broken non-SFINAE-friendly `set_debug_format()` for `const char *` formatter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112832 --- Comment #3 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d40796e3813fdf646ca7b7ce9630d5cc121353b4 commit r13-8130-gd40796e3813fdf646ca7b7ce9630d5cc121353b4 Author: Jonathan Wakely Date: Mon Dec 4 12:03:28 2023 + libstdc++: Disable std::formatter::set_debug_format [PR112832] All set_debug_format member functions should be guarded by the __cpp_lib_formatting_ranges macro (which is not defined yet). libstdc++-v3/ChangeLog: PR libstdc++/112832 * include/std/format (formatter::set_debug_format): Ensure this member is defined conditionally for all specializations. * testsuite/std/format/formatter/112832.cc: New test. (cherry picked from commit 3cd73543a1122d3c81409e3e9a26c3e94c3d324f)
[Bug libstdc++/110133] System error message should ideally use strerror_r over strerror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110133 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ca233ac9ba085e2acd385bda6a778684a0c96694 commit r13-8129-gca233ac9ba085e2acd385bda6a778684a0c96694 Author: Jonathan Wakely Date: Fri Nov 3 13:59:48 2023 + libstdc++: Use strerror_r in std::generic_category()::message(int) [PR110133] Use strerror_r instead of strerror when available, due to the latter not being thread-safe. This is complicated by Glibc providing a GNU-specific strerror_r which is not compatible with POSIX strerror_r, so we need to dispatch on the return type. Because we estimate the initial std::string buffer size we might end up with excess capacity in the returned std::string. We can slightly tweak the std::system_error constructors to make use of that excess capacity, so that in some cases we require fewer allocations to construct the std::system_error::what() string. libstdc++-v3/ChangeLog: PR libstdc++/110133 * include/std/system_error (system_error::system_error): Group arguments so that concatenation can reuse rvalue's capacity. * src/c++11/system_error.cc (strerror_string): New function. [_GLIBCXX_HAVE_STRERROR_R] (use_strerror_result): New functions. (generic_error_category::message): Use strerror_string. (system_error_category::message): Likewise. (cherry picked from commit 51f94778b45514992a716b0b2d7a87244e6f0018)
[Bug libstdc++/112473] integer_sequence accepts non-integer types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112473 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:f6ed5e0715da7040b04c465424bb33fcb95a5c20 commit r13-8131-gf6ed5e0715da7040b04c465424bb33fcb95a5c20 Author: Jonathan Wakely Date: Fri Nov 10 12:21:52 2023 + libstdc++: Add static_assert to std::integer_sequence [PR112473] C++20 allows class types as non-type template parameters, but std::integer_sequence explicitly disallows them. Enforce that. libstdc++-v3/ChangeLog: PR libstdc++/112473 * include/bits/utility.h (integer_sequence): Add static_assert. * testsuite/20_util/integer_sequence/112473.cc: New test. (cherry picked from commit 0953497a81f1e320989b9f2aaa7f56747eddd4a0)
[Bug libstdc++/111948] subrange modifies a const size object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111948 --- Comment #10 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:be26992b3115b95189ac02fcf25902cb5430c0e1 commit r13-8133-gbe26992b3115b95189ac02fcf25902cb5430c0e1 Author: Jonathan Wakely Date: Tue Oct 24 20:15:12 2023 +0100 libstdc++: Add workaround to std::ranges::subrange [PR111948] libstdc++-v3/ChangeLog: PR libstdc++/111948 * include/bits/ranges_util.h (subrange): Add constructor to _Size to avoid setting member in constructor. * testsuite/std/ranges/subrange/111948.cc: New test. (cherry picked from commit 08448dc146b6dd32383d64ab491a594d41f62aaa)
[Bug libstdc++/110133] System error message should ideally use strerror_r over strerror
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110133 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |13.3 Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- Fixed for 13.3, I don't think I'll backport it further.
[Bug libstdc++/112832] [std::format] Broken non-SFINAE-friendly `set_debug_format()` for `const char *` formatter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112832 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for 13.3, thanks for the report.
[Bug c++/112883] New: FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2b (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112883 Bug ID: 112883 Summary: FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2b (test for excess errors) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- On hppa-unknown-linux-gnu: FAIL: g++.dg/modules/xtreme-header-2_c.C -std=c++2b (test for excess errors) Excess errors: /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/format:3524:28: error: invalid use of non-static data member 'std::basic_format_args, wchar_t> >::__as_base ::' /home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/include/format:3527:19: error: invalid use of non-static data member 'std::basic_format_args, wchar_t> >::__as_base ::' Similar fails: FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors) See PR98531.
[Bug tree-optimization/112884] New: Missing optimization: fold a%2==0 ? a/2*2 : 0 to a%2==0 ? a : 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112884
Bug ID: 112884
Summary: Missing optimization: fold a%2==0 ? a/2*2 : 0 to
a%2==0 ? a : 0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: xxs_chy at outlook dot com
Target Milestone: ---
Godbolt example: https://godbolt.org/z/Ec1ax79r8
For the select arm "a / 2 * 2" in:
unsigned src(unsigned a) {
return a % 2 == 0 ? (a / 2 * 2) : 0;
}
it's equivalent to "a", so the program could be folded to:
unsigned tgt(unsigned a) {
return a % 2 == 0 ? a : 0;
}
Both GCC and LLVM missed such optimization in select arms.
[Bug libstdc++/112882] [14 Regression] std::clamp no longer usable in header only mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112882 Jonathan Wakely changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/112885] New: FAIL: gcc.dg/tree-ssa/ssa-sink-16.c (internal compiler error: Segmentation fault )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112885 Bug ID: 112885 Summary: FAIL: gcc.dg/tree-ssa/ssa-sink-16.c (internal compiler error: Segmentation fault ) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Created attachment 56818 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56818=edit Preprocessed source Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdi r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-16.c -f diagnostics-plain-output -O2 -fno-tree-pre -fno-tree-dominator-opts -fdump-tre e-sink -fdump-tree-optimized -S -o ssa-sink-16.s(timeout = 300) spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/obj dir/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-16.c -fdi agnostics-plain-output -O2 -fno-tree-pre -fno-tree-dominator-opts -fdump-tree-si nk -fdump-tree-optimized -S -o ssa-sink-16.s during GIMPLE pass: cddce /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-16.c: In function 'f': /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-16.c:5:5: internal compiler error: Segmentation fault 0x8b656f crash_signal ../../gcc/gcc/toplev.cc:316 0xa26a4c find_uses_to_rename_use ../../gcc/gcc/tree-ssa-loop-manip.cc:424 0xa26c03 find_uses_to_rename_use ../../gcc/gcc/tree-ssa-loop-manip.cc:414 0xa26c03 find_uses_to_rename_stmt ../../gcc/gcc/tree-ssa-loop-manip.cc:464 0xa26c03 find_uses_to_rename_bb ../../gcc/gcc/tree-ssa-loop-manip.cc:495 0xa27683 find_uses_to_rename ../../gcc/gcc/tree-ssa-loop-manip.cc:521 0xa27683 rewrite_into_loop_closed_ssa_1 ../../gcc/gcc/tree-ssa-loop-manip.cc:588 0xa27683 rewrite_into_loop_closed_ssa(bitmap_head*, unsigned int) ../../gcc/gcc/tree-ssa-loop-manip.cc:628 0x9075e7 repair_loop_structures ../../gcc/gcc/tree-cfgcleanup.cc:1190 0x9075e7 cleanup_tree_cfg(unsigned int) ../../gcc/gcc/tree-cfgcleanup.cc:1209 0x78089b execute_function_todo ../../gcc/gcc/passes.cc:2057 0x780ebb do_per_function ../../gcc/gcc/passes.cc:1687 0x78103f execute_todo ../../gcc/gcc/passes.cc:2142 Please submit a full bug report, with preprocessed source (by using -freport-bug). (gdb) r Starting program: /home/dave/gnu/gcc/objdir/gcc/cc1 -fpreprocessed ssa-sink-16.i -quiet -dumpbase ssa-sink-16.c -dumpbase-ext .c -O2 -version -fdiagnostics-color=never -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-urls=never -fdiagnostics-path-format=separate-events -fdiagnostics-text-art-charset=none -fno-tree-pre -fno-tree-dominator-opts -fdump-tree-sink -fdump-tree-optimized -o ssa-sink-16.s warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. GNU C17 (GCC) version 14.0.0 20231204 (experimental) [master r14-6126-g886f256ce3b] (hppa-linux-gnu) compiled by GNU C version 14.0.0 20231204 (experimental) [master r14-6126-g886f256ce3b], GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 04c59775674c2a8fe5fa9ca70cc96db0 Program received signal SIGSEGV, Segmentation fault. find_uses_to_rename_use (bb=0xfabdc070, use_blocks=0x191d580, need_phis=, use=) at ../../gcc/gcc/tree-ssa-loop-manip.cc:424 424 if (!loop_outer (def_loop)) (gdb) disass $pc-16,$pc+16 Dump of assembler code from 0xa26a3c to 0xa26a5c: 0x00a26a3c :ldw 10(r24),ret0 0x00a26a40 :cmpib,= 0,ret0,0xa26aa0 0x00a26a44 :copy r25,r3 0x00a26a48 :ldw c(ret0),r26 => 0x00a26a4c :ldw 20(r26),ret0 0x00a26a50 :cmpib,=,n 0,ret0,0xa26aa0 0x00a26a54 :ldw 4(ret0),r19 0x00a26a58 :cmpib,= 0,r19,0xa26aa0 End of assembler dump. (gdb) p/x $r26 $1 = 0x0 (gdb) bt #0 find_uses_to_rename_use (bb=0xfabdc070, use_blocks=0x191d580, need_phis=, use=) at ../../gcc/gcc/tree-ssa-loop-manip.cc:424 #1 0x00a26c04 in find_uses_to_rename_use (need_phis=0x19bacc0, use_blocks=0x191d580, use=, bb=0xfabdc070) at ../../gcc/gcc/tree-ssa-loop-manip.cc:414 #2 find_uses_to_rename_stmt (use_flags=5, need_phis=0x19bacc0, use_blocks=0x191d580, stmt=0xfabdc070) at ../../gcc/gcc/tree-ssa-loop-manip.cc:464 #3 find_uses_to_rename_bb (bb=, use_blocks=0x191d580, need_phis=0x19bacc0, use_flags=5) at ../../gcc/gcc/tree-ssa-loop-manip.cc:495 #4 0x00a27684 in find_uses_to_rename (use_flags=5, need_phis=0x191d580, use_blocks=0x191d580, changed_bbs=) at ../../gcc/gcc/tree-ssa-loop-manip.cc:521 #5 rewrite_into_loop_closed_ssa_1 (use_flags=5, update_flag=, changed_bbs=) at
[Bug target/112871] [14 Regression] RISCV ICE: in extract_insn, at recog.cc:2804 (unrecognizable insn) with -03 rv32gc_zicond
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112871 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug middle-end/112872] [14 Regression] RISCV ICE: in store_integral_bit_field, at expmed.cc:1049 with -03 rv64gcv_zvl1024b --param=riscv-autovec-preference=fixed-vlmax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112872 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0
[Bug rtl-optimization/112875] [14 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.cc:670 with -Oz -frounding-math -fno-dce -fno-trapping-math -fno-tree-dce -fno-tree-dse -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112875 Richard Biener changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org Status|UNCONFIRMED |NEW Summary|ICE: in |[14 Regression] ICE: in |lra_eliminate_regs_1, at|lra_eliminate_regs_1, at |lra-eliminations.cc:670 |lra-eliminations.cc:670 |with -Oz -frounding-math|with -Oz -frounding-math |-fno-dce -fno-trapping-math |-fno-dce -fno-trapping-math |-fno-tree-dce -fno-tree-dse |-fno-tree-dce -fno-tree-dse |-g |-g Last reconfirmed||2023-12-06 Known to work||13.2.1 Keywords||ice-on-valid-code, ||needs-bisection, ra Target||x86_64-*-* Ever confirmed|0 |1 Target Milestone|--- |14.0 Component|debug |rtl-optimization --- Comment #1 from Richard Biener --- Confirmed. #1 0x0147b8fc in lra_eliminate_regs_1 (insn=0x77201180, x=0x77203df0, mem_mode=E_VOIDmode, subst_p=true, update_p=false, update_sp_offset=..., full_p=false) at /space/rguenther/src/gcc/gcc/lra-eliminations.cc:670 670gcc_unreachable (); (gdb) l 665 return gen_rtx_USE (GET_MODE (x), new_rtx); 666return x; 667 668 case CLOBBER: 669 case SET: 670gcc_unreachable (); 671 672 default: 673break; 674 } (gdb) p debug_rtx (insn) (debug_insn 41 40 42 3 (var_location:SI q (fix:SI (plus:SF (float:SF (sign_extend:SI (mem/c:QI (plus:DI (reg/f:DI 19 frame) (const_int -12 [0xfff4])) [3 %sfp+-12 S1 A32]))) (clobber:SF (const_int 0 [0]) "t.c":9:7 -1 (nil))
[Bug c++/48026] #pragma optimize ignored for C++ for preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48026 Gwenole Beauchesne changed: What|Removed |Added CC||gb.devel at gmail dot com --- Comment #5 from Gwenole Beauchesne --- Created attachment 56811 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56811=edit Proposed patch against trunk Here is a proposed patch against trunk, which includes a fix for PR preprocessor/87299 (#pragma GCC target).
[Bug c++/48026] #pragma optimize ignored for C++ for preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48026 --- Comment #6 from Sam James --- (In reply to Gwenole Beauchesne from comment #5) > Created attachment 56811 [details] > Proposed patch against trunk > > Here is a proposed patch against trunk, which includes a fix for PR > preprocessor/87299 (#pragma GCC target). Could you send this to the mailing list if it's still relevant? Thanks. (https://gcc.gnu.org/contribute.html)
[Bug preprocessor/87299] #pragma GCC target behaves differently when using -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87299 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org Target Milestone|--- |14.0 --- Comment #7 from Sam James --- (In reply to Lewis Hyatt from comment #6) > Fixed for GCC 14. (Setting milestone, thanks!)
[Bug preprocessor/87299] #pragma GCC target behaves differently when using -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87299 --- Comment #8 from Gwenole Beauchesne --- Hi, can you please consider a backport to GCC 13 branch? The patch applies cleanly as is, but causes regressions that are further fixed with e45c564e (for PR pch/112319). GCC 13 is the first and most complete compiler for modern C++ (>= C++20) support and readily available, or soon available, as the system compiler for major distributions. This is useful to C++ projects that (debately) use multiple wrappers for SIMD support (xsimd, simde, mipp, etc.), but without correct support for runtime dispatching. So, using #pragma GCC target is a handy solution for that. Thanks.
[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876
康桓瑋 changed:
What|Removed |Added
Summary|rangesc.end() is|ranges:to: c.end() is
|unnecessarily assigned by |unnecessarily assigned by
|the return value of |the return value of
|c.emplace() |c.emplace()
--- Comment #1 from 康桓瑋 ---
which is not guaranteed to be well-formed.
#include
struct R {
std::string insert(int, int);
int end();
};
auto r = std::ranges::to(std::views::single(0));
[Bug tree-optimization/106511] [13/14 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener --- (In reply to Andrew Macleod from comment #8) > (In reply to Richard Biener from comment #2) > > VRP could use max_stmt_executions here (note it doesn't properly handle loop > > nests so the name is somewhat misleading) > > Do you have to ask for max_stmt_executions on each loop nest for the stmt to > get the real total? and multiple them all together? or can you only count > on loop_outer()? max_stmt_executions is for the loop you pass, not including outer loop (or containing irreducible region) iterations. The loop you usually pass is gimple_bb (stmt)->loop_father which is the immediately containing loop. This will be useful only when the PHI we want to analyze is in the very same loop, if it is in an outer loop then things become more complicated (you then could multiply by max_loop_iterations of the containing loop maybe - but start simple ;))
[Bug middle-end/112572] [14 regression] LLVM miscompiled since r14-5355-g3cd3a09b3f91a1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572 --- Comment #33 from Jakub Jelinek --- This should be now hopefully latent after r14-6210-ge44ed92dbbe9d4e5c23f486cd2f77a6f9ee513c5, we need to decide about the updating and usability of REG_UNUSED notes, but after moving the pass it shouldn't trigger on this testcase.
[Bug c++/41201] #pragma GCC target ("sse2") doesn't alter __SSE2__ in C++ (as it does in C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41201 Sam James changed: What|Removed |Added Depends on||87299 Target Milestone|--- |14.0 CC||lhyatt at gcc dot gnu.org See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=87299 | Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87299 [Bug 87299] #pragma GCC target behaves differently when using -save-temps
[Bug libstdc++/112876] New: rangesc.end() is unnecessarily assigned by the return value of c.emplace()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876 Bug ID: 112876 Summary: rangesc.end() is unnecessarily assigned by the return value of c.emplace() Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: ---
[Bug tree-optimization/112809] during GIMPLE pass: bitintlower ICE: in limb_access_type, at gimple-lower-bitint.cc:563 at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112809 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0ca64f846edce3c7b7f26bcc5978118e560e65b1 commit r14-6209-g0ca64f846edce3c7b7f26bcc5978118e560e65b1 Author: Jakub Jelinek Date: Wed Dec 6 09:55:30 2023 +0100 lower-bitint: Fix arithmetics followed by extension by many bits [PR112809] A zero or sign extension from result of some upwards_2limb operation is implemented in lower_mergeable_stmt as an extra loop which fills in the extra bits with 0s or 1s. If the delta of extended vs. unextended bit count is small, the code doesn't use a loop and emits up to a couple of stores to constant indexes, but if the delta is large, it uses cnt = (bo_bit != 0) + 1 + (rem != 0); statements. bo_bit is non-zero for bit-field loads and is done in that case as straight line, the unconditional 1 in there is for a loop which handles most of the limbs in the delta and finally (rem != 0) is for the case when the extended precision is not a multiple of limb_prec and is again done in straight line code (after the loop). The testcase ICEs because the decision what idx to use was incorrect for kind == bitint_prec_huge (i.e. when the precision delta is very large) and rem == 0 (i.e. the extended precision is multiple of limb_prec). In that case cnt is either 1 (if bo_bit == 0) or 2, and idx should be either first size_int (start) and then result of create_loop (for bo_bit != 0) or just result of create_loop, but by mistake the last case was size_int (end), which means when precision is multiple of limb_prec storing above the precision (which ICEs; but also not emitting the loop which is needed). 2023-12-06 Jakub Jelinek PR tree-optimization/112809 * gimple-lower-bitint.cc (bitint_large_huge::lower_mergeable_stmt): For separate_ext in kind == bitint_prec_huge mode if rem == 0, create for i == cnt - 1 the loop rather than using size_int (end). * gcc.dg/bitint-48.c: New test.
[Bug rtl-optimization/112760] [14 Regression] wrong code with -O2 -fno-dce -fno-guess-branch-probability -m8bit-idiv -mavx --param=max-cse-insns=0 and __builtin_add_overflow_p() since r14-5355
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112760 --- Comment #6 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e44ed92dbbe9d4e5c23f486cd2f77a6f9ee513c5 commit r14-6210-ge44ed92dbbe9d4e5c23f486cd2f77a6f9ee513c5 Author: Jakub Jelinek Date: Wed Dec 6 09:59:12 2023 +0100 i386: Move vzeroupper pass from after reload pass to after postreload_cse [PR112760] Regardless of the outcome of the REG_UNUSED discussions, I think it is a good idea to move the vzeroupper pass one pass later. As can be seen in the multiple PRs and as postreload.cc documents, reload/LRA is known to create dead statements quite often, which is the reason why we have postreload_cse pass at all. Doing vzeroupper pass before such cleanup means the pass including df_analyze for it needs to process more instructions than needed and because mode switching adds note problem, also higher chance of having stale REG_UNUSED notes. And, I really don't see why vzeroupper can't wait until those cleanups are done. 2023-12-06 Jakub Jelinek PR rtl-optimization/112760 * config/i386/i386-passes.def (pass_insert_vzeroupper): Insert after pass_postreload_cse rather than pass_reload. * config/i386/i386-features.cc (rest_of_handle_insert_vzeroupper): Adjust comment for it. * gcc.dg/pr112760.c: New test.
[Bug rtl-optimization/112760] [14 Regression] wrong code with -O2 -fno-dce -fno-guess-branch-probability -m8bit-idiv -mavx --param=max-cse-insns=0 and __builtin_add_overflow_p() since r14-5355
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112760 --- Comment #7 from Jakub Jelinek --- This is now latent, we need to decide about the updating and usability of REG_UNUSED notes, but after moving the pass it shouldn't trigger on this testcase.
[Bug middle-end/112877] New: TARGET_PROMOTE_PROTOTYPES is not honored consistently, should maybe not apply to builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112877 Bug ID: 112877 Summary: TARGET_PROMOTE_PROTOTYPES is not honored consistently, should maybe not apply to builtins Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- Currently only the C, C++ and Ada frontends honor (maybe partly) TARGET_PROMOTE_PROTOTYPES so this is at most an optimization feature, in particular it doesn't look like the target can guarantee ABI constraints with this (zero/sign extending arguments at callers). TARGET_PROMOTE_PROTOTYPES should be (and is AFAICS) reflected into DECL_ARG_TYPE. combine is the only thing lookig at DECL_ARG_TYPE. The iq2000, microblaze and PA targets look at DECL_ARG_TYPE (didn't look at what). In particular the vectorizer is pessimized by the promotion when vectorizing builtins working on < int arguments and for OMP SIMD function vectorization. Targets might get more control when the hook were passed a function decl rather than only a function type. But since nothing on the GIMPLE level cares about DECL_ARG_TYPE it might be possible to reflect TARGET_PROMOTE_PROTOTYPES only during RTL expansion.
[Bug c++/41201] #pragma GCC target ("sse2") doesn't alter __SSE2__ in C++ (as it does in C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41201 Gwenole Beauchesne changed: What|Removed |Added CC||gb.devel at gmail dot com --- Comment #8 from Gwenole Beauchesne --- Hi, this is a duplicate of PR preprocessor/87299, which is now fixed for GCC 14.
[Bug c++/41201] #pragma GCC target ("sse2") doesn't alter __SSE2__ in C++ (as it does in C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41201 Sam James changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Sam James --- Fixed for 14. Thanks!
[Bug c++/48026] #pragma optimize ignored for C++ for preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48026
Bug 48026 depends on bug 41201, which changed state.
Bug 41201 Summary: #pragma GCC target ("sse2") doesn't alter __SSE2__ in C++
(as it does in C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41201
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
[Bug target/112868] GCC passes -many to the assembler for --enable-checking=release builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112868 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #4 from Sam James --- I was quite surprised by this behaviour. It should really be documented if we're going to stick with it, but I don't think we should at all..
[Bug libstdc++/112876] ranges:to: c.end() is unnecessarily assigned by the return value of c.emplace()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876 --- Comment #2 from 康桓瑋 --- I believe the above is well-formed after LWG 4016. In addition, container-appendable requires `c.emplace(c.end(), *it)` to be well-formed but `auto end = c.end(); c.emplace(end, *it);` may not be. Sorry for the pedantic.
[Bug middle-end/112872] [14 Regression] RISCV ICE: in store_integral_bit_field, at expmed.cc:1049 with -03 rv64gcv_zvl1024b --param=riscv-autovec-preference=fixed-vlmax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112872 --- Comment #2 from Robin Dapp --- Thanks. Yes that's similar and also looks fixed by the introduction of the vec_init expander. Added this test case to the patch and will push it soon.
[Bug tree-optimization/112809] during GIMPLE pass: bitintlower ICE: in limb_access_type, at gimple-lower-bitint.cc:563 at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112809 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Should be fixed now.
[Bug middle-end/88345] -Os overrides -falign-functions=N on the command line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #18 from Jan Hubicka --- Reading all the discussion again, I am leaning towards -falign-all-functions + documentation update explaining that -falign-functions/-falign-loops are optimizations and ignored for -Os. I do use -falign-functions/-falign-loops when tuning for new generations of CPUs and I definitely want to have way to specify alignment that is ignored for cold functions (as perforance optimization) and we have this behavior since profile code was introduced in 2002. As an optimization, we also want to have hot functions aligned more than 8 byte boundary needed for patching. I will prepare patch for this and send it for disucssion. Pehraps we want -flive-patching to also imply FUNCTION_BOUNDARY increase on x86-64? Or is live patching useful if function entries are not aligned?
[Bug middle-end/112872] [14 Regression] RISCV ICE: in store_integral_bit_field, at expmed.cc:1049 with -03 rv64gcv_zvl1024b --param=riscv-autovec-preference=fixed-vlmax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112872 --- Comment #3 from GCC Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:056cce412862f8d9b56a40dfbcbc3f9fa7f92883 commit r14-6211-g056cce412862f8d9b56a40dfbcbc3f9fa7f92883 Author: Robin Dapp Date: Tue Dec 5 15:24:12 2023 +0100 RISC-V: Add vec_init expander for masks [PR112854]. PR112854 shows a problem on rv32 with zvl1024b. During the course of expand_constructor we try to overlay/subreg a 64-element mask by a scalar (Pmode) register. This works for zvl512b and its maximum of 32 elements but fails for rv32 and 64 elements. To circumvent this this patch adds a vec_init expander for vector masks by initializing a QImode vector and comparing that against 0. gcc/ChangeLog: PR target/112854 PR target/112872 * config/riscv/autovec.md (vec_initqi): New expander. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/pr112854.c: New test. * gcc.target/riscv/rvv/autovec/pr112872.c: New test.
[Bug middle-end/112854] [14] RISCV ICE: expand: in store_integral_bit_field, at expmed.cc:1049 on rv32gcv_zvl1024b --param=riscv-autovec-preference=fixed-vlmax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112854 --- Comment #4 from GCC Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:056cce412862f8d9b56a40dfbcbc3f9fa7f92883 commit r14-6211-g056cce412862f8d9b56a40dfbcbc3f9fa7f92883 Author: Robin Dapp Date: Tue Dec 5 15:24:12 2023 +0100 RISC-V: Add vec_init expander for masks [PR112854]. PR112854 shows a problem on rv32 with zvl1024b. During the course of expand_constructor we try to overlay/subreg a 64-element mask by a scalar (Pmode) register. This works for zvl512b and its maximum of 32 elements but fails for rv32 and 64 elements. To circumvent this this patch adds a vec_init expander for vector masks by initializing a QImode vector and comparing that against 0. gcc/ChangeLog: PR target/112854 PR target/112872 * config/riscv/autovec.md (vec_initqi): New expander. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/pr112854.c: New test. * gcc.target/riscv/rvv/autovec/pr112872.c: New test.
[Bug tree-optimization/89618] Inner loop won't vectorize unless dummy statement is included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89618 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #6 from Richard Biener --- Fixed.
[Bug libstdc++/105562] [12 Regression] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562 --- Comment #25 from Romain Geissler --- So it means we should rather go for "silencing" workaround from comment #19 ?
[Bug libstdc++/105562] [12 Regression] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562 --- Comment #26 from rguenther at suse dot de --- On Wed, 6 Dec 2023, romain.geissler at amadeus dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562 > > --- Comment #25 from Romain Geissler --- > So it means we should rather go for "silencing" workaround from comment #19 ? No, I think people shouldn't care for warnings with -fsanitize=... (or not use -Wall).
[Bug libstdc++/105562] [12 Regression] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #23 from Romain Geissler --- Hi, We have also hit an occurence of this bug while using address sanitizer and gcc 13. I see in comment #22 Jakub proposes to re-open this ticket, but I can re-create a dedicated one just for the ASAN related issue if you prefer. I don't know if the proposal to silence this warning made by Jonathan in #19 is considered a "long term fix" for this or just a temporary solution until the internal compiler bug is fixed. Cheers, Romain
[Bug target/112853] RISC-V: RVV: SPEC2017 525.x264 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112853 --- Comment #8 from Robin Dapp --- With Juzhe's latest fix that disables VLS modes >= 128 bit for zvl128b x264 runs without issues here and some of the additional execution failures are gone. Will post the current comparison later.
[Bug libstdc++/105562] [12 Regression] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562 --- Comment #24 from Richard Biener --- The bug wasn't about uninit diagnostics with ASAN but without. There are plenty of diagnostic "bugs" when sanitizing is enabled and those are really hard to fix since plenty of diagnostics rely on optimization to avoid false positives which ASAN and friends prohibit.
[Bug middle-end/98673] pass fre4 inhibit pass dom3 to create much more optimized code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98673 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #7 from Richard Biener --- No updates, verified the code is still the same, assuming not an issue.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 106722, which changed state. Bug 106722 Summary: bogus uninit warning in tree-vect-loop-manip.cc https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106722 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/106722] bogus uninit warning in tree-vect-loop-manip.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106722 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener --- I think this is fixed now, the preprocessed source isn't accepted for me anymore on trunk.
[Bug libstdc++/105562] [12 Regression] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562 --- Comment #27 from Jakub Jelinek --- That is just a very partial solution. As mentioned in lots of other bugreports, one should simply ignore or take with a grain of salt warnings from the instrumented builds (whether it is -fsanitize=undefined, -fsanitize=address, -fsanitize=thread or I think -fprofile-generate or similar as well). Any such instrumentation significantly modifies the intermediate language and prevents various optimizations which necessarily lead to more false positives in the non-frontend warnings. So, best similarly to what libtool does when compiling a file twice, once with -fpic, once without, redirects diagnostics of one to /dev/null, go with 2 builds, one sanitized/instrumented with -w, another non-instrumented with full warnings. The big question is if the compiler should do that by default (simply ignore all middle-end warnings in instrumented functions), or if we should provide some support in the driver for building stuff twice, once instrumented without middle-end warnings, once non-instrumented with warnings. We already have -fcompare-debug which does something similar (build normally and -gtoggle -w.
[Bug debug/112878] New: ICE: in ctf_add_slice, at ctfc.cc:499 with -std=c23 -gctf1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112878
Bug ID: 112878
Summary: ICE: in ctf_add_slice, at ctfc.cc:499 with -std=c23
-gctf1
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/root/gcc_set/202311291030/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/202311291030/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/202311291030
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leak
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231129 (experimental) (GCC)
git version: 99fa0bfd63d97825c4221dcd3123940f1d0e6291
***
Program:
$ cat mutant.c
struct {
_BitInt(282) a : 280;
} b;
***
Command Lines:
$ gcc -std=c23 -gctf1 mutant.c
mutant.c:3:1: internal compiler error: in ctf_add_slice, at ctfc.cc:499
3 | } b;
| ^
0x8d0e95 ctf_add_slice(ctf_container*, unsigned int, unsigned long, unsigned
int, unsigned int, die_struct*)
../../gcc/gcc/ctfc.cc:499
0xb6a770 gen_ctf_sou_type
../../gcc/gcc/dwarf2ctf.cc:617
0xb69fb7 gen_ctf_type
../../gcc/gcc/dwarf2ctf.cc:892
0xb6aa61 ctf_do_die(die_struct*)
../../gcc/gcc/dwarf2ctf.cc:978
0xbbc62b ctf_debug_do_cu
../../gcc/gcc/dwarf2out.cc:32985
0xbbc62b ctf_debug_do_cu
../../gcc/gcc/dwarf2out.cc:32978
0xbbc62b dwarf2out_early_finish
../../gcc/gcc/dwarf2out.cc:33114
0xb2411f symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.cc:2578
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109289 Thomas Schwinge changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #8 from Thomas Schwinge --- (In reply to myself from comment #2) > [...]/source-gcc/libgcc/emutls.c: In function ‘__emutls_get_address’: > [...]/source-gcc/libgcc/emutls.c:172:13: error: implicit declaration of > function ‘calloc’ [-Wimplicit-function-declaration] > 172 | arr = calloc (size + 1, sizeof (void *)); > | ^~ > [...]/source-gcc/libgcc/emutls.c:32:1: note: include ‘’ or > provide a declaration of ‘calloc’ >31 | #include "gthr.h" > +++ |+#include >32 | > [...]/source-gcc/libgcc/emutls.c:172:13: warning: incompatible implicit > declaration of built-in function ‘calloc’ [-Wbuiltin-declaration-mismatch] > 172 | arr = calloc (size + 1, sizeof (void *)); > | ^~ > [...]/source-gcc/libgcc/emutls.c:172:13: note: include ‘’ or > provide a declaration of ‘calloc’ > [...]/source-gcc/libgcc/emutls.c:184:13: error: implicit declaration of > function ‘realloc’ [-Wimplicit-function-declaration] > 184 | arr = realloc (arr, (size + 1) * sizeof (void *)); > | ^~~ > [...]/source-gcc/libgcc/emutls.c:184:13: note: include ‘’ or > provide a declaration of ‘realloc’ > [...]/source-gcc/libgcc/emutls.c:184:13: warning: incompatible implicit > declaration of built-in function ‘realloc’ [-Wbuiltin-declaration-mismatch] > [...]/source-gcc/libgcc/emutls.c:184:13: note: include ‘’ or > provide a declaration of ‘realloc’ > GCC's suggestion to "include ‘’" needs to be carefully reviewed, > in case this is meant to be buildable in an environment without C library > headers? (In reply to Florian Weimer from comment #3) > Thomas, the safe thing to do would be to use __builtin_calloc and > __builtin_realloc in those spots because it avoids a dependency on an > external header that might not exist at this point. That part got resolved differently, in commit r14-6207-g6e84dafcc72d1cd6d028b42f1801e092a91d3214 "tsystem.h: Declare calloc/realloc #ifdef inhibit_libc".
[Bug target/112879] New: [14 Regression] 4% exec time regression of 525.x264_r on AMD Zen4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112879 Bug ID: 112879 Summary: [14 Regression] 4% exec time regression of 525.x264_r on AMD Zen4 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: needs-bisection Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: fkastl at suse dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu There's a 4% slowdown of 525.x264_r on AMD Zen4 between commits g:af7fa3135b6b046f g:e85c596ae2d1e5f5 Here is a plot showing this regression: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=958.377.0 I've seen this regression on two different Zen4 machines but haven't observed it on machines with different architecture.
[Bug libstdc++/105562] [12 Regression] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562 --- Comment #28 from Romain Geissler --- Ok it's clear. I haven't really played yet with sanitizers, I didn't know it had these well known "issue" with creating more middle end false positive warnings (I am used to them in LTO mode). So I will advise that we relax warning severity/disable some warnings in my company when using sanitizers. Thanks !
[Bug libstdc++/105562] [12 Regression] std::function::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #29 from Sam James --- (In reply to Romain Geissler from comment #28) > Ok it's clear. I haven't really played yet with sanitizers, I didn't know it > had these well known "issue" with creating more middle end false positive > warnings (I am used to them in LTO mode). > > So I will advise that we relax warning severity/disable some warnings in my > company when using sanitizers. > > Thanks ! See also https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fsanitize_003dbuiltin. "Note that sanitizers tend to increase the rate of false positive warnings, most notably those around -Wmaybe-uninitialized. We recommend against combining -Werror and [the use of] sanitizers."
[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109289
--- Comment #9 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d7ceffab96ecd021d3e869dff33d0ad4b8577c4f
commit r14-6218-gd7ceffab96ecd021d3e869dff33d0ad4b8577c4f
Author: Jakub Jelinek
Date: Wed Dec 6 12:27:12 2023 +0100
libgcc: Avoid -Wbuiltin-declaration-mismatch warnings in emutls.c
When libgcc is being built in --disable-tls configuration or on
a target without native TLS support, one gets annoying warnings:
../../../../libgcc/emutls.c:61:7: warning: conflicting types for built-in
function â__emutls_get_addressâ; expected âvoid *(void *)â
[-Wbuiltin-declaration-mismatch]
61 | void *__emutls_get_address (struct __emutls_object *);
| ^~~~
../../../../libgcc/emutls.c:63:6: warning: conflicting types for built-in
function â__emutls_register_commonâ; expected âvoid(void *, unsigned int,
unsigned int, void *)â
+[-Wbuiltin-declaration-mismatch]
63 | void __emutls_register_common (struct __emutls_object *, word,
word, void *);
| ^~~~
../../../../libgcc/emutls.c:140:1: warning: conflicting types for built-in
function â__emutls_get_addressâ; expected âvoid *(void *)â
[-Wbuiltin-declaration-mismatch]
140 | __emutls_get_address (struct __emutls_object *obj)
| ^~~~
../../../../libgcc/emutls.c:204:1: warning: conflicting types for built-in
function â__emutls_register_commonâ; expected âvoid(void *, unsigned int,
unsigned int, void *)â
+[-Wbuiltin-declaration-mismatch]
204 | __emutls_register_common (struct __emutls_object *obj,
| ^~~~
The thing is that in that case __emutls_get_address and
__emutls_register_common are builtins, and are declared with void *
arguments rather than struct __emutls_object *.
Now, struct __emutls_object is a type private to libgcc/emutls.c and the
middle-end creates on demand when calling the builtins a similar structure
(with small differences, like not having the union in there).
We have a precedent for this e.g. for fprintf or strftime builtins where
the builtins are created with magic fileptr_type_node or
const_tm_ptr_type_node
types and then match it with user definition of pointers to some structure,
but I think for this case users should never define these functions
themselves nor call them and having special types for them in the compiler
would mean extra compile time spent during compiler initialization and more
GC data, so I think it is better to keep the compiler as is.
On the library side, there is an option to just follow what the
compiler is doing and do
EMUTLS_ATTR void
-__emutls_register_common (struct __emutls_object *obj,
+__emutls_register_common (void *xobj,
word size, word align, void *templ)
{
+ struct __emutls_object *obj = (struct __emutls_object *) xobj;
but that will make e.g. libabigail complain about ABI change in libgcc.
So, the patch just turns the warning off.
2023-12-06 Thomas Schwinge
Jakub Jelinek
PR libgcc/109289
* emutls.c: Add GCC diagnostic ignored
"-Wbuiltin-declaration-mismatch"
pragma.
[Bug tree-optimization/112880] New: ICE: in smallest_mode_for_size, at stor-layout.cc:356 with __builtin_mul_overflow() of _BitInt(1024)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112880 Bug ID: 112880 Summary: ICE: in smallest_mode_for_size, at stor-layout.cc:356 with __builtin_mul_overflow() of _BitInt(1024) Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 56812 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56812=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O testcase.c during GIMPLE pass: cddce testcase.c: In function 'foo': testcase.c:7:1: internal compiler error: in smallest_mode_for_size, at stor-layout.cc:356 7 | } | ^ 0x14dedcf smallest_mode_for_size(poly_int<1u, unsigned long>, mode_class) /repo/gcc-trunk/gcc/stor-layout.cc:356 0x14e3715 smallest_int_mode_for_size(poly_int<1u, unsigned long>) /repo/gcc-trunk/gcc/machmode.h:916 0x14e3715 layout_type(tree_node*) /repo/gcc-trunk/gcc/stor-layout.cc:2405 0x1809acc build_nonstandard_integer_type(unsigned long, int) /repo/gcc-trunk/gcc/tree.cc:7129 0x16251ec maybe_optimize_arith_overflow /repo/gcc-trunk/gcc/tree-ssa-dce.cc:1246 0x16271b1 eliminate_unnecessary_stmts /repo/gcc-trunk/gcc/tree-ssa-dce.cc:1491 0x16271b1 perform_tree_ssa_dce /repo/gcc-trunk/gcc/tree-ssa-dce.cc:1973 0x1627785 tree_ssa_cd_dce /repo/gcc-trunk/gcc/tree-ssa-dce.cc:2014 0x1627785 execute /repo/gcc-trunk/gcc/tree-ssa-dce.cc:2097 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-6210-20231206095912-ge44ed92dbbe-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-6210-20231206095912-ge44ed92dbbe-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231206 (experimental) (GCC)
[Bug target/112879] [14 Regression] 4% exec time regression of 525.x264_r on AMD Zen4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112879 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 CC||liuhongt at gcc dot gnu.org --- Comment #1 from Richard Biener --- Possibly the reduc_* support in the backend now BB vectorizes unprofitable cases.
[Bug libstdc++/112858] [14 Regression] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858
--- Comment #5 from Thomas Schwinge ---
(I did see that the '__cxa_thread_atexit_impl' issue has been resolved
differently, but there is a genuine GCC/nvptx issue here.)
(In reply to myself from comment #1)
> Indeed in 'build-gcc/nvptx-none/libstdc++-v3/libsupc++/atexit_thread.o' I
> see:
>
> // BEGIN GLOBAL FUNCTION DECL: __cxa_thread_atexit_impl
> .extern .func (.param .u32 %value_out) __cxa_thread_atexit_impl (.param
> .u64 %in_ar0, .param .u64 %in_ar1, .param .u64 %in_ar2);
>
> That is, '.extern' instead of '.weak' linking directive, huh.
That one indeed is a GCC/nvptx back end issue. A fix might look similar to the
following:
--- gcc/config/nvptx/nvptx.cc
+++ gcc/config/nvptx/nvptx.cc
@@ -1001,10 +1001,11 @@ write_fn_proto_1 (std::stringstream , bool
is_defn,
const char *name, const_tree decl, bool force_public)
{
- if (lookup_attribute ("alias", DECL_ATTRIBUTES (decl)) == NULL)
+ if (lookup_attribute ("alias", DECL_ATTRIBUTES (decl)) == NULL
+ && !DECL_WEAK (decl))
write_fn_marker (s, is_defn, TREE_PUBLIC (decl) || force_public,
name);
/* PTX declaration. */
if (DECL_EXTERNAL (decl))
-s << ".extern ";
+s << (DECL_WEAK (decl) ? ".weak " : ".extern ");
else if (TREE_PUBLIC (decl) || force_public)
s << (DECL_WEAK (decl) ? ".weak " : ".visible ");
> ..., but still doing the NULL check: [...]
..., and that check ('if (__cxa_thread_atexit_impl)') then fails to assemble,
and thus the build (!) fails:
ptxas fatal : Cannot take address of function '__cxa_thread_atexit_impl'
Thus, more smarts are needed to make "weak, undefined" work. (May be able to
fix this up in the linker, assuming seeing the whole program; similar to
PR105018 "[nvptx] Need better alias support" ideas?) (For reference, "weak,
defined" does not run into this problem.)
[Bug middle-end/112881] New: ICE: in count_type_elements, at expr.cc:7034 when initializing struct with a _BitInt(64) member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112881
Bug ID: 112881
Summary: ICE: in count_type_elements, at expr.cc:7034 when
initializing struct with a _BitInt(64) member
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 56813
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56813=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c
testcase.c: In function 'foo':
testcase.c:9:13: internal compiler error: in count_type_elements, at
expr.cc:7034
9 | (struct S){ p };
| ^
0x7578aa count_type_elements
/repo/gcc-trunk/gcc/expr.cc:7034
0x109c10a categorize_ctor_elements_1
/repo/gcc-trunk/gcc/expr.cc:7146
0x1194cb7 gimplify_init_constructor
/repo/gcc-trunk/gcc/gimplify.cc:5473
0x11a1acd gimplify_modify_expr
/repo/gcc-trunk/gcc/gimplify.cc:6357
0x118df99 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:16719
0x1190936 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7476
0x119f4e3 gimplify_and_add(tree_node*, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:493
0x119f4e3 gimplify_decl_expr
/repo/gcc-trunk/gcc/gimplify.cc:2139
0x118eda3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:16916
0x1190936 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7476
0x11909e7 gimplify_and_add(tree_node*, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:493
0x11909e7 gimplify_compound_literal_expr
/repo/gcc-trunk/gcc/gimplify.cc:5338
0x118e64b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:16713
0x1190936 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7476
0x1191a39 gimplify_bind_expr
/repo/gcc-trunk/gcc/gimplify.cc:1614
0x118eea3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:16920
0x11b0664 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7476
0x11b0664 gimplify_body(tree_node*, bool)
/repo/gcc-trunk/gcc/gimplify.cc:17986
0x11b0a9a gimplify_function_tree(tree_node*)
/repo/gcc-trunk/gcc/gimplify.cc:18185
0xfb50e7 cgraph_node::analyze()
/repo/gcc-trunk/gcc/cgraphunit.cc:685
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-6210-20231206095912-ge44ed92dbbe-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-6210-20231206095912-ge44ed92dbbe-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231206 (experimental) (GCC)
[Bug target/112879] [14 Regression] 4% exec time regression of 525.x264_r on AMD Zen4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112879 --- Comment #2 from Hongtao Liu --- (In reply to Richard Biener from comment #1) > Possibly the reduc_* support in the backend now BB vectorizes unprofitable > cases. maybe zmm reduction, and we should have reasonable cost for reduction vec_to_scalar.
[Bug target/112891] [10/11/12/13/14 Regression] Missing vzeroupper insert.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112891 --- Comment #2 from Hongtao Liu --- (In reply to Hongtao Liu from comment #1) > Aaused by r10-3477-g2a2e3a0dfcbe08, Can be fixed by revert the patch. > > --- a/gcc/config/i386/i386.cc > +++ b/gcc/config/i386/i386.cc > @@ -15032,14 +15032,7 @@ ix86_avx_u128_mode_needed (rtx_insn *insn) >if (avx_upper_reg_found) > return AVX_U128_DIRTY; > > - /* If the function is known to preserve some SSE registers, > -RA and previous passes can legitimately rely on that for > -modes wider than 256 bits. It's only safe to issue a > -vzeroupper if all SSE registers are clobbered. */ > - const function_abi = insn_callee_abi (insn); > - if (vzeroupper_pattern (PATTERN (insn), VOIDmode) > - || !hard_reg_set_subset_p (reg_class_contents[SSE_REGS], > -abi.mode_clobbers (V4DImode))) > + if (vzeroupper_pattern (PATTERN (insn), VOIDmode)) > return AVX_U128_ANY; > >return AVX_U128_CLEAN; Remove this regressed many testcases So it looks like we need to handle ix86_avx_u128_mode_after --- a/gcc/config/i386/i386.cc +++ b/gcc/config/i386/i386.cc @@ -15177,7 +15177,14 @@ ix86_avx_u128_mode_after (int mode, rtx_insn *insn) bool avx_upper_reg_found = false; note_stores (insn, ix86_check_avx_upper_stores, _upper_reg_found); - return avx_upper_reg_found ? AVX_U128_DIRTY : AVX_U128_CLEAN; + if (avx_upper_reg_found) + return AVX_U128_DIRTY; + + const function_abi = insn_callee_abi (insn); + if (!hard_reg_set_subset_p (reg_class_contents[SSE_REGS], + abi.mode_clobbers (V4DImode))) + return AVX_U128_ANY; + return AVX_U128_CLEAN; }
[Bug testsuite/112894] [14 Regression] g++.dg/warn/Winvalid-memory-model-2.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112894 --- Comment #2 from Andrew Pinski --- Maybe caused by https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5e8a30d8b8f4d7ea0a8340b46c1e0c865dbde781 ...
[Bug analyzer/112850] -Wanalyzer-tainted-allocation-size false positive seen in Linux kernel's sound/core/rawmidi.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112850 --- Comment #1 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:08b7462d3ad8e5acd941b7c777c5b26b4064d686 commit r14-6239-g08b7462d3ad8e5acd941b7c777c5b26b4064d686 Author: David Malcolm Date: Wed Dec 6 19:25:26 2023 -0500 analyzer: fix taint false positives with UNKNOWN [PR112850] PR analyzer/112850 reports a false positive from -Wanalyzer-tainted-allocation-size on the Linux kernel [1] where -fanalyzer complains that an allocation size is attacker-controlled despite the value being correctly sanitized against upper and lower limits. The root cause is that the expression is sufficiently complex to exceed the -param=analyzer-max-svalue-depth= threshold, currently at 12, with depth 13, and so it is treated as UNKNOWN. Hence the sanitizations are seen as comparisons of an UNKNOWN symbolic value against constants, and these were being ignored by the taint state machine. The expression in question is relatively typical for those seen in Linux kernel ioctl handlers, and I was surprised that it had exceeded the analyzer's default expression complexity limit. This patch addresses this problem in three ways: (a) the default value of the threshold parameter is increased, from 12 to 18, so that such expressions are precisely handled (b) adding a new -Wanalyzer-symbol-too-complex to warn when the symbol complexity limit is reached. This is off by default for users, and on by default in the test suite. (c) the taint state machine handles comparisons against UNKNOWN svalues by dropping all taint information on that execution path, so that if the complexity limit has been exceeded we don't generate false positives As well as fixing the taint false positive (PR analyzer/112850), the patch also fixes a couple of leak false positives seen on flex-generated scanners (PR analyzer/103546). [1] specifically, in sound/core/rawmidi.c's handler for SNDRV_RAWMIDI_STREAM_OUTPUT. gcc/ChangeLog: PR analyzer/103546 PR analyzer/112850 * doc/invoke.texi: Add -Wanalyzer-symbol-too-complex. gcc/analyzer/ChangeLog: PR analyzer/103546 PR analyzer/112850 * analyzer.opt (-param=analyzer-max-svalue-depth=): Increase from 12 to 18. (Wanalyzer-symbol-too-complex): New. * diagnostic-manager.cc (null_assignment_sm_context::clear_all_per_svalue_state): New. * engine.cc (impl_sm_context::clear_all_per_svalue_state): New. * program-state.cc (sm_state_map::clear_all_per_svalue_state): New. * program-state.h (sm_state_map::clear_all_per_svalue_state): New decl. * region-model-manager.cc (region_model_manager::reject_if_too_complex): Add -Wanalyzer-symbol-too-complex. * sm-taint.cc (taint_state_machine::on_condition): Handle comparisons against UNKNOWN. * sm.h (sm_context::clear_all_per_svalue_state): New. gcc/testsuite/ChangeLog: PR analyzer/103546 PR analyzer/112850 * c-c++-common/analyzer/call-summaries-pr107158-2.c: Add -Wno-analyzer-symbol-too-complex. * c-c++-common/analyzer/call-summaries-pr107158.c: Likewise. * c-c++-common/analyzer/deref-before-check-pr109060-haproxy-cfgparse.c: Likewise. * c-c++-common/analyzer/feasibility-3.c: Add -Wno-analyzer-too-complex and -Wno-analyzer-symbol-too-complex. * c-c++-common/analyzer/flex-with-call-summaries.c: Add -Wno-analyzer-symbol-too-complex. Remove fail for PR analyzer/103546 leak false positive. * c-c++-common/analyzer/flex-without-call-summaries.c: Remove xfail for PR analyzer/103546 leak false positive. * c-c++-common/analyzer/infinite-recursion-3.c: Add -Wno-analyzer-symbol-too-complex. * c-c++-common/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early-O2.c: Likewise. * c-c++-common/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c: Likewise. * c-c++-common/analyzer/null-deref-pr108400-SoftEtherVPN-WebUi.c: Likewise. * c-c++-common/analyzer/null-deref-pr108806-qemu.c: Likewise. * c-c++-common/analyzer/null-deref-pr108830.c: Likewise. * c-c++-common/analyzer/pr94596.c: Likewise. * c-c++-common/analyzer/strtok-2.c: Likewise. * c-c++-common/analyzer/strtok-4.c: Add -Wno-analyzer-too-complex and -Wno-analyzer-symbol-too-complex. * c-c++-common/analyzer/strtok-cppreference.c: Likewise. * gcc.dg/analyzer/analyzer.exp: Add -Wanalyzer-symbol-too-complex
[Bug analyzer/103546] -Wanalyzer-null-dereference false positives reported on flex-generated scanners
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103546 --- Comment #8 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:08b7462d3ad8e5acd941b7c777c5b26b4064d686 commit r14-6239-g08b7462d3ad8e5acd941b7c777c5b26b4064d686 Author: David Malcolm Date: Wed Dec 6 19:25:26 2023 -0500 analyzer: fix taint false positives with UNKNOWN [PR112850] PR analyzer/112850 reports a false positive from -Wanalyzer-tainted-allocation-size on the Linux kernel [1] where -fanalyzer complains that an allocation size is attacker-controlled despite the value being correctly sanitized against upper and lower limits. The root cause is that the expression is sufficiently complex to exceed the -param=analyzer-max-svalue-depth= threshold, currently at 12, with depth 13, and so it is treated as UNKNOWN. Hence the sanitizations are seen as comparisons of an UNKNOWN symbolic value against constants, and these were being ignored by the taint state machine. The expression in question is relatively typical for those seen in Linux kernel ioctl handlers, and I was surprised that it had exceeded the analyzer's default expression complexity limit. This patch addresses this problem in three ways: (a) the default value of the threshold parameter is increased, from 12 to 18, so that such expressions are precisely handled (b) adding a new -Wanalyzer-symbol-too-complex to warn when the symbol complexity limit is reached. This is off by default for users, and on by default in the test suite. (c) the taint state machine handles comparisons against UNKNOWN svalues by dropping all taint information on that execution path, so that if the complexity limit has been exceeded we don't generate false positives As well as fixing the taint false positive (PR analyzer/112850), the patch also fixes a couple of leak false positives seen on flex-generated scanners (PR analyzer/103546). [1] specifically, in sound/core/rawmidi.c's handler for SNDRV_RAWMIDI_STREAM_OUTPUT. gcc/ChangeLog: PR analyzer/103546 PR analyzer/112850 * doc/invoke.texi: Add -Wanalyzer-symbol-too-complex. gcc/analyzer/ChangeLog: PR analyzer/103546 PR analyzer/112850 * analyzer.opt (-param=analyzer-max-svalue-depth=): Increase from 12 to 18. (Wanalyzer-symbol-too-complex): New. * diagnostic-manager.cc (null_assignment_sm_context::clear_all_per_svalue_state): New. * engine.cc (impl_sm_context::clear_all_per_svalue_state): New. * program-state.cc (sm_state_map::clear_all_per_svalue_state): New. * program-state.h (sm_state_map::clear_all_per_svalue_state): New decl. * region-model-manager.cc (region_model_manager::reject_if_too_complex): Add -Wanalyzer-symbol-too-complex. * sm-taint.cc (taint_state_machine::on_condition): Handle comparisons against UNKNOWN. * sm.h (sm_context::clear_all_per_svalue_state): New. gcc/testsuite/ChangeLog: PR analyzer/103546 PR analyzer/112850 * c-c++-common/analyzer/call-summaries-pr107158-2.c: Add -Wno-analyzer-symbol-too-complex. * c-c++-common/analyzer/call-summaries-pr107158.c: Likewise. * c-c++-common/analyzer/deref-before-check-pr109060-haproxy-cfgparse.c: Likewise. * c-c++-common/analyzer/feasibility-3.c: Add -Wno-analyzer-too-complex and -Wno-analyzer-symbol-too-complex. * c-c++-common/analyzer/flex-with-call-summaries.c: Add -Wno-analyzer-symbol-too-complex. Remove fail for PR analyzer/103546 leak false positive. * c-c++-common/analyzer/flex-without-call-summaries.c: Remove xfail for PR analyzer/103546 leak false positive. * c-c++-common/analyzer/infinite-recursion-3.c: Add -Wno-analyzer-symbol-too-complex. * c-c++-common/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early-O2.c: Likewise. * c-c++-common/analyzer/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c: Likewise. * c-c++-common/analyzer/null-deref-pr108400-SoftEtherVPN-WebUi.c: Likewise. * c-c++-common/analyzer/null-deref-pr108806-qemu.c: Likewise. * c-c++-common/analyzer/null-deref-pr108830.c: Likewise. * c-c++-common/analyzer/pr94596.c: Likewise. * c-c++-common/analyzer/strtok-2.c: Likewise. * c-c++-common/analyzer/strtok-4.c: Add -Wno-analyzer-too-complex and -Wno-analyzer-symbol-too-complex. * c-c++-common/analyzer/strtok-cppreference.c: Likewise. * gcc.dg/analyzer/analyzer.exp: Add -Wanalyzer-symbol-too-complex
[Bug tree-optimization/112859] [12/13/14 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-2097-g9f34b780b0461e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112859 Sam James changed: What|Removed |Added Keywords|needs-bisection | CC||sjames at gcc dot gnu.org Summary|[12/13/14 Regression] wrong |[12/13/14 Regression] wrong |code at -O3 on |code at -O3 on |x86_64-linux-gnu|x86_64-linux-gnu since ||r12-2097-g9f34b780b0461e --- Comment #3 from Sam James --- bisected to r12-2097-g9f34b780b0461e
[Bug modula2/112893] gm2 fails to detect procedure address actual parameter is incompatible with cardinal formal parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112893 --- Comment #2 from Gaius Mulley --- This bug has been forwarded from the gm2 mailing list.
[Bug libstdc++/112858] [14 Regression] nvptx: 'unresolved symbol __cxa_thread_atexit_impl'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858 --- Comment #7 from GCC Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:3d0f3382fa7b5677f35a9becf75ac436cd7eda7b commit r14-6261-g3d0f3382fa7b5677f35a9becf75ac436cd7eda7b Author: Alexandre Oliva Date: Thu Dec 7 00:38:14 2023 -0300 libsupc++: try cxa_thread_atexit_impl at runtime g++.dg/tls/thread_local-order2.C fails when the toolchain is built for a platform that lacks __cxa_thread_atexit_impl, even if the program is built and run using that toolchain on a (later) platform that offers __cxa_thread_atexit_impl. This patch adds runtime testing for __cxa_thread_atexit_impl on select platforms (GNU variants, for starters) that support weak symbols. for libstdc++-v3/ChangeLog PR libstdc++/112858 * config/os/gnu-linux/os_defines.h (_GLIBCXX_MAY_HAVE___CXA_THREAD_ATEXIT_IMPL): Define. * libsupc++/atexit_thread.cc [__GXX_WEAK__ && _GLIBCXX_MAY_HAVE___CXA_THREAD_ATEXIT_IMPL] (__cxa_thread_atexit): Add dynamic detection of __cxa_thread_atexit_impl.
[Bug middle-end/112411] ICE: SIGSEGV with --param=min-nondebug-insn-uid=2147483647 on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411 --- Comment #10 from Richard Biener --- vec<> doesn't really support "large" vectors: unsigned m_alloc : 31; unsigned m_using_auto_storage : 1; unsigned m_num; so it's basically using 'int'. I guess we should make that alloc = (alloc * 3 / 2) use size_t though or simply do (alloc / 2) * 3 since we know alloc >= 16 here so the rounding error isn't important. Still ICEing on overflow here would be desirable.
[Bug testsuite/112894] [14 Regression] g++.dg/warn/Winvalid-memory-model-2.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112894 --- Comment #1 from Andrew Pinski --- Started at or before r14-6204-g953a9302d1 : https://gcc.gnu.org/pipermail/gcc-testresults/2023-December/802491.html
[Bug testsuite/112894] New: [14 Regression] g++.dg/warn/Winvalid-memory-model-2.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112894 Bug ID: 112894 Summary: [14 Regression] g++.dg/warn/Winvalid-memory-model-2.C fails Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: testsuite-fail Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++17 dg-regexp 28 not found: " *inlined from [^\\n +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++17 dg-regexp 29 not found: " *inlined from [^\\n +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++17 dg-regexp 43 not found: " *inlined from [^\\n +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++17 dg-regexp 44 not found: " *inlined from [^\\n +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++17 dg-regexp 45 not found: " *inlined from [^\\n +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++17 dg-regexp 75 not found: " *inlined from [^\\n +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++17 dg-regexp 76 not found: " *inlined from [^\\n +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++17 dg-regexp 77 not found: " *inlined from [^\\n +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++17 warning at line 30 (test for warnings, line ) +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++17 warning at line 46 (test for warnings, line ) +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++20 dg-regexp 28 not found: " *inlined from [^\\n +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++20 dg-regexp 29 not found: " *inlined from [^\\n +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++20 dg-regexp 43 not found: " *inlined from [^\\n +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++20 dg-regexp 44 not found: " *inlined from [^\\n +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++20 dg-regexp 45 not found: " *inlined from [^\\n +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++20 dg-regexp 75 not found: " *inlined from [^\\n +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++20 dg-regexp 76 not found: " *inlined from [^\\n +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++20 dg-regexp 77 not found: " *inlined from [^\\n +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++20 warning at line 30 (test for warnings, line ) +FAIL: g++.dg/warn/Winvalid-memory-model-2.C -std=gnu++20 warning at line 46 (test for warnings, line ) -LAST_UPDATED: Tue Dec 5 22:01:45 UTC 2023 (revision r14-6194-g9610ba7b6ff) +LAST_UPDATED: Wed Dec 6 22:45:04 UTC 2023 (revision r14-6236-g09a08df7193)
[Bug testsuite/112894] [14 Regression] g++.dg/warn/Winvalid-memory-model-2.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112894 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug middle-end/112895] New: ICE: error reporting routines re-entered. (in check_tag cp/class.cc:1474) with -fdiagnostics-format=sarif-stderr on simple C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112895
Bug ID: 112895
Summary: ICE: error reporting routines re-entered. (in
check_tag cp/class.cc:1474) with
-fdiagnostics-format=sarif-stderr on simple C++ code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: diagnostic, ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 56823
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56823=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -fdiagnostics-format=sarif-stderr testcase.C
internal compiler error: error reporting routines re-entered.
{"$schema":
"https://raw.githubusercontent.com/oasis-tcs/sarif-spec/master/Schemata/sarif-schema-2.1.0.json;,
"version": "2.1.0",
"runs": [{"tool": {"driver": {"name": "GNU C++17",
"fullName": "GNU C++17 (GCC) version 14.0.0
20231207 (experimental) (x86_64-pc-linux-gnu)",
"version": "14.0.0 20231207 (experimental)",
"informationUri": "https://gcc.gnu.org/gcc-14/;,
"rules": [{"id": "-Wreturn-type",
"helpUri":
"https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wreturn-type"}]}},
"invocations": [{"executionSuccessful": true,
"toolExecutionNotifications": []}],
"originalUriBaseIds": {"PWD": {"uri":
"file:///home/smatz/gcc-bug/569/"}},
"artifacts": [{"location": {"uri": "testcase.C",
"uriBaseId": "PWD"},
"contents": {"text": "inline namespace __cxx11
__attribute__((__abi_tag__))\n{\n struct basic_string\n {\n };\n} //
namespace __cxx11\n\nbasic_string\nGetSMFFile ()\n{\n}\n"},
"sourceLanguage": "cplusplus"}],
"results": []}]}
Internal compiler error:
0xee6ad7 check_tag
/repo/gcc-trunk/gcc/cp/class.cc:1474
0xee6ad7 mark_or_check_attr_tags
/repo/gcc-trunk/gcc/cp/class.cc:1517
0xee6ad7 mark_or_check_tags
/repo/gcc-trunk/gcc/cp/class.cc:1542
0xee6c59 find_abi_tags_r
/repo/gcc-trunk/gcc/cp/class.cc:1566
0x1b0b6b4 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 >*))
/repo/gcc-trunk/gcc/tree.cc:11420
0x1b0ed95 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
/repo/gcc-trunk/gcc/tree.cc:11680
0xee7fd1 check_abi_tags
/repo/gcc-trunk/gcc/cp/class.cc:1649
0xfdd424 write_mangled_name
/repo/gcc-trunk/gcc/cp/mangle.cc:790
0xfe3450 mangle_decl_string
/repo/gcc-trunk/gcc/cp/mangle.cc:4393
0xfe363a get_mangled_id
/repo/gcc-trunk/gcc/cp/mangle.cc:4414
0xfe363a mangle_decl(tree_node*)
/repo/gcc-trunk/gcc/cp/mangle.cc:4452
0x1ae611d decl_assembler_name(tree_node*)
/repo/gcc-trunk/gcc/tree.cc:719
0x1886108 compiler_logical_location::get_internal_name_for_tree(tree_node*)
/repo/gcc-trunk/gcc/tree-logical-location.cc:59
0x1886108 current_fndecl_logical_location::get_internal_name() const
/repo/gcc-trunk/gcc/tree-logical-location.cc:140
0x2c983c0 sarif_builder::make_logical_location_object(logical_location const&)
const
/repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:1109
0x2c99ee1 sarif_builder::set_any_logical_locs_arr(json::object*,
logical_location const*)
/repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:757
0x2c99ee1 sarif_builder::set_any_logical_locs_arr(json::object*,
logical_location const*)
/repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:751
0x2c99ee1 sarif_builder::make_location_object(rich_location const&,
logical_location const*)
/repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:780
0x2c9a0be sarif_builder::make_locations_arr(diagnostic_info const&)
/repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:742
0x2c9bba5 sarif_builder::make_result_object(diagnostic_context*,
diagnostic_info const&, diagnostic_t)
/repo/gcc-trunk/gcc/diagnostic-format-sarif.cc:604
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/61338] too many permutation in a vectorized "reverse loop"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61338 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- *** Bug 112892 has been marked as a duplicate of this bug. ***
