[Bug target/118815] [15 Regression] Getting `Vector size conflicts between AVX10.1 and AVX512, using 512 as max vector size` warning with -Wsystem-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815 --- Comment #3 from Haochen Jiang --- Which makes this thing more weird than my expected is that avx10_2rounding and avx10_2minmax intrin file seems not reporting the warning. It also should from my understanding, but it may shed the light of the real issue. I am trying with different combination of push and pops to see what goes wrong.
[Bug target/118815] [15 Regression] Getting `Vector size conflicts between AVX10.1 and AVX512, using 512 as max vector size` warning with -Wsystem-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815
--- Comment #4 from Haochen Jiang ---
(In reply to Haochen Jiang from comment #3)
> Which makes this thing more weird than my expected is that avx10_2rounding
> and avx10_2minmax intrin file seems not reporting the warning. It also
> should from my understanding, but it may shed the light of the real issue.
Forget about that, they will also throw warning, but the good news is that I
have derived a much smaller case for that. When it is wrapped into the push and
pop of AVX10.2-256, the func will throw warning out.
'''
#pragma GCC push_options
#pragma GCC target("avx10.2-256")
void foo();
#pragma GCC pop_options
'''
[Bug target/47253] Conditional jump to tail function is not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47253
--- Comment #9 from H.J. Lu ---
Created attachment 60445
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60445&action=edit
A patch
[hjl@gnu-tgl-3 pr47253]$ cat y.c
void t(), f();
void
decide(bool ok)
{
if (ok)
t();
else
f();
}
[hjl@gnu-tgl-3 pr47253]$ make y.s
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -O2 -S
y.c
[hjl@gnu-tgl-3 pr47253]$ cat y.s
.file "y.c"
.text
.p2align 4
.globl decide
.type decide, @function
decide:
.LFB0:
.cfi_startproc
testb %dil, %dil
je f
jmp t
.p2align 4,,10
.p2align 3
.L2:
jmp f
.cfi_endproc
.LFE0:
.size decide, .-decide
.ident "GCC: (GNU) 15.0.1 20250210 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-tgl-3 pr47253]$
But the unreachable basic block isn't removed.
[Bug middle-end/96900] [12/13/14/15 Regression] bogus -Warray-bounds on strlen with valid pointer obtained from just-past-the-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96900 Andrew Pinski changed: What|Removed |Added Keywords||false-positive --- Comment #10 from Andrew Pinski --- Note the location is messed up starting in GCC 12. GCC 11 gave: : In function 'int g()': :13:27: warning: offset '1' outside bounds of constant string [-Warray-bounds] 13 | return __builtin_strlen (p - sizeof s.a);// bogus -Warray-bounds | ~^~~~ GCC 12 gives: : In function 'int g()': :10:5: warning: offset '1' outside bounds of constant string [-Warray-bounds] 10 | int g (void) | ^ Looks like c_strlen could use a loc argument but that is a huge huge change.
[Bug fortran/88124] Wrong results with procedure in seperate file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88124 Thomas Koenig changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #12 from Thomas Koenig --- (In reply to anlauf from comment #11) > I tried the appended code with main and sub split into 2 .F files, > and with the flags given in the mail to the ML, but can NOT reproduce the > issue with the following compiler versions: > > (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 > > (SUSE Linux) 7.5.0 > (SUSE Linux) 10.2.1 > > 7.2.0 > 8.4.1 > 9.3.1 > 10.2.1 > 11 (HEAD) > > So can we assume that this has been fixed (accidentally) in the meantime? Yes, this is now fixed. I think we can close this.
[Bug libstdc++/118811] New: SIGABRT (or ASAN heap-use-after-free) in chrono::locate_zone--chrono::tzdb_list during exit handlers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811 Bug ID: 118811 Summary: SIGABRT (or ASAN heap-use-after-free) in chrono::locate_zone--chrono::tzdb_list during exit handlers Product: gcc Version: 14.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: nicholas at nicholaswilliams dot net Target Milestone: --- Created attachment 60437 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60437&action=edit Minimal reproduction application I have discovered a SIGABRT (or, when ASAN is enabled, a heap-use-after-free report) in std::chrono::locate_zone() when it calls std::chrono::tzdb_list::begin() as a result of C++20 Chrono library use during application shutdown (exit handlers). I'm not able to attach our proprietary code, so I have attached a fully functional minimal replication application that successfully demonstrates the problem. If it helps, I can say that our exact use case involves an internal logging library that uses a background std::thread to flush log events to their intended destination(s). This is done because our real-time application behavior is very performance sensitive and we don't want anything to be blocked by log flushes. The background thread is kept alive until the very latest moment possible to avoid losing log events. I thought it would be useful to have the details from a system on which the bug does not occur (Ubuntu 24.04 with GCC 13.3.0) to compare against the details from a system on which the bug does occur (RHEL 9 with GCC 14.2.1), so I have attached the .ii files, "-v" compile output, and runtime output from *both* systems. (Or at least, I'm going to try to. It seems to only allow me to attach a single file, so I'm going to try to attach additional files after creating this.) Apologies if this is too much or not any more helpful than had I just attached the files from the buggy system. I compiled on both systems with this command/these options: $ g++ -v -save-temps -std=c++20 -fsanitize=address -fsanitize-address-use-after-scope -Wall -Wextra -Werror -D_GLIBCXX_ASSERTIONS -D_GLIBCXX_DEBUG -o gcc_chrono_segfault gcc_chrono_segfault.cpp The "-D_GLIBCXX_ASSERTIONS -D_GLIBCXX_DEBUG" was added as instructed in the bug reporting instructions. Without those, the behavior is identical (still works with GCC 13, still fails with GCC 14). The use of Address Sanitizer here is because it provides substantial details about the source of the problem, but without it the application still fails with SIGABRT (134). I don't claim to be an expert on the C++ specification, but my understanding is that since it is not explicitly stated that time zones are unsafe to use during exit handlers, they should be safe to use during exit handlers. We certainly haven't had a problem using any other C++ features (I/O streams, threads, strings, even other chrono features). >From what I can tell reading through the ASAN report and the code in the chrono header, the problem appears to be related to the use of a chrono class's private static class data member that's a shared_ptr, without any checks about the validity of said shared_ptr. Since static class data members are destructed before static global variables, the shared_ptr in chrono gets destructed before our logging thread shared_ptr. In my opinion, this data should either be stored in some more-durable (longer-living) way, or it should be re-loaded if the shared_ptr is found to be invalid. Perhaps, even, there should be some kind of fallback plan. I'm not certain on the best course of action. In our case, we were previously using gmtime_r, std::put_time, etc. to format our timestamp, so our workaround for this problem is to revert the change we made that took advantage of this new C++20 Chrono feature. I've been unable to devise any other kind of workaround that still allows us to use std::chrono::time_zone. Happy to provide any more information or try any other things as needed. Just ask.
[Bug tree-optimization/108608] [12 Regression] AArch64 vectorizer ICE in vect_transform_reduction and __builtin_fmax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108608 fengfei.xi at horizon dot auto changed: What|Removed |Added CC||fengfei.xi at horizon dot auto --- Comment #11 from fengfei.xi at horizon dot auto --- (In reply to GCC Commits from comment #9) > The releases/gcc-12 branch has been updated by Richard Sandiford > : > > https://gcc.gnu.org/g:65216cd44b8c89640ad987b6227ea1d748456a41 > > commit r12-9381-g65216cd44b8c89640ad987b6227ea1d748456a41 > Author: Richard Sandiford > Date: Mon Apr 3 09:57:07 2023 +0100 > > vect: Fix single def-use cycle for ifn reductions [PR108608] > > The patch that added support for fmin/fmax reductions didn't > handle single def-use cycles. In some ways, this seems like > going out of our way to make things slower, but that's a > discussion for another day. > Hi Richard Thanks for your patch, I tested it on gcc-12-2 of debian12 OS and it solved the problem. Since my understanding of GCC optimization is limited. could you please explain under what specific circumstances this change might lead to slower performance? Also, is there a more complete fix or any plans for further optimization? Best regards, Fengfei.Xi > gcc/ > PR tree-optimization/108608 > * tree-vect-loop.cc (vect_transform_reduction): Handle single > def-use cycles that involve function calls rather than tree > codes. > > gcc/testsuite/ > PR tree-optimization/108608 > * gcc.dg/vect/pr108608.c: New test. > * gcc.target/aarch64/sve/pr108608-1.c: Likewise. > > (cherry picked from commit 2bb444787ed17a9e786f544cdf51ee2ac6779ab2)
[Bug libstdc++/118811] SIGABRT (or ASAN heap-use-after-free) in chrono::locate_zone--chrono::tzdb_list during exit handlers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811 --- Comment #5 from Nicholas Williams --- Created attachment 60442 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60442&action=edit .ii file from buggy RHEL/GCC14
[Bug ipa/117315] [12/13/14/15 regression] Wireshark miscompiled with LTO since r11-5391-gbb07490abba850
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117315
--- Comment #14 from Sam James ---
Looking at this again, wmem_tree_new_autoreset has __attribute__((malloc))
which promises that the memory returned isn't aliased by anything else
("fresh").
In wmem_test_tree, we birth 'tree' with wmem_tree_new_autoreset, but tree is a
pointer to freshly allocated memory, while tree->data_allocator is a pointer to
one of its arguments. I think we assume it can't be null as a result later on
which is why -fno-delete-null-pointer-checks works.
Is this like a 'lifetime-dse' thing? Is it legal for wmem_tree_new_autoreset to
modify 'tree' before it's returned like that for the malloc attribute?
[Bug ipa/117315] [12/13/14/15 regression] Wireshark miscompiled with LTO since r11-5391-gbb07490abba850
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117315 --- Comment #15 from Sam James --- (In reply to Sam James from comment #14) > Is this like a 'lifetime-dse' thing? Is it legal for wmem_tree_new_autoreset > to modify 'tree' before it's returned like that for the malloc attribute? (The issue not being that it assigns metadata, but that it assigns metadata with something that lives before/after the allocation/free.)
[Bug libstdc++/118811] SIGABRT (or ASAN heap-use-after-free) in chrono::locate_zone--chrono::tzdb_list during exit handlers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811 --- Comment #9 from Andrew Pinski --- So looking into this slightly, tzdb_list deconstructor will call the deconstructor of shared_ptr<_Node>. But that should always be called after the deconstructor of BackgroundThread. Oh I get the failure on the trunk with -static-libstdc++ . So there is an ordering issue here.
[Bug ipa/117315] [12/13/14/15 regression] Wireshark miscompiled with LTO since r11-5391-gbb07490abba850
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117315 Sam James changed: What|Removed |Added Attachment #59461|0 |1 is obsolete|| --- Comment #16 from Sam James --- Created attachment 60444 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60444&action=edit wireshark-ipa-6.tar.xz Fixed up testcase (not smaller, just with a script & some needed args). PIE is important.
[Bug tree-optimization/118796] [15 Regression] ICE when building atlas-ecmwf 0.40.0 (copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1109)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118796 --- Comment #3 from Sam James --- (In reply to Sam James from comment #2) Ignore the last install. We obviously don't want/need that. If you do for some reason, then add the custom install prefix on the cmake command.
[Bug libstdc++/118811] SIGABRT (or ASAN heap-use-after-free) in chrono::locate_zone--chrono::tzdb_list during exit handlers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811 --- Comment #6 from Nicholas Williams --- Created attachment 60443 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60443&action=edit .ii file from working Ubuntu/GCC13
[Bug libstdc++/118811] SIGABRT (or ASAN heap-use-after-free) in chrono::locate_zone--chrono::tzdb_list during exit handlers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811 --- Comment #7 from Nicholas Williams --- I think I have now attached everything. Under the "What we do not want" on the bug reporting instructions, it says "An attached archive (tar, zip, shar, whatever) containing all (or some) of the above." It also later says, "Please avoid posting an archive (.tar, .shar or .zip)." However, the *.ii files were nearly 3 megabytes and Bugzilla would not let me attach them. Since the *.ii files were specifically requested in "What we need," I compressed them into zip archives and attached them anyway.
[Bug libstdc++/118811] SIGABRT (or ASAN heap-use-after-free) in chrono::locate_zone--chrono::tzdb_list during exit handlers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811
--- Comment #8 from Andrew Pinski ---
Works on the trunk.
[apinski@xeond2 upstream-gcc-isel]$ ~/upstream-gcc-isel/bin/g++ -std=c++20
-fsanitize=address -fsanitize-address-use-after-scope -Wall -Wextra -Werror
-D_GLIBCXX_ASSERTIONS -D_GLIBCXX_DEBUG t56.cc
LD_LIBRARY[apinski@xeond2 upstream-gcc-isel]$
LD_LIBRARY_PATH=${HOME}/upstream-gcc-isel/lib64 ./a.out
2025-02-10T03:37:10.001040Z Starting background thread
2025-02-10T03:37:09.999885Z Entering main
2025-02-10T03:37:11.016418Z Exiting main
2025-02-10T03:37:11.016641Z Destructing background thread
2025-02-10T03:37:11.043605Z Background thread shutting down
2025-02-10T03:37:11.044133Z Background thread shutdown complete
[apinski@xeond2 upstream-gcc-isel]$
This is with
```
[apinski@xeond2 upstream-gcc-isel]$ uname -a
Linux xeond2.wrightpinski.org 5.14.0-425.el9.x86_64 #1 SMP PREEMPT_DYNAMIC Wed
Feb 21 18:27:37 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
[apinski@xeond2 upstream-gcc-isel]$ /lib64/libc.so.6
GNU C Library (GNU libc) stable release version 2.34.
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 11.4.1 20231218 (Red Hat 11.4.1-3).
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
.
```
[Bug tree-optimization/118796] [15 Regression] ICE when building atlas-ecmwf 0.40.0 (copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1109)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118796
--- Comment #2 from Sam James ---
```
mkdir /tmp/fortran && cd /tmp/fortran
# Unfortunately, we have to install at least one library, so we do it in
/tmp/fortran/prefix to keep it off the real system.
mkdir /tmp/fortran/prefix
git clone https://github.com/ecmwf/ecbuild
export PATH="/tmp/fortran/ecbuild:${PATH}"
git clone https://github.com/ecmwf/eckit
cmake -B build -S . -DCMAKE_INSTALL_PREFIX=/tmp/fortran/prefix
make -C build -j$(nproc) -l$(nproc)
make -C build -j$(nproc) -l$(nproc) install
cd /tmp/fortran
git clone https://github.com/ecmwf/fckit
# This will fail because of PR118789. Workaround is to use gfortran-14, like:
# FC=gfortran-14 CC=gcc-14 CXX=g++-14 FFLAGS="-O2" CFLAGS="-O2" CXXFLAGS="-O2"
cmake -B build -S . -DCMAKE_INSTALL_PREFIX=/tmp/fortran/prefix
FFLAGS="-O2" CFLAGS="-O2" CXXFLAGS="-O2" cmake -B build -S .
-DCMAKE_INSTALL_PREFIX=/tmp/fortran/prefix
make -C build -j$(nproc) -l$(nproc)
make -C build -j$(nproc) -l$(nproc) install
cd /tmp/fortran
git clone https://github.com/ecmwf/atlas
cd atlas
# If this fails, you can try disable more arguments. The critical part is
Fortran but I didn't try disable more.
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release
-DBUILD_SITE=debian -DCMAKE_INSTALL_LOCALSTATEDIR=/var
-DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON "-GUnix Makefiles"
-DECBUILD_LOG_LEVEL=DEBUG -DCMAKE_VERBOSE_MAKEFILE=ON
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DENABLE_DOCS=On -DENABLE_CXX17=On
-DENABLE_CLANG_TIDY=Off -DENABLE_GRIDTOOLS_STORAGE=Off -DENABLE_TESSELATION=On
-DENABLE_CGAL=On -DENABLE_ECTRANS=On -DENABLE_OMP=On -DENABLE_FORTRAN=On
-Datlas_FULL_INSTALL_CMAKE_DIR=/usr/lib/x86_64-linux-gnu/cmake/atlas_ecmwf
-DENABLE_INIT_SNAN=On -DENABLE_PROJ=On -DENABLE_ACC=On -DENABLE_ECKIT_CODEC=On
-DCMAKE_HIP_ARCHITECTURES=gfx803\;gfx900\;gfx906\;gfx908\;gfx90a\;gfx1010\;gfx1030\;gfx1100\;gfx1101\;gfx1102
-B build -Deckit_ROOT=/tmp/fortran/prefix -Dfckit_ROOT=/tmp/fortran/prefix
-DENABLE_ECTRANS=OFF -DENABLE_TESSELATION=OFF -DENABLE_CGAL=OFF
-DENABLE_PROJ=OFF
# The CMake-generated Makefiles accept 'VERBOSE=1' to see the build commands
for extraction
make -C build -j$(nproc) -l$(nproc) VERBOSE=1
make -C build -j$(nproc) -l$(nproc) install
```
To get the mod files etc, I look in the build dir for .mod and then delete it
and the depend files and run make again to capture the right commands, but you
can just keep the full log from make instead for the full build if you want and
grep that.
[Bug libstdc++/118811] SIGABRT (or ASAN heap-use-after-free) in chrono::locate_zone--chrono::tzdb_list during exit handlers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811 --- Comment #1 from Nicholas Williams --- Created attachment 60438 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60438&action=edit gcc -v output from buggy RHEL/GCC14
[Bug libstdc++/118811] SIGABRT (or ASAN heap-use-after-free) in chrono::locate_zone--chrono::tzdb_list during exit handlers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811 --- Comment #4 from Nicholas Williams --- Created attachment 60441 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60441&action=edit runtime output from working Ubuntu/GCC13
[Bug libstdc++/118811] SIGABRT (or ASAN heap-use-after-free) in chrono::locate_zone--chrono::tzdb_list during exit handlers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811 --- Comment #2 from Nicholas Williams --- Created attachment 60439 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60439&action=edit gcc -v output from working Ubuntu/GCC13
[Bug libstdc++/118811] SIGABRT (or ASAN heap-use-after-free) in chrono::locate_zone--chrono::tzdb_list during exit handlers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118811 --- Comment #3 from Nicholas Williams --- Created attachment 60440 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60440&action=edit runtime output from buggy RHEL/GCC14
[Bug c++/96957] [12/13/14/15 Regression] GCC thinks a non-dependent base is dependent because of template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96957 Andrew Pinski changed: What|Removed |Added See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=47435 --- Comment #9 from Andrew Pinski --- https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1390
[Bug c++/118812] Improve diagnostic for non class used as a base class (even a typedef)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118812 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug preprocessor/118813] New: Compile error when using __OPTIMIZE__ without value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813 Bug ID: 118813 Summary: Compile error when using __OPTIMIZE__ without value Product: gcc Version: 14.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: kistlin at protonmail dot ch Target Milestone: --- Hello, it's more a clarification I guess rather than a bug report. Recently I compiled a project and got: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/include/avx512bwintrin.h:202:17: error: #if with no expression 202 | #if __OPTIMIZE__ | ^ The project only defined `#define __OPTIMIZE__`. Based on the GCC manual one could argue the define is wrong. But on the other hand the headers use different versions of #ifdef and #if. https://github.com/gcc-mirror/gcc/blob/846837c2406ae7a52d9123b29c13e4b8b9d14224/gcc/config/i386/avx512bwintrin.h#L202 compared to this usage https://github.com/gcc-mirror/gcc/blob/846837c2406ae7a52d9123b29c13e4b8b9d14224/gcc/config/i386/avx512bwintrin.h#L2841 gcc --version gcc (GCC) 14.2.1 20250128 GCC manual Section 3.7.2 Common Predefined Macros ``` __OPTIMIZE__ __OPTIMIZE_SIZE__ __NO_INLINE__ These macros describe the compilation mode. __OPTIMIZE__ is defined in all optimizing compilations. __OPTIMIZE_SIZE__ is defined if the compiler is optimizing for size, not speed. __NO_INLINE__ is defined if no functions will be inlined into their callers (when not optimizing, or when inlining has been specifically disabled by -fno-inline). These macros cause certain GNU header files to provide optimized definitions, using macros or inline functions, of system library functions. You should not use these macros in any way unless you make sure that programs will execute with the same effect whether or not they are defined. If they are defined, their value is 1. ``` For me as a non-regular reader of the manual `If they are defined, their value is 1.` could have two meanings. Either whoever defines the macro has to set its value to 1. Or if #define __OPTIMIZE__ is used, the preprocessor sets its value to 1. See also https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues/20#note_244143 for the same info and a minimal working example. Could you shed some light on this? Thanks!
[Bug c++/118812] New: Improve diagnostic for non class used as a base class (even a typedef)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118812
Bug ID: 118812
Summary: Improve diagnostic for non class used as a base class
(even a typedef)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Very much related to PR101519.
take:
```
typedef int t;
struct C : t { };
```
Currently GCC outputs:
```
:2:14: error: expected class-name before '{' token
2 | struct C : t { };
| ^
```
But it is not obvious what it means, it is even worse with type alias like:
```
template
using t = X;
struct C : t { };
```
At least with a dependent name, GCC provides a decent error message.
That is:
```
template
using t = X;
template
struct C : t { };
C a;
```
Gives:
```
: In instantiation of 'struct C':
:5:8: required from here
5 | C a;
|^
:4:8: error: base type 't' {aka 'int'} fails to be a struct or
class type
4 | struct C : t { };
|^
```
[Bug c/97991] [12/13/14/15 Regression] ICE in c_parser_consume_token, at c/c-parser.c:850
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97991
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
--- Comment #8 from Andrew Pinski ---
Even simplified testcase:
```
#pragma message _Pragma ("pack(bar)")
```
That is it happens with pack (on some targets), redefine_extname and message
pragma which does expansion inside the pragma
That is:
c-family/c-pragma.cc: c_register_pragma_with_expansion (0, "pack",
handle_pragma_pack);
c-family/c-pragma.cc: c_register_pragma_with_expansion (0, "redefine_extname",
c-family/c-pragma.cc: c_register_pragma_with_expansion (0, "message",
handle_pragma_message);
config/sol2-c.cc: c_register_pragma_with_expansion (0, "align",
solaris_pragma_align);
config/vms/vms-c.cc: c_register_pragma_with_expansion (NULL,
"__nomember_alignment",
config/vms/vms-c.cc: c_register_pragma_with_expansion (NULL,
"nomember_alignment",
The assert was added with r0-72806-gbc4071dd66fd4d (which I think caused it).
I think I have a simple fix. the assert should just be changed to allow
CPP_PRAGMA when inside a in_pragma (which is like what the C++ front-end does).
Note the preprocessed source is wrong too but it is wrong for C++ already.
I will try to fix that tomorrow.
[Bug target/116594] [meta-bug] xtheadvector brokeness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116594 Bug 116594 depends on bug 116590, which changed state. Bug 116590 Summary: unrecognized opcode th.vmv8r.v th.vfrec7.v when compiling for risc-v xtheadvector https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116590 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug jit/117047] [15 regression] Segfault in libgccjit garbage collection when compiling GNU Emacs with Native Compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #7 from Richard Biener --- I'd say bisecting might be most helpful, but it looks like a ::wrapper registration issue (I'm just assuming the JITs GC state hangs off a "dynamic" GC root and apps are allowed to allocate/deallocate wrappers).
[Bug target/116590] unrecognized opcode th.vmv8r.v th.vfrec7.v when compiling for risc-v xtheadvector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116590 Cooper Qu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Cooper Qu --- Fixed by Jeff Law.
[Bug fortran/56423] F08/0071: Shall reject invalid Vector subscript target with Pointer assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56423 Thomas Koenig changed: What|Removed |Added Last reconfirmed|2015-10-10 00:00:00 |2025-2-9 CC||tkoenig at gcc dot gnu.org --- Comment #3 from Thomas Koenig --- > $ cat z2.f90 > program p >integer, target :: x(3) = [7, 8, 9] >type t > integer, pointer :: a(:) >end type >type(t) :: z >z = t(x(2)) >print *, z%a > end > > This now gives
[Bug modula2/118761] gm2 driver doesn't behave as gcc for --help=BLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118761 Gaius Mulley changed: What|Removed |Added Last reconfirmed||2025-02-09 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #2 from Gaius Mulley --- Confirmed, many thanks for the bug report, will fix.
[Bug fortran/99302] untranslated diagnostic from gfc_compare_interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99302 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Last reconfirmed||2025-02-09 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Thomas Koenig --- I'm not quite sure what the texts should look like. Could you provide an example?
[Bug target/118806] New: [avr] Optimize running main (-mo-call-main)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118806 Bug ID: 118806 Summary: [avr] Optimize running main (-mo-call-main) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Add a new command line option -mno-call-main that uses a more efficient way of running main as provided by the startup code from libmcu.a XCALL main XJMP exit Instead, main can be put in .init9 so no call is required to run it. Specifying -mno-call-main asserts that main does not return. This option is useful for devices with very limited resources.
[Bug target/118806] [avr] Optimize running main (-mo-call-main)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118806 Georg-Johann Lay changed: What|Removed |Added Keywords||missed-optimization Target||avr Target Milestone|--- |15.0
[Bug c++/60551] __attribute__((unused)) is ignored for 'static' declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60551 Petr Skocik changed: What|Removed |Added CC||pskocik at gmail dot com --- Comment #3 from Petr Skocik --- Same in plain C. static void dont_warn(void) __attribute((unused)); results in -Wunused-function warning if dont_warn isn't defined. On clang, the __attribute((unused)) successfully suppresses the warning. https://godbolt.org/z/5KEqWvaTz
[Bug c++/118808] operator new allocates wrong size for object of a template class with two variants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118808 Kio changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Kio --- sorry to say this, but the problem is with cmake which behaved (probably as documented) but not as i assumed. an option set in a subdirectory didn't make it into the main project. the issue raised here very likely was a false alert.
[Bug fortran/118159] link from Fortran documentation, coco is now an online casino
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118159 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #5 from Thomas Koenig --- Andrew, are you still onto this? If not, I could do it.
[Bug fortran/118159] link from Fortran documentation, coco is now an online casino
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118159 --- Comment #6 from Andrew Pinski --- (In reply to Thomas Koenig from comment #5) > Andrew, are you still onto this? If not, I could do it. No I am not working on this.
[Bug fortran/118159] link from Fortran documentation, coco is now an online casino
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118159 Thomas Koenig changed: What|Removed |Added Assignee|pinskia at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #7 from Thomas Koenig --- So let me steal this PR from you.
[Bug preprocessor/118813] Compile error when using __OPTIMIZE__ without value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #2 from Sam James --- Note that "Or if #define __OPTIMIZE__ is used, the preprocessor sets its value to 1." is invalid as we're talking about "pre-defined".
[Bug c/118814] New: -Warray-bounds causes internal compiler error: Segmentation fault during GIMPLE pass: vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118814
Bug ID: 118814
Summary: -Warray-bounds causes internal compiler error:
Segmentation fault during GIMPLE pass: vrp
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lukeshu at lukeshu dot com
Target Milestone: ---
System / GCC version / GCC options:
$ /usr/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.1 20250207 (GCC)
Reproducer source code:
struct inner {};
struct outer {
struct inner self;
int members[];
};
static struct outer *root = &(struct outer){
.members = {0},
};
struct inner *get_root(void) {
return &root->self;
}
Reproducer command and output:
$ /usr/bin/gcc -O3 -Warray-bounds=1 -o bug.o -c bug.c
during GIMPLE pass: vrp
bug.c: In function ‘get_root’:
bug.c:13:15: internal compiler error: Segmentation fault
13 | struct inner *get_root(void) {
| ^~~~
0x1f93416 internal_error(char const*, ...)
???:0
0x106f234 tree_to_poly_int64(tree_node const*)
???:0
0x10bf1be component_ref_size(tree_node*, special_array_member*)
???:0
0xe5a847 decl_init_size(tree_node*, bool)
???:0
0xc89c96 compute_objsize(tree_node*, gimple*, int, access_ref*,
pointer_query*)
???:0
0xc89e0e pointer_query::get_ref(tree_node*, gimple*, access_ref*, int)
???:0
0x1c90a69 array_bounds_checker::check_mem_ref(unsigned int, tree_node*,
bool)
???:0
0x1c91548 array_bounds_checker::check_addr_expr(unsigned int, tree_node*,
gimple*)
???:0
0x1c91760 array_bounds_checker::check_array_bounds(tree_node**, int*,
void*)
???:0
0x10ad639 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 >*))
???:0
0xa3c630 walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
???:0
0x1c7fdf5
check_array_bounds_dom_walker::before_dom_children(basic_block_def*)
???:0
0x1c6ed0f dom_walker::walk(basic_block_def*)
???:0
0x10a3b6e execute_ranger_vrp(function*, bool, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
for
instructions.
[Bug preprocessor/118813] [14/15 regression] Compile error when using __OPTIMIZE__ without value since r14-4490-g03a8504815d539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105339 --- Comment #5 from Andrew Pinski --- So Looking into the history of srsran code, it looks like this define was workaround the issue reported in PR 105339.
[Bug preprocessor/118813] [14/15 regression] Compile error when using __OPTIMIZE__ without value since r14-4490-g03a8504815d539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=96174 --- Comment #6 from Andrew Pinski --- Or PR 96174.
[Bug preprocessor/118813] [14/15 regression] Compile error when using __OPTIMIZE__ without value since r14-4490-g03a8504815d539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- __OPTIMIZE__ is in the implementation defined identifier space so it is reversed for the implementation.
[Bug preprocessor/118813] [14/15 regression] Compile error when using __OPTIMIZE__ without value since r14-4490-g03a8504815d539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Pinski from comment #6) > Or PR 96174. it was definitely to workaround PR 96174 (just checked and srsran uses _mm512_cmp_ps_mask ).
[Bug target/96174] AVX-512 functions missing when compiled without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96174 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.4 Known to work||10.2.0, 11.1.0, 9.4.0 Known to fail||10.1.0, 9.3.0
[Bug preprocessor/118813] [14/15 regression] Compile error when using __OPTIMIZE__ without value since r14-4490-g03a8504815d539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813 --- Comment #8 from Andrew Pinski --- https://github.com/srsran/srsRAN_4G/commit/94a06867a3c3efbb8c6eb36e1ac2fa5f1aa2dc07 I like how it was someone else that reported the issue to GCC 3 years later.
[Bug tree-optimization/118814] [13/14/15 regression] -Warray-bounds causes internal compiler error: Segmentation fault during GIMPLE pass: vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118814 --- Comment #2 from Andrew Pinski --- Wait this is a dup.
[Bug tree-optimization/118814] [13/14/15 regression] -Warray-bounds causes internal compiler error: Segmentation fault during GIMPLE pass: vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118814 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 109828 ***
[Bug c/109828] [13/14/15 Regression] static compound literal with flexible array in initializer leads to invalid size and ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828 Andrew Pinski changed: What|Removed |Added CC||lukeshu at lukeshu dot com --- Comment #15 from Andrew Pinski --- *** Bug 118814 has been marked as a duplicate of this bug. ***
[Bug ipa/117315] [12/13/14/15 regression] Wireshark miscompiled with LTO since r11-5391-gbb07490abba850
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117315
--- Comment #17 from Sam James ---
Looking at trunk. LHS (-) is with malloc attribute (-> crashes), RHS (+) is
without (-> works).
In local-pure-const, we get:
```
--- a/libwsutil.so-wmem_tree.c.054t.local-pure-const1
+++ b/libwsutil.so-wmem_tree.c.054t.local-pure-const1
[...]
@@ -596,13 +596,13 @@ Pass statistics of "local-pure-const":
scanning: wmem_register_callback (data_scope_7(D), wmem_tree_reset_cb,
tree_6);
checking flags for call: neither
scanning: return tree_6;
-checking previously known:Function is locally looping.
-Function is locally malloc.
+checking previously known:
+wmem_tree_new_autoreset/13 is not a malloc candidate, reason: Return value has
uses outside return stmt and comparisons against 0.
+Function is locally looping.
```
We have:
```
* malloc_candidate_p() checks if FUN can possibly be annotated with malloc
attribute. Currently this function does a very conservative analysis.
FUN is considered to be a candidate if
1) It returns a value of pointer type.
2) SSA_NAME_DEF_STMT (return_value) is either a function call or
a phi, and element of phi is either NULL or
SSA_NAME_DEF_STMT(element) is function call.
3) The return-value has immediate uses only within comparisons (gcond or
gassign)
and return_stmt (and likewise a phi arg has immediate use only within
comparison
or the phi stmt). */
#define DUMP_AND_RETURN(reason) \
{ \
if (dump_file && (dump_flags & TDF_DETAILS)) \
fprintf (dump_file, "\n%s is not a malloc candidate, reason: %s\n", \
(node->dump_name ()), (reason)); \
return false; \
}
```
Fine, that's not because it's clearly unsuitable for malloc, it's just being
cautious.
ealias is where everything diverges:
```
--- a/wmem_test-wmem_test.c.040t.ealias
+++ b/wmem_test-wmem_test.c.040t.ealias
@@ -44,154 +44,155 @@ CALLUSED(20) = callarg(23)
CALLCLOBBERED(21) = callarg(23)
callescape(19) = callarg(23)
ESCAPED = extra_allocator_10
-HEAP(25) = &NONLOCAL
-tree_12 = &HEAP(25)
+tree_12 = NONLOCAL
+tree_12 = callarg(22)
+tree_12 = callarg(23)
i.0_1 = i_4
-callescape(29) = NONLOCAL
-CALLUSED(30) = callescape(29)
-callarg(32) = tree_12
+callescape(28) = NONLOCAL
+CALLUSED(29) = callescape(28)
+callarg(31) = tree_12
+callarg(31) = callarg(31) + UNKNOWN
+callarg(31) = *callarg(31) + UNKNOWN
+CALLUSED(29) = callarg(31)
+*callarg(31) = callescape(28)
+CALLCLOBBERED(30) = callarg(31)
+callescape(28) = callarg(31)
+ESCAPED = tree_12
+callarg(32) = i.0_1
[... loads more ...]
Collapsing static cycles and doing variable substitution
@@ -205,76 +206,75 @@ Equivalence classes for indirect node id 5 "NONLOCAL":
pointer 4, location 5
Equivalence classes for indirect node id 6 "ESCAPED_RETURN": pointer 14,
location 0
Equivalence classes for direct node id 7 "STOREDANYTHING": pointer 0, location
0
Equivalence classes for indirect node id 8 "INTEGER": pointer 15, location 0
-Equivalence classes for indirect node id 9 "HEAP(25)": pointer 16, location 6
-Equivalence classes for direct node id 10 "wmem_allocator_new": pointer 0,
location 0
-Equivalence classes for direct node id 11 "callescape(10)": pointer 4,
location 0
-Equivalence classes for direct node id 12 "CALLUSED(11)": pointer 4, location
0
-Equivalence classes for direct node id 13 "CALLCLOBBERED(12)": pointer 0,
location 0
-Equivalence classes for direct node id 14 "allocator_8": pointer 4, location 0
-Equivalence classes for direct node id 15 "callescape(14)": pointer 4,
location 0
-Equivalence classes for direct node id 16 "CALLUSED(15)": pointer 4, location
0
-Equivalence classes for direct node id 17 "CALLCLOBBERED(16)": pointer 0,
location 0
-Equivalence classes for direct node id 18 "extra_allocator_10": pointer 4,
location 0
-Equivalence classes for direct node id 19 "wmem_tree_new_autoreset": pointer
0, location 0
-Equivalence classes for direct node id 20 "callescape(19)": pointer 19,
location 0
-Equivalence classes for direct node id 21 "CALLUSED(20)": pointer 19, location
0
-Equivalence classes for direct node id 22 "CALLCLOBBERED(21)": pointer 19,
location 0
-Equivalence classes for indirect node id 23 "callarg(22)": pointer 17,
location 0
[... loads more ...]
+Equivalence classes for direct node id 9 "wmem_allocator_new": pointer 0,
location 0
+Equivalence classes for direct node id 10 "callescape(10)": pointer 4,
location 0
+Equivalence classes for direct node id 11 "CALLUSED(11)": pointer 4, location
0
+Equivalence classes for direct node id 12 "CALLCLOBBERED(12)": pointer 0,
location 0
+Equivalence classes for direct node id 13 "allocator_8": pointer 4, location 0
+Equivalence classes for direct node id 14 "callescape(14)": pointer 4,
location 0
+Equivalence classes for direct node id 15 "CALLUSED(15)": pointer 4, location
0
+Equivalence classes for direct node id 16 "CALLCLOBBERED(16)": pointer 0,
location 0
+Equivalence classes for direct node id 17 "extra_allo
[Bug preprocessor/118813] [14/15 regression] Compile error when using __OPTIMIZE__ without value since r14-4490-g03a8504815d539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813 Sam James changed: What|Removed |Added Summary|Compile error when using|[14/15 regression] Compile |__OPTIMIZE__ without value |error when using ||__OPTIMIZE__ without value ||since ||r14-4490-g03a8504815d539 See Also||https://github.com/srsran/s ||rsRAN_4G/issues/1451, ||https://gitlab.archlinux.or ||g/archlinux/packaging/packa ||ges/gcc/-/issues/20 CC||haochen.jiang at intel dot com --- Comment #3 from Sam James --- r14-4490-g03a8504815d539
[Bug preprocessor/118813] Compile error when using __OPTIMIZE__ without value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813 Sam James changed: What|Removed |Added Keywords||internal-improvement --- Comment #1 from Sam James --- We should make it consistent with other intrinsics headers but the project is wrong there. __* is reserved. There's no reason for it to be defining it at all.
[Bug c/118814] [13/14/15 regression] -Warray-bounds causes internal compiler error: Segmentation fault during GIMPLE pass: vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118814
Sam James changed:
What|Removed |Added
Summary|-Warray-bounds causes |[13/14/15 regression]
|internal compiler error:|-Warray-bounds causes
|Segmentation fault during |internal compiler error:
|GIMPLE pass: vrp|Segmentation fault during
||GIMPLE pass: vrp
Keywords||ice-on-invalid-code
Target Milestone|--- |13.4
--- Comment #1 from Sam James ---
Rejected with 12, ICEs from 13:
```
$ gcc-12 z.c -O3 -Warray-bounds=1
z.c:10:20: error: non-static initialization of a flexible array member
10 | .members = {0},
|^
z.c:10:20: note: (near initialization for '(anonymous)')
```
[Bug target/118813] [14/15 regression] avx512bwintrin.h is not `-Wsystem-headers -Wundef` clean since r14-4490-g03a8504815d539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813 Andrew Pinski changed: What|Removed |Added Component|preprocessor|target Summary|[14/15 regression] Compile |[14/15 regression] |error when using|avx512bwintrin.h is not |__OPTIMIZE__ without value |`-Wsystem-headers -Wundef` |since |clean since |r14-4490-g03a8504815d539|r14-4490-g03a8504815d539 Last reconfirmed||2025-02-10 Ever confirmed|0 |1 Keywords|internal-improvement| Status|RESOLVED|NEW Resolution|INVALID |--- Target||x86_64 --- Comment #9 from Andrew Pinski --- Actually this header should be `-Wsystem-headers -Wundef` clean.
[Bug target/118813] [14/15 regression] avx512bwintrin.h is not `-Wsystem-headers -Wundef` clean since r14-4490-g03a8504815d539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813 --- Comment #11 from Haochen Jiang --- It should be #ifdef instead of #if here from my first glance.
[Bug target/118813] [14/15 regression] avx512bwintrin.h is not `-Wsystem-headers -Wundef` clean since r14-4490-g03a8504815d539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813 --- Comment #10 from Andrew Pinski --- ``` In file included from /opt/compiler-explorer/gcc-trunk-20250209/lib/gcc/x86_64-linux-gnu/15.0.1/include/immintrin.h:61, from :1: /opt/compiler-explorer/gcc-trunk-20250209/lib/gcc/x86_64-linux-gnu/15.0.1/include/avx512bwintrin.h:202:5: warning: '__OPTIMIZE__' is not defined, evaluates to '0' [-Wundef] 202 | #if __OPTIMIZE__ | ^~~~ ```
[Bug target/118815] [15 Regression] Getting `Vector size conflicts between AVX10.1 and AVX512, using 512 as max vector size` warning with -Wsystem-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815 --- Comment #1 from Andrew Pinski --- Also notice the diagnostic does NOT mention which function this is from either.
[Bug target/118815] New: [15 Regression] Getting `Vector size conflicts between AVX10.1 and AVX512, using 512 as max vector size` warning with -Wsystem-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815
Bug ID: 118815
Summary: [15 Regression] Getting `Vector size conflicts between
AVX10.1 and AVX512, using 512 as max vector size`
warning with -Wsystem-headers
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: x86_64
```
#include
```
With -Wsystem-headers -std=c17 gives notices:
```
In file included from
/opt/compiler-explorer/gcc-trunk-20250209/lib/gcc/x86_64-linux-gnu/15.0.1/include/immintrin.h:151:
/opt/compiler-explorer/gcc-trunk-20250209/lib/gcc/x86_64-linux-gnu/15.0.1/include/avx10_2mediaintrin.h:113:1:
warning: Vector size conflicts between AVX10.1 and AVX512, using 512 as max
vector size
113 | {
| ^
```
[Bug target/118813] [14/15 regression] avx512bwintrin.h is not `-Wsystem-headers -Wundef` clean since r14-4490-g03a8504815d539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813 --- Comment #12 from Haochen Jiang --- And the define seems not to be the workaround for those two PRs. It is much like a typo when moving things around for AVX10 since GCC13 (before AVX10 introduction), it is still wrapped by #ifdef.
[Bug c/114870] [13/14/15 Regression] stddef.h problem with -Wsystem-headers and -std=c23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114870 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Target Milestone|--- |13.4 CC||pinskia at gcc dot gnu.org Last reconfirmed||2025-02-10 Summary|stddef.h problem with |[13/14/15 Regression] |-Wsystem-headers on Fedora |stddef.h problem with |40 |-Wsystem-headers and ||-std=c23 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. I just noticed this myself Sorry for not confirming earlier. stddef.h is under GCC control in this case too.
[Bug target/118815] [15 Regression] Getting `Vector size conflicts between AVX10.1 and AVX512, using 512 as max vector size` warning with -Wsystem-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815 Sam James changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-02-10
[Bug target/118813] [14/15 regression] avx512bwintrin.h is not `-Wsystem-headers -Wundef` clean since r14-4490-g03a8504815d539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118813 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=118815, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=114870 --- Comment #13 from Andrew Pinski --- Noticed 2 other -Wsystem-header issues, PR 118815 is the target warning for conflict of AVX10 and AVX512 or something like that and PR 114870 is a generic -std=gnu23 issue.
[Bug c++/118809] Excessive memory usage with global std::vector> in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118809 Sam James changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-02-10 Ever confirmed|0 |1 --- Comment #2 from Sam James --- It uses a lot of memory with 10/11/12 but it becomes slow with 13+.
[Bug target/118815] [15 Regression] Getting `Vector size conflicts between AVX10.1 and AVX512, using 512 as max vector size` warning with -Wsystem-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118815 --- Comment #2 from Haochen Jiang --- My guess (and probably it should be) is on the push and pop target for AVX10 related options and evex512 usage causing the issue. AVX10.2-256 will only use 256 size, and there is elsewhere enabling evex512 and forgetting to pop that, causing it messed up and finished up with this warning. Let me check where it enables 512 accidentally.
[Bug fortran/118789] [15 Regression] ICE in gfc_add_modify_loc, at fortran/trans.cc:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118789 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #5 from Andrew Pinski --- This blocks trying to build atlas-ecmwf .
[Bug fortran/56423] F08/0071: Shall reject invalid Vector subscript target with Pointer assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56423 --- Comment #6 from anlauf at gcc dot gnu.org --- Created attachment 60435 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60435&action=edit Patch This patch diagnoses the rank mismatch as well as the vector subscripts, and is currently regtesting. Requires adjustment of: gfortran.dg/derived_constructor_comps_2.f90
[Bug fortran/56423] F08/0071: Shall reject invalid Vector subscript target with Pointer assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56423
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #5 from anlauf at gcc dot gnu.org ---
The rank mismatch is detected with:
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 7adbf958aec..112874e53f6 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -1370,7 +1373,7 @@ resolve_structure_cons (gfc_expr *expr, int init)
gfc_find_vtab (&cons->expr->ts);
if (cons->expr->expr_type != EXPR_NULL && rank != cons->expr->rank
- && (comp->attr.allocatable || cons->expr->rank))
+ && (comp->attr.allocatable || comp->attr.pointer ||
cons->expr->rank))
{
gfc_error ("The rank of the element in the structure "
"constructor at %L does not match that of the "
This gives:
pr56423-z2.f90:7:8:
7 | z = t(x(2))
|1
Error: The rank of the element in the structure constructor at (1) does not
match that of the component (0/1)
in agreement with other brands.
Still missing: detection of invalid vector subscripts.
[Bug c++/118791] declare variant messes up template instantiation with rvalue arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118791 Tobias Burnus changed: What|Removed |Added CC||jason at redhat dot com --- Comment #5 from Tobias Burnus --- (In reply to sandra from comment #3) > Curiously, on the OG14 development branch the rvalue calls work but the > lvalue ones are broken instead: Confirmed with GCC 14. This is caused by the following patch - which changes whether one or the other fails in the static assert. Namely: // FAILS with: 7eec6fedf45 // OK with dd3f3c71df6 int lvalue = 0; lvalue_int(lvalue); lvalue_const_int(static_cast(lvalue)); // OK for: 7eec6fedf45 // FAILS with dd3f3c71df6 rvalue_int(0); rvalue_const_int(static_cast(0)); * * * The patch that caused the flip is: r15-6707-gdd3f3c71df66ed commit dd3f3c71df66ed6fd3872ab780f5813831100d1c (HEAD) Author: Jason Merrill AuthorDate: Mon Dec 23 19:57:56 2024 -0500 CommitDate: Wed Jan 8 16:34:58 2025 -0500 c++: fix conversion issues Some issues caught by a check from another patch: In the convert_like_internal bad_p handling, we are iterating from outside to inside, so once we recurse into convert_like we need to stop looping. In build_ramp_function, we're assigning REFERENCE_TYPE things, so we need to build the assignment directly rather than rely on functions that implement C++ semantics. In omp_declare_variant_finalize_one, the parameter object building failed to handle reference parms, and it seems simpler to just use build_stub_object like other parts of the compiler. gcc/cp/ChangeLog: * call.cc (convert_like_internal): Add missing break. * coroutines.cc (cp_coroutine_transform::build_ramp_function): Build INIT_EXPR directly. * decl.cc (omp_declare_variant_finalize_one): Use build_stub_object. gcc/testsuite/ChangeLog: * g++.dg/gomp/declare-variant-3.C: Don't depend on expr dump. * g++.dg/gomp/declare-variant-5.C: Likewise.
[Bug middle-end/96564] [12/13/14/15 Regression] New maybe use of uninitialized variable warning since r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96564
--- Comment #21 from Andrew Pinski ---
So after r15-580, we can optimize:
```
extern void* malloc (long unsigned int);
void fun (unsigned *x) {
if (x == 0)
__builtin_unreachable();
unsigned *a = malloc (*x);
if (a == 0)
return;
if (a != x)
*a = *x;
*x = *a;
}
```
But it can't handle:
```
extern void* malloc (long unsigned int);
void fun (unsigned *x) {
if (x == 0)
return;
unsigned *a = malloc (*x);
if (a == 0)
return;
if (a != x)// (A)
*a = *x;
*x = *a;
}
```
[Bug c++/70349] FAIL: g++.dg/abi/abi-tag18a.C -std=gnu++98 scan-assembler _ZZ1fB7__test1vEN1T1gB7__test2Ev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70349 --- Comment #3 from John David Anglin --- Created attachment 60436 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60436&action=edit 64-bit assembler output
[Bug preprocessor/117166] [15 regression] ICE when building lxml-5.3.0 with LTO (linemap_line_start, at libcpp/line-map.cc:949)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117166 Sam James changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING |RESOLVED --- Comment #7 from Sam James --- This is obsolete (or obsolete enough) with 64-bit location_t.
[Bug target/118806] [avr] Optimize running main (-mo-call-main)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118806 --- Comment #2 from Georg-Johann Lay --- (In reply to Xi Ruoyao from comment #1) > Maybe it can also be done if main is [[noreturn]]? Not sure about that. The proposed patch /sets/ [[noreturn]] provided the conditions are right, i.e. -mno-call-main and main() doesn't have [[section]]. Rationale is to trigger a warning when main() /does/ return, since there is no way to call exit() like the current .init9 code does, and the code would go haywire like in the testsuite where returning from main() is commonplace. To date, one effect of [[noreturn]] is that no callee-saved regs are pushed/popped. That's also the case for OS_task, which is the default except -mno-main-is-OS_task. Thinking about it, [[noreturn]] -> -mno-call-main should work, though I wanted to be conservative in order not to produce testsuite fallout, and let the user be in control.
[Bug ipa/115767] [12/13/14/15 regression] GCC loses track of value on aarch64 with -O2 since r11-3308-gd119f34c952f87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767 --- Comment #23 from Sam James --- (In reply to Xi Ruoyao from comment #22) > Maybe it's worthy to try the new LLVM TBAA sanitizer for this? Good idea. It has no complaints.
[Bug target/118772] BPF doesn't actually support effective-target 'exceptions'?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118772 Thomas Schwinge changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org --- Comment #3 from Thomas Schwinge --- .
[Bug c++/118807] New: [modules] ICE in c_tree_chain_next during GGC with explicit instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118807
Bug ID: 118807
Summary: [modules] ICE in c_tree_chain_next during GGC with
explicit instantiations
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nshead at gcc dot gnu.org
Target Milestone: ---
The following sample ICEs during garbage collection on trunk:
$ cat test.cpp
module;
template class basic_streambuf;
template struct basic_streambuf {
friend void __istream_extract();
};
template class basic_streambuf;
template class basic_streambuf;
$ g++ -fmodules --param=ggc-min-expand=0 --param=ggc-min-heapsize=0
-Wno-global-module -S test.cpp
test.cpp:7:40: internal compiler error: Segmentation fault
7 | template class basic_streambuf;
|^
0x3ca55b1 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x1d14f82 crash_signal
../../gcc/gcc/toplev.cc:322
0x7f494591131f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x135ba02 c_tree_chain_next(tree_node*)
../../gcc/gcc/c-family/c-common.h:1442
0x134e772 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:108
0x1350abb gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:453
0x1351741 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:610
0x1351bdc gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:669
0x134e576 gt_ggc_mx_lang_decl(void*)
./gt-cp-tree.h:60
0x135002f gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:345
0x117cf9d gt_ggc_mx_cp_binding_level(void*)
./gt-cp-name-lookup.h:28
0x117d04b gt_ggc_mx_cp_binding_level(void*)
./gt-cp-name-lookup.h:34
0x134e690 gt_ggc_mx_lang_decl(void*)
./gt-cp-tree.h:87
0x134f011 gt_ggc_mx_lang_tree_node(void*)
./gt-cp-tree.h:214
0x17b02e6 ggc_mark_root_tab
../../gcc/gcc/ggc-common.cc:75
0x17b0401 ggc_mark_roots()
../../gcc/gcc/ggc-common.cc:104
0x14a5373 ggc_collect(ggc_collect)
../../gcc/gcc/ggc-page.cc:2231
0x105968a c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.cc:5504
0x144d679 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.cc:1408
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/118808] operator new allocates wrong size for object of a template class with two variants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118808 --- Comment #1 from Kio --- line 82826
[Bug c++/118808] New: operator new allocates wrong size for object of a template class with two variants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118808
Bug ID: 118808
Summary: operator new allocates wrong size for object of a
template class with two variants
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@little-bat.de
Target Milestone: ---
Created attachment 60433
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60433&action=edit
gcc version, invocation and .ii file
compiling with arm-none-eabi for cortex-m0plus
compiling for release with -O3 is faulty.
compiling for debug with -Og is correct.
when allocating an object of a template class, which has two separate
definitions for two variants A and B separated by std::enable_if, where variant
B is based on variant A, operator new() only allocates the size for variant A
when instantiating an object of variant B.
the correct constructor is called which overwrites the end of the allocated
memory thus corrupting the heap.
in this example:
virtual base class Canvas
template class Pixmap;
// variant A without attributes:
template
class Pixmap> : public
Canvas {...}
// variant B with attributes is based on variant A without attributes:
template
class Pixmap> final :
public Pixmap {...}
the invocation is in line 8286 of the .ii file
[Bug ipa/117315] [12/13/14/15 regression] Wireshark miscompiled with LTO since r11-5391-gbb07490abba850
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117315 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 --- Comment #13 from Jeffrey A. Law --- May be INVALID, but we need to reach a conclusion if wireshark is doing something wrong or if we have a codegen correctness issue.
[Bug ipa/118785] [15 Regression] ICE when building vpl-gpu-rt (during IPA pass, ICE in decompose, at wide-int.h:1049)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118785 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/118805] [15 Regression] wrong code at -O1 with "-fno-tree-ccp -fno-tree-copy-prop -fno-tree-forwprop -fno-tree-fre" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118805 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1
[Bug lto/118790] [15 Regression] ICE when building fiat (crash in loc_list_from_tree_1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118790 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/118616] [15 regression] false positive -Waggressive-loop-optimizations warnings in tree-vect-generic.cc with LTO and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118616 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2
[Bug preprocessor/117166] [15 regression] ICE when building lxml-5.3.0 with LTO (linemap_line_start, at libcpp/line-map.cc:949)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117166 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1
[Bug target/117957] [15 regression] vectorization pessimizes std::vector push/pop test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117957 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/116479] [15 Regression] wrong code with -O -funroll-loops -finline-stringops -fmodulo-sched --param=max-iterations-computation-cost=637924876 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116479 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4
[Bug target/116215] [12/13/14/15 regression] -Wstringop-overflow in i386-expand.cc since r12-2132-ga110855667782d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116215 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/115675] [15 Regression] truncv4hiv4qi affect r14-1402-gd8545fb2c71683's optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115675 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/117764] [15 Regression] cddce should handle __builtin_unreachable guards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117764 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2
[Bug ipa/115767] [12/13/14/15 regression] GCC loses track of value on aarch64 with -O2 since r11-3308-gd119f34c952f87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P1 --- Comment #21 from Jeffrey A. Law --- Might be an aliasing problem or may be a codegen issue. The former obviously makes this INVALID, the latter would start as a P1 issue.
[Bug ipa/115767] [12/13/14/15 regression] GCC loses track of value on aarch64 with -O2 since r11-3308-gd119f34c952f87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767 --- Comment #22 from Xi Ruoyao --- Maybe it's worthy to try the new LLVM TBAA sanitizer for this?
[Bug tree-optimization/115202] [12/13/14/15 Regression] Missed optimization: std::min(f ? (unsigned short)m : a, ~0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115202 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2
[Bug target/117006] [15 regression] GCC trunk generates larger code than GCC 14 at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117006 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2
[Bug driver/118803] cannot pass parameter `--save-temps` to `collect2`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118803 --- Comment #5 from Lorinczy Zsigmond --- Thank you. Does this also explain why `-Wl,--save-temps` cannot be used?
[Bug libgcc/118685] FreeBSD static executables segfault due to libgcc missing crtbeginT.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118685 --- Comment #9 from GCC Commits --- The releases/gcc-14 branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:796849274c155d6f3430d94500cfa3c11fb59a1d commit r14-11282-g796849274c155d6f3430d94500cfa3c11fb59a1d Author: Dimitry Andric Date: Tue Jan 28 18:36:16 2025 +0100 libgcc: On FreeBSD use GCC's crt objects for static linking Add crtbeginT.o to extra_parts on FreeBSD. This ensures we use GCC's crt objects for static linking. Otherwise it could mix crtbeginT.o from the base system with libgcc's crtend.o, possibly leading to segfaults. libgcc: PR target/118685 * config.host (*-*-freebsd*): Add crtbeginT.o to extra_parts. Signed-off-by: Dimitry Andric
[Bug fortran/99302] untranslated diagnostic from gfc_compare_interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99302
--- Comment #2 from Roland Illig ---
If compare_fsyms produces an error message, it may look like this:
> Statement function bei file.f:123
In this message, the word "bei" is in German, while "Statement function" is in
English.
Maybe you can ask Martin Sebor for details regarding the diagnostics.
There are several other code smells in that area, such as:
* mixing strncpy with snprintf in gfc_check_dummy_characteristics
* fixed-size buffers
* using nonstandard quote characters (' instead of %<)
[Bug target/118806] [avr] Optimize running main (-mo-call-main)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118806 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- Maybe it can also be done if main is [[noreturn]]?
[Bug rtl-optimization/116028] [15 Regression] gcc.dg/pr10474.c test failure since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116028 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #17 from Segher Boessenkool --- (In reply to Andrew Pinski from comment #15) > Oh I see there is some terminology issue here, volatile register usage by > Surya in the above means caller saved register and is not related to > volatile RTL flag (which was not being looked at). Yeah. I got too many people think that "volatile parameter registers" actually means something, is understood by many people. I just always have to think a lot about what the "caller-save" and "callee-save" triply indirect things mean, so I never use those horrible terms. And the "volatil" RTL flag usually has nothing to do with "volatile", not in the C standard sense, and not in this sense either. It is all historical ;-)
[Bug middle-end/118801] Excessive compile time with -g -O2 -fpeel-loops -fno-var-tracking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118801 --- Comment #2 from David Binderman --- (In reply to Andrew Pinski from comment #1) > Note you might also want to use -fno-checking for the trunk. Thanks for the tip. Still a 26 times expansion. foundBugs $ time ../results/bin/gcc -c -w -g -O2 -fno-var-tracking -fno-checking bug1088.c real0m0.258s user0m0.235s sys 0m0.017s foundBugs $ time ../results/bin/gcc -c -w -g -O2 -fpeel-loops -fno-var-tracking -fno-checking bug1088.c real0m7.378s user0m6.196s sys 0m1.116s foundBugs $ Might an expansion of 10 times be a reasonable target ?
[Bug driver/118803] cannot pass parameter `--save-temps` to `collect2`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118803 --- Comment #3 from Lorinczy Zsigmond --- > On elf targets including Linux, collect2 does not produce any `*cdtor.c` > files. Instead there is an elf section which gets used. Well `strace(1)` shows the creation of the *cdtor.c file, but it is true that I haven't described yet the platform: it is amd64/Centos7.9, gcc-14.2 compiled from source. Using gcc option `-save-temps` or `--save-temps` has no effect on `collect2`.
