[Bug tree-optimization/117764] [15 Regression] cddce should handle __builtin_unreachable guards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117764
Jan Hubicka changed:
What|Removed |Added
Summary|cddce should handle |[15 Regression] cddce
|__builtin_unreachable |should handle
|guards |__builtin_unreachable
||guards
CC||mjambor at suse dot cz
--- Comment #1 from Jan Hubicka ---
This is a regression, since I introduced the __builtin_unreachable guards to
std::vector::size.
I wonder if reasonable heuristics would be to mark the conditionals guarding
__builtin_unreachable as live provided that their control-dependency block is
already live for other reason. This will allow removal of unnecesary loops.
We may however need to do something about ipa-sra as well. If inlining failed,
it is not a best idea to keep dead argument just because we know its range.
Jonathan's reverted patch:
diff --git a/libstdc++-v3/include/bits/stl_vector.h
b/libstdc++-v3/include/bits/stl_vector.h
index acb29396d264..e593be443bc2 100644
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -388,6 +388,24 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
}
protected:
+
+ __attribute__((__always_inline__))
+ _GLIBCXX20_CONSTEXPR void
+ _M_invariant() const
+ {
+#if __OPTIMIZE__
+ if (this->_M_impl._M_finish < this->_M_impl._M_start)
+ __builtin_unreachable();
+ if (this->_M_impl._M_finish > this->_M_impl._M_end_of_storage)
+ __builtin_unreachable();
+
+ size_t __sz = this->_M_impl._M_finish - this->_M_impl._M_start;
+ size_t __cap = this->_M_impl._M_end_of_storage -
this->_M_impl._M_start;
+ if (__sz > __cap)
+ __builtin_unreachable();
+#endif
+ }
+
_GLIBCXX20_CONSTEXPR
void
_M_create_storage(size_t __n)
@@ -987,7 +1005,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
_GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
size_type
size() const _GLIBCXX_NOEXCEPT
- { return size_type(this->_M_impl._M_finish - this->_M_impl._M_start); }
+ {
+ _Base::_M_invariant();
+ return size_type(this->_M_impl._M_finish - this->_M_impl._M_start);
+ }
/** Returns the size() of the largest possible %vector. */
_GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
shows that people may do such things. Here _M_invariant is empty, but Jonathan
clearly assumed that we will always inline it to every size() invokation and
then FRE multiple loads from _M_finish, M_start and friends and then after
inlining use this to derive useful value ranges for live code...
We may declare this as impossible, but I wonder what are the options :)
Also ipa-modref can detect the parameter as effectively unused...
[Bug fortran/117765] New: Impure function within a BLOCK construct within a DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765 Bug ID: 117765 Summary: Impure function within a BLOCK construct within a DO CONCURRENT Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kargls at comcast dot net Target Milestone: --- Created attachment 59689 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59689&action=edit patch The Fortran 2023 standard contains C1143 A reference to an impure procedure shall not appear within a DO CONCURRENT construct. gfortran fails to enforce this constraint if the impure function is wrapped within a BLOCK construct. That is, do concurrent (i=1:4) block y(i) = impure_foo(i) ! <-- not reported! end bloc end do The attached patch will have gfortran catch this.
[Bug target/117547] FAIL: gcc.target/i386/*-pr93673.c without TARGET_PROMOTE_PROTOTYPES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117547 --- Comment #5 from H.J. Lu --- Created attachment 59691 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59691&action=edit A patch
[Bug target/117767] [15 Regression] ICE: in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.cc:5103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117767 Andrew Pinski changed: What|Removed |Added Keywords||build, ice-on-valid-code Target Milestone|--- |15.0 Summary|ICE: in |[15 Regression] ICE: in |rs6000_builtin_vectorizatio |rs6000_builtin_vectorizatio |n_cost, at |n_cost, at |config/rs6000/rs6000.cc:510 |config/rs6000/rs6000.cc:510 |3 |3
[Bug target/117767] ICE: in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.cc:5103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117767 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-11-25 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #2 from Andrew Pinski --- Also can you please show how the options you configured gcc with?
[Bug tree-optimization/117767] [15 Regression] ICE: in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.cc:5103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117767 Andrew Pinski changed: What|Removed |Added Component|target |tree-optimization --- Comment #3 from Andrew Pinski --- Definitely very much related to PR 117720 as it is the same assert happening.
[Bug tree-optimization/117767] [15 Regression] ICE: in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.cc:5103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117767 --- Comment #4 from Sergey Fedorov --- COLLECT_GCC=/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/build/./prev-gcc/xg++ Target: powerpc-apple-darwin10 Configured with: /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/gcc-15-20241124/configure --prefix=/opt/local --build=powerpc-apple-darwin10 --enable-languages=c,c++,objc,obj-c++,lto,fortran,jit --libdir=/opt/local/lib/libgcc --includedir=/opt/local/include/gcc --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-powerpc --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-powerpc --with-gxx-include-dir=/opt/local/include/gcc/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --with-zstd=/opt/local --enable-checking=release --disable-multilib --enable-lto --enable-libstdcxx-time --without-build-config --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --enable-host-shared --with-darwin-extra-rpath=/opt/local/lib/libgcc --with-libiconv-prefix=/opt/local --disable-tls --with-tune-cpu=G5 --with-gxx-libcxx-include-dir=/opt/local/libexec/gcc-powerpc/libc++/include/c++/v1 --with-pkgversion='MacPorts gcc-powerpc 15-20241124_0+G5+stdlib_flag' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.0 20241124 (experimental) (MacPorts gcc-powerpc 15-20241124_0+G5+stdlib_flag)
[Bug tree-optimization/117767] [15 Regression] ICE: in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.cc:5103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117767 Andrew Pinski changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 Keywords||needs-reduction --- Comment #7 from Andrew Pinski --- Reducing
[Bug tree-optimization/117767] [15 Regression] ICE: in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.cc:5103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117767 --- Comment #5 from Sergey Fedorov --- COLLECT_GCC_OPTIONS='-v' '-save-temps' '-B' '/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/build/./prev-gcc/' '-B' '/opt/local/powerpc-apple-darwin10/bin/' '-nostdinc++' '-B' '/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/build/prev-powerpc-apple-darwin10/libstdc++-v3/src/.libs' '-B' '/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/build/prev-powerpc-apple-darwin10/libstdc++-v3/libsupc++/.libs' '-isystem' '/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/build/prev-powerpc-apple-darwin10/libstdc++-v3/include/powerpc-apple-darwin10' '-isystem' '/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/build/prev-powerpc-apple-darwin10/libstdc++-v3/include' '-isystem' '/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/gcc-15-20241124/libstdc++-v3/libsupc++' '-L/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/build/prev-powerpc-apple-darwin10/libstdc++-v3/src/.libs' '-L/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/build/prev-powerpc-apple-darwin10/libstdc++-v3/libsupc++/.libs' '-c' '-g' '-O2' '-fno-checking' '-D' 'IN_GCC' '-fno-exceptions' '-fno-rtti' '-fasynchronous-unwind-tables' '-Wextra' '-Wall' '-Wno-error=narrowing' '-Wwrite-strings' '-Wcast-qual' '-Wsuggest-attribute=format' '-Wconditionally-supported' '-Woverloaded-virtual=2' '-Wpedantic' '-Wno-long-long' '-Wno-variadic-macros' '-Wno-overlength-strings' '-Werror' '-D' 'HAVE_CONFIG_H' '-fPIC' '-I' '.' '-I' '.' '-I' '/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/gcc-15-20241124/gcc' '-I' '/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/gcc-15-20241124/gcc/.' '-I' '/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/gcc-15-20241124/gcc/../include' '-I' '/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/gcc-15-20241124/gcc/../libcpp/include' '-I' '/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/gcc-15-20241124/gcc/../libcody' '-I' '/opt/local/include' '-I' '/opt/local/include' '-I' '/opt/local/include' '-I' '/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/gcc-15-20241124/gcc/../libdecnumber' '-I' '/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/gcc-15-20241124/gcc/../libdecnumber/dpd' '-I' '../libdecnumber' '-I' '/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/gcc-15-20241124/gcc/../libbacktrace' '-I' '/opt/local/include' '-I' '/opt/local/include' '-o' 'bb-reorder.o' '-MT' 'bb-reorder.o' '-MMD' '-MP' '-MF' './.deps/bb-reorder.TPo' '-mmacosx-version-min=10.6.0' '-asm_macosx_version_min=10.6' '-nodefaultexport' '-shared-libgcc' /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/build/./prev-gcc/cc1plus -fpreprocessed bb-reorder.ii -feliminate-unused-debug-symbols -fPIC -quiet -dumpbase bb-reorder.cc -dumpbase-ext .cc -mmacosx-version-min=10.6.0 -g -O2 -Wextra -Wall -Wno-error=narrowing -Wwrite-strings -Wcast-qual -Wsuggest-attribute=format -Wconditionally-supported -Woverloaded-virtual=2 -Wpedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -version -fno-checking -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fPIC -o bb-reorder.s GNU C++17 (MacPorts gcc-powerpc 15-20241124_0+G5+stdlib_flag) version 15.0.0 20241124 (experimental) (powerpc-apple-darwin10) compiled by GNU C version 10.5.0, GMP version 6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.27-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 90621ec9d5818901d9fd897bda8ba50d during GIMPLE pass: vect /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/gcc-15-20241124/gcc/bb-reorder.cc: In function 'basic_block_def* copy_bb(basic_block, edge, basic_block, int)': /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/gcc-15-20241124/gcc/bb-reorder.cc:832:1: internal compiler error: in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.cc:5103 832 | copy_bb (basic_block old_bb, edge e, basic_block bb, int trace) | ^~~ Please submit a full bug report, with preprocessed source (by using -freport-bug). See <https://trac.macports.org/newticket> for instructions.
[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #13 from Tom Lane --- After further experimentation, it seems to me that: * There was a behavioral change between gcc 9.3.1 and the later releases I tested. Specifically, in 9.3.1 a -march switch does not override the platform-selected default -mfpu, whereas in later releases the default -mfpu is ignored if there's -march on the command line. I don't know if this was intentional. I can work with it, but: * I still maintain that it's a bug either that -march=armv8-a doesn't imply FPU support, or that -march=armv8-a accepts the useless option +nofp and not the useful option +fp. That option behavior would be sensible if armv8-a implied FPU support as it does on aarch64, but it's broken if the arch doesn't imply that on arm32. * The ARM Options documentation page https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/ARM-Options.html is at least complicit in this, since it says under armv8-a ‘+nofp’ Disable the floating-point, Advanced SIMD and cryptographic instructions. without mentioning that the FP instructions aren't enabled in the first place. Also, for completeness' sake here's the full -v output from the Raspberry Pi OS compiler: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/12/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Raspbian 12.2.0-14+rpi1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major version-only --program-suffix=-12 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6+fp --with-float=hard --disable-werror --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (Raspbian 12.2.0-14+rpi1)
[Bug tree-optimization/117767] [15 Regression] ICE: in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.cc:5103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117767 --- Comment #6 from Sergey Fedorov --- Created attachment 59692 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59692&action=edit Preprocessed source with --save-temps
[Bug target/117767] ICE: in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.cc:5103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117767 --- Comment #1 from Andrew Pinski --- Can you attach the preprocessed source?.
[Bug target/117767] New: ICE: in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.cc:5103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117767 Bug ID: 117767 Summary: ICE: in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.cc:5103 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vital.had at gmail dot com CC: iains at gcc dot gnu.org, pinskia at gcc dot gnu.org Target Milestone: --- Target: powerpc-apple-darwin gcc from 20241124 snapshot fails on Darwin PowerPC on: ``` :info:build during GIMPLE pass: vect :info:build /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/gcc-15-20241124/gcc/bb-reorder.cc: In function 'basic_block_def* copy_bb(basic_block, edge, basic_block, int)': :info:build /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_lang_gcc-powerpc/libgcc-powerpc/work/gcc-15-20241124/gcc/bb-reorder.cc:832:1: internal compiler error: in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.cc:5103 :info:build 832 | copy_bb (basic_block old_bb, edge e, basic_block bb, int trace) :info:build | ^~~ ``` The last one known to build (on the same system) is 20240901. I did not build snapshots in between, but if needed, I can try bisecting.
[Bug tree-optimization/117767] [15 Regression] ICE: in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.cc:5103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117767 --- Comment #8 from Andrew Pinski --- Created attachment 59693 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59693&action=edit Reduced testcase
[Bug tree-optimization/117767] [15 Regression] ICE: in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.cc:5103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117767 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords|needs-reduction | --- Comment #9 from Andrew Pinski --- .
[Bug tree-optimization/117767] [15 Regression] ICE: in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.cc:5103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117767 Andrew Pinski changed: What|Removed |Added Target|powerpc-apple-darwin|powerpc*-*-* --- Comment #10 from Andrew Pinski --- `./cc1plus t.cc -I. -O2 -mcpu=G4` is enough to reproduce it for powerpc-linux-gnu.
[Bug fortran/117765] Impure function within a BLOCK construct within a DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765 --- Comment #3 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #2) > In the test case dg-error there is a missing space at the end of the before > the brace } Fixing and tested here. It fixes one test failure.
[Bug fortran/117765] Impure function within a BLOCK construct within a DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765 --- Comment #4 from Jerry DeLisle --- In the test case dg-error there is a missing space at the end of the quote before the brace } Fixing and tested here. It fixes one test failure.
[Bug fortran/117765] Impure function within a BLOCK construct within a DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765 --- Comment #5 from kargls at comcast dot net --- On 11/24/24 13:51, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765 > > --- Comment #4 from Jerry DeLisle --- > In the test case dg-error there is a missing space at the end of the quote > before the brace } Fixing and tested here. It fixes one test failure. > Whoops. Sorry about the extra work.
[Bug libstdc++/117630] Useless atexit entry for generic_category_instance and system_category_instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117630 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #16 from Hans-Peter Nilsson --- (In reply to R. Diez from comment #8) > I haven't found any way to make the linker say why it is pulling certain > symbols or object files. That sounds like the GNU linker "-y" option (as in "-y symbol"). Does that not DTRT?
[Bug fortran/84869] [12/13/14 Regression] ICE in gfc_class_len_get, at fortran/trans-expr.c:233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84869 --- Comment #13 from GCC Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:e78a0cb8604cd3e0fdbc606ed5e7094b646ded02 commit r13-9212-ge78a0cb8604cd3e0fdbc606ed5e7094b646ded02 Author: Paul Thomas Date: Sun Nov 24 14:22:06 2024 + Fortran: Fix segfault in allocation of unlimited poly array [PR84869] 2024-11-24 Paul Thomas gcc/fortran/ChangeLog PR fortran/84869 * trans-expr.cc (trans_class_vptr_len_assignment): To access the '_len' field, 're' must be unlimited polymorphic. gcc/testsuite/ PR fortran/84869 * gfortran.dg/pr84869.f90: Comment out test of component refs. (cherry picked from commit 911a870a6198a2fe50af8bbeb63de1dfaa90de0e)
[Bug fortran/117763] [15.0 regression] segmentation fault through allocatable char arrays (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-11-24 Ever confirmed|0 |1 --- Comment #6 from Paul Thomas --- Hi Juergen, Confirmed. Sometime tomorrow, I'll revert in turn each of the patches that you have pinpointed. It's not obvious at first sight which one it can be. Thanks for the report. Paul
Re: x86_64-gnu 14.2.0 cross-compiler -O2 removes THREAD_SETMEM in glibc sigreturn.c
Andreas Schwab, le dim. 24 nov. 2024 15:15:43 +0100, a ecrit: > On Nov 24 2024, Sergey Bugaev wrote: > > So are you saying that we always must mark any asm statement that > > might transfer control somewhere else w/o returning as 'asm goto', > > even if we don't actually need to jump to any of the C-level labels? > > An ordinary asm is not allowed to change flow control. I was suggesting on IRC to rather move the asm bit outside any function and just call it as a function (with attribute noreturn). Samuel
[Bug target/117562] [15 Regression] 40% slowdown of 482.sphinx3 on Zen4, Zen5 since r15-5120-g9a62c149589103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117562 --- Comment #12 from GCC Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:ba4cf2e296d8d5950c3d356fa6b6efcad00d0189 commit r15-5639-gba4cf2e296d8d5950c3d356fa6b6efcad00d0189 Author: liuhongt Date: Thu Nov 21 23:57:38 2024 -0800 Fix uninitialized operands[2] in vec_unpacks_hi_v4sf. It could cause weired spill in RA when register pressure is high. gcc/ChangeLog: PR target/117562 * config/i386/sse.md (vec_unpacks_hi_v4sf): Initialize operands[2] with CONST0_RTX.
[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 Xi Ruoyao changed: What|Removed |Added Keywords|documentation | --- Comment #11 from Xi Ruoyao --- (In reply to Tom Lane from comment #10) > I could make sense of all this if you were to say "your -march overrides the > default -mfpu". Which would be fine, but it's still the case that the gcc > documentation and switch design say that -march=armv8-a implies FPU support. > At the very least you've got a documentation bug there. No, it's only said so for AArch64 target, not the ARM target. They are two completely different targets for GCC.
[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #12 from Tom Lane --- This does seem like there is some confusion between arm32 and aarch64. Specifically, having +nofp and not +fp makes sense on the aarch64 side. It doesn't make sense for arm32, but nonetheless that's how it's acting.
[Bug fortran/117763] [14/15 regression] segmentation fault through allocatable char arrays (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763 Andrew Pinski changed: What|Removed |Added Target Milestone|15.0|14.3
[Bug c/117741] GCC hangs when compiling a specific C file on the trunk version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117741 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:e9f3eb8493c66da143561d6b866c4b3204e42574 commit r15-5633-ge9f3eb8493c66da143561d6b866c4b3204e42574 Author: Andrew Pinski Date: Sat Nov 23 13:42:47 2024 -0800 gimplefe: Fix handling of ')'/'}' after a parse error [PR117741] The problem here is c_parser_skip_until_found stops at a closing nesting delimiter without consuming it. So if we don't consume it in c_parser_gimple_compound_statement, we would go into an infinite loop. The C parser similar code in c_parser_statement_after_labels to handle this specific case too. PR c/117741 gcc/c/ChangeLog: * gimple-parser.cc (c_parser_gimple_compound_statement): Handle CPP_CLOSE_PAREN/CPP_CLOSE_SQUARE with an error and skipping the token. gcc/testsuite/ChangeLog: * gcc.dg/gimplefe-54.c: New test. Signed-off-by: Andrew Pinski
[Bug c/101057] [gimplefe] GIMPLE frontend issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101057 Bug 101057 depends on bug 117741, which changed state. Bug 117741 Summary: GCC hangs when compiling a specific C file on the trunk version https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117741 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82086 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org CC||jvdelisle at gcc dot gnu.org --- Comment #13 from Jerry DeLisle --- I took a little dive into this and I see what is happening. We call nml_read_obj recursively. The inital call is with the derived type as an array and the rank and dimensions are correct and the repeat count set properly. Then, when we go to read the component which is a scalar by itself we do another nml_read_obj but this time there is no loop spec to iterate over so we pass through that code and hit the error message. To fix this I think we need to save the repeat count and pass it down into the nml_read_object. At the moment it is a global saved in the dtp structure.
[Bug c/117741] GCC hangs when compiling a specific C file on the trunk version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117741 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |15.0 Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed.
[Bug fortran/117763] [15 regression] segmentation fault through allocatable char arrays (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #59688|0 |1 is obsolete|| --- Comment #8 from anlauf at gcc dot gnu.org --- Created attachment 59690 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59690&action=edit Fixed shorter reproducer
[Bug fortran/117763] [15 regression] segmentation fault through allocatable char arrays (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763 --- Comment #9 from anlauf at gcc dot gnu.org --- The shortened reproducer fails for me at runtime not only on 15-trunk, but on 14-branch too, and with same backtrace, so if we have a regression, it should be on 14-branch, too.
[Bug target/117715] [15 regression] gcc.target/sparc/20230328-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117715 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Eric Botcazou --- They should pass again now.
[Bug fortran/117763] [14/15 regression] segmentation fault through allocatable char arrays (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763
--- Comment #10 from anlauf at gcc dot gnu.org ---
The dump-tree difference between 14.2.0 and 14.2.1-HEAD is:
@@ -1662,7 +1662,7 @@
void model_data_get_field_array_ptr (struct array01_field_data_t & __result,
struct __class_model_data_Model_data_t_t & model)
{
*__result = model->_data->field;
- __result->span = 272;
+ __result->span = model->_vptr->_size;
return;
}
Paul, that looks like your playing field.
[Bug target/36503] x86 can use x >> -y for x >> 32-y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503 --- Comment #13 from GCC Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:1ff69000b50e8ac184e925af71e794e7c3d5d2a6 commit r15-5635-g1ff69000b50e8ac184e925af71e794e7c3d5d2a6 Author: Uros Bizjak Date: Sun Nov 24 22:00:18 2024 +0100 i386: x86 can use x >> -y for x >> 32-y [PR36503] x86 targets mask 32-bit shifts with a 5-bit mask (and 64-bit with 6-bit mask), so they can use x >> -y instead of x >> 32-y. This form is very common in bitstream readers, where it's used to read the top N bits from a word. The optimization converts: movl$32, %ecx subl%esi, %ecx sall%cl, %eax to: negl%ecx sall%cl, %eax PR target/36503 gcc/ChangeLog: * config/i386/i386.md (*ashl3_negcnt): New define_insn_and_split pattern. (*ashl3_negcnt_1): Ditto. (*3_negcnt): Ditto. (*3_negcnt_1): Ditto. gcc/testsuite/ChangeLog: * gcc.target/i386/pr36503-1.c: New test. * gcc.target/i386/pr36503-2.c: New test.
[Bug target/36503] x86 can use x >> -y for x >> 32-y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503 Uroš Bizjak changed: What|Removed |Added Target Milestone|--- |15.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Uroš Bizjak --- Implemented for gcc-15.
[Bug middle-end/115489] [12/13/14/15 regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc:589 since r12-3278-g823685221de986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115489 --- Comment #5 from Andrew Pinski --- *** Bug 117748 has been marked as a duplicate of this bug. ***
[Bug fortran/117765] Impure function within a BLOCK construct within a DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765 --- Comment #2 from Jerry DeLisle --- In the test case dg-error there is a missing space at the end of the before the brace } Fixing and tested here. It fixes one test failure.
[Bug tree-optimization/117764] [15 Regression] cddce should handle __builtin_unreachable guards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117764 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #2 from Martin Jambor --- (In reply to Jan Hubicka from comment #1) > We may however need to do something about ipa-sra as well. If inlining > failed, it is not a best idea to keep dead argument just because we know its > range. > I don't think IPA-SRA does that. Is this something that is happening in the testcase from the bug summary? Do I need to use some inlining parameters to reproduce it?
[Bug middle-end/115489] [12/13/14/15 regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc:589 since r12-3278-g823685221de986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115489 Andrew Pinski changed: What|Removed |Added CC||xieym3 at zohomail dot com --- Comment #4 from Andrew Pinski --- *** Bug 117758 has been marked as a duplicate of this bug. ***
[Bug c/117748] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in create_tmp_from_val, at gimplify.cc:592
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117748 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 115489 ***
[Bug c/117758] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in create_tmp_from_val, at gimplify.cc:592
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117758 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- . *** This bug has been marked as a duplicate of bug 115489 ***
[Bug c/117757] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_gimplify_expr, at c-family/c-gimplify.cc:810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117757
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords||ice-checking
Last reconfirmed||2024-11-24
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Reduced testcase:
```
void d() {
int h = 0;
1 << h;
int h[4];
}
```
[Bug c/117753] [12/13/14/15 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in build_int_cst, at tree.cc:1533
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117753 Andrew Pinski changed: What|Removed |Added Summary|ICE: tree check: expected |[12/13/14/15 Regression] |class ‘type’, have |ICE: tree check: expected |‘exceptional’ (error_mark) |class ‘type’, have |in build_int_cst, at|‘exceptional’ (error_mark) |tree.cc:1533|in build_int_cst, at ||tree.cc:1533 Status|UNCONFIRMED |NEW Last reconfirmed||2024-11-24 Ever confirmed|0 |1 Target Milestone|--- |12.5 Keywords||error-recovery, ||ice-on-invalid-code --- Comment #1 from Andrew Pinski --- Confirmed. Reduced testcase: ``` int n; void f1(int[n]); float n(); void f1(int[n]); ```
[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #6 from Tom Lane --- Further info: I dug up an ancient Fedora 30 ARM32 system, and it does not exhibit this behavior: $ touch foo.c $ gcc -c -march=armv8-a foo.c [fine] $ gcc -c -march=armv8-a -mfloat-abi=hard foo.c [also fine] This is with $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7hl-redhat-linux-gnueabi/9/lto-wrapper Target: armv7hl-redhat-linux-gnueabi Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-gnu-indirect-function --disable-sjlj-exceptions --with-tune=generic-armv7-a --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux --build=armv7hl-redhat-linux-gnueabi Thread model: posix gcc version 9.3.1 20200408 (Red Hat 9.3.1-2) (GCC) So it'd seem this is a regression introduced somewhere between 9.3.1 and 10.5.0. I have a report I've not confirmed personally that 10.2.1 is okay.
[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #7 from Andrew Pinski --- The difference between your netbsd built compiler and the fedora one is that the fedora one is built with "--with-fpu=vfpv3-d16" If anything you should be sending a bug report first to netbsd since that is where you got the binary from: --with-bugurl=http://www.NetBSD.org/support/send-pr.html
[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #5 from Tom Lane --- As far as that goes: I don't think there are any armv8-a machines without an FPU, either. The v8a spec technically allows it in 32-bit but not 64-bit mode; but desultory searching doesn't find any examples.
[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #8 from Andrew Pinski --- Also the ARM ARM says the following here about fp/simd on A32/T32: E1.3.10 Implications of not including Advanced SIMD and floating-point support "Exceptionally, for implementation targeting specialized markets, Arm might produce or license an Armv8-A implementation that does not provide any support for Advanced SIMD and floating-point instructions. In such an implementation, in AArch32 state:"
[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #9 from Andrew Pinski --- I don't see why you are using armv8-a with aarch32. Many recent armv8-a/armv9-a cores don't even include an A32/T32 env.
[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #10 from Tom Lane --- Well, I simplified the report a bit compared to the real use-case. What we actually want to use is "-march=armv8-a+crc" so as to compile hardware CRC instructions (that will be used only if a runtime check verifies availability of CRC features). On these platforms with armv7 or older as baseline, CRC primitives won't compile without playing some kind of game with -march. This has worked for us (the Postgres project) for quite a few years, and we just became aware that it's not working with some newer ARM32 platforms. I guess what you are saying is that NetBSD have misconfigured the compiler by not including any -mfpu in their default configuration. Perhaps, but then why does their default configuration work at all? Because they certainly are requiring hard-float ABI. Also, that explanation doesn't fit the failure on Raspberry Pi OS, which visibly does have -mfpu in its default config. (Well, actually they wrote -march=...+fp, but that's documented as equivalent to some -mfpu value or other.) I could make sense of all this if you were to say "your -march overrides the default -mfpu". Which would be fine, but it's still the case that the gcc documentation and switch design say that -march=armv8-a implies FPU support. At the very least you've got a documentation bug there.
[Bug fortran/117763] New: [15.0 regression] segmentation fault through allocatable char arrays (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763 Bug ID: 117763 Summary: [15.0 regression] segmentation fault through allocatable char arrays (?) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- Created attachment 59687 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59687&action=edit Reproducer, ca. 830 lines The following regression has been introduced very likely between Nov 11 and Nov 18, triggering our CI with the newest gcc/gfortran version. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x0040b243 in iso_varying_string::len_ (string=) at main_ut.f90:55 55 if(ALLOCATED(string%chars)) then (gdb) bt #0 0x0040b243 in iso_varying_string::len_ (string=) at main_ut.f90:55 #1 models::model_append_field_vars (model=...) at main_ut.f90:776 #2 0x0040c48c in main_ut () at main_ut.f90:797 The reproducer is attached, I'll try to reduce it even further.
[Bug tree-optimization/116463] [15 Regression] complex multiply vectorizer detection failures after r15-3087-gb07f8a301158e5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #23 from rguenther at suse dot de ---
> Am 23.11.2024 um 13:20 schrieb tnfchris at gcc dot gnu.org
> :
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
>
> --- Comment #22 from Tamar Christina ---
> Ok, so the problem with the ones on trunk isn't necessarily the
> canonicalization itself but that our externals handling is a bit shallow.
>
> On externals we determine that we have no information on the DF and return
> TOP.
> This is because DR analysis doesn't try to handle externals since they're not
> part of the loop.
>
> However all we need to know for complex numbers is whether the externals are
> loaded from the same place and the order of them.
>
> concretely the loop pre-header is:
>
> [local count: 10737416]:
> b$real_11 = REALPART_EXPR ;
> b$imag_10 = IMAGPART_EXPR ;
> _53 = -b$imag_10;
>
> and the loop body:
>
> [local count: 1063004408]:
> ...
>
> _23 = REALPART_EXPR <*_5>;
> _24 = IMAGPART_EXPR <*_5>;
> _27 = _24 * _53;
> _28 = _23 * _53;
>
> codegen before after:
>
> {_24, _23} * { _53, _53 }
>
> and after
>
> { _24, _24 } * { _53, b$real_11 }
>
> Before we were able to easily tell that the order for the multiply would be
> IMAG, REAL.
> In the after (GCC 15) case that information is there, but requires us to
> follow
> the externals.
>
> Richi what do you think about extending externals handling in linear_loads_p
> to
> follow all external ops and if they load from the same memref to figure out
> the
> "virtual lane permute"?
Externs do not have a permute as we build them from scalars. So any permute
can be trivially imposed on them - rather than TOP they should be BOTTOM. Of
course there’s also no advantage of imposing a permute on them.
> We can store the info in a new externals cache (to avoid re-walking externals
> we already walked, as perm_cache stores slp nodes) and the permute for the
> node in the perm_cache as we do for any cached lookups today?
>
> This would also fix the other tests Andrew added in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463#c4
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
[Bug fortran/84869] [12/13/14 Regression] ICE in gfc_class_len_get, at fortran/trans-expr.c:233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84869 --- Comment #12 from GCC Commits --- The releases/gcc-14 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:911a870a6198a2fe50af8bbeb63de1dfaa90de0e commit r14-10977-g911a870a6198a2fe50af8bbeb63de1dfaa90de0e Author: Paul Thomas Date: Sun Nov 24 14:22:06 2024 + Fortran: Fix segfault in allocation of unlimited poly array [PR84869] 2024-11-24 Paul Thomas gcc/fortran/ChangeLog PR fortran/84869 * trans-expr.cc (trans_class_vptr_len_assignment): To access the '_len' field, 're' must be unlimited polymorphic. gcc/testsuite/ PR fortran/84869 * gfortran.dg/pr84869.f90: Comment out test of component refs.
[Bug fortran/109345] [12/13/14 Regression] class(*) variable that is a string array is not handled correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109345 --- Comment #10 from GCC Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:0794ca02b47935cd672f74815023d708e5e262e1 commit r13-9211-g0794ca02b47935cd672f74815023d708e5e262e1 Author: Paul Thomas Date: Sun Nov 24 14:25:37 2024 + Fortran: Suppress failing part of testcase [PR109345] 2024-11-24 Paul Thomas gcc/testsuite/ PR fortran/109345 * gfortran.dg/pr109345.f90: Comment out test of component refs.
[Bug libgcc/85869] libgcc fails to build in canadian cross: cet.h not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85869 --- Comment #3 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:470ebd31843db58fc503ccef38b82d0da93c65e4 commit r15-5629-g470ebd31843db58fc503ccef38b82d0da93c65e4 Author: Paul Thomas Date: Sun Nov 24 12:01:32 2024 + Fortran: Fix segfault in allocation of unlimited poly array [PR85869] 2024-11-24 Paul Thomas gcc/fortran/ChangeLog PR fortran/85869 * trans-expr.cc (trans_class_vptr_len_assignment): To access the '_len' field, re must be unlimited polymorphic. gcc/testsuite/ PR fortran/85869 * gfortran.dg/pr85869.f90: Comment out test of component refs.
[Bug libgcc/85869] libgcc fails to build in canadian cross: cet.h not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85869 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #4 from Paul Thomas --- (In reply to GCC Commits from comment #3) > The master branch has been updated by Paul Thomas : > Sorry about the noise - I commited with the wrong PR number - should have bee 84869. Paul
[Bug fortran/84869] [12/13/14 Regression] ICE in gfc_class_len_get, at fortran/trans-expr.c:233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84869 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Summary|[12/13/14/15 Regression]|[12/13/14 Regression] ICE |ICE in gfc_class_len_get, |in gfc_class_len_get, at |at fortran/trans-expr.c:233 |fortran/trans-expr.c:233 CC||pault at gcc dot gnu.org --- Comment #10 from Paul Thomas --- I blew the commit by labelling it with the wrong PR: s/85869/84869/ The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:470ebd31843db58fc503ccef38b82d0da93c65e4 commit r15-5629-g470ebd31843db58fc503ccef38b82d0da93c65e4 Author: Paul Thomas Date: Sun Nov 24 12:01:32 2024 + Fortran: Fix segfault in allocation of unlimited poly array [PR85869] 2024-11-24 Paul Thomas gcc/fortran/ChangeLog PR fortran/85869 * trans-expr.cc (trans_class_vptr_len_assignment): To access the '_len' field, re must be unlimited polymorphic. gcc/testsuite/ PR fortran/85869 * gfortran.dg/pr85869.f90: Comment out test of component refs.
[Bug fortran/84869] [12/13/14 Regression] ICE in gfc_class_len_get, at fortran/trans-expr.c:233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84869 --- Comment #11 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:aa09e32c4d4ebdd58f677a7ecbdcb93cce84823d commit r15-5630-gaa09e32c4d4ebdd58f677a7ecbdcb93cce84823d Author: Paul Thomas Date: Sun Nov 24 14:01:21 2024 + Fortran: Correct name of testcase [PR84869] 2024-11-24 Paul Thomas gcc/testsuite/ PR fortran/84869 * gfortran.dg/pr84869.f90: Copy of test below with number corrected. * gfortran.dg/pr85869.f90: deleted.
[Bug fortran/84674] [12/13/14/15 Regression] Derived type name change makes a program segfault, removing non_overridable helps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84674 --- Comment #17 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:dd6dbbb5111fba960ad0ee7999a225783e0ae80e commit r15-5628-gdd6dbbb5111fba960ad0ee7999a225783e0ae80e Author: Paul Thomas Date: Sun Nov 24 08:50:58 2024 + Fortran: Fix non_overridable typebound proc problems [PR84674/117730]. 2024-11-24 Paul Thomas gcc/fortran/ChangeLog PR fortran/117730 * class.cc (add_proc_comp): Only reject a non_overridable if it has no overridden procedure and the component is already present in the vtype. PR fortran/84674 * resolve.cc (resolve_fl_derived): Do not build a vtable for a derived type extension that is completely empty. gcc/testsuite/ChangeLog PR fortran/117730 * gfortran.dg/pr117730_a.f90: New test. * gfortran.dg/pr117730_b.f90: New test. PR fortran/84674 * gfortran.dg/pr84674.f90: New test.
[Bug fortran/117730] Wrong code with non_overridable typebound procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117730 --- Comment #8 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:dd6dbbb5111fba960ad0ee7999a225783e0ae80e commit r15-5628-gdd6dbbb5111fba960ad0ee7999a225783e0ae80e Author: Paul Thomas Date: Sun Nov 24 08:50:58 2024 + Fortran: Fix non_overridable typebound proc problems [PR84674/117730]. 2024-11-24 Paul Thomas gcc/fortran/ChangeLog PR fortran/117730 * class.cc (add_proc_comp): Only reject a non_overridable if it has no overridden procedure and the component is already present in the vtype. PR fortran/84674 * resolve.cc (resolve_fl_derived): Do not build a vtable for a derived type extension that is completely empty. gcc/testsuite/ChangeLog PR fortran/117730 * gfortran.dg/pr117730_a.f90: New test. * gfortran.dg/pr117730_b.f90: New test. PR fortran/84674 * gfortran.dg/pr84674.f90: New test.
[Bug rust/117762] New: libgrust/libproc_macro_internal/tokenstream.cc: 3 * performance issues ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117762 Bug ID: 117762 Summary: libgrust/libproc_macro_internal/tokenstream.cc: 3 * performance issues ? Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rust Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org, pierre-emmanuel.patry at embecosm dot com Target Milestone: --- Static analyser cppcheck says: trunk/libgrust/libproc_macro_internal/tokenstream.cc:32:55: performance: Function parameter 'vec' should be passed by const reference. [passedByValue] trunk/libgrust/libproc_macro_internal/tokenstream.cc:35:13: performance: Range variable 'tt' should be declared as const reference. [iterateByValue] trunk/libgrust/libproc_macro_internal/tokenstream.cc:67:30: performance: Function parameter 'tree' should be passed by const reference. [passedByValue] Might be worth fixing.
[Bug rust/117762] libgrust/libproc_macro_internal/tokenstream.cc: 3 * performance issues ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117762 --- Comment #1 from David Binderman --- Five more little problems in libgrust: trunk/libgrust/libproc_macro_internal/group.cc:28:32: performance: Function parameter 'stream' should be passed by const reference. [passedByValue] trunk/libgrust/libproc_macro_internal/ident.cc:62:32: performance: Function parameter 'str' should be passed by const reference. [passedByValue] trunk/libgrust/libproc_macro_internal/tokentree.cc:28:34: performance: Function parameter 'group' should be passed by const reference. [passedByValue] trunk/libgrust/libproc_macro_internal/tokentree.cc:36:34: performance: Function parameter 'ident' should be passed by const reference. [passedByValue] trunk/libgrust/libproc_macro_internal/tokentree.cc:52:36: performance: Function parameter 'literal' should be passed by const reference. [passedByValue]
Re: x86_64-gnu 14.2.0 cross-compiler -O2 removes THREAD_SETMEM in glibc sigreturn.c
Samuel Thibault, le dim. 24 nov. 2024 12:44:00 +0100, a ecrit:
> Sergey Bugaev, le dim. 24 nov. 2024 14:35:33 +0300, a ecrit:
> > Reduced further:
> >
> > --8<--
> > struct hurd_sigstate;
> >
> > typedef struct
> > {
>
> [... the content doesn't actually matter]
>
> > unsigned int reply_port;
> > } tcbhead_t;
> >
> > void
> > __sigreturn2 (struct hurd_sigstate *ss, unsigned long *usp,
> > unsigned int sc_reply_port)
> > {
> > (* (unsigned int __seg_fs *) __builtin_offsetof (tcbhead_t,
> > reply_port) = sc_reply_port);
> >
> > #ifdef ADD_NOP
> > asm ("nop");
> > #endif
> >
> >
> > asm volatile ("movq %0, %%rsp\n"
> > "retq $128" :
> > : "rm" (usp));
> >
> > __builtin_unreachable ();
> > }
> > >8---
>
> Could it be simply because __builtin_unreachable tells gcc that the
> function is not supposed to actually execute, just because it doesn't
> know that the retq asm snippet is indeed a noreturn? Can we tell gcc
> that?
Sergey points me at
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Goto-Labels
“
GCC assumes that asm execution falls through to the next statement (if
this is not the case, consider using the __builtin_unreachable intrinsic
after the asm statement)
”
so it's the documented way to make it so, but apparently it does more
than this and affects the fs-segmented store.
Samuel
Re: x86_64-gnu 14.2.0 cross-compiler -O2 removes THREAD_SETMEM in glibc sigreturn.c
Reduced further:
--8<--
struct hurd_sigstate;
typedef struct
{
void *tcb;
union dtv *dtv;
unsigned int self_do_no_use;
int __glibc_padding1;
int multiple_threads;
int gscope_flag;
unsigned long sysinfo;
unsigned long stack_guard;
unsigned long pointer_guard;
long __glibc_padding2[2];
int private_futex;
int __glibc_padding3;
void *__private_tm[4];
void *__private_ss;
unsigned long long int ssp_base;
unsigned int reply_port;
struct hurd_sigstate *_hurd_sigstate;
struct rtld_catch *rtld_catch;
} tcbhead_t;
void
__sigreturn2 (struct hurd_sigstate *ss, unsigned long *usp,
unsigned int sc_reply_port)
{
(* (unsigned int __seg_fs *) __builtin_offsetof (tcbhead_t,
reply_port) = sc_reply_port);
#ifdef ADD_NOP
asm ("nop");
#endif
asm volatile ("movq %0, %%rsp\n"
"retq $128" :
: "rm" (usp));
__builtin_unreachable ();
}
>8---
Reproducible on x86_64-linux-gnu gcc just as well:
$ gcc anew.c -c -O2
$ objdump -d anew.o
anew.o: file format elf64-x86-64
Disassembly of section .text:
<__sigreturn2>:
0: 48 89 f4 mov%rsi,%rsp
3: c2 80 00 ret$0x80
$ gcc anew.c -c -O2 -D ADD_NOP
$ objdump -d anew.o
anew.o: file format elf64-x86-64
Disassembly of section .text:
<__sigreturn2>:
0: 64 89 14 25 80 00 00 mov%edx,%fs:0x80
7: 00
8: 90nop
9: 48 89 f4 mov%rsi,%rsp
c: c2 80 00 ret$0x80
Sergey
Re: x86_64-gnu 14.2.0 cross-compiler -O2 removes THREAD_SETMEM in glibc sigreturn.c
Sergey Bugaev, le dim. 24 nov. 2024 14:35:33 +0300, a ecrit:
> Reduced further:
>
> --8<--
> struct hurd_sigstate;
>
> typedef struct
> {
[... the content doesn't actually matter]
> unsigned int reply_port;
> } tcbhead_t;
>
> void
> __sigreturn2 (struct hurd_sigstate *ss, unsigned long *usp,
> unsigned int sc_reply_port)
> {
> (* (unsigned int __seg_fs *) __builtin_offsetof (tcbhead_t,
> reply_port) = sc_reply_port);
>
> #ifdef ADD_NOP
> asm ("nop");
> #endif
>
>
> asm volatile ("movq %0, %%rsp\n"
> "retq $128" :
> : "rm" (usp));
>
> __builtin_unreachable ();
> }
> >8---
Could it be simply because __builtin_unreachable tells gcc that the
function is not supposed to actually execute, just because it doesn't
know that the retq asm snippet is indeed a noreturn? Can we tell gcc
that?
Samuel
[Bug fortran/117763] [15.0 regression] segmentation fault through allocatable char arrays (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763 --- Comment #1 from Jürgen Reuter --- Created attachment 59688 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59688&action=edit Shorter reproducer
[Bug fortran/117763] [15.0 regression] segmentation fault through allocatable char arrays (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763 --- Comment #2 from Jürgen Reuter --- This is a shorter reproducer: 1 module iso_varying_string 2implicit none 3integer, parameter, private :: GET_BUFFER_LEN = 1 4 5type, public :: varying_string 6 private 7 character(LEN=1), dimension(:), allocatable :: chars 8end type varying_string 9 10interface assignment(=) 11 module procedure op_assign_CH_VS 12 module procedure op_assign_VS_CH 13end interface assignment(=) 14 15interface char 16 module procedure char_auto 17 module procedure char_fixed 18end interface char 19 20interface len 21 module procedure len_ 22end interface len 23 24interface var_str 25 module procedure var_str_ 26end interface var_str 27 28public :: assignment(=) 29public :: char 30public :: len 31public :: var_str 32 33private :: op_assign_CH_VS 34private :: op_assign_VS_CH 35private :: char_auto 36private :: char_fixed 37private :: len_ 38private :: var_str_ 39 40 contains 41 42elemental function len_ (string) result (length) 43 type(varying_string), intent(in) :: string 44 integer :: length 45 if(ALLOCATED(string%chars)) then 46 length = SIZE(string%chars) 47 else 48 length = 0 49 endif 50end function len_ 51 52elemental subroutine op_assign_CH_VS (var, exp) 53 character(LEN=*), intent(out):: var 54 type(varying_string), intent(in) :: exp 55 var = char(exp) 56end subroutine op_assign_CH_VS 57 58elemental subroutine op_assign_VS_CH (var, exp) 59 type(varying_string), intent(out) :: var 60 character(LEN=*), intent(in) :: exp 61 var = var_str(exp) 62end subroutine op_assign_VS_CH 63 64pure function char_auto (string) result (char_string) 65 type(varying_string), intent(in) :: string 66 character(LEN=len(string)) :: char_string 67 integer :: i_char 68 forall(i_char = 1:len(string)) 69 char_string(i_char:i_char) = string%chars(i_char) 70 end forall 71end function char_auto 72 73pure function char_fixed (string, length) result (char_string) 74 type(varying_string), intent(in) :: string 75 integer, intent(in) :: length 76 character(LEN=length):: char_string 77 char_string = char(string) 78end function char_fixed 79 80elemental function var_str_ (char) result (string) 81 character(LEN=*), intent(in) :: char 82 type(varying_string) :: string 83 integer :: length 84 integer :: i_char 85 length = LEN(char) 86 ALLOCATE(string%chars(length)) 87 forall(i_char = 1:length) 88 string%chars(i_char) = char(i_char:i_char) 89 end forall 90end function var_str_ 91 92 end module iso_varying_string 93 94 module model_data 95use, intrinsic :: iso_c_binding !NODEP! 96use iso_varying_string, string_t => varying_string 97 98implicit none 99private 100 101public :: field_data_t 102public :: model_data_t 103 104type :: field_data_t 105 private 106 type(string_t) :: longname 107 integer :: pdg = 0 108 logical :: has_anti = .false. 109 type(string_t), dimension(:), allocatable :: name, anti 110 type(string_t) :: tex_name 111 integer :: multiplicity = 1 112 contains 113 procedure :: init => field_data_init 114 procedure :: set => field_data_set 115 procedure :: get_longname => field_data_get_longname 116 procedure :: get_name_array => field_data_get_name_array 117end type field_data_t 118 119type :: model_data_t 120 private 121 type(field_data_t), dimension(:), allocatable :: field 122 contains 123 generic :: init => model_data_init 124 procedure, private :: model_data_init 125 procedure :: get_field_array_ptr => model_data_get_field_array_ptr 126 procedure :: get_field_ptr_by_index => model_data_get_field_ptr_index 127 procedure :: init_sm_test => model_data_init_sm_test 128end type model_data_t 129 130 131 contains 132 133subroutine field_data_init (prt, longname, pdg) 134 class(field_data_t), intent(out) :: prt 135 type(string_t), intent(in) :: longname 1
[Bug fortran/117763] [15.0 regression] segmentation fault through allocatable char arrays (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763 --- Comment #3 from Jürgen Reuter --- Comment on attachment 59688 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59688 Shorter reproducer >module iso_varying_string > implicit none > integer, parameter, private :: GET_BUFFER_LEN = 1 > > type, public :: varying_string > private > character(LEN=1), dimension(:), allocatable :: chars > end type varying_string > > interface assignment(=) > module procedure op_assign_CH_VS > module procedure op_assign_VS_CH > end interface assignment(=) > > interface char > module procedure char_auto > module procedure char_fixed > end interface char > > interface len > module procedure len_ > end interface len > > interface var_str > module procedure var_str_ > end interface var_str > > public :: assignment(=) > public :: char > public :: len > public :: var_str > > private :: op_assign_CH_VS > private :: op_assign_VS_CH > private :: char_auto > private :: char_fixed > private :: len_ > private :: var_str_ > >contains > > elemental function len_ (string) result (length) >type(varying_string), intent(in) :: string >integer :: length >if(ALLOCATED(string%chars)) then > length = SIZE(string%chars) >else > length = 0 >endif > end function len_ > > elemental subroutine op_assign_CH_VS (var, exp) >character(LEN=*), intent(out):: var >type(varying_string), intent(in) :: exp >var = char(exp) > end subroutine op_assign_CH_VS > > elemental subroutine op_assign_VS_CH (var, exp) >type(varying_string), intent(out) :: var >character(LEN=*), intent(in) :: exp >var = var_str(exp) > end subroutine op_assign_VS_CH > > pure function char_auto (string) result (char_string) >type(varying_string), intent(in) :: string >character(LEN=len(string)) :: char_string >integer :: i_char >forall(i_char = 1:len(string)) > char_string(i_char:i_char) = string%chars(i_char) >end forall > end function char_auto > > pure function char_fixed (string, length) result (char_string) >type(varying_string), intent(in) :: string >integer, intent(in) :: length >character(LEN=length):: char_string >char_string = char(string) > end function char_fixed > > elemental function var_str_ (char) result (string) >character(LEN=*), intent(in) :: char >type(varying_string) :: string >integer :: length >integer :: i_char >length = LEN(char) >ALLOCATE(string%chars(length)) >forall(i_char = 1:length) > string%chars(i_char) = char(i_char:i_char) >end forall > end function var_str_ > >end module iso_varying_string > >module model_data > use, intrinsic :: iso_c_binding !NODEP! > use iso_varying_string, string_t => varying_string > > implicit none > private > > public :: field_data_t > public :: model_data_t > > type :: field_data_t > private > type(string_t) :: longname > integer :: pdg = 0 > logical :: has_anti = .false. > type(string_t), dimension(:), allocatable :: name, anti > type(string_t) :: tex_name > integer :: multiplicity = 1 > contains > procedure :: init => field_data_init > procedure :: set => field_data_set > procedure :: get_longname => field_data_get_longname > procedure :: get_name_array => field_data_get_name_array > end type field_data_t > > type :: model_data_t > private > type(field_data_t), dimension(:), allocatable :: field > contains > generic :: init => model_data_init > procedure, private :: model_data_init > procedure :: get_field_array_ptr => model_data_get_field_array_ptr > procedure :: get_field_ptr_by_index => model_data_get_field_ptr_index > procedure :: init_sm_test => model_data_init_sm_test > end type model_data_t > > >contains > > subroutine field_data_init (prt, longname, pdg) >class(field_data_t), intent(out) :: prt >type(string_t), intent(in) :: longname >integer, intent(in) :: pdg >prt%longname = longname >prt%pdg = pdg >prt%tex_name = "" > end subroutine field_data_init > > subroutine field_data_set (prt, & > name, anti, tex_name) >class(field_data_t), intent(inout) :: prt >type(string_t), dimension(:), intent(in), optional :: name, anti >type(string_t), intent(in), optional :: tex_name >if (present (name)) then > if (allocated (prt%name)) deallocate (prt%name) > allocate (prt%name (size (name)), source = name) >end if >if (present (anti)) then > if (allocated (prt%anti)) deallocate (prt%anti) > allocate (prt%anti (size (anti)), source = anti) > prt%has_anti = .true. >end if >if (present (tex_name)) prt%tex_name = tex_name > end subroutine field_data_set > > pure function field_data_get_longname (prt) result (name) >
[Bug tree-optimization/116463] [15 Regression] complex multiply vectorizer detection failures after r15-3087-gb07f8a301158e5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
--- Comment #24 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #23)
> > Am 23.11.2024 um 13:20 schrieb tnfchris at gcc dot gnu.org
> > :
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116463
> >
> > --- Comment #22 from Tamar Christina ---
> > Ok, so the problem with the ones on trunk isn't necessarily the
> > canonicalization itself but that our externals handling is a bit shallow.
> >
> > On externals we determine that we have no information on the DF and return
> > TOP.
> > This is because DR analysis doesn't try to handle externals since they're
> > not
> > part of the loop.
> >
> > However all we need to know for complex numbers is whether the externals are
> > loaded from the same place and the order of them.
> >
> > concretely the loop pre-header is:
> >
> > [local count: 10737416]:
> > b$real_11 = REALPART_EXPR ;
> > b$imag_10 = IMAGPART_EXPR ;
> > _53 = -b$imag_10;
> >
> > and the loop body:
> >
> > [local count: 1063004408]:
> > ...
> >
> > _23 = REALPART_EXPR <*_5>;
> > _24 = IMAGPART_EXPR <*_5>;
> > _27 = _24 * _53;
> > _28 = _23 * _53;
> >
> > codegen before after:
> >
> > {_24, _23} * { _53, _53 }
> >
> > and after
> >
> > { _24, _24 } * { _53, b$real_11 }
> >
> > Before we were able to easily tell that the order for the multiply would be
> > IMAG, REAL.
> > In the after (GCC 15) case that information is there, but requires us to
> > follow
> > the externals.
> >
> > Richi what do you think about extending externals handling in
> > linear_loads_p to
> > follow all external ops and if they load from the same memref to figure out
> > the
> > "virtual lane permute"?
>
> Externs do not have a permute as we build them from scalars. So any permute
> can be trivially imposed on them - rather than TOP they should be BOTTOM.
> Of course there’s also no advantage of imposing a permute on them.
>
But the scalars can access memory that we can tell what they are.
My point with the above was that it doesn't make sense to me that we know that
{a[0],a[1]} reads a linearly but that with
a1 = a[0]
a2 = a[1]
{a1,a2} we say "sorry we know nothing about you".
Yes they're externals but they have a defined order of use in the SLP tree.
This isn't about imposing a permute. I said virtual permute since linear_load_p
uses the lane permutes on loads to determine the memory access order.
We DO already impose any order on them, but the other operand is oddodd, so the
overall order ends up being oddodd because any known permute overrides unknown
ones.
So the question is, can we not follow externals in a constructor to figure out
if how they are used they all read from the same base and in which order?
Re: x86_64-gnu 14.2.0 cross-compiler -O2 removes THREAD_SETMEM in glibc sigreturn.c
On Nov 24 2024, Sergey Bugaev wrote: > So are you saying that we always must mark any asm statement that > might transfer control somewhere else w/o returning as 'asm goto', > even if we don't actually need to jump to any of the C-level labels? An ordinary asm is not allowed to change flow control. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: x86_64-gnu 14.2.0 cross-compiler -O2 removes THREAD_SETMEM in glibc sigreturn.c
On Sun, Nov 24, 2024 at 3:58 PM Andreas Schwab wrote:
> > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Goto-Labels
> >
> > “
> > GCC assumes that asm execution falls through to the next statement (if
> > this is not the case, consider using the __builtin_unreachable intrinsic
> > after the asm statement)
> > ”
> >
> > so it's the documented way to make it so, but apparently it does more
> > than this and affects the fs-segmented store.
>
> This is only about asm goto.
So are you saying that we always must mark any asm statement that
might transfer control somewhere else w/o returning as 'asm goto',
even if we don't actually need to jump to any of the C-level labels?
How would I even write something like that at the syntax level? asm
goto ("blah" ); results in "error: expected identifier before ‘)’
token". Do I need to make up a label that I never actually use just to
put something there? If I do that, will GCC assume that the asm
statement only ever jumps to that dummy label (as opposed to jumping
out)?
Thanks,
Sergey
Re: x86_64-gnu 14.2.0 cross-compiler -O2 removes THREAD_SETMEM in glibc sigreturn.c
On Nov 24 2024, Samuel Thibault via Gcc-bugs wrote: > Sergey points me at > > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Goto-Labels > > “ > GCC assumes that asm execution falls through to the next statement (if > this is not the case, consider using the __builtin_unreachable intrinsic > after the asm statement) > ” > > so it's the documented way to make it so, but apparently it does more > than this and affects the fs-segmented store. This is only about asm goto. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
[Bug fortran/117763] [15.0 regression] segmentation fault through allocatable char arrays (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763 Jürgen Reuter changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #5 from Jürgen Reuter --- Potential commits that introduced the regression: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=42a2df0b7985b2a4732ba1c29726ac7aabd5eeae or https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e22d80d4f0f8d33f538c1a4bad07b2c819a6d55c or this (character pointers!): https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f530a8c61383b174a476b64f46d56adeedf49dc4 or this here: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f70c1d517e09c4dde421774a8cec591ca3c479a0 so either Paul or Harald ;) Cheers, Juergen
[Bug fortran/117763] [15.0 regression] segmentation fault through allocatable char arrays (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763 --- Comment #4 from Jürgen Reuter --- There are two left-over use statements for modules parser and variables which need to be taken out.
[Bug tree-optimization/117764] [15 Regression] cddce should handle __builtin_unreachable guards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117764 Sam James changed: What|Removed |Added Target Milestone|--- |15.0 Known to fail||15.0 Known to work||14.2.1
[Bug libstdc++/117630] Useless atexit entry for generic_category_instance and system_category_instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117630 --- Comment #17 from R. Diez --- > > I haven't found any way to make the linker say why it is pulling certain > > symbols or object files. > > That sounds like the GNU linker "-y" option (as in "-y symbol"). Does that > not DTRT? That option didn't help me the last time I tried. Like I said, I think that some other file, like "gcc-14.2.0/libstdc++-v3/src/c++11/cow-stdexcept.cc", is referencing some other symbol in file system_error.cc . Just by pulling system_error.cc into the link process, the Linker pulls in those static instances which happen to live in that file. Because those instances have non-trivial constructors and/or destructors, the corresponding constructors and/or destructors are registered as globals for that file. Even though nothing else uses those static instances, the reference inside the related constructors or destructors is enough to make them seem "used" and prevent them from being discarded. The effect is described here: Bug 117673 - unused static object with just allocation in constructor and free in destructor is not removed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117673 I would need a more powerful linker option or linker report to navigate the dependencies, so that I can tell what symbol pulled a particular C++ module, and inspect some sort of dependency graph with all symbols in that file.
[Bug tree-optimization/117764] New: cddce should handle __builtin_unreachable guards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117764
Bug ID: 117764
Summary: cddce should handle __builtin_unreachable guards
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
In the following testcase:
#include
void test (std::vector v)
{
for (size_t i = 0; i < v.size (); i++)
;
}
we used to be able to optimize out the empty loop pre-inlining, however now
after cddce2 we get:
void test (struct vector & v)
{
ptrdiff_t __dif;
size_t i;
int * _4;
int * _6;
long int _7;
long unsigned int _9;
[local count: 118111600]:
goto ; [100.00%]
[local count: 955630224]:
i_5 = i_1 + 1;
[local count: 1073741824]:
# i_1 = PHI <0(2), i_5(3)>
_4 = MEM[(const struct vector *)v_3(D)].D.25542._M_impl.D.24853._M_finish;
_6 = MEM[(const struct vector *)v_3(D)].D.25542._M_impl.D.24853._M_start;
_7 = _4 - _6;
__dif_8 = _7 /[ex] 4;
if (_7 < 0)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_unreachable ();
[local count: 1073741824]:
_9 = (long unsigned int) __dif_8;
if (i_1 < _9)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 118111600]:
return;
}
The mini-dce of fnsummary is able to figure out that if (_7 < 0)
is unnecesary, but rest is held together by the empty loop.
I think cddce needs to understand __builtin_unreachable guards, too. However
what is not clear to me is how to decide what guards are potentially useful for
later optimization...
[Bug libstdc++/117630] Useless atexit entry for generic_category_instance and system_category_instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117630 --- Comment #18 from Hans-Peter Nilsson --- (In reply to R. Diez from comment #17) > > > I haven't found any way to make the linker say why it is pulling certain > > > symbols or object files. > > > > That sounds like the GNU linker "-y" option (as in "-y symbol"). Does that > > not DTRT? > > That option didn't help me the last time I tried. Ok, just wanted to check in case you'd overlooked it. It has helped me in similar situations, used by adding "-Wl,-y,symbol" to gcc options and together with the previously mentioned -Map option.
[Bug tree-optimization/117764] [15 Regression] cddce should handle __builtin_unreachable guards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117764 --- Comment #4 from Andrew Pinski --- We will most likely have a similar issue with assume attribute too.
[Bug fortran/117765] Impure function within a BLOCK construct within a DO CONCURRENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117765 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- Looks reasonable. I will test and push for you in a few days. We'll see if anyone else has any comments.
[Bug c/117766] New: Confusion over whether ARM32 -march=armv8-a implies floating point support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 Bug ID: 117766 Summary: Confusion over whether ARM32 -march=armv8-a implies floating point support Product: gcc Version: 10.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tgl at sss dot pgh.pa.us Target Milestone: --- On 32-bit ARM platforms with hard-float ABI, I observe this strange behavior: $ touch foo.c $ gcc -c -march=armv8-a foo.c cc1: error: '-mfloat-abi=hard': selected processor lacks an FPU So apparently gcc thinks this arch doesn't include FP hardware. The gcc documentation says the contrary, however. Moreover, if I ask for FP support: $ gcc -c -march=armv8-a+fp foo.c gcc: error: 'armv8-a' does not support feature 'fp' gcc: note: valid feature names are: crc simd crypto nocrypto nofp sb predres; did you mean 'nofp'? If it doesn't include FP hardware, why's there a +nofp option rather than +fp? A workaround is to specify an FPU type explicitly: $ gcc -c -march=armv8-a -mfpu=vfpv4 foo.c but it doesn't seem to me I should have to. This particular typescript was taken from a "generic" ARM32 build of NetBSD 10.0, which uses $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/lto-wrapper Target: armv7--netbsdelf-eabihf Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure --target=armv7--netbsdelf-eabihf --enable-long-long --enable-threads --with-bugurl=http://www.NetBSD.org/support/send-pr.html --with-pkgversion='NetBSD nb2 20230710' --with-system-zlib --without-isl --enable-__cxa_atexit --enable-libstdcxx-time=rt --enable-libstdcxx-threads --with-diagnostics-color=auto-if-env --with-default-libstdcxx-abi=new --with-mpc-lib=/var/obj/mknative/evbarm-earmv7hf/usr/src/external/lgpl3/mpc/lib/libmpc --with-mpfr-lib=/var/obj/mknative/evbarm-earmv7hf/usr/src/external/lgpl3/mpfr/lib/libmpfr --with-gmp-lib=/var/obj/mknative/evbarm-earmv7hf/usr/src/external/lgpl3/gmp/lib/libgmp --with-mpc-include=/usr/src/external/lgpl3/mpc/dist/src --with-mpfr-include=/usr/src/external/lgpl3/mpfr/dist/src --with-gmp-include=/usr/src/external/lgpl3/gmp/lib/libgmp/arch/arm --enable-tls --enable-initfini-array --disable-multilib --disable-libstdcxx-pch --build=armv7--netbsdelf-eabihf --host=armv7--netbsdelf-eabihf --with-sysroot=/var/obj/mknative/evbarm-earmv7hf/usr/src/destdir.evbarm Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.5.0 (nb3 20231008) I have also gotten this identical behavior with the build of gcc 12.2.0 included in current (Nov 2024) Raspberry Pi OS 32-bit. I don't have that system booted up to give you the full gcc -v output, but my notes mention $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/12/lto-wrapper Target: arm-linux-gnueabihf Configured with: ... --with-arch=armv6+fp --with-float=hard ... Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (Raspbian 12.2.0-14+rpi1)
[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #2 from Andrew Pinski --- Otherwise try -march=armv8-a+simd as simd and fp for armv8-a are linked.
[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #1 from Andrew Pinski --- Does -mfpu=auto work ?
[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #3 from Tom Lane --- No go on fpu=auto, at least on the NetBSD platform: $ gcc -c -march=armv8-a -mfpu=auto foo.c cc1: error: '-mfloat-abi=hard': selected processor lacks an FPU The simd method does work to stop the error: $ gcc -c -march=armv8-a+simd foo.c but I suspect it licenses the compiler to emit more than I want it to.
[Bug target/117766] Confusion over whether ARM32 -march=armv8-a implies floating point support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117766 --- Comment #4 from Andrew Pinski --- (In reply to Tom Lane from comment #3) > The simd method does work to stop the error: > > $ gcc -c -march=armv8-a+simd foo.c > > but I suspect it licenses the compiler to emit more than I want it to. For armv8-a all env that support fp will support simd instructions too. Unless you have some odd armv8-a processor which as far as I know has never made too.
[Bug fortran/84869] [12 Regression] ICE in gfc_class_len_get, at fortran/trans-expr.c:233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84869 Paul Thomas changed: What|Removed |Added Summary|[12/13/14 Regression] ICE |[12 Regression] ICE in |in gfc_class_len_get, at|gfc_class_len_get, at |fortran/trans-expr.c:233|fortran/trans-expr.c:233 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Paul Thomas --- Fixed on 13-branch through to mainline. As usual, Gerhard, many thanks for the report. The fix was so trivial that I have no idea why it took so long for it to be noticed and fixed. Paul
[Bug fortran/117763] [15 regression] segmentation fault through allocatable char arrays (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763 Sam James changed: What|Removed |Added Known to work||14.2.1 Keywords||wrong-code Known to fail||15.0 Target Milestone|--- |15.0 Summary|[15.0 regression] |[15 regression] |segmentation fault through |segmentation fault through |allocatable char arrays (?) |allocatable char arrays (?)
[Bug tree-optimization/117764] [15 Regression] cddce should handle __builtin_unreachable guards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117764
--- Comment #3 from Jan Hubicka ---
> I don't think IPA-SRA does that. Is this something that is happening in the
> testcase from the bug summary? Do I need to use some inlining parameters to
> reproduce it?
Problem is that at ipa analysis we may have something like
void
foo (int *a)
{
if (*a > 10)
__builtin_unreachable ();
}
We keep this conditional because we think that it may give useful value
range at late optimization. If foo is inlined, this may happen if *a is
used in caller in some interesting way.
However if foo remains offline, it is sily to keep parameter a around.
[Bug target/117715] [15 regression] gcc.target/sparc/20230328-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117715 --- Comment #4 from GCC Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:ab952929f7741998e3f28959c85e7abbf88ea79f commit r15-5632-gab952929f7741998e3f28959c85e7abbf88ea79f Author: Eric Botcazou Date: Sun Nov 24 20:23:34 2024 +0100 Fix vectorization regressions on the SPARC This fixes the vectorization regressions present on the SPARC by switching from vcond[u] patterns to vec_cmp[u] + vcond_mask_ patterns. While I was at it, I merged the patterns for V4HI/V2SI and V8QI enabled with VIS 3/VIS 4 to follow the model of those enabled with VIS 4B, and standardized all the mnemonics to the version documented in the Oracle SPARC architecture 2015. gcc/ PR target/117715 * config/sparc/sparc-protos.h (sparc_expand_vcond): Rename to... (sparc_expand_vcond_mask): ...this. * config/sparc/sparc.cc (TARGET_VECTORIZE_GET_MASK_MODE): Define. (sparc_vis_init_builtins): Adjust the CODE_FOR_* identifiers. (sparc_get_mask_mode): New function. (sparc_expand_vcond): Rename to... (sparc_expand_vcond_mask): ...this and adjust. * config/sparc/sparc.md (unspec): Remove UNSPEC_FCMP & UNSPEC_FUCMP and rename UNSPEC_FPUCMPSHL into UNSPEC_FPCMPUSHL. (fcmp_vis): Merge into... (fpcmp8_vis): Merge into... (fpcmp_vis): ...this. (fucmp8_vis): Merge into... (fpcmpu_vis): Merge into... (fpcmpu_vis): ...this. (vec_cmp): New expander. (vec_cmpu): Likewise. (vcond): Delete. (vcondv8qiv8qi): Likewise. (vcondu): Likewise. (vconduv8qiv8qi): Likewise. (vcond_mask_): New expander. (fpcmpshl): Adjust. (fpcmpushl): Likewise. (fpcmpdeshl): Likewise. (fpcmpurshl): Likewise. * doc/md.texi (vcond_mask_len_): Fix pasto. gcc/testsuite/ * gcc.target/sparc/20230328-1.c: Adjust to new mnemonics. * gcc.target/sparc/20230328-4.c: Likewise. * gcc.target/sparc/fcmp.c: Likewise. * gcc.target/sparc/fucmp.c: Likewise.
[Bug fortran/117763] [15 regression] segmentation fault through allocatable char arrays (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763 anlauf at gcc dot gnu.org changed: What|Removed |Added CC|anlauf at gmx dot de | --- Comment #7 from anlauf at gcc dot gnu.org --- Jürgen, there is really no need to double-spam me.
[Bug fortran/117763] [14/15 regression] segmentation fault through allocatable char arrays (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117763 --- Comment #11 from Jürgen Reuter --- (In reply to anlauf from comment #9) > The shortened reproducer fails for me at runtime not only on 15-trunk, but > on 14-branch too, and with same backtrace, so if we have a regression, > it should be on 14-branch, too. [Sorry for the double-tag, will keep it in mind]. Indeed, 14.2.0 is in our CI, and is not failing.
[Bug tree-optimization/117764] [15 Regression] cddce should handle __builtin_unreachable guards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117764 --- Comment #5 from Richard Biener --- But the inlining argument basically says CDDCE shouldn't handle __builtin_unreachable control stmts optimistically given a use could appear only after inlining ... doesn't this then imply WONTFIX?
[Bug c/117745] [12/13/14/15 Regression] GCC hangs with invalid code with sizeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117745 Richard Biener changed: What|Removed |Added Version|unknown |15.0 Priority|P3 |P2
[Bug c/117749] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117749 Richard Biener changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Version|unknown |15.0 Blocks||101057 --- Comment #1 from Richard Biener --- it's not so useful to fuzz __GIMPLE Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101057 [Bug 101057] [meta-bug] [gimplefe] GIMPLE frontend issues
[Bug c/117747] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.cc:86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117747 Richard Biener changed: What|Removed |Added Last reconfirmed||2024-11-25 Ever confirmed|0 |1 Blocks||101057 Status|UNCONFIRMED |NEW Keywords||error-recovery, ||ice-on-invalid-code Version|unknown |15.0 --- Comment #1 from Richard Biener --- Confirmed also with -fgimple: > ./cc1 -quiet t.c -fgimple t.c: In function ‘foo’: t.c:3:10: error: ‘b’ undeclared (first use in this function) 3 | int t1 ; b = - 7 ; | ^ t.c:3:10: note: each undeclared identifier is reported only once for each function it appears in t.c:4:1: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.cc:86 4 | } | ^ the GIMPLE FE emits <<< error >>> = -7; note the GIMPLE FE isn't designed to handle all errors upfront, instead it resorts to the verifier. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101057 [Bug 101057] [meta-bug] [gimplefe] GIMPLE frontend issues
[Bug fortran/117768] New: [15.0 regression] ICE in diagnostic_impl (?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117768 Bug ID: 117768 Summary: [15.0 regression] ICE in diagnostic_impl (?) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- This regression seems to have been introduced between Nov 18 (still working HEAD 0dc389f21bfd4ee49d57bcfaa1d1936456c55e48) and Nov 25: eio_ascii_sub.f90:381:25: 381 | end submodule eio_ascii_s | 1 internal compiler error: Segmentation fault 0x26dca5e diagnostic_context::diagnostic_impl(rich_location*, diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag (*) [1], diagnostic_t) ???:0 0x26f21de internal_error(char const*, ...) ???:0 0x11a07c4 relayout_decl(tree_node*) ???:0 0xdd9e1d allocate_struct_function(tree_node*, bool) ???:0 0xb4f364 gfc_generate_function_code(gfc_namespace*) ???:0 0xb1d2b1 gfc_generate_module_code(gfc_namespace*) ???:0 0xaba3ad gfc_parse_file() ???:0 Please submit a full bug report, with preprocessed source (by using -freport-bug). I will submit a reproducer shortly.
[Bug tree-optimization/115825] [12/13/14 Regression] Loop unrolling increases code size with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825 Richard Biener changed: What|Removed |Added Known to work||15.0 Summary|[12/13/14/15 Regression]|[12/13/14 Regression] Loop |Loop unrolling increases|unrolling increases code |code size with -Os |size with -Os --- Comment #13 from Richard Biener --- Fixed on trunk, I'm unlikely going to backport this though as with all heuristics this is going to cause some regressions (none important though, hopefully). There's a workaround by adding #pragma GCC unroll 0 to loops where this hurts most. Going to keep it open for tracking/duping anyway.
[Bug middle-end/117756] [12/13/14/15 Regression] ICE: in analyze_functions, at cgraphunit.cc:1404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117756 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Version|unknown |15.0
[Bug c/117753] [12/13/14/15 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in build_int_cst, at tree.cc:1533
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117753 Richard Biener changed: What|Removed |Added Version|unknown |15.0 Priority|P3 |P4
