[Bug c/116854] New: GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854 Bug ID: 116854 Summary: GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support Product: gcc Version: 13.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ipsum.te.futue at gmail dot com Target Milestone: --- Summary: GCC enables __haswell__ on certain AMD Excavator CPUs that '-march=native' resolves to '-march=bdver4 -mno-rdrnd' despite the fact that RDRND should be checked for and required in order to enable __haswell__. While investigating segfaults within Qt, compiled with GCC 13.3.1, it has been discovered that GCC is attempting to compile for RDRND on bdver4 arch CPUs. Affected users specify -march=native, which resolves to -march=bdver4. Docs state that bdver4 is a superset of Haswell, which implies the presence of RDRND: ~ $ gcc -dM -E -march=bdver4 -xc /dev/null | grep RDRND #define __RDRND__ 1 To quote from this [https://bugreports.qt.io/browse/QTBUG-129193?focusedId=825891&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-825891] comment, in the original Qt bug: "Ok, so the problem is that this CPU is missing the random number generator instructions, which all Intel CPU have had since Ivy Bridge (2013). That is a problem, but not our problem here. Our problem here is that we have a mismatch between what features are required at compile-time to enable __haswell__ and which ones are checked at runtime for that CPU." It is important to note that the Gentoo tool `resolve-march-native` returns '-mno-rdrnd' as part of its resolution for an affected machine, however it seems that even with this being the case, GCC compiles the affected Qt libraries expecting RDRND as part of the feature set. A final quote from the Qt bug: "Apparently, for AMD Excavator (Bulldozer 4), GCC says that the RDRND ISA extension is mandatory. That means QtCore assumes it's always present if you compile with -march=bdver4 and that is likely to crash with SIGILL if you use that flag." NB: Affected users compiled with '-march=native' in all documented cases, and allowed GCC to resolve the CPU arch and features. ~ $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/13/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-13.3.1_p20240614/work/gcc-13-20240614/configure --host=x86_64-pc-lin ux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/13 --includedir=/usr/lib/ gcc/x86_64-pc-linux-gnu/13/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13 --mandir=/usr/share/gcc-data /x86_64-pc-linux-gnu/13/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/info --with-gxx-include-dir=/usr/li b/gcc/x86_64-pc-linux-gnu/13/include/g++-v13 --disable-silent-rules --disable-dependency-tracking --with-python-dir= /share/gcc-data/x86_64-pc-linux-gnu/13/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable- checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 13.3.1_p20240614 p17' --w ith-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-thr eads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed -point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --enable-cet --disable-systemtap --di sable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --without-isl --enable-default-pie - -enable-default-ssp --disable-fixincludes --with-build-config='bootstrap-lto bootstrap-cet' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.3.1 20240614 (Gentoo Hardened 13.3.1_p20240614 p17)
[Bug c++/116844] Disambiguation of T x = delete("text")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116844
--- Comment #3 from Jakub Jelinek ---
I think this isn't rejects-valid, http://eel.is/c++draft/dcl.fct#17 says that
typedef introduced functions should be only declared, not defined, and {} or =
delete; or = delete ("reason"); are definitions (and I think using is counted
as typedef).
I think all we do wrong is report different errors from what the standard says
how it should be parsed (so pedantically a non-issue, we still reject it, but
QoI).
[Bug libstdc++/116853] New: [Regression 15] Bootstrap fails on *-darwin* after r15-3859-g63a598deb0c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116853 Bug ID: 116853 Summary: [Regression 15] Bootstrap fails on *-darwin* after r15-3859-g63a598deb0c9 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org CC: jason at gcc dot gnu.org, redi at gcc dot gnu.org Target Milestone: --- Three fails of the form: /scratch/12-mon-rosetta/gcc-master/prev-x86_64-apple-darwin21/libstdc++-v3/include/bits/basic_string.h:4410:43: error: argument of function call might be a candidate for a format attribute [-Werror=suggest-attribute=format] 4410 | return __gnu_cxx::__to_xstring(&std::vsnprintf, __n, |~~~^~ 4411 |"%f", __val); | (line 4420 and 4430 the same). This does not appear to be bogus - but in ext/string_conversions.h we have only a template for this which does not accept the attribute. I am testing the following work-around - but that might not be the preferred solution: diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h index 976577f8f22..e9b17ea48b5 100644 --- a/libstdc++-v3/include/bits/basic_string.h +++ b/libstdc++-v3/include/bits/basic_string.h @@ -4399,6 +4399,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 return __str; } #elif _GLIBCXX_USE_C99_STDIO +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wsuggest-attribute=format" // NB: (v)snprintf vs sprintf. _GLIBCXX_NODISCARD @@ -4430,6 +4432,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11 return __gnu_cxx::__to_xstring(&std::vsnprintf, __n, "%Lf", __val); } +#pragma GCC diagnostic pop #endif // _GLIBCXX_USE_C99_STDIO #if defined(_GLIBCXX_USE_WCHAR_T) && _GLIBCXX_USE_C99_WCHAR
[Bug libstdc++/116853] [15 regression] Bootstrap fails on Darwin, Solaris after r15-3859-g63a598deb0c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116853 Rainer Orth changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Rainer Orth --- This is exactly the same issue I'm seeing on Solaris.
[Bug libstdc++/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
--- Comment #6 from Jakub Jelinek ---
At least on i686-linux, I think this is PCH related, moving away the
stdc++.h.gch directory makes the warning disappear, so it is some kind of
interaction between the diagnostics ignores recorded during PCH writing vs.
their later use.
Unfortunately simple:
[[deprecated]] int foo () { return 42; }
template
struct S {
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
static int bar () { return foo (); }
#pragma GCC diagnostic pop
};
header and
#include "pr116847.h"
int a = S<0>::bar ();
doesn't reproduce that (with PCH).
[Bug tree-optimization/116850] [12/13/14/15 Regression] ICE at -O{s,2,3} on x86_64-linux-gnu: in verify_dominators, at dominance.cc:1194
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116850
Richard Biener changed:
What|Removed |Added
Version|unknown |15.0
CC||matz at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Target Milestone|--- |12.5
--- Comment #2 from Richard Biener ---
It's basically a checking issue - we're computing post-dominators on demand
but with checking each time we do this we verify them. But our CFG
manipulations do not update post-dominators which is what it trips on.
I've tried the following but post-dom updating isn't easy if the new
block is the successor. We should pretend the old block was new and
re-associate existing post-dom info with the new block.
diff --git a/gcc/gimple-ssa-isolate-paths.cc b/gcc/gimple-ssa-isolate-paths.cc
index fae18db0c1d..c0d4451384a 100644
--- a/gcc/gimple-ssa-isolate-paths.cc
+++ b/gcc/gimple-ssa-isolate-paths.cc
@@ -104,14 +104,27 @@ insert_trap (gimple_stmt_iterator *si_p, tree op)
gsi_insert_after (si_p, seq, GSI_NEW_STMT);
if (stmt_ends_bb_p (stmt))
{
- split_block (gimple_bb (stmt), stmt);
+ edge e = split_block (gimple_bb (stmt), stmt);
+ if (dom_info_available_p (CDI_POST_DOMINATORS))
+ /* FIXME */;
return;
}
}
else
gsi_insert_before (si_p, seq, GSI_NEW_STMT);
- split_block (gimple_bb (new_stmt), new_stmt);
+ edge e = split_block (gimple_bb (new_stmt), new_stmt);
+ if (dom_info_available_p (CDI_POST_DOMINATORS))
+{
+ e->dest->dom[1]
+ = e->src->dom[1];
+ e->src->dom[1] = NULL;
+ add_to_dominance_info (CDI_POST_DOMINATORS, e->src);
+ set_immediate_dominator (CDI_POST_DOMINATORS, e->src,
+ e->dest);
+ redirect_immediate_dominators (CDI_POST_DOMINATORS, e->dest,
+e->src);
+}
*si_p = gsi_for_stmt (stmt);
}
That said, it would be best to remove the requirement on post-dominators.
I think we can end up running into the broken post-dom info and we
don't want to re-compute it all the time.
diff --git a/gcc/gimple-ssa-isolate-paths.cc b/gcc/gimple-ssa-isolate-paths.cc
index fae18db0c1d..401f99789f3 100644
--- a/gcc/gimple-ssa-isolate-paths.cc
+++ b/gcc/gimple-ssa-isolate-paths.cc
@@ -803,7 +818,8 @@ warn_return_addr_local (basic_block bb, greturn
*return_stmt)
return;
/* We only need it for this particular case. */
- calculate_dominance_info (CDI_POST_DOMINATORS);
+ if (!dom_info_available_p (CDI_POST_DOMINATORS))
+calculate_dominance_info (CDI_POST_DOMINATORS);
const args_loc_t *argsloc = locmap.get (return_stmt);
gcc_assert (argsloc);
fixes the ICE but as said above leaves us to possibly refer to broken /
non-existent DOM info and crash.
[Bug c++/116852] -fvisibility-inlines-hidden does not hide template functions without 'inline'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116852 --- Comment #1 from Richard Biener --- I don't think there's a way besides wrapping those inside #pragma GCC visibility, using attributes and/or -fvisibility I also don't think being a template makes a function "special" to other functions, so not sure if a new -fvisibility-functin-templates-hidden makes sense.
[Bug libstdc++/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847 Rainer Orth changed: What|Removed |Added Target|powerpc64-linux-gnu,|powerpc64-linux-gnu, |powerpc64le-linux-gnu |powerpc64le-linux-gnu, ||*-*-solaris2.11 Component|other |libstdc++ CC||ro at gcc dot gnu.org --- Comment #3 from Rainer Orth --- I see similar errors (100 libstdc++ tests FAILing with excess errors) on Solaris, both sparc and x86. The patch also broke Solaris bootstrap; will report that separately.
[Bug libstdc++/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847 --- Comment #4 from Iain Sandoe --- (In reply to Rainer Orth from comment #3) > The patch also broke Solaris bootstrap; will report that separately. likewise *-darwin* (also have a report in preparation).
[Bug middle-end/116788] Relative sysroot and -save-temps don't play nicely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116788 --- Comment #7 from w.steinwender at freenet dot de --- Compilation with -save-temps works if EACCES and ENOTDIR is added to the list after if. cc1 -v reports "ignoring nonexistent directory". Maybe remove_duplicates() should return different reasons for different errnos.
[Bug libstdc++/116853] [Regression 15] Bootstrap fails on *-darwin* after r15-3859-g63a598deb0c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116853 Iain Sandoe changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=116847 Target Milestone|--- |15.0 Last reconfirmed||2024-9-26
[Bug libstdc++/116853] [15 regression] Bootstrap fails on Darwin, Solaris after r15-3859-g63a598deb0c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116853 --- Comment #2 from Jonathan Wakely --- The workaround is fine to push if it works.
[Bug tree-optimization/116850] [12/13/14/15 Regression] ICE at -O{s,2,3} on x86_64-linux-gnu: in verify_dominators, at dominance.cc:1194
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116850 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Instead of using post-dominance from entry we could approximate that by dominance from exit which requires adding fake exit edges.
[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116550 Georg-Johann Lay changed: What|Removed |Added Attachment #59196|0 |1 is obsolete|| --- Comment #7 from Georg-Johann Lay --- Created attachment 59197 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59197&action=edit diff-test-v2.txt Results are looking good on avr, too (I had a nit in PATH).
[Bug c/116854] GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854 --- Comment #1 from Uroš Bizjak --- (In reply to Anonymous from comment #0) > Summary: GCC enables __haswell__ on certain AMD Excavator CPUs that > '-march=native' resolves to '-march=bdver4 -mno-rdrnd' despite the fact that > RDRND should be checked for and required in order to enable __haswell__. > > While investigating segfaults within Qt, compiled with GCC 13.3.1, it has > been discovered that GCC is attempting to compile for RDRND on bdver4 arch > CPUs. Affected users specify -march=native, which resolves to -march=bdver4. > > Docs state that bdver4 is a superset of Haswell, which implies the presence > of RDRND: > > ~ $ gcc -dM -E -march=bdver4 -xc /dev/null | grep RDRND > #define __RDRND__ 1 > > > To quote from this > [https://bugreports.qt.io/browse/QTBUG-129193?focusedId=825891&page=com. > atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment- > 825891] comment, in the original Qt bug: > > "Ok, so the problem is that this CPU is missing the random number generator > instructions, which all Intel CPU have had since Ivy Bridge (2013). That is > a problem, but not our problem here. Our problem here is that we have a > mismatch between what features are required at compile-time to enable > __haswell__ and which ones are checked at runtime for that CPU." > > It is important to note that the Gentoo tool `resolve-march-native` returns > '-mno-rdrnd' as part of its resolution for an affected machine, however it > seems that even with this being the case, GCC compiles the affected Qt > libraries expecting RDRND as part of the feature set. > > A final quote from the Qt bug: > "Apparently, for AMD Excavator (Bulldozer 4), GCC says that the RDRND ISA > extension is mandatory. That means QtCore assumes it's always present if you > compile with -march=bdver4 and that is likely to crash with SIGILL if you > use that flag." > > NB: Affected users compiled with '-march=native' in all documented cases, > and allowed GCC to resolve the CPU arch and features. -march=native also returns compile flags that fine-tune available ISAs. You can see all flags passed to cc1 by adding -### to the compiler flags, e.g.: gcc -march=native -### hello.c However, -march=bdver4 -mno-rdrnd is what this will show for your target and gcc -march=bdver4 -mno-rdrnd for sure won't define __RDRND__. Does QT enable RDRND instruction based on the definition of __haswell__ or based on the definiotion of __RDRND__?
[Bug libstdc++/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #3 from Rainer Orth ---
> I see similar errors (100 libstdc++ tests FAILing with excess errors) on
> Solaris, both sparc and x86.
The Solaris testsuite failures boil down to just a few issues:
bits/locale_facets_nonio.tcc:1479: warning: converting from
'std::istreambuf_iterator >
(std::__cxx11::time_get::)(std::__cxx11::time_get::iter_type,
std::__cxx11::time_get::iter_type, std::ios_base&,
std::ios_base::iostate&, std::tm*, char, char) const' {aka
'std::istreambuf_iterator >
(std::__cxx11::time_get::)(std::istreambuf_iterator >, std::istreambuf_iterator
>, std::ios_base&, std::_Ios_Iostate&, std::tm*, char, char) const'} to 'void*'
[-Wpmf-conversions]
bits/stl_tempbuf.h:209: warning: 'std::pair<_Tp*, long int>
std::get_temporary_buffer(ptrdiff_t) [with _Tp = __gnu_test::copy_tracker;
ptrdiff_t = long int]' is deprecated [-Wdeprecated-declarations]
condition_variable:266: warning: 'bool std::uncaught_exception()' is
deprecated: use 'std::uncaught_exceptions()' instead
[-Wdeprecated-declarations]
latch:68: warning: comparison of integer expressions of different signedness:
'const long unsigned int' and 'std::ptrdiff_t' {aka 'long int'}
[-Wsign-compare]
ostream:521: warning: 'bool std::uncaught_exception()' is deprecated: use
'std::uncaught_exceptions()' instead [-Wdeprecated-declarations]
parallel/base.h:157: warning: 'template struct std::binary_function' is deprecated [-Wdeprecated-declarations]
With the exception of the latch one, most of them shouldn't occur since
the code is already wrapped in
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-W..."
[...]
#pragma GCC diagnostic pop
[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116550 --- Comment #8 from Georg-Johann Lay --- Though it seems there are also new execution FAILs: $ make -k check-gcc RUNTESTFLAGS="--target_board=atmega128-sim --tool_opts=-mlra execute.exp=simd-[12].c -all" Running /home/john/xgnu/source/gcc-master/gcc/testsuite/gcc.c-torture/execute/execute.exp ... PASS: gcc.c-torture/execute/simd-1.c -O0 (test for excess errors) PASS: gcc.c-torture/execute/simd-1.c -O0 execution test PASS: gcc.c-torture/execute/simd-1.c -O1 (test for excess errors) FAIL: gcc.c-torture/execute/simd-1.c -O1 execution test PASS: gcc.c-torture/execute/simd-1.c -O2 (test for excess errors) FAIL: gcc.c-torture/execute/simd-1.c -O2 execution test PASS: gcc.c-torture/execute/simd-1.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/execute/simd-1.c -O3 -g execution test PASS: gcc.c-torture/execute/simd-1.c -Os (test for excess errors) FAIL: gcc.c-torture/execute/simd-1.c -Os execution test PASS: gcc.c-torture/execute/simd-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: gcc.c-torture/execute/simd-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test PASS: gcc.c-torture/execute/simd-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) PASS: gcc.c-torture/execute/simd-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test PASS: gcc.c-torture/execute/simd-2.c -O0 (test for excess errors) PASS: gcc.c-torture/execute/simd-2.c -O0 execution test PASS: gcc.c-torture/execute/simd-2.c -O1 (test for excess errors) PASS: gcc.c-torture/execute/simd-2.c -O1 execution test PASS: gcc.c-torture/execute/simd-2.c -O2 (test for excess errors) FAIL: gcc.c-torture/execute/simd-2.c -O2 execution test PASS: gcc.c-torture/execute/simd-2.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/execute/simd-2.c -O3 -g execution test PASS: gcc.c-torture/execute/simd-2.c -Os (test for excess errors) FAIL: gcc.c-torture/execute/simd-2.c -Os execution test FAIL: gcc.c-torture/execute/simd-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error: in patch_jump_insn, at cfgrtl.cc:1303) FAIL: gcc.c-torture/execute/simd-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: gcc.c-torture/execute/simd-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test PASS: gcc.c-torture/execute/simd-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (test for excess errors) PASS: gcc.c-torture/execute/simd-2.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test
Re: Is this a bug is 14.2.0?
On 26/09/24 04:44 +, Jason Mancini wrote:
Problem happens in 14.2.0, 13.2.0, 12.2.0
Doesn't seem to happen in 10.2.0 or 11.2.0
Only seems to happen for -std=c++17/14/11, but not for c++20/23/26.
Only seems to happen for -O2, but not -O0 / -O1 / -O3.
Happens for vector, but not deque or list.
Happens for vector, but not vector.
Doesn't happen if the enum is declared outside the function.
Doesn't happen with clang++.
Issue replicates on godbolt.
The gcc-bugs mailing list is for automated email from our Bugzilla
database, not for reporting (or asking about) bugs. Emails sent to
this list will often be overlooked, missed, or just ignored.
This particular problem is a false positive warning (which you've
turned into an error with -Werror, so the solution is to not do that).
I don't think this false positive is already known, so it would be
great if you could report it as a bug, please see
https://gcc.gnu.org/bugs/
Thanks!
Thanks,
Jason Mancini
==
g++ -c source.cc -Werror=nonnull -std=c++17 -O2
==
#include
void f(bool p)
{
enum e { e1 };
std::vector v;
if (p) { v = { e1 }; }
else { v = { e1 }; }
}
=== or even ===
#include
void f(bool p)
{
enum e { };
std::vector v;
if (p) { v = { }; }
else { v = { }; }
}
==
In file included from (...)/gcc-14.2.0/include/c++/14.2.0/vector:62,
from source.cc:1:
In static member function 'static _Up* std::__copy_move<_IsMove, true,
std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp = const
f(bool)::e; _Up = f(bool)::e; bool _IsMove = false]',
inlined from '_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove =
false; _II = const f(bool)::e*; _OI = f(bool)::e*]' at
(...)/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:521:30,
inlined from '_OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove =
false; _II = const f(bool)::e*; _OI = f(bool)::e*]' at
(...)/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:548:42,
inlined from '_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove =
false; _II = const f(bool)::e*; _OI = f(bool)::e*]' at
(...)/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:555:31,
inlined from '_OI std::copy(_II, _II, _OI) [with _II = const f(bool)::e*;
_OI = f(bool)::e*]' at
(...)/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:651:7,
inlined from 'void std::vector<_Tp, _Alloc>::_M_assign_aux(_ForwardIterator,
_ForwardIterator, std::forward_iterator_tag) [with _ForwardIterator = const f(bool)::e*;
_Tp = f(bool)::e; _Alloc = std::allocator]' at
(...)/gcc-14.2.0/include/c++/14.2.0/bits/vector.tcc:343:19:
(...)/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:452:30: error: argument
1 null where non-null expected [-Werror=nonnull]
452 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
| ~^~~
(...)/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:452:30: note: in a call
to built-in function 'void* __builtin_memmove(void*, const void*, long unsigned
int)'
==
EOM
[Bug libstdc++/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
--- Comment #7 from Jonathan Wakely ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #5)
> latch:68: warning: comparison of integer expressions of different
> signedness: 'const long unsigned int' and 'std::ptrdiff_t' {aka 'long int'}
> [-Wsign-compare]
I'll take care of this one.
[Bug tree-optimization/116855] New: Unsafe early-break vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
Bug ID: 116855
Summary: Unsafe early-break vectorization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fxue at os dot amperecomputing.com
Target Milestone: ---
For the case:
char string[1020];
char * find(size_t n, char c)
{
for (size_t i = 0; i < n; i++) {
if (string[i] == c)
return &string[i];
}
return 0;
}
On aarch64 (not SVE compilation), the loop could be vectorized with -O3 as:
...
bnd.5_22 = n_4(D) >> 4;
vect_cst__50 = {c_6(D), c_6(D), ..., c_6(D), c_6(D)};
...
# vectp_string.10_47 = PHI
# ivtmp_63 = PHI
...
vect__1.12_49 = MEM [(char *)vectp_string.10_47];
mask_patt_9.13_51 = vect__1.12_49 == vect_cst__50;
if (mask_patt_9.13_51 != { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 })
goto ; [5.50%]
else
goto ; [94.50%]
...
vectp_string.10_48 = vectp_string.10_47 + 16;
ivtmp_64 = ivtmp_63 + 1;
if (ivtmp_64 < bnd.5_22)
goto ; [94.50%]
else
goto ; [5.50%]
Suppose that n is 1026, larger than length of "string", and only its last
element equals "char c", then the search would end up with a vector load that
contains unsafe memory accesses out bound of "string", and this may trigger
segfault.
One possible fix is to generate vector niter using the smaller value between
known constant bound and variable scalar niter. Another solution is that we
could follow assertion as "-fallow-store-data-races", which assume segfault
would not happen, so it is fine with introduction of new data races, then we
could enable the vectorization with -Ofast, not -O3. And by this means, it
could be extended to cover data array (represented by pointer) with no
statically-determined bound, for example:
char * find(char *string, size_t n, char c)
{
for (size_t i = 0; i < n; i++) {
if (string[i] == c)
return &string[i];
}
return 0;
}
[Bug c/116856] New: Generated Code with unaligned uint32_t potentially hardfaults on ARM (due to LDRD)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856 Bug ID: 116856 Summary: Generated Code with unaligned uint32_t potentially hardfaults on ARM (due to LDRD) Product: gcc Version: 13.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: robert.hoelzl at posteo dot de Target Milestone: --- When accessing two consecutive 32bit values and xor-ing them (or probably doing any operation) GCC ARM32 in optimization mode uses LDRD (https://developer.arm.com/documentation/ddi0406/c/Application-Level-Architecture/Instruction-Details/Alphabetical-list-of-instructions/LDRD--immediate-?lang=en) to load both values at once. But LDRD does not work on unaligned pointers (https://developer.arm.com/documentation/dui0473/m/using-the-assembler/address-alignment) and thus causing a hard fault. The code to reproduce the problem roughly looks like: uint8_t array[100]; uint32_t * ptr = array + 1; // <- maybe you need another index to ensure that ptr is unaligned *ptr ^= *(ptr+1); Tested on Cortex-M33 with GCC 13.3 and GCC 10.3 with optimization for size.
[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116550 --- Comment #9 from Georg-Johann Lay --- The gcc.c-torture/execute/simd-[12].c tests PASS with -mno-lra but are FAILing with -mlra. Without your patch there are some ICEs, with your patch it's only execution FAILs.
[Bug c/116856] Generated Code with unaligned uint32_t potentially hardfaults on ARM (due to LDRD)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- uint32_t has an alignment requirement. You can make an unaligned type and access via that instead. Or use memcpy .
[Bug c/116856] Generated Code with unaligned uint32_t potentially hardfaults on ARM (due to LDRD)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856 Robert Hölzl changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Robert Hölzl --- Cortex-M generally allows unaligned access: https://developer.arm.com/documentation/ddi0406/c/Appendices/ARMv6-Differences/Application-level-memory-support/Alignment?lang=en Actually I tested already to create an unaligned type (although I'd expect that the compiler guesses that without a hint): uint8_t array[100]; uint32_t __attribute__ ((__aligned__(1))) * ptr = (uint32_t *) (array + 1); *ptr ^= *(ptr+1); But that still uses LDRD (although it should be clear to the compiler that this will not work out).
[Bug ada/52280] FAIL: c974013 -- C974013 Abortable part did not execute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52280 Eric Botcazou changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from Eric Botcazou --- Is this still relevant?
[Bug ada/43485] select ... then abort ... end select don't abort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43485 --- Comment #3 from Eric Botcazou --- > Still present on the mainline, but the problem directly comes from the use > of Ada.Real_Time, i.e. this works if you replace it with Ada.Calendar. This is apparently sufficient: diff --git a/gcc/ada/libgnarl/a-retide.adb b/gcc/ada/libgnarl/a-retide.adb index 80e3d31ed17..d7cac0f2124 100644 --- a/gcc/ada/libgnarl/a-retide.adb +++ b/gcc/ada/libgnarl/a-retide.adb @@ -31,11 +31,13 @@ with Ada.Exceptions; +with System.Soft_Links; with System.Tasking; with System.Task_Primitives.Operations; package body Ada.Real_Time.Delays is + package SSL renames System.Soft_Links; package STPO renames System.Task_Primitives.Operations; @@ -62,7 +64,9 @@ package body Ada.Real_Time.Delays is Ada.Exceptions.Raise_Exception (Program_Error'Identity, "potentially blocking operation"); else + SSL.Abort_Defer.all; STPO.Timed_Delay (Self_Id, To_Duration (T), Absolute_RT); + SSL.Abort_Undefer.all; end if; end Delay_Until;
[Bug ada/43485] select ... then abort ... end select don't abort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43485 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/116855] Unsafe early-break vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
--- Comment #1 from Andrew Pinski ---
the string array has an alignment of 16 byte so is this an issue? Since we know
the alignment then there is possibility of incorrect behavior.
.align 4
.set.LANCHOR0,. + 0
.type string, %object
.size string, 1020
string:
.zero 1020
base_address: &string
offset from base address: 0
constant offset from base address: 0
step: 1
base alignment: 16
base misalignment: 0
offset alignment: 128
step alignment: 1
base_object: string
Access function 0: {0, +, 1}_1
Though doing:
char string[1020] __attribute__((aligned(1)));
still cause the wrong thing.
[Bug ada/43485] select ... then abort ... end select don't abort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43485 Eric Botcazou changed: What|Removed |Added Version|unknown |15.0 --- Comment #2 from Eric Botcazou --- Still present on the mainline, but the problem directly comes from the use of Ada.Real_Time, i.e. this works if you replace it with Ada.Calendar.
[Bug ada/116832] Code after a select-then-abort in an abortable part executes when the outer select-then-abort completes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116832 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- PR ada/43485 comes from the use of Ada.Real_Time so is unrelated.
[Bug ada/116832] Code after a select-then-abort in an abortable part executes when the outer select-then-abort completes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116832 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2024-09-26 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #4 from Eric Botcazou --- Not clear if we support nested ATCs indeed. What do you use them for?
[Bug libstdc++/116857] New: [15 Regression] libsupc++ build failure on mingw32: libstdc++-v3/libsupc++/guard.cc:39:1: error: declaration of 'int __cxxabiv1::__cxa_guard_acquire(__guard*) noexcept' has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116857 Bug ID: 116857 Summary: [15 Regression] libsupc++ build failure on mingw32: libstdc++-v3/libsupc++/guard.cc:39:1: error: declaration of 'int __cxxabiv1::__cxa_guard_acquire(__guard*) noexcept' has a different exception specifier Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- Noticed the build failure today on `x86_64-w64-mingw32` target as: > ../../../../source/libstdc++-v3/libsupc++/guard.cc:39:1: error: declaration of 'int __cxxabiv1::__cxa_guard_acquire(__guard*) noexcept' has a different exception specifier >39 | __cxa_guard_acquire (__guard* g) _GLIBCXX_NOTHROW > | ^~~ > In file included from ../../../../source/libstdc++-v3/libsupc++/guard.cc:28: > /build/source/libstdc++-v3/libsupc++/cxxabi.h:120:3: note: from previous declaration 'int __cxxabiv1::__cxa_guard_acquire(__guard*)' > 120 | __cxa_guard_acquire(__guard*); > | ^~~ Looks like `__cxa_guard_acquire()` has exception mismatch: cxxabi.h- int cxxabi.h: __cxa_guard_acquire(__guard*); guard.cc-extern "C" int guard.cc:__cxa_guard_acquire (__guard* g) _GLIBCXX_NOTHROW Should both have consistent _GLIBCXX_NOTHROW annotation? (or absence of both) I'm not sure what change exposed the build failure.
[Bug libstdc++/116857] [15 Regression] libsupc++ build failure on mingw32: libstdc++-v3/libsupc++/guard.cc:39:1: error: declaration of 'int __cxxabiv1::__cxa_guard_acquire(__guard*) noexcept' has a di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116857 --- Comment #1 from Jonathan Wakely --- Probably r15-3859-g63a598deb0c9fc
[Bug ada/116832] Code after a select-then-abort in an abortable part executes when the outer select-then-abort completes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116832 --- Comment #5 from Liam Powell --- See the following code (shortened for clarity). There's probably a way to do this without them, but our workaround works here. select Connection.Hold; -- Continues after update is done then abort declare Occurrence : Ada.Exceptions.Exception_Occurrence; begin select Fatal_Exception_Occurrence_Holder.Get (Occurrence); then abort Update_Check.Block_Until_Check_For_Update; -- Prompt user if required Update_Check.Block_Until_Update_Allowed; -- Tell user update is running end select; Fatal_Exception_Occurrence_Holder.Get (Occurrence); -- Above line to compensate for GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116832 -- Display error end; Connection.Hold; -- Continues after update is done end select;
[Bug libstdc++/116857] [15 Regression] libsupc++ build failure on mingw32: libstdc++-v3/libsupc++/guard.cc:39:1: error: declaration of 'int __cxxabiv1::__cxa_guard_acquire(__guard*) noexcept' has a di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116857 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-09-26 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- But that just stopped the mismatch being ignored, the real bug was adding the NOTHROW in the first place, in r13-3381-gf036d759ecee53 The API is defined by the declarations in cxxabi.h so the definition should not be marked noexcept.
[Bug libstdc++/116857] [15 Regression] libsupc++ build failure on mingw32: libstdc++-v3/libsupc++/guard.cc:39:1: error: declaration of 'int __cxxabiv1::__cxa_guard_acquire(__guard*) noexcept' has a di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116857 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Keywords||build Target Milestone|--- |13.4
[Bug tree-optimization/116585] [12/13/14 Regression] SSA corruption with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116585 --- Comment #6 from Richard Biener --- (In reply to qinzhao from comment #5) > (In reply to Richard Biener from comment #4) > > Fixed on trunk sofar. > > thanks a lot for fixing this so quick. > Will this patch be backported to older releases? Yes, I'll pick it up after some soaking on trunk during my next backporting round. If you want to do the work of cherry-picking and regtesting feel free to do this earlier - it's been a week on trunk and a quite safe change.
[Bug target/69374] install.texi is bit-rotten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374 --- Comment #22 from GCC Commits --- The trunk branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:27003e5d6eadcddde617b89f11bab47ab75cc203 commit r15-3888-g27003e5d6eadcddde617b89f11bab47ab75cc203 Author: Gerald Pfeifer Date: Wed Sep 25 21:43:29 2024 +0800 doc: Remove MinGW note on binutils 2.16 Binutils 2.16 is 13 years old; no need to specifically refer to it as a requirement. gcc: PR target/69374 * doc/install.texi (Specific) <*-*-mingw32>: Remove note regarding binutils 2.16.
[Bug target/116822] [15 regression] RISC-V: ICE in compute_nregs_for_mode, at config/riscv/riscv-vector-costs.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116822 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed||2024-09-26 Status|UNCONFIRMED |NEW --- Comment #3 from Richard Biener --- Confirmed. #1 0x01838a1f in riscv_vector::compute_nregs_for_mode ( loop_vinfo=0x4bf5b90, mode=E_SImode, biggest_mode=E_HImode, lmul=8) at /space/rguenther/src/gcc-autopar_devel/gcc/config/riscv/riscv-vector-costs.cc:457 457 gcc_assert (biggest_size >= mode_size); and the caller processes an INTEGER_CST "var" with SImode. compute_local_live_ranges happily processes the '1' in ivtmp_379 = ivtmp_381 - 1; but this shouldn't be the issue with somehow computing a wrong biggest_mode. But I don't feel like debugging this mess of risc-v code. The patch results in more load/store-lanes to be used which should be good.
[Bug rtl-optimization/116550] [lra][avr] internal compiler error: in final_scan_insn_1, at final.cc:2807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116550 --- Comment #6 from Georg-Johann Lay --- ...I am stuck here. When I am testing locally, a single test like $ make -k check-gcc RUNTESTFLAGS="--target_board=atmega128-sim --tool_opts=-mlra compile.exp=2009-1.c -all" works fine, but on the remote (cfarm421 in that case) I am getting UNRESOLVED/UNSUPPORTED result.
[Bug middle-end/116845] gcc.dg/pr109393.c test fails on ilp32 targets (and maybe others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116845 --- Comment #7 from ptomsich at gcc dot gnu.org --- Our team will also be busy with other priorities for the next weeks. We will attempt to schedule this before the end of stage 1, but might still have to delay until stage 3.
[Bug target/116854] GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854 --- Comment #4 from Andrew Pinski --- > Since the BIOS and/or OS can disable it, >From the way I understand it, even things like avx can be turned on/off too. Does that mean gcc should disable avx by default for most targets, NO. Again the issue is qt is trying to reinterpret -march=native which is incorrect thing to always.
[Bug target/116856] Generated Code with unaligned uint32_t potentially hardfaults on ARM (due to LDRD)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856
--- Comment #4 from Andrew Pinski ---
```
#include
typedef uint32_t uuint32_t __attribute__ ((__aligned__(1))) ;
void f(uint8_t *array)
{
uuint32_t * ptr = (uuint32_t *) (array + 1);
*ptr ^= *(ptr+1);
}
```
Works for me with -mcpu=cortex-m33:
ldr r3, [r0, #1] @ unaligned
ldr r2, [r0, #5] @ unaligned
eorsr3, r3, r2
str r3, [r0, #1] @ unaligned
bx lr
This also works:
```
#include
typedef uint32_t uuint32_t __attribute__ ((__aligned__(1))) ;
void g(uint8_t *);
void f()//uint8_t *array)
{
uint8_t array[100];
uuint32_t * ptr = (uuint32_t *) (array + 1);
*ptr ^= *(ptr+1);
g(array);
}
```
Giving:
```
push{lr}
sub sp, sp, #108
ldr r3, [sp, #5] @ unaligned
ldr r2, [sp, #9] @ unaligned
add r0, sp, #4
eorsr3, r3, r2
str r3, [sp, #5] @ unaligned
bl g
```
[Bug testsuite/116683] new test g++.dg/ext/pragma-unroll-lambda-lto.C from r15-3585-g9759f6299d9633 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116683
--- Comment #5 from Alex Coplan ---
Ah, so the problem seems to be that we're scanning for "Unrolled loop 3 times"
appearing exactly once in the dump, but on powerpc it appears twice; that is
because the loop in main gets unrolled too (presumably due to different
unrolling heuristics on power).
The following, therefore, seems to fix the test failures on powerpc:
diff --git a/gcc/testsuite/g++.dg/ext/pragma-unroll-lambda-lto.C
b/gcc/testsuite/g++.dg/ext/pragma-unroll-lambda-lto.C
index 64cdf90f34d..20cbd2d15cf 100644
--- a/gcc/testsuite/g++.dg/ext/pragma-unroll-lambda-lto.C
+++ b/gcc/testsuite/g++.dg/ext/pragma-unroll-lambda-lto.C
@@ -24,6 +24,7 @@ short *use_find(short *p)
int main(void)
{
short a[1024];
+#pragma GCC unroll 0
for (int i = 0; i < 1024; i++)
a[i] = rand ();
I'll submit that fix if it still passes on aarch64 with that change too.
Re: Is this a bug is 14.2.0?
On Thu, Sep 26, 2024 at 2:57 AM Jonathan Wakely via Gcc-bugs
wrote:
>
> On 26/09/24 04:44 +, Jason Mancini wrote:
> >Problem happens in 14.2.0, 13.2.0, 12.2.0
> >Doesn't seem to happen in 10.2.0 or 11.2.0
> >Only seems to happen for -std=c++17/14/11, but not for c++20/23/26.
> >Only seems to happen for -O2, but not -O0 / -O1 / -O3.
> >Happens for vector, but not deque or list.
> >Happens for vector, but not vector.
> >Doesn't happen if the enum is declared outside the function.
> >Doesn't happen with clang++.
> >Issue replicates on godbolt.
>
> The gcc-bugs mailing list is for automated email from our Bugzilla
> database, not for reporting (or asking about) bugs. Emails sent to
> this list will often be overlooked, missed, or just ignored.
>
> This particular problem is a false positive warning (which you've
> turned into an error with -Werror, so the solution is to not do that).
>
> I don't think this false positive is already known, so it would be
> great if you could report it as a bug, please see
> https://gcc.gnu.org/bugs/
Just a quick follow up, I see Jason did submit a bug report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116851 . I have not
looked into it yet but I suspect it is related to how jump threading
is done and then the warning is done way after jump threading and
there just happens to be a path somehow that has become a nullptr.
Thanks,
Andrew
>
> Thanks!
>
>
>
>
> >Thanks,
> >Jason Mancini
> >
> >==
> >
> >g++ -c source.cc -Werror=nonnull -std=c++17 -O2
> >
> >==
> >
> >#include
> >void f(bool p)
> >{
> > enum e { e1 };
> > std::vector v;
> > if (p) { v = { e1 }; }
> > else { v = { e1 }; }
> >}
> >
> >=== or even ===
> >
> >#include
> >void f(bool p)
> >{
> > enum e { };
> > std::vector v;
> > if (p) { v = { }; }
> > else { v = { }; }
> >}
> >
> >==
> >
> >In file included from (...)/gcc-14.2.0/include/c++/14.2.0/vector:62,
> > from source.cc:1:
> >In static member function 'static _Up* std::__copy_move<_IsMove, true,
> >std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp =
> >const f(bool)::e; _Up = f(bool)::e; bool _IsMove = false]',
> >inlined from '_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove
> > = false; _II = const f(bool)::e*; _OI = f(bool)::e*]' at
> > (...)/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:521:30,
> >inlined from '_OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove
> > = false; _II = const f(bool)::e*; _OI = f(bool)::e*]' at
> > (...)/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:548:42,
> >inlined from '_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove =
> > false; _II = const f(bool)::e*; _OI = f(bool)::e*]' at
> > (...)/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:555:31,
> >inlined from '_OI std::copy(_II, _II, _OI) [with _II = const
> > f(bool)::e*; _OI = f(bool)::e*]' at
> > (...)/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:651:7,
> >inlined from 'void std::vector<_Tp,
> > _Alloc>::_M_assign_aux(_ForwardIterator, _ForwardIterator,
> > std::forward_iterator_tag) [with _ForwardIterator = const f(bool)::e*; _Tp
> > = f(bool)::e; _Alloc = std::allocator]' at
> > (...)/gcc-14.2.0/include/c++/14.2.0/bits/vector.tcc:343:19:
> >(...)/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:452:30: error:
> >argument 1 null where non-null expected [-Werror=nonnull]
> > 452 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
> > | ~^~~
> >(...)/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:452:30: note: in a
> >call to built-in function 'void* __builtin_memmove(void*, const void*, long
> >unsigned int)'
> >
> >==
> >EOM
> >
>
[Bug tree-optimization/116855] [14/15 Regression] Unsafe early-break vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855 --- Comment #3 from Richard Biener --- I would suggest to add a STMT_VINFO_ENSURE_NOTRAP or so and delay actual verification to vectorizable_load when both vector type and VF are fixed. We'd then likely need a LOOP_VINFO_MUST_USE_PARTIAL_VECTORS_P set conservatively the other way around from LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P. Alignment peeling could then peel if STMT_VINFO_ENSURE_NOTRAP and the target cannot do full loop masking.
[Bug tree-optimization/116850] [12/13/14/15 Regression] ICE at -O{s,2,3} on x86_64-linux-gnu: in verify_dominators, at dominance.cc:1194
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116850 --- Comment #4 from Michael Matz --- > Instead of using post-dominance from entry we could approximate that by > dominance from exit which requires adding fake exit edges. Hmm? post-dominance _is_ dominance from exit. (IOW: it's dominance on the reverse CFG). With the usual caveat that dead-ends need to be handled unlike the dominance case (hence the fake exit edges). I haven't yet looked at the problem here in detail, but generally speaking updating dominators is unboundedly difficult if random new edges are added (as in: all doms might change hence recomputing all of them can be equivalent). I don't think we ever did so for any postdom problem and just recompute. It may very well be that this would be too expensive here in which case we simply cannot do these transformations iteratively, we instead need to compute which transformations we want to do, then do all of them, then recompute postdom, and then stop.
[Bug fortran/116858] gfortran.dg/initialization_25.f90 test failure (exposed by r15-3890-g34bf6aa41ba539)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116858 Sam James changed: What|Removed |Added Last reconfirmed||2024-09-26 Assignee|unassigned at gcc dot gnu.org |sjames at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Sam James --- Oh, I see. r0-100012-gcdc6637d7c78ec reverted the change but kept the test, but marked it XFAIL in an ad-hoc way. I'll mark it XFAIL properly then close this.
[Bug fortran/116858] gfortran.dg/initialization_25.f90 test failure (exposed by r15-3890-g34bf6aa41ba539)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116858 Sam James changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Sam James --- Fixed.
[Bug target/116078] [15 Regression] 10-12% slowdown of 436.cactusADM on AMD Zen2 since r15-2187-g838999bb23303e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116078 --- Comment #6 from Filip Kastl --- Or maybe one binary has some expensive instructions which the other one doesn't. I didn't notice anything like that while looking through the perf results but I'm still learning to use perf effectively.
[Bug fortran/116858] gfortran.dg/initialization_25.f90 test failure (exposed by r15-3890-g34bf6aa41ba539)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116858 --- Comment #2 from GCC Commits --- The master branch has been updated by Sam James : https://gcc.gnu.org/g:819098dc71f2079aedc15a904ab5f17f0788d991 commit r15-3899-g819098dc71f2079aedc15a904ab5f17f0788d991 Author: Sam James Date: Thu Sep 26 15:43:33 2024 +0100 testsuite: XFAIL gfortran.dg/initialization_25.f90 properly The test was disabled/XFAIL'd informally in r0-100012-gcdc6637d7c78ec, but r15-3890-g34bf6aa41ba539 didn't realize this, causing a FAIL. Fix that by marking it as XFAIL per the original intent. gcc/testsuite/ChangeLog: PR fortran/35779 PR fortran/116858 * gfortran.dg/initialization_25.f90: Mark as XFAIL.
[Bug fortran/35779] error pointer wrong in PARAMETER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779 --- Comment #14 from GCC Commits --- The master branch has been updated by Sam James : https://gcc.gnu.org/g:819098dc71f2079aedc15a904ab5f17f0788d991 commit r15-3899-g819098dc71f2079aedc15a904ab5f17f0788d991 Author: Sam James Date: Thu Sep 26 15:43:33 2024 +0100 testsuite: XFAIL gfortran.dg/initialization_25.f90 properly The test was disabled/XFAIL'd informally in r0-100012-gcdc6637d7c78ec, but r15-3890-g34bf6aa41ba539 didn't realize this, causing a FAIL. Fix that by marking it as XFAIL per the original intent. gcc/testsuite/ChangeLog: PR fortran/35779 PR fortran/116858 * gfortran.dg/initialization_25.f90: Mark as XFAIL.
[Bug libstdc++/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847 Sam James changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-09-26
[Bug target/116078] [15 Regression] 10-12% slowdown of 436.cactusADM on AMD Zen2 since r15-2187-g838999bb23303e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116078 --- Comment #5 from Filip Kastl --- I've double checked that the slowdown really happens on this commit. It realy does. I've also double checked that the resulting binary is different. I've seen this slowdown on 2 separate Zen 2 machines. I've run perf on binaries compiled with GCCs with and without the commit. The dynamic instruction count is actually higher without the commit but only by ~0.0001%. The static instruction count is almost exactly the same (+-3 instructions). Unless I'm doing something wrong, this is weird. I guess this slowdown could be explained by instructions randomly being organized in way that the Zen 2 microarchitecture likes more? I've heard that this sometimes happens.
[Bug fortran/93158] Coarray ICE when module and submodule are in separate files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93158 Andre Vehreschild changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #2 from Andre Vehreschild --- Patch at https://gcc.gnu.org/pipermail/fortran/2024-September/061098.html Waiting for review.
[Bug testsuite/116683] new test g++.dg/ext/pragma-unroll-lambda-lto.C from r15-3585-g9759f6299d9633 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116683 --- Comment #3 from Alex Coplan --- Sorry for the delay in looking into this. So it looks like the unrolling works as expected without LTO, at least I see: ;; Unrolled loop 3 times, constant # of iterations 26 insns in the dump with a powerpc cc1. So unfortunately the problem seems to be both powerpc- and LTO-specific, meaning I'll need to build a full native powerpc toolchain on a cfarm machine to reproduce. In general, it would help if IBM folks could provide more triage with such issues. I can try to look into it but it will take me much longer as I'm not familiar with powerpc and don't have a suitable environment set up.
[Bug c++/116852] -fvisibility-inlines-hidden does not hide template functions without 'inline'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116852 --- Comment #3 from Jonathan Wakely --- Yeah. they're implemented similarly with comdat approaches, but the C++ standard formally defines what "inline function" means, and it doesn't apply to all function templates.
[Bug libstdc++/116857] [15 Regression] libsupc++ build failure on mingw32: libstdc++-v3/libsupc++/guard.cc:39:1: error: declaration of 'int __cxxabiv1::__cxa_guard_acquire(__guard*) noexcept' has a di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116857 --- Comment #6 from Sergei Trofimovich --- The change fixed `x86_64-w64-mingw32` build for me. Thank you!
[Bug target/116856] Generated Code with unaligned uint32_t potentially hardfaults on ARM (due to LDRD)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2024-09-26 --- Comment #3 from Richard Earnshaw --- Please post a self-contained testcase that demonstrates what you think the issue is. We can't reason properly about fragments of code.
[Bug libstdc++/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847 --- Comment #10 from Jakub Jelinek --- Created attachment 59200 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59200&action=edit gcc15-pr116847-1.patch Apparently diagnostic.h already uses auto_vec in one spot. So for now here is a cleanup patch which uses vectors in two spots instead of the hand managed arrays (with the advantage of exponential reallocation rather than linear).
[Bug fortran/116858] New: gfortran.dg/initialization_25.f90 test failure (exposed by r15-3890-g34bf6aa41ba539)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116858 Bug ID: 116858 Summary: gfortran.dg/initialization_25.f90 test failure (exposed by r15-3890-g34bf6aa41ba539) Product: gcc Version: 13.3.1 Status: UNCONFIRMED Keywords: testsuite-fail Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- I missed this one myself. https://inbox.sourceware.org/gcc-patches/202409261407.48qe7b13385...@shliclel4214.sh.intel.com/T/#u reports that gfortran.dg/initialization_25.f90 fails since r15-3890-g34bf6aa41ba539. r15-3890-g34bf6aa41ba539 just fixes a typo in the dejagnu directive syntax used. Please take a look at the problem itself, thanks! I'll mark it as XFAIL in a moment.
[Bug libstdc++/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847 --- Comment #11 from Jakub Jelinek --- Created attachment 59201 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59201&action=edit gcc15-pr116847-2.patch Untested fix on top of the previous patch. Unfortunately it regresses FAIL: g++.dg/pch/line-map-3.C -g -I. -Dwith_PCH dg-regexp 23 not found: "[^[:space:]]*: some warnings being treated as errors" The thing is that by saving/restoring m_classify_diagnostic array in addition to the history, we restore with PCH restore the -Werror=someoption -Wno-error=someotheroption state from the PCH saving command line and ignore the current one. So perhaps I should just save the other vectors (history/push_list).
[Bug libstdc++/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847 --- Comment #12 from Jason Merrill --- (In reply to Jakub Jelinek from comment #10) > Created attachment 59200 [details] > gcc15-pr116847-1.patch > > Apparently diagnostic.h already uses auto_vec in one spot. So for now here > is a cleanup patch which uses vectors in two spots instead of the hand > managed arrays (with the advantage of exponential reallocation rather than > linear). LGTM. (In reply to Jakub Jelinek from comment #11) > Created attachment 59201 [details] > gcc15-pr116847-2.patch > > Untested fix on top of the previous patch. > Unfortunately it regresses > FAIL: g++.dg/pch/line-map-3.C -g -I. -Dwith_PCH dg-regexp 23 not found: > "[^[:space:]]*: some warnings being treated as errors" > The thing is that by saving/restoring m_classify_diagnostic array in > addition to the history, we restore with PCH restore the -Werror=someoption > -Wno-error=someotheroption state from the PCH saving command line and ignore > the current one. So perhaps I should just save the other vectors > (history/push_list). I was thinking just history, we don't need to handle push in a PCH and pop after it.
[Bug libstdc++/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC||dmalcolm at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
Actually, pilot error. It actually does reproduce with it, and reproduces
since like forever.
c=/opt/notnfs/gcc-bisect/obj/gcc/cc1plus.r15-3886; $c -quiet -D_GNU_SOURCE
pr116847.h --output-pch pr116847.h.gch; $c -quiet -D_GNU_SOURCE -Winvalid-pch
pr116847.C
pr116847.h: In instantiation of ‘static int S::bar() [with int N = 0]’:
pr116847.C:3:19: required from here
3 | int a = S<0>::bar ();
| ~~^~
pr116847.h:6:32: warning: ‘int foo()’ is deprecated [-Wdeprecated-declarations]
6 | static int bar () { return foo (); }
|^~
pr116847.h:1:20: note: declared here
1 | [[deprecated]] int foo () { return 42; }
|^~~
pr116847.h:6:32: warning: ‘int foo()’ is deprecated [-Wdeprecated-declarations]
6 | static int bar () { return foo (); }
|^~
pr116847.h:1:20: note: declared here
1 | [[deprecated]] int foo () { return 42; }
|^~~
pr116847.h:6:32: warning: ‘int foo()’ is deprecated [-Wdeprecated-declarations]
6 | static int bar () { return foo (); }
|^~
pr116847.h:1:20: note: declared here
1 | [[deprecated]] int foo () { return 42; }
|^~~
Same all the way to r13-282, before that we didn't support --output-pch space
argument, but changing that to --output-pch=pr116847.h.gch and far earlier
changing [[deprecated]] to __attribute__((deprecated)) all the way to
r0-100966-g5e88be0d153ec
when the diagnostic history has been introduced.
I think the reason is simple, neither global_dc nor
global_dc->m_option_classifier->m_option_classifier and
global_dc->m_option_classifier->m_n_classification_history are in GC, so
effectively after PCH restore there is empty history.
Dunno if we want to support say:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wwhatever"
in a header which is compiled with PCH and #pragma GCC diagnostic pop in the
main source or another header, if yes, we need to save/restore more stuff, like
m_classify_diagnostic and m_push_list and m_n_push, if not, I think we need to
save/restore just the classification history.
That can be done either by making that stuff GTY, or by explicitly
saving/restoring the stuff that needs saving/restoring, like e.g.
cpp_write_pch_state/cpp_read_state does.
OT, is there a reason why diagnostic.{h,cc} doesn't use vec.h and uses its own
vectors instead?
m_push_list = (int *) xrealloc (m_push_list, (m_n_push + 1) * sizeof (int));
m_push_list[m_n_push ++] = m_n_classification_history;
or
i = m_n_classification_history;
m_classification_history =
(diagnostic_classification_change_t *) xrealloc
(m_classification_history, (i + 1)
* sizeof
(diagnostic_classification_change_t));
m_classification_history[i].location = where;
m_classification_history[i].option = option_id.m_idx;
m_classification_history[i].kind = new_kind;
m_n_classification_history ++;
is simply terrible for many reasons:
1) linear growth rather than exponential growth
2) not using XRESIZEVEC macro, m_push_list = XRESIZEVEC (int, m_push_list,
m_n_push + 1);
3) = shouldn't be at the end of line
4) space before ++
If yes, say because of it is also linked into gen* utilities and if they can't
link with vec.o, then at least the formatting
should be fixed and exponential growth should be added, especially now that the
pragmas are widely used.
I see 159 #pragma GCC diagnostic ignored and 147 #pragma GCC diagnostic pop
pragmas in libstdc++ headers, so if one includes lots of STL headers,
that is ~300 reallocations on the history and wonder how many on the other
vectors.
[Bug libstdc++/116857] [15 Regression] libsupc++ build failure on mingw32: libstdc++-v3/libsupc++/guard.cc:39:1: error: declaration of 'int __cxxabiv1::__cxa_guard_acquire(__guard*) noexcept' has a di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116857 --- Comment #3 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:efdda203f52b9b55ef9acc8ad668bbd0570a8de6 commit r15-3892-gefdda203f52b9b55ef9acc8ad668bbd0570a8de6 Author: Jonathan Wakely Date: Thu Sep 26 12:12:13 2024 +0100 libstdc++: Remove noexcept-specifier from MCF __cxa_guard_acquire [PR116857] This function definition should not be marked as non-throwing, because the declaration in is potentially throwing. Also fix whitespace. libstdc++-v3/ChangeLog: PR libstdc++/116857 * libsupc++/guard.cc (__cxa_guard_acquire): Remove _GLIBCXX_NOTHROW to match declaration in .
[Bug libstdc++/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847 --- Comment #9 from Jakub Jelinek --- Oh, and the reason why libstdc++ testsuite on x86_64-linux is clean at least for me is revealed by adding -Winvalid-pch to the command lines of the affected testcases: cc1plus: warning: /home/jakub/src/gcc/obj16/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch: created and used with differing settings of '-mshstk' [-Winvalid-pch] cc1plus: warning: /home/jakub/src/gcc/obj16/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2g.gch: created and used with differing settings of '-mshstk' [-Winvalid-pch]
[Bug libstdc++/116857] [15 Regression] libsupc++ build failure on mingw32: libstdc++-v3/libsupc++/guard.cc:39:1: error: declaration of 'int __cxxabiv1::__cxa_guard_acquire(__guard*) noexcept' has a di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116857 --- Comment #5 from LIU Hao --- Thanks for the fix! (it indeed does not throw on Windows.)
[Bug c++/116852] -fvisibility-inlines-hidden does not hide template functions without 'inline'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116852 Nathaniel Shead changed: What|Removed |Added CC||nshead at gcc dot gnu.org --- Comment #2 from Nathaniel Shead --- > Aren't functions templates implicitly declared inline in C++, like inline > defined member functions? FWIW function templates aren't implicitly inline, they just have similar behaviour with regards to ODR.
[Bug target/116725] operand size mismatch for vfpclasssd and vfpclassss when using -masm=intel for AVX512 builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116725 Antoni changed: What|Removed |Added Attachment #59115|0 |1 is obsolete|| --- Comment #2 from Antoni --- Created attachment 59198 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59198&action=edit More complete reproducer
[Bug target/116725] operand size mismatch for vfpclasssd and vfpclassss when using -masm=intel for AVX512 builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116725 --- Comment #3 from Antoni --- Created attachment 59199 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59199&action=edit Tentative fix for the issue I have the following that seems to fix the issue. I don't know if this is the correct way to fix it since I'm not very familiar with the backend. I'll soon post this as a real patch.
[Bug middle-end/114855] ICE: Segfault when compiling large autogenerated C source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 --- Comment #56 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:942bbb2357656019caa3f8ebd2d23b09222f039a commit r15-3896-g942bbb2357656019caa3f8ebd2d23b09222f039a Author: Richard Biener Date: Wed Sep 25 10:38:12 2024 +0200 tree-optimization/114855 - speed up dom_oracle::register_transitives dom_oracle::register_transitives contains an unbound dominator walk which for the testcase in PR114855 dominates the profile. The following fixes the unbound work done by assigning a constant work budget to the loop, bounding the number of dominators visited but also the number of relations processed. This gets both dom_oracle::register_transitives and get_immediate_dominator off the profile. I'll note that we're still doing an unbound dominator walk via equiv_set in find_equiv_dom at the start of the function and when we register a relation that also looks up the same way. At least for the testcase at hand this isn't an issue. I've also amended the guard to register_transitives with the per-basic-block limit for the number of relations registered not being exhausted. PR tree-optimization/114855 * params.opt (--param transitive-relations-work-bound): New. * doc/invoke.texi (--param transitive-relations-work-bound): Document. * value-relation.cc (dom_oracle::register_transitives): Assing an overall work budget, bounding the dominator walk and the number of relations processed. (dom_oracle::record): Only register_transitives when the number of already registered relations does not yet exceed the per-BB limit.
[Bug tree-optimization/116585] [12/13/14 Regression] SSA corruption with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116585 --- Comment #7 from Qing Zhao --- > > Yes, I'll pick it up after some soaking on trunk during my next backporting > round. If you want to do the work of cherry-picking and regtesting feel free > to do this earlier - it's been a week on trunk and a quite safe change. > Sure, I can do the backporting to GCC12, 13,and 14.
[Bug fortran/116858] gfortran.dg/initialization_25.f90 test failure (exposed by r15-3890-g34bf6aa41ba539)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116858 Sam James changed: What|Removed |Added Version|13.3.1 |15.0 Target Milestone|--- |15.0
[Bug target/116854] GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- So bdver4 does have RDRND support just buggy bios's cause linux to disable it: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c49a0a80137c7ca7d6ced4c812c9e07a949f6f24 That would mean GCC is doing the right thing really ... And why -march=native is working correctly. Just QT breaks because it tries to decode -march=native into -march=bdver4 without doing the rest. So invalid.
[Bug libstdc++/116857] [15 Regression] libsupc++ build failure on mingw32: libstdc++-v3/libsupc++/guard.cc:39:1: error: declaration of 'int __cxxabiv1::__cxa_guard_acquire(__guard*) noexcept' has a di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116857 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jonathan Wakely --- It should be fixed now, please reopen if not. I should probably backport it to gcc-13 and gcc-14, although it's not breaking bootstrap there so less urgent.
[Bug libstdc++/116853] [15 regression] Bootstrap fails on Darwin, Solaris after r15-3859-g63a598deb0c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116853 --- Comment #3 from GCC Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:d797202caa34f008399dc65e10cc723f52fcbcc5 commit r15-3894-gd797202caa34f008399dc65e10cc723f52fcbcc5 Author: Iain Sandoe Date: Thu Sep 26 11:07:41 2024 +0100 libstdc++: Suppress an attribute suggestion warning [PR116853]. This warning is triggering during the build and breaking bootstrap on at least two targets. The warning appears valid, but the final fix for it is not yet clear. In the meantime, to restore bootstrap, the following patch ignores the warning in the relevant code section. PR libstdc++/116853 libstdc++-v3/ChangeLog: * include/bits/basic_string.h: Ignore suggest-attribute=format warning when using posix vsnprintf in to_string() implementations. Signed-off-by: Iain Sandoe
[Bug tree-optimization/116855] [14/15 Regression] Unsafe early-break vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Keywords||wrong-code CC||rguenth at gcc dot gnu.org Summary|Unsafe early-break |[14/15 Regression] Unsafe |vectorization |early-break vectorization Version|unknown |14.2.1 Target Milestone|--- |14.3 Status|UNCONFIRMED |NEW Last reconfirmed||2024-09-26 Blocks||53947 --- Comment #2 from Richard Biener --- We're using ref_within_array_bound and I think that's OK in the case we're using loop masking - but when not using loop masking and in particular also masking the load, relying on it is broken - we'd have to amend the API to pass in a maximum number of space for excess elements accessed. Relying on alignment of course works as well. Thus confirmed, also happens on x86 with -msse4.1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug target/116854] GCC incorrectly assumes all CPUs where -march=native resolves to -march=bdver4 will have RDRND support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854 --- Comment #3 from Thiago Macieira --- (In reply to Andrew Pinski from comment #2) > So bdver4 does have RDRND support just buggy bios's cause linux to disable > it: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=c49a0a80137c7ca7d6ced4c812c9e07a949f6f24 > > > That would mean GCC is doing the right thing really ... > > And why -march=native is working correctly. Just QT breaks because it tries > to decode -march=native into -march=bdver4 without doing the rest. > > So invalid. The bug as reported is invalid, because it reported the wrong thing. The problem has nothing to do with -march=native. The problem is only -march=bdver4, which enables RDRND unconditionally. Since the BIOS and/or OS can disable it, it stands to reason not all Excavators have RDRND. GCC should not enable it unconditionally.
[Bug testsuite/116683] new test g++.dg/ext/pragma-unroll-lambda-lto.C from r15-3585-g9759f6299d9633 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116683 Alex Coplan changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-09-26 --- Comment #4 from Alex Coplan --- I can reproduce the failure on cfarm29, I'll try and see if I can figure out what's going on.
[Bug libstdc++/116859] New: Bootstrap broken on FreeBSD due to _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859 Bug ID: 116859 Summary: Bootstrap broken on FreeBSD due to _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: kargls at comcast dot net Target Milestone: --- It seems someone committed a change after 20240909 that now breaks bootstrap on FreeBSD. I could complete a normal bootstrap on the above date. I now see thousands of warnings about !_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC not being portable. This unfortunately ends up with an error thusly, /usr/home/sgk/gcc/objx/./prev-gcc/xg++ -B/usr/home/sgk/gcc/objx/./prev-gcc/ -B/usr/home/sgk/work/x/x86_64-unknown-freebsd15.0/bin/ -nostdinc++ -B/usr/home/sgk/gcc/objx/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/src/.libs -B/usr/home/sgk/gcc/objx/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/libsupc++/.libs -I/usr/home/sgk/gcc/objx/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/include/x86_64-unknown-freebsd15.0 -I/usr/home/sgk/gcc/objx/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/include -I/usr/home/sgk/gcc/gccx/libstdc++-v3/libsupc++ -L/usr/home/sgk/gcc/objx/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/src/.libs -L/usr/home/sgk/gcc/objx/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/libsupc++/.libs -I../../gccx/libcpp -I. -I../../gccx/libcpp/../include -I../../gccx/libcpp/include -g -O2 -fno-checking -gtoggle -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -Werror -fno-exceptions -fno-rtti -I../../gccx/libcpp -I. -I../../gccx/libcpp/../include -I../../gccx/libcpp/include-c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../../gccx/libcpp/charset.cc In file included from /usr/home/sgk/gcc/objx/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/include/stdlib.h:36, from ../../gccx/libcpp/system.h:218, from ../../gccx/libcpp/charset.cc:21: /usr/home/sgk/gcc/objx/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/include/cstdlib:209:6: error: this use of "defined" may not be portable [-Werror=expansion-to-defined] 209 | #if !_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC | ^~ /usr/home/sgk/gcc/objx/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/include/cstdlib:219:6: error: this use of "defined" may not be portable [-Werror=expansion-to-defined] 219 | #if !_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC | ^~ /usr/home/sgk/gcc/objx/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/include/cstdlib:229:41: error: this use of "defined" may not be portable [-Werror=expansion-to-defined] 229 | #if _GLIBCXX_USE_C99_LONG_LONG_CHECK || _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC | ^~ /usr/home/sgk/gcc/objx/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/include/cstdlib:236:6: error: this use of "defined" may not be portable [-Werror=expansion-to-defined] 236 | #if !_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC | ^~ /usr/home/sgk/gcc/objx/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/include/cstdlib:249:6: error: this use of "defined" may not be portable [-Werror=expansion-to-defined] 249 | #if !_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC | ^~ /usr/home/sgk/gcc/objx/prev-x86_64-unknown-freebsd15.0/libstdc++-v3/include/cstdlib:253:6: error: this use of "defined" may not be portable [-Werror=expansion-to-defined] 253 | #if !_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC | ^~ cc1plus: all warnings being treated as errors
[Bug libstdc++/116859] [15 Regression] Bootstrap broken on FreeBSD due to _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859 Andrew Pinski changed: What|Removed |Added Summary|Bootstrap broken on FreeBSD |[15 Regression] Bootstrap |due to |broken on FreeBSD due to |_GLIBCXX_USE_C99_LONG_LONG_ |_GLIBCXX_USE_C99_LONG_LONG_ |DYNAMIC |DYNAMIC Target Milestone|--- |15.0
[Bug libstdc++/116859] Bootstrap broken on FreeBSD due to _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859 --- Comment #1 from Andrew Pinski --- 3d7c150e3f05 libstdc++-v3/config/os/bsd/freebsd/os_defines.h (Benjamin Kosnik 2003-07-05 04:05:45 + 39) #define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !defined __LONG_LONG_SUPPORTED) has not changed in years. Maybe it was the recent `#pragma system_header` changes.
[Bug tree-optimization/116851] vector assignment compilation fails claiming null STL argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116851 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-09-26
[Bug target/115860] [15 regression] Register pairs and regrename since r15-1579-g792f97b44ffc5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115860 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Stefan Schulze Frielinghaus : https://gcc.gnu.org/g:3eb3fbc89c638a72611efdc54110b8113f79ee8d commit r14-10713-g3eb3fbc89c638a72611efdc54110b8113f79ee8d Author: Stefan Schulze Frielinghaus Date: Thu Sep 26 19:38:02 2024 +0200 s390: Fix TF to FPRX2 conversion [PR115860] Currently subregs originating from *tf_to_fprx2_0 and *tf_to_fprx2_1 survive register allocation. This in turn leads to wrong register renaming. Keeping the current approach would mean we need two insns for *tf_to_fprx2_0 and *tf_to_fprx2_1, respectively. Something along the lines (define_insn "*tf_to_fprx2_0" [(set (subreg:DF (match_operand:FPRX2 0 "nonimmediate_operand" "=f") 0) (unspec:DF [(match_operand:TF 1 "general_operand" "v")] UNSPEC_TF_TO_FPRX2_0))] "TARGET_VXE" "#") (define_insn "*tf_to_fprx2_0" [(set (match_operand:DF 0 "nonimmediate_operand" "=f") (unspec:DF [(match_operand:TF 1 "general_operand" "v")] UNSPEC_TF_TO_FPRX2_0))] "TARGET_VXE" "vpdi\t%v0,%v1,%v0,1 [(set_attr "op_type" "VRR")]) and similar for *tf_to_fprx2_1. Note, pre register allocation operand 0 has mode FPRX2 and afterwards DF once subregs have been eliminated. Since we always copy a whole vector register into a floating-point register pair, another way to fix this is to merge *tf_to_fprx2_0 and *tf_to_fprx2_1 into a single insn which means we don't have to use subregs at all. The downside of this is that the assembler template contains two instructions, now. The upside is that we don't have to come up with some artificial insn before RA which might be more readable/maintainable. That is implemented by this patch. In commit r11-4872-ge627cda5686592, the output operand specifier %V was introduced which is used in tf_to_fprx2 only, now. Instead of coming up with its counterpart %F for floating-point registers, which would also only be used in tf_to_fprx2, I print the operands directly. This renders %V unused which is why it is removed by this patch. gcc/ChangeLog: PR target/115860 * config/s390/s390.cc (print_operand): Remove operand specifier %V. * config/s390/s390.md (UNSPEC_TF_TO_FPRX2): New. * config/s390/vector.md (*tf_to_fprx2_0): Remove. (*tf_to_fprx2_1): Remove. (tf_to_fprx2): New. gcc/testsuite/ChangeLog: * gcc.target/s390/vector/long-double-asm-abi.c: Adapt scan-assembler directive. * gcc.target/s390/vector/long-double-to-i64.c: Adapt scan-assembler directive. * gcc.target/s390/pr115860-1.c: New test. (cherry picked from commit 46c2538435dfc50dd5c67c4e03ce387d1f6ebe9b)
[Bug middle-end/116736] missing diagnostic for out-of-bounds array access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116736 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #1 from qinzhao at gcc dot gnu.org --- with bounds sanitizer, the out-of-bound access can be detected during runtime: /home/opc/Install/latest-d/bin/gcc -O2 -fsanitize=bounds -fstrict-flex-arrays=3 t.c t.c:15:21: runtime error: index 1 out of bounds for type 'int [*]'
[Bug middle-end/116861] [15 regression] ICE when building netpbm-11.2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861 --- Comment #1 from Sam James --- Note that this has Tamar's patch applied for PR116817.
[Bug middle-end/116736] missing diagnostic for out-of-bounds array access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116736 --- Comment #2 from qinzhao at gcc dot gnu.org --- currently, the "counted_by" info is used in __builtin_dynamic_object_size and bounds sanitizer. and expected to catch out-of-bounds access during runtime. So, this is the expected behavior.
[Bug middle-end/116861] New: [15 regression] ICE when building netpbm-11.2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861
Bug ID: 116861
Summary: [15 regression] ICE when building netpbm-11.2.10
Product: gcc
Version: 13.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Created attachment 59204
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59204&action=edit
pnmcrop.i.xz
Originally reported downstream in gentoo at https://bugs.gentoo.org/940307.
```
$ gcc -c pnmcrop.i -O2
during GIMPLE pass: widening_mul
pnmcrop.c: In function ‘main’:
pnmcrop.c:1438:1: internal compiler error: Segmentation fault
1438 | main(int argc, const char *argv[]) {
| ^~~~
0x620089b3d8c2 internal_error(char const*, ...)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/diagnostic-global-context.cc:517
0x62008939a9fb crash_signal
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/toplev.cc:321
0x71805df942ef ???
/usr/src/debug/sys-libs/glibc-2.40-r3/glibc-2.40/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x62008a100a0d gphi* as_a(gimple*)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/is-a.h:255
0x62008a100a0d gphi_iterator::phi() const
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimple-iterator.h:47
0x62008a100a0d after_dom_children
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-math-opts.cc:6136
0x620089eac091 dom_walker::walk(basic_block_def*)
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/domwalk.cc:354
0x62008a100491 execute
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-ssa-math-opts.cc:6309
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug other/116860] New: New test case gcc.dg/tree-ssa/fold-xor-and-or.c from r15-3866-ga88d6c6d777ad7 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116860 Bug ID: 116860 Summary: New test case gcc.dg/tree-ssa/fold-xor-and-or.c from r15-3866-ga88d6c6d777ad7 fails Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:a88d6c6d777ad7c9235e2e620318f26e5347e50a, r15-3866-ga88d6c6d777ad7 make -k check-gcc RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/fold-xor-and-or.c" FAIL: gcc.dg/tree-ssa/fold-xor-and-or.c scan-tree-dump-not optimized "d1_[0-9]+.D. \\^ d2_[0-9]+.D." commit a88d6c6d777ad7c9235e2e620318f26e5347e50a (HEAD) Author: Konstantinos Eleftheriou Date: Wed Aug 7 17:54:30 2024 +0200 match: Fix A || B not optimized to true when !B implies A [PR114326] * gcc.dg/tree-ssa/fold-xor-and-or.c: New test.
[Bug middle-end/116861] [15 regression] ICE when building netpbm-11.2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861 Sam James changed: What|Removed |Added Target Milestone|--- |15.0 Version|13.3.1 |15.0 Keywords||ice-on-valid-code
[Bug middle-end/116860] New test case gcc.dg/tree-ssa/fold-xor-and-or.c from r15-3866-ga88d6c6d777ad7 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116860 Andrew Pinski changed: What|Removed |Added Keywords||testsuite-fail Component|other |middle-end --- Comment #1 from Andrew Pinski --- most likely a missed optimization for `--param=logical-op-non-short-circuit=0` case .
[Bug middle-end/116861] [15 regression] ICE when building netpbm-11.2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861 --- Comment #2 from Sam James --- ==236952== Invalid read of size 8 ==236952==at 0x1EDB670: UnknownInlinedFun (tree-ssa-math-opts.cc:4174) ==236952==by 0x1EDB670: (anonymous namespace)::math_opts_dom_walker::after_dom_children(basic_block_def*) (tree-ssa-math-opts.cc:6137) ==236952==by 0x1C86091: dom_walker::walk(basic_block_def*) (domwalk.cc:354) ==236952==by 0x1EDA491: (anonymous namespace)::pass_optimize_widening_mul::execute(function*) [clone .lto_priv.0] (tree-ssa-math-opts.cc:6309) ==236952==by 0x183AD2: execute_one_pass(opt_pass*) [clone .cold] (passes.cc:2659) ==236952==by 0x1BFDA9B: execute_pass_list_1(opt_pass*) (passes.cc:2768) ==236952==by 0x1BFDAB8: execute_pass_list_1(opt_pass*) (passes.cc:2769) ==236952==by 0x1BFD848: execute_pass_list(function*, opt_pass*) (passes.cc:2779) ==236952==by 0x1B6E700: cgraph_node::expand() (cgraphunit.cc:1845) ==236952==by 0x1AEF0A5: UnknownInlinedFun (cgraphunit.cc:2028) ==236952==by 0x1AEF0A5: symbol_table::compile() (cgraphunit.cc:2404) ==236952==by 0x2317B68: symbol_table::finalize_compilation_unit() (cgraphunit.cc:2589) ==236952==by 0x22BADB0: compile_file() [clone .lto_priv.0] (toplev.cc:478) ==236952==by 0x22677E0: UnknownInlinedFun (toplev.cc:2213) ==236952==by 0x22677E0: toplev::main(int, char**) (toplev.cc:2373) ==236952== Address 0x5c3b818 is in a rw- anonymous segment ==236952== ==236952== Invalid read of size 1 ==236952==at 0x1EDAA0D: UnknownInlinedFun (is-a.h:255) ==236952==by 0x1EDAA0D: UnknownInlinedFun (gimple-iterator.h:47) ==236952==by 0x1EDAA0D: (anonymous namespace)::math_opts_dom_walker::after_dom_children(basic_block_def*) (tree-ssa-math-opts.cc:6136) ==236952==by 0x1C86091: dom_walker::walk(basic_block_def*) (domwalk.cc:354) ==236952==by 0x1EDA491: (anonymous namespace)::pass_optimize_widening_mul::execute(function*) [clone .lto_priv.0] (tree-ssa-math-opts.cc:6309) ==236952==by 0x183AD2: execute_one_pass(opt_pass*) [clone .cold] (passes.cc:2659) ==236952==by 0x1BFDA9B: execute_pass_list_1(opt_pass*) (passes.cc:2768) ==236952==by 0x1BFDAB8: execute_pass_list_1(opt_pass*) (passes.cc:2769) ==236952==by 0x1BFD848: execute_pass_list(function*, opt_pass*) (passes.cc:2779) ==236952==by 0x1B6E700: cgraph_node::expand() (cgraphunit.cc:1845) ==236952==by 0x1AEF0A5: UnknownInlinedFun (cgraphunit.cc:2028) ==236952==by 0x1AEF0A5: symbol_table::compile() (cgraphunit.cc:2404) ==236952==by 0x2317B68: symbol_table::finalize_compilation_unit() (cgraphunit.cc:2589) ==236952==by 0x22BADB0: compile_file() [clone .lto_priv.0] (toplev.cc:478) ==236952==by 0x22677E0: UnknownInlinedFun (toplev.cc:2213) ==236952==by 0x22677E0: toplev::main(int, char**) (toplev.cc:2373) ==236952== Address 0xa5a5a5a5a5a5a5a5 is not stack'd, malloc'd or (recently) free'd
[Bug libstdc++/116859] [15 Regression] Bootstrap broken on FreeBSD due to _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Fix for that should be obvious, -#define _GLIBCX_GLIBCXX_USE_C99_LONG_LONG_DYNAMICX_USE_C99_LONG_LONG_DYNAMIC +#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 DragonFly needs the same thing and FreeBSD has another spot: ./config/os/bsd/freebsd/os_defines.h:#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !defined __LONG_LONG_SUPPORTED) ./config/os/bsd/freebsd/os_defines.h:#define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE ./config/os/bsd/dragonfly/os_defines.h:#define _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !defined __LONG_LONG_SUPPORTED)
[Bug libstdc++/116859] [15 Regression] Bootstrap broken on FreeBSD due to _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-09-26 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- .(In reply to Jakub Jelinek from comment #3) > Fix for that should be obvious, > -#define > _GLIBCX_GLIBCXX_USE_C99_LONG_LONG_DYNAMICX_USE_C99_LONG_LONG_DYNAMIC > +#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 > > DragonFly needs the same thing and FreeBSD has another spot: > ./config/os/bsd/freebsd/os_defines.h:#define > _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !defined > __LONG_LONG_SUPPORTED) > ./config/os/bsd/freebsd/os_defines.h:#define > _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE > ./config/os/bsd/dragonfly/os_defines.h:#define > _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !defined > __LONG_LONG_SUPPORTED) Yes I was going to say something similar too.
[Bug libstdc++/116847] [15 regression] r15-3859-g63a598deb0c9fc causes many excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847 Jakub Jelinek changed: What|Removed |Added Attachment #59201|0 |1 is obsolete|| --- Comment #13 from Jakub Jelinek --- Created attachment 59202 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59202&action=edit gcc15-pr116847-3.patch This seems to work on quick testing (just pch.exp so far). > I was thinking just history, we don't need to handle push in a PCH and pop > after it. If people don't do it, then all the patch does is writes an extra 32-bit 0 and reads it back. But if people do something like that, the state could become inconsistent, and just saving/restoring it IMHO is easier than diagnosing issues like that. But if you strongly prefer, I can add a sorry if (!m_push_list.empty_p ()) during PCH save and otherwise ignore that vector (or error but then we'd need to document it; but would it be an error just for PCH saved headers if they have more pushes than pops, or should we check the balances on every single header (then it would need more infrastructure)).
[Bug libstdc++/116859] [15 Regression] Bootstrap broken on FreeBSD due to _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859 --- Comment #5 from Jakub Jelinek --- Created attachment 59203 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59203&action=edit gcc15-pr116859.patch Here it is in patch form. But I can't really test it on FreeBSD nor DragonFly.
[Bug libstdc++/116859] [15 Regression] Bootstrap broken on FreeBSD due to _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859 --- Comment #2 from Sam James --- (In reply to Andrew Pinski from comment #1) > Maybe it was the recent `#pragma system_header` changes. surely, yes..
[Bug libstdc++/116859] [15 Regression] Bootstrap broken on FreeBSD due to _GLIBCXX_USE_C99_LONG_LONG_DYNAMIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859 --- Comment #6 from kargls at comcast dot net --- (In reply to Jakub Jelinek from comment #5) > Created attachment 59203 [details] > gcc15-pr116859.patch > > Here it is in patch form. But I can't really test it on FreeBSD nor > DragonFly. I just grabbed the patch. It will take about an hour to get to the failing point. I'll report back when completed.
[Bug tree-optimization/116851] vector assignment compilation fails claiming null STL argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116851 --- Comment #2 from Andrew Pinski --- Looks we warn about code which will be removed later on. I have not looked into it further though.
[Bug tree-optimization/116861] [15 regression] ICE when building netpbm-11.2.10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861 --- Comment #3 from Sam James --- Created attachment 59205 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59205&action=edit reduced.i cvise spat this out but it's pretty big still, not modified it yet
