[Bug bootstrap/91767] New: After r274953, clang-compiled xgcc segfaults during RTL pass: stv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91767 Bug ID: 91767 Summary: After r274953, clang-compiled xgcc segfaults during RTL pass: stv Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dimitry at andric dot com Target Milestone: --- As reported in https://bugs.freebsd.org/240387, after the gcc10-devel port was updated from the 20190825 snapshot to the 20190901 snapshot, bootstrapping started to fail due to a segfault, when the host compiler is clang 8.0. Bisecting showed that the segfaults start appearing after r274953. The error appears for different source files, when building libgcc with xgcc, but it always looks like: during RTL pass: stv /home/dim/src/gcc/libgcc/config/libbid/bid128_fma.c: In function 'bid128_ext_fma': /home/dim/src/gcc/libgcc/config/libbid/bid128_fma.c:3569:1: internal compiler error: Segmentation fault 3569 | } | ^ Running under valgrind shows: ==19771== Invalid read of size 1 ==19771==at 0x82D7DC: gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u, unsigned long>) (src/gcc/gcc/emit-rtl.c:1013) ==19771==by 0xFFE42E: make_vector_copies (src/gcc/gcc/config/i386/i386-features.c:716) ==19771==by 0xFFE42E: (anonymous namespace)::general_scalar_chain::convert_registers() (src/gcc/gcc/config/i386/i386-features.c:1173) ==19771==by 0xFFC3B8: convert (src/gcc/gcc/config/i386/i386-features.c:1192) ==19771==by 0xFFC3B8: convert_scalars_to_vector (src/gcc/gcc/config/i386/i386-features.c:1629) ==19771==by 0xFFC3B8: (anonymous namespace)::pass_stv::execute(function*) (src/gcc/gcc/config/i386/i386-features.c:1767) ==19771==by 0xB3463D: execute_one_pass(opt_pass*) (src/gcc/gcc/passes.c:2494) ==19771==by 0xB35047: execute_pass_list_1(opt_pass*) (src/gcc/gcc/passes.c:2580) ==19771==by 0xB35059: execute_pass_list_1(opt_pass*) (src/gcc/gcc/passes.c:2581) ==19771==by 0xB27164: execute_pass_list(function*, opt_pass*) (src/gcc/gcc/passes.c:2591) ==19771==by 0x768E5A: cgraph_node::expand() (src/gcc/gcc/cgraphunit.c:2194) ==19771==by 0x76C4DD: expand_all_functions (src/gcc/gcc/cgraphunit.c:2332) ==19771==by 0x76C4DD: symbol_table::compile() (src/gcc/gcc/cgraphunit.c:2688) ==19771==by 0x76CA4F: symbol_table::finalize_compilation_unit() (src/gcc/gcc/cgraphunit.c:2868) ==19771==by 0xC150F3: compile_file() (src/gcc/gcc/toplev.c:481) ==19771==by 0xC14BCE: do_compile (src/gcc/gcc/toplev.c:2166) ==19771==by 0xC14BCE: toplev::main(int, char**) (src/gcc/gcc/toplev.c:2301) ==19771== Address 0x2 is not stack'd, malloc'd or (recently) free'd ==19771== Unfortunately this does not give much more information than simply running under gdb. It looks like an entry in a hash map is searched for, but unexpectedly returns NULL. This NULL value is then passed as a rtx_def pointer to gen_rtx_SUBREG(), which attempts to access one of the struct elements, and this causes the segfault.
[Bug target/91767] [10 regression] After r274953, clang-compiled xgcc segfaults during RTL pass: stv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91767 --- Comment #3 from Dimitry Andric --- (In reply to Jakub Jelinek from comment #2) > Isn't that a clang bug though? hash_map has a constructor which should be > invoked by the general_scalar_chain constructor... It is possible, though I think it is more likely that clang optimizes some sort of undefined behavior differently from gcc. I attempted to get the initial stage (e.g. the xgcc build, is that the first stage, or the "zeroth" stage?) to build with -fsanitize=undefined, but it failed with linker errors.
[Bug target/91767] [10 regression] After r274953, clang-compiled xgcc segfaults during RTL pass: stv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91767
--- Comment #5 from Dimitry Andric ---
Hmm, it appears that this diff "fixes" it:
diff --git a/gcc/config/i386/i386-features.c b/gcc/config/i386/i386-features.c
index 9505b4a1330..091a59f3cb9 100644
--- a/gcc/config/i386/i386-features.c
+++ b/gcc/config/i386/i386-features.c
@@ -1166,7 +1166,11 @@ general_scalar_chain::convert_registers ()
bitmap_iterator bi;
unsigned id;
EXECUTE_IF_SET_IN_BITMAP (defs_conv, 0, id, bi)
-defs_map.put (regno_reg_rtx[id], gen_reg_rtx (smode));
+{
+ rtx key = regno_reg_rtx[id];
+ rtx val = gen_reg_rtx (smode);
+ defs_map.put (key, val);
+}
EXECUTE_IF_SET_IN_BITMAP (insns_conv, 0, id, bi)
for (df_ref ref = DF_INSN_UID_DEFS (id); ref; ref = DF_REF_NEXT_LOC (ref))
if (bitmap_bit_p (defs_conv, DF_REF_REGNO (ref)))
but obviously that can't be right, unless gen_reg_rtx() is doing something
horrible to regno_reg_rtx[]. I only see it adding another element at the end,
though.
I think this might indeed be some clang code generation bug, as the assembly
looks a little different with the above patch applied.
Digging further...
[Bug c++/70528] [5 Regression] bogus error: constructor required before non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70528 Dimitry Andric changed: What|Removed |Added CC||dimitry at andric dot com --- Comment #17 from Dimitry Andric --- (In reply to Jason Merrill from comment #15) > How important is it to fix this in GCC 5? For the FreeBSD ports system, gcc 5.4 is currently still the default version for programs requiring gcc. So it would be nice to have this fix in the branch. And the fix itself does not seem to be very invasive.
[Bug libstdc++/69388] Allow functexcept.cc definitions to be replaced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69388 Dimitry Andric changed: What|Removed |Added CC||dimitry at andric dot com --- Comment #4 from Dimitry Andric --- (In reply to Jonathan Wakely from comment #3) > Following discussion with one of the libc++ developers, we're considering > some common API that would allow an aplication to globally turn those throws > into aborts, so that redefining them would be unnecessary. As I discussed with libc++ maintainer Eric Fiselier, it would be nice if those functions called terminate() in the 'fatal' case instead. Then you at least have some standardized way of overriding the termination with your own mechanism, which appears to be what the Mozilla authors wanted to achieve. (Note that even gcc redefines abort() so it can catch it in its own way... :)
[Bug c++/67888] Compiling clang 3.7.0 results in is used but never defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67888 Dimitry Andric changed: What|Removed |Added CC||dimitry at andric dot com, ||paolo.carlini at oracle dot com --- Comment #6 from Dimitry Andric --- This appears to have been fixed with https://gcc.gnu.org/viewcvs?rev=224492&root=gcc&view=rev by Paolo Carlini, see also bug 51048. It seems to look easy enough to backport to earlier branchs. Paolo, can you please confirm?
[Bug c/64825] New: -Wcast-qual does not warn about struct members which are arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64825
Bug ID: 64825
Summary: -Wcast-qual does not warn about struct members which
are arrays
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitry at andric dot com
I'm not sure if it is intentional in gcc, but when using -Wcast-qual, it does
not warn about casting away the constness of struct members which are arrays.
For example, in this minimal test case:
struct foo {
int bar[1];
};
void *baz(const struct foo *f)
{
void *p = (void *)&f->bar;
return p;
}
Compiled with gcc version 5.0.0 20150111 (experimental) (FreeBSD Ports
Collection), using -Wcast-qual, this gives no warning at all.
Compiled with clang version 3.6.0 (branches/release_36 226102), using
-Wcast-qual, gives the expected:
foo.c:7:20: warning: cast from 'int const (*)[1]' to 'void *' drops const
qualifier [-Wcast-qual]
void *p = (void *)&f->bar;
^
1 warning generated.
[Bug jit/101491] [11 regression] /usr/local/include/libgccjit++.h conflicts between different GCC installations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491 Dimitry Andric changed: What|Removed |Added CC||dimitry at andric dot com, ||dmalcolm at gcc dot gnu.org --- Comment #1 from Dimitry Andric --- It appears libgccjit.h and libgccjit++.h are installed into $(includedir), via gcc/jit/Make-lang.in: jit.install-headers: installdirs $(INSTALL_DATA) $(srcdir)/jit/libgccjit.h \ $(DESTDIR)$(includedir)/libgccjit.h $(INSTALL_DATA) $(srcdir)/jit/libgccjit++.h \ $(DESTDIR)$(includedir)/libgccjit++.h This has been the case since David committed r217374. I'm unsure why these headers seem to be installed only recently?
[Bug jit/101491] [11 regression] /usr/local/include/libgccjit++.h conflicts between different GCC installations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491 --- Comment #4 from Dimitry Andric --- (In reply to Gerald Pfeifer from comment #3) > (In reply to David Malcolm from comment #2) > > I wonder why this changed recently; as Dimitry notes, this has been > > done the same since the initial merger of libgccjit into trunk. > > I believe we are not looking at a regression in one of the FreeBSD ports > nor on the gccjit side, just an issue that's been there "from day 1". > > Dimitry, is this consistent with your experience? Yes, it's only the FreeBSD gcc 11 and 12 ports that have these headers. But indeed they have been provided by gcc's Makefiles since 2014.
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #10 from Dimitry Andric --- Note there are other issues with poisoned identifiers, so I'll ask again: is a non-bootstrapped build even supposed to work, and officially supported, or not? Or more qualified, is a non-bootstrapped build only officially supported when building on a host with gcc and libstdc++? Otherwise, keeping this bug open makes no real sense, as there seems to be no movement at all on committing this patch. And it would make no sense to post any follow-up patches either.
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #16 from Dimitry Andric --- Created attachment 57639 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57639&action=edit Fix identifier poisoning in libcc1plugin and libc1plugin Here is another patch that can be committed separately. It fixes the direct inclusion of in libcc1plugin.cc and libcp1plugin.cc, and replaces it with INCLUDE_VECTOR before system.h.
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #17 from Dimitry Andric --- With both attached patches, I can build gcc master (gcc-14-9347-g790e0b478ea) with --disable-bootstrap, against libc++ 18 on FreeBSD 15-CURRENT, using clang 18 as host compiler.
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #21 from Dimitry Andric --- (In reply to Iain Sandoe from comment #20) > This is fixed on trunk, but is needed on open release branches. Indeed, please merge both commits: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=9970b576b7e4ae337af1268395ff221348c4b34a https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5213047b1d50af63dfabb5e5649821a6cb157e33
[Bug other/111632] New: gcc's C++ components fail to compile against recent libc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 Bug ID: 111632 Summary: gcc's C++ components fail to compile against recent libc++ headers Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: dimitry at andric dot com Target Milestone: --- As reported in https://bugs.freebsd.org/274041 and a number of related PRs, when building gcc's C++ sources against recent libc++ (>= 17), the poisoning of the ctype macros due to including safe-ctype.h before including C++ standard headers such as , , etc, causes many compilation errors, similar to: In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23: In file included from /home/dim/src/gcc/master/gcc/system.h:233: In file included from /usr/include/c++/v1/vector:321: In file included from /usr/include/c++/v1/__format/formatter_bool.h:20: In file included from /usr/include/c++/v1/__format/formatter_integral.h:32: In file included from /usr/include/c++/v1/locale:202: /usr/include/c++/v1/__locale:546:5: error: '__abi_tag__' attribute only applies to structs, variables, functions, and namespaces 546 | _LIBCPP_INLINE_VISIBILITY | ^ /usr/include/c++/v1/__config:813:37: note: expanded from macro '_LIBCPP_INLINE_VISIBILITY' 813 | # define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI | ^ /usr/include/c++/v1/__config:792:26: note: expanded from macro '_LIBCPP_HIDE_FROM_ABI' 792 | __attribute__((__abi_tag__(_LIBCPP_TOSTRING(_LIBCPP_VERSIONED_IDENTIFIER | ^ In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23: In file included from /home/dim/src/gcc/master/gcc/system.h:233: In file included from /usr/include/c++/v1/vector:321: In file included from /usr/include/c++/v1/__format/formatter_bool.h:20: In file included from /usr/include/c++/v1/__format/formatter_integral.h:32: In file included from /usr/include/c++/v1/locale:202: /usr/include/c++/v1/__locale:547:37: error: expected ';' at end of declaration list 547 | char_type toupper(char_type __c) const | ^ /usr/include/c++/v1/__locale:553:48: error: too many arguments provided to function-like macro invocation 553 | const char_type* toupper(char_type* __low, const char_type* __high) const |^ /home/dim/src/gcc/master/gcc/../include/safe-ctype.h:146:9: note: macro 'toupper' defined here 146 | #define toupper(c) do_not_use_toupper_with_safe_ctype | ^ This is because libc++ uses different transitive includes than libstdc++, and some of those transitive includes pull in various ctype declarations (typically via ). There was already a special case for including before safe-ctype.h, so move the rest of the C++ standard header includes to the same location, to fix the problem.
[Bug other/111632] gcc's C++ components fail to compile against recent libc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #1 from Dimitry Andric --- Created attachment 56010 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56010&action=edit Include safe-ctype.h after C++ standard headers, to avoid over-poisoning
[Bug middle-end/111632] gcc's C++ components fail to compile against recent libc++ headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #3 from Dimitry Andric --- (In reply to Richard Biener from comment #2) > the patch looks reasonable, please post it to gcc-patc...@gcc.gnu.org https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631611.html
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #29 from Dimitry Andric --- (In reply to Liviu Ionescu from comment #28) > (In reply to Francois-Xavier Coudert from comment #27) > > *** Bug 115006 has been marked as a duplicate of this bug. *** > > 11506 is related to gcov.cc, does the existing fixes also apply to this file? https://gcc.gnu.org/g:9970b576b7e4ae337af1268395ff221348c4b34a fixes system.h which is also included by gcov.cc, so I would expect that to work. Which version of gcc were you building?
[Bug middle-end/111632] gcc fails to bootstrap when using libc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 --- Comment #5 from Dimitry Andric --- Is there any further action required to get this patch in? :)
[Bug libstdc++/117210] [15 regression] error: 'llabs' is not a member of 'std'; did you mean 'labs'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117210 --- Comment #12 from Dimitry Andric --- So, something like this? diff --git a/libstdc++-v3/config/os/bsd/freebsd/os_defines.h b/libstdc++-v3/config/os/bsd/freebsd/os_defines.h index 0d63ae6cec4..e414524dcc2 100644 --- a/libstdc++-v3/config/os/bsd/freebsd/os_defines.h +++ b/libstdc++-v3/config/os/bsd/freebsd/os_defines.h @@ -26,6 +26,9 @@ #ifndef _GLIBCXX_OS_DEFINES #define _GLIBCXX_OS_DEFINES 1 +// For __ISO_C_VISIBLE and __LONG_LONG_SUPPORTED +#include + // System-specific #define, typedefs, corrections, etc, go here. This // file will come before all others. I think a similar approach might be needed for NetBSD and/or OpenBSD, btw.
[Bug libstdc++/117210] [15 regression] error: 'llabs' is not a member of 'std'; did you mean 'labs'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117210
--- Comment #10 from Dimitry Andric ---
(In reply to Jonathan Wakely from comment #9)
> Does this work?
>
> #include
> #include
>
> int main ()
> {
> long long a = 5;
> std::llabs(a);
> return 0;
> }
Yes, that works. So maybe we were lucky that cdefs.h got transitively included
in the past, but not anymore?
That said, sys/cdefs.h is really a bit of a FreeBSD implementation detail. It
does get included automatically with most of the regular system headers,
including .
[Bug libstdc++/117210] [15 regression] error: 'llabs' is not a member of 'std'; did you mean 'labs'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117210
Dimitry Andric changed:
What|Removed |Added
CC||dimitry at andric dot com
--- Comment #6 from Dimitry Andric ---
It's conditionalized on _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC in
namespace std
{
#if !_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC
using ::__gnu_cxx::lldiv_t;
#endif
using ::__gnu_cxx::_Exit;
#if !_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC
using ::__gnu_cxx::llabs;
using ::__gnu_cxx::div;
using ::__gnu_cxx::lldiv;
#endif
using ::__gnu_cxx::atoll;
using ::__gnu_cxx::strtof;
using ::__gnu_cxx::strtoll;
using ::__gnu_cxx::strtoull;
using ::__gnu_cxx::strtold;
} // namespace std
In the FreeBSD port I see in
/usr/local/lib/gcc15/include/c++/x86_64-portbld-freebsd15.0/bits/os_defines.h:
#define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE >= 1999))
#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1
#if _GLIBCXX_USE_C99_DYNAMIC || !defined __LONG_LONG_SUPPORTED
#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC 1
#else
#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC 0
#endif
I think __LONG_LONG_SUPPORTED is supposed to come out of a base system header,
/usr/include/sys/cdefs.h, and similar for __ISO_C_VISIBLE.
However, this piece of code in FreeBSD's os_defines.h changed not that long
ago, in commit r15-3904-ge23e5370d58 for bug 116859:
--- a/libstdc++-v3/config/os/bsd/freebsd/os_defines.h
+++ b/libstdc++-v3/config/os/bsd/freebsd/os_defines.h
@@ -36,8 +36,16 @@
#define _GLIBCXX_USE_C99_CHECK 1
#define _GLIBCXX_USE_C99_DYNAMIC (!(__ISO_C_VISIBLE >= 1999))
#define _GLIBCXX_USE_C99_LONG_LONG_CHECK 1
-#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC ||
!defined __LONG_LONG_SUPPORTED)
+#if _GLIBCXX_USE_C99_DYNAMIC || !defined __LONG_LONG_SUPPORTED
+#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC 1
+#else
+#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC 0
+#endif
#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1
-#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE
+#ifdef _XOPEN_SOURCE
+#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC 1
+#else
+#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC 0
+#endif
#endif
There is a good chance this commit is the reason.
[Bug libgcc/118685] FreeBSD static executables segfault due to libgcc missing crtbeginT.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118685 --- Comment #1 from Dimitry Andric --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674663.html
[Bug libgcc/118685] New: FreeBSD static executables segfault due to libgcc missing crtbeginT.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118685
Bug ID: 118685
Summary: FreeBSD static executables segfault due to libgcc
missing crtbeginT.o
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitry at andric dot com
Target Milestone: ---
On one of the FreeBSD mailing lists, Steve Kargl reported an issue with
statically linked executables segfaulting, if they were compiled with gcc 14
[1].
The segfaults were caused by a bad .dtors section in such executables, looking
like:
Hex dump of section '.dtors':
0x004efca8
The function that walks over the dtors section is called __do_global_dtors_aux
[2]. It skips over the first element, since it should always be -1, but it
expects the array to be terminated by either a -1 or a 0 value. Because the
section is too short, it overruns into whatever section follows, usually
resulting in a segfault.
Further investigation shows that the cause for the strange .dtors section is
that gcc with the -static option attempts to link crtbeginT.o and crtend.o:
$ gcc -v -static helloworld.c -o helloworld
...
/usr/local/libexec/gcc14/gcc/x86_64-portbld-freebsd15.0/14.2.0/collect2 \
-plugin
/usr/local/libexec/gcc14/gcc/x86_64-portbld-freebsd15.0/14.2.0/liblto_plugin.so
\
-plugin-opt=/usr/local/libexec/gcc14/gcc/x86_64-portbld-freebsd15.0/14.2.0/lto-wrapper
\
-plugin-opt=-fresolution=/tmp/ccRgJPpe.res \
-plugin-opt=-pass-through=-lgcc \
-plugin-opt=-pass-through=-lgcc_eh \
-plugin-opt=-pass-through=-lc \
-plugin-opt=-pass-through=-lgcc \
-plugin-opt=-pass-through=-lgcc_eh \
-m elf_x86_64_fbsd \
-V \
-Bstatic \
-o helloworld \
/usr/lib/crt1.o \
/usr/lib/crti.o \
/usr/local/lib/gcc14/gcc/x86_64-portbld-freebsd15.0/14.2.0/crtbeginT.o \
-L/usr/local/lib/gcc14/gcc/x86_64-portbld-freebsd15.0/14.2.0 \
-L/usr/local/lib/gcc14/gcc/x86_64-portbld-freebsd15.0/14.2.0/../../../../../x86_64-portbld-freebsd15.0/lib
\
-L/usr/local/lib/gcc14/gcc/x86_64-portbld-freebsd15.0/14.2.0/../../.. \
/tmp/ccEhqbzH.o \
-lgcc \
-lgcc_eh \
-lc \
-lgcc \
-lgcc_eh \
/usr/local/lib/gcc14/gcc/x86_64-portbld-freebsd15.0/14.2.0/crtend.o \
/usr/lib/crtn.o
Because the gcc port does not contain a crtbeginT.o file, it finds the
corresponding file in /usr/lib instead, thus "mixing" the base system
crtbeginT.o with the gcc-provided crtend.o.
The base system crtbeginT.o contains the first part of the .dtors section:
static crt_func __DTOR_LIST__[] __section(".dtors") __used = {
(crt_func)-1
};
and normally the base system's crtend.o contains the last part:
static crt_func __DTOR_END__[] __section(".dtors") __used = {
(crt_func)0
};
However, the gcc-provided crtend.o does _not_ contain any .dtors section, since
gcc's configure script detects support for
.preinit_array/.init_array/.fini_array, and thus defines
HAVE_INITFINI_ARRAY_SUPPORT.
Therefore, the final .dtors section in a static executable only contains the
first part, which results in the segfault.
Note that dynamic executables never see this issue, because then gcc will use
its _own_ crtbeginS.o and crtendS.so: there will be no .ctors or .dtors
sections in the executable, but .init and .fini sections.
As to fixing the problem, on the FreeBSD side we are going to implement
seatbelts in the code that walks over the .ctors and .dtors tables, ensuring
that they will not overrun the actual section boundaries. But this is really
only a workaround.
On the gcc side, we would like to suggest adding crtbeginT.o to the
libgcc-provided crt objects, so it will prefer that one over the base system's
version. In that case, static executables will also end up without any
.ctors/dtors sections, and segfaults will be avoided. (Alternatively, gcc could
stop providing crt startup objects completely, and rely on the base system
ones, but that is a lot more drastic.)
I will submit a patch to gcc-patches@ for this.
[1] https://lists.freebsd.org/archives/freebsd-hackers/2025-January/004236.html
[2] https://cgit.freebsd.org/src/tree/lib/csu/common/crtbegin.c#n69
[Bug tree-optimization/113239] [13/14/15 regression] After 822a11a1e64, bogus -Warray-bounds warnings in std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113239
Dimitry Andric changed:
What|Removed |Added
CC||dimitry at andric dot com
--- Comment #12 from Dimitry Andric ---
(In reply to Andrew Pinski from comment #10)
> The warning seems to be fixed on the trunk but the missed optimization is
> still around.
FWIW, bisection shows the warning went away with r15-4578-g774ad67fba4
("Implement operator_pointer_diff::fold_range") for bug 117222 ("[15
regression] Missed optimization with with std::vector resize in loop since
r15-575-gda73261ce7731b") by Andrew Macleod.
[Bug tree-optimization/117204] [12/13/14/15 regression] After r12-2132-ga1108556677, bogus -Warray-bounds warnings in std::vector::back()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117204
Dimitry Andric changed:
What|Removed |Added
CC||dimitry at andric dot com
--- Comment #4 from Dimitry Andric ---
(In reply to Jeffrey A. Law from comment #3)
> I think the minimized test is bogus. Note:
>
> struct vector : _Vector_base<_Tp, _Alloc> {
> typedef _Vector_base<_Tp, _Alloc> _Base;
> typedef _Base::pointer iterator;
> using _Base::_M_impl;
> vector();
> vector(vector &) { _M_impl._M_finish = 0; }
> __alloc_traits::reference back() {
> iterator __trans_tmp_5 = _M_impl._M_finish, __trans_tmp_2 =
> __trans_tmp_5;
> return *(__trans_tmp_2 - 1);
> }
> };
>
> Note the assignment to _M_impl._M_finish, which is then assigned to
> __trans_tmp_5 which is then assigned to __trans_tmp_2 and then dereferenced.
>
> That corresponds to this chunk of IL:
>
> last = MEM[(const struct tdr_t &)0B + 18446744073709551592];
>
>
> That's going to trigger the out of bounds access warning, but I think it's
> warranted in this case.
It could be that cvise messed this up while reducing, but the basic code came
straight out of libstdc++. So it's still a possible issue in libstdc++.
In any case, we're ignoring -Warray-bounds now since it gives too many false
positives.
