[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 Richard Biener changed: What|Removed |Added CC||fweimer at redhat dot com --- Comment #20 from Richard Biener --- (In reply to Brendan Dolan-Gavitt from comment #19) > I read through the crtfastmath.c implementations for the other affected > targets and confirmed that they do all set flush-to-zero in this thread: > > https://threadreaderapp.com/thread/1567612053363347461.html > > I agree that there should be a way for a shared library to link > crtfastmath.o if it wants that behavior. But is there a reason > -l:crtfastmath.o isn't sufficient in that case? Why does it need to be > enabled automatically when -Ofast/-ffast-math/-funsafe-math optimizations > are turned on? The reasons for most of the "globbing" into -ffast-math/-Ofast are the rules for SPEC CPU 2006 base flags which IIRC limited the number of flags allowed (that's no longer a requirement for SPEC CPU 2017). And of course that users will not know of the flags but are likely not interested in denormals when using -ffast-math. > The other note I would add is that in multi-threaded applications, > crtfastmath.o is already not behaving as intended: FTZ/DAZ will only be set > in the CPU state of the thread that loaded the shared library; it's hard to > imagine a case where a user wants individual threads to have different > FTZ/DAZ (unless they explicitly manage that by hand). Example: [...] Yeah. Not sure how often dynamic objects are opened from within threads though. That said, a possibility to enforce "consistency" at least would be to save/restore the FP state around dlopen() so that shared objects loaded not at program startup would not affect FP state at all? The same could be done for shared objects loaded at program startup of course. The other way around would eventually be to make the CTOR __tls, that should eventually force all threads to change their FP state(?).
[Bug tree-optimization/106896] [13 Regression] ICE in to_sreal_scale, at profile-count.cc:339
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106896 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Target Milestone|--- |13.0
[Bug other/106899] Snapshots do not contain pre-generated man pages & info pages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106899 --- Comment #5 from Richard Biener --- The resource issue is probably a non-issue these days
[Bug middle-end/106892] [11/12 Regression] Wrong code at -O3 on x86_64-linux-gnu since r11-963-g80d6f89e78fc3b77
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106892 --- Comment #13 from Martin Liška --- > Shouldn't that be 106892? Right, I at least fixed ChangeLog entry in g:3fa66b95570a125fd35d5721c9eb08d975f73e82.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 106901, which changed state. Bug 106901 Summary: [13 Regression] False positive -Warray-bounds with -O2 or higher? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug tree-optimization/106901] [13 Regression] False positive -Warray-bounds with -O2 or higher?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Summary|False positive |[13 Regression] False |-Warray-bounds with -O2 or |positive -Warray-bounds |higher? |with -O2 or higher? Component|c++ |tree-optimization Known to work||12.2.0 Blocks||56456 Resolution|--- |INVALID Target Milestone|--- |13.0 --- Comment #6 from Richard Biener --- I think this is invalid. We inline bar into foo and see if (size < 5) return false; for (i = 5; i < size; ++i) if (vec[i] != 0) so we know that vec[5] is accessed when the loop is executed which is out of bounds and we diagnose that. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |11.4 Known to fail||11.2.0, 12.2.0 Priority|P3 |P2 Known to work||10.3.0 Keywords||needs-bisection, wrong-code Target|X86_64 |x86_64-*-* CC||rguenth at gcc dot gnu.org Status|UNCONFIRMED |NEW Summary|Program compiled with -O3 |[11/12/13 Regression] |-mfma produces different|Program compiled with -O3 |result |-mfma produces different ||result Last reconfirmed||2022-09-12 --- Comment #2 from Richard Biener --- Confirmed. -fno-tree-slp-vectorize avoids the issue.
[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106894 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:994ea892bd02dd8a1c04875ad3553c57939c3abf commit r13-2617-g994ea892bd02dd8a1c04875ad3553c57939c3abf Author: Jakub Jelinek Date: Mon Sep 12 10:48:19 2022 +0200 libgomp: Fix up icv-6.c [PR106894] The thing is, make check or make check RUNTESTFLAGS="c.exp='icv-6.c' c++.exp='icv-6.c'" in libgomp obj dir work fine, but make -j32 -k check RUNTESTFLAGS="c.exp='icv-6.c' c++.exp='icv-6.c'" fails. The thing is that the testcase as written relies on OMP_NUM_THREADS not being set in environment (as it takes priority over OMP_NUM_THREADS_ALL for the host). So, if either a user has OMP_NUM_THREADS=42 in the environment by himself, or when doing make check with -jN, we trigger: if test $$num_cpus -gt 8 && test -z "$$OMP_NUM_THREADS"; then \ OMP_NUM_THREADS=8; export OMP_NUM_THREADS; \ echo @@@ libgomp OMP_NUM_THREADS adjusted to 8 because of parallel make check and too many CPUs; \ fi; \ in libgomp/testsuite/Makefile.am and so the test fails. 2022-09-12 Jakub Jelinek PR libgomp/106894 * testsuite/libgomp.c-c++-common/icv-6.c: Include string.h. (main): Avoid tests for which corresponding non-_ALL suffixed variable is in the environment, or for OMP_NUM_TEAMS on the device OMP_NUM_TEAMS_DEV_?.
[Bug tree-optimization/106905] New: [13 Regression] ia64: ICE in in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:8412 on zstd-1.5.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106905
Bug ID: 106905
Summary: [13 Regression] ia64: ICE in in
vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:8412
on zstd-1.5.2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
The error apepared in this week's gcc-weekly snapshot. Original failure happens
to ICE on zstd-1.5.2 when compiling for ia64-unknown-linux-gnu target.
Extracted example:
// $ cat zdict.c.c
long ZDICT_fillNoise_p, ZDICT_trainFromBuffer_legacy_result;
unsigned ZDICT_fillNoise_acc;
int ZDICT_totalSampleSize_nbFiles;
static void ZDICT_fillNoise(void *buffer, long length) {
unsigned prime2 = 9;
for (ZDICT_fillNoise_p = 0; ZDICT_fillNoise_p < length; ZDICT_fillNoise_p++)
ZDICT_fillNoise_acc *= ((char *)buffer)[ZDICT_fillNoise_p] = prime2;
}
long ZDICT_trainFromBuffer_legacy() {
void *newBuff;
long total;
for (; ZDICT_totalSampleSize_nbFiles;)
total += 0;
long sBuffSize = total;
newBuff = 0;
ZDICT_fillNoise(newBuff + sBuffSize, 32);
return ZDICT_trainFromBuffer_legacy_result;
}
Crashing:
$ ia64-unknown-linux-gnu-gcc-13.0.0 -std=c99 -Wall -Wextra -O3 -fPIC -c
zdict.c.c
during GIMPLE pass: vect
zdict.c.c: In function 'ZDICT_trainFromBuffer_legacy':
zdict.c.c:10:6: internal compiler error: in vect_peel_nonlinear_iv_init, at
tree-vect-loop.cc:8412
10 | long ZDICT_trainFromBuffer_legacy() {
| ^~~~
0x142e907 diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, __va_list_tag (*) [1], diagnostic_t)
???:0
0x142f757 internal_error(char const*, ...)
???:0
0x5db0de fancy_abort(char const*, int, char const*)
???:0
0x5c8a88 vect_peel_nonlinear_iv_init(gimple**, tree_node*, tree_node*,
tree_node*, vect_induction_op_type) [clone .cold]
???:0
0xd9b1f1 vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*, tree_node**,
tree_node**, tree_node**, int, bool, bool, tree_node**)
???:0
0xd90776 vect_transform_loop(_loop_vec_info*, gimple*)
???:0
0xdc8a0b vect_transform_loops(hash_table*&,
loop*, gimple*, function*)
???:0
0xdc90a3 try_vectorize_loop(hash_table*&,
unsigned int*, loop*, function*)
???:0
0xdc960c (anonymous namespace)::pass_vectorize::execute(function*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libgomp/106894] [13 regression] multiple libgomp failures after r13-2545-g9f2fca56593a2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106894 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #8 from Jakub Jelinek --- Should be now fixed completely.
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 --- Comment #22 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:723ef5a937dbab5e7a35761fd7f0ff0c76849340 commit r13-2618-g723ef5a937dbab5e7a35761fd7f0ff0c76849340 Author: Jakub Jelinek Date: Mon Sep 12 11:31:11 2022 +0200 libstdc++: Outline the overlapping case of string _M_replace into a separate function [PR105329] The following patch is partially a workaround for bogus warnings when the compiler isn't able to fold _M_disjunct call into constant false, but also an optimization attempt - assuming _M_disjunct (__s) is rare, the patch should shrink code size for the common case and use library or for non-standard instantiations an out of line function to handle the rare case. 2022-09-12 Jakub Jelinek PR tree-optimization/105329 * acinclude.m4 (libtool_VERSION): Change to 6:31:0. * config/abi/pre/gnu.ver (GLIBCXX_3.4.21): Don't export std::basic_string methods with name length of 15. (GLIBCXX_3.4.31): Export std::basic_string::_M_replace_cold. * testsuite/util/testsuite_abi.cc (check_version): Handle GLIBCXX_3.4.31. * include/bits/basic_string.h (std::basic_string::_M_replace_cold): Declare. * include/bits/basic_string.tcc (std::basic_string::_M_replace_cold): Define and export even for C++20. (std::basic_string::_M_replace): Use __builtin_expect, outline the overlapping case to _M_replace_cold. * configure: Regenerated.
[Bug tree-optimization/106905] [13 Regression] ia64: ICE in in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:8412 on zstd-1.5.2 since r13-2503-gc13223b790bbc5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106905 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Summary|[13 Regression] ia64: ICE |[13 Regression] ia64: ICE |in in |in in |vect_peel_nonlinear_iv_init |vect_peel_nonlinear_iv_init |, at tree-vect-loop.cc:8412 |, at tree-vect-loop.cc:8412 |on zstd-1.5.2 |on zstd-1.5.2 since ||r13-2503-gc13223b790bbc5 Status|UNCONFIRMED |NEW Target Milestone|--- |13.0 CC||crazylht at gmail dot com Last reconfirmed||2022-09-12 --- Comment #1 from Martin Liška --- Started with r13-2503-gc13223b790bbc5.
[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #21 from Florian Weimer --- (In reply to Richard Biener from comment #20) > Yeah. Not sure how often dynamic objects are opened from within threads > though. We know that some shared objects call pthread_create from ELF constructors, which is enough to potentially expose the issue if the ELF constructors are ordered in certain ways. > That said, a possibility to enforce "consistency" at least would > be to save/restore the FP state around dlopen() so that shared objects > loaded not at program startup would not affect FP state at all? > The same could be done for shared objects loaded at program startup of > course. I think GCC should not automatically link crtfastmath.o with -shared. That will fix this particular issue for new shared objects, where the action-at-a-distance issue is most prominent and least desirable I think. > The other way around would eventually be to make the CTOR __tls, that > should eventually force all threads to change their FP state(?). No, all current TLS constructors run lazily when some language construct is used. There is no way to run TLS constructors at dlopen time. We can in theory change CPU state using glibc's SETXID broadcast, but it will impact legitimate uses of the control register (e.g., changes to the FP control word around a block of code that is executed in a non-default mode). These days, we'd probably use GNU property notes for something like this (although we'd likely not make it a global property in the first place, not for this).
[Bug libgomp/106906] New: libgomp/env.c: 3 * boolean value assigned to pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106906 Bug ID: 106906 Summary: libgomp/env.c: 3 * boolean value assigned to pointer Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com CC: jakub at gcc dot gnu.org Target Milestone: --- Static analyser cppcheck says: libgomp/env.c:1895:19: error: Boolean value assigned to pointer. [assignBoolToPointer] libgomp/env.c:1902:19: error: Boolean value assigned to pointer. [assignBoolToPointer] libgomp/env.c:1910:19: error: Boolean value assigned to pointer. [assignBoolToPointer] First one is icv_addr[1] = false; but void *icv_addr[3]) so this could probably benefit from a tidyup.
[Bug target/106907] New: gcc/config/rs6000/rs6000.cc:23155: strange expression ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106907 Bug ID: 106907 Summary: gcc/config/rs6000/rs6000.cc:23155: strange expression ? Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Static analyser cppcheck says: gcc/config/rs6000/rs6000.cc:23155:16: style: Boolean result is used in bitwise operation. Clarify expression with parentheses. [clarifyCondition] Source code is fprintf (file, "\t .amdhsa_system_vgpr_workitem_id\t%i\n", (cfun->machine->args.requested & (1 << WORK_ITEM_ID_Z_ARG)) ? 2 : cfun->machine->args.requested & (1 << WORK_ITEM_ID_Y_ARG) ? 1 : 0); Maybe better code: fprintf (file, "\t .amdhsa_system_vgpr_workitem_id\t%i\n", (cfun->machine->args.requested & (1 << WORK_ITEM_ID_Z_ARG)) ? 2 : (cfun->machine->args.requested & (1 << WORK_ITEM_ID_Y_ARG)) ? 1 : 0);
[Bug target/106907] gcc/config/rs6000/rs6000.cc:23155: strange expression ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106907 --- Comment #1 from David Binderman --- Wrong source code. It should be: if (swapped ^ !BYTES_BIG_ENDIAN && icode != CODE_FOR_vsx_xxpermdi_v16qi) That looks like it could benefit from some ( and ). The source code I did mention produces this message: gcc/config/gcn/gcn.cc:5563:5: style: Clarify calculation precedence for '&' and '?'. [clarifyCalculation] So two bugs reports in one.
[Bug target/106907] gcc/config/rs6000/rs6000.cc:23155: strange expression ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106907 --- Comment #2 from David Binderman --- In the same file rs6000.cc, cppcheck produces: gcc/config/rs6000/rs6000.cc:28477:8: style: Same expression on both sides of '&&'. [duplicateExpression] Source code is info->all_words_same = (info->words[0] == info->words[1] && info->words[0] == info->words[1] && info->words[0] == info->words[2] && info->words[0] == info->words[3]);
[Bug tree-optimization/106896] [13 Regression] ICE in to_sreal_scale, at profile-count.cc:339
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106896
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #1 from rsandifo at gcc dot gnu.org
---
The problematic line is:
return bb->count.to_sreal_scale (ENTRY_BLOCK_PTR_FOR_FN (cfun)->count);
where bb->count is:
{m_val = 0, m_quality = GUESSED_LOCAL}
and the entry block count is:
{m_val = 0, m_quality = PRECISE}
So we fail the first assert here:
/* Watch for cases where one count is IPA and other is not. */
if (in.ipa ().initialized_p ())
{
gcc_checking_assert (ipa ().initialized_p ());
/* If current count is inter-procedurally 0 and IN is inter-procedurally
non-zero, return 0. */
if (in.ipa ().nonzero_p ()
&& !ipa().nonzero_p ())
return 0;
}
else
/* We can handle correctly 0 IPA count within locally estimated
profile, but otherwise we are lost and this should not happen. */
gcc_checking_assert (!ipa ().initialized_p () || !ipa ().nonzero_p ());
But ipa() says:
/* Return variant of profile count which is always safe to compare
across functions. */
profile_count ipa () const
{
if (m_quality > GUESSED_GLOBAL0_ADJUSTED)
return *this;
if (m_quality == GUESSED_GLOBAL0)
return zero ();
if (m_quality == GUESSED_GLOBAL0_ADJUSTED)
return adjusted_zero ();
return uninitialized ();
}
So it feels like the ipa() in to_sreal_scale is a speculative
“could I compare this value across functions, if I had to?”.
The bb->count computation quoted above is deliberately intraprocedural
rather than interprocedural. In that context it doesn't really seem
relevant that one of the values could be compared across functions,
since that isn't what we're doing.
What's the right fix here?
[Bug target/106907] gcc/config/rs6000/rs6000.cc:23155: strange expression ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106907 --- Comment #3 from Andreas Schwab --- Should probably be written as swapped != !BYTES_BIG_ENDIAN.
[Bug libgomp/106906] libgomp/env.c: 3 * boolean value assigned to pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106906
--- Comment #1 from Jakub Jelinek ---
Well, it is correct as is, because while icv_addr[3] and params[3] have void *
type, they are actually cast to various types (either other pointers or bool
etc.).
But there is no need not to make the cast explicit and after all, there is
icv_addr[0] = icv_addr[1] = icv_addr[2] = NULL;
before the switch, so zero reinitialization is just a waste of time unless
compiler optimizes that out.
So we could go for:
2022-09-12 Jakub Jelinek
PR libgomp/106906
* env.c (get_icv_member_addr): Cast false to void * before assigning
it to icv_addr[1], and comment the whole assignment out.
--- libgomp/env.c.jj2022-09-12 10:32:00.935086858 +0200
+++ libgomp/env.c 2022-09-12 13:27:22.893571697 +0200
@@ -1892,14 +1892,14 @@ get_icv_member_addr (struct gomp_initial
{
case GOMP_ICV_NTEAMS:
icv_addr[0] = &icvs->nteams_var;
- icv_addr[1] = false;
+ /* icv_addr[1] = (void *) false; */
break;
case GOMP_ICV_DYNAMIC:
icv_addr[0] = &(*icvs).dyn_var;
break;
case GOMP_ICV_TEAMS_THREAD_LIMIT:
icv_addr[0] = &icvs->teams_thread_limit_var;
- icv_addr[1] = false;
+ /* icv_addr[1] = (void *) false; */
break;
case GOMP_ICV_SCHEDULE:
icv_addr[0] = &icvs->run_sched_var;
@@ -1907,7 +1907,7 @@ get_icv_member_addr (struct gomp_initial
break;
case GOMP_ICV_THREAD_LIMIT:
icv_addr[0] = &icvs->thread_limit_var;
- icv_addr[1] = false;
+ /* icv_addr[1] = (void *) false; */
icv_addr[2] = (void *) UINT_MAX;
break;
case GOMP_ICV_NTHREADS:
[Bug libstdc++/106908] New: libsupc++ wrong declaration of __unexpected_handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106908 Bug ID: 106908 Summary: libsupc++ wrong declaration of __unexpected_handler Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ralphengels at gmail dot com Target Milestone: --- the declaration of __unexpected_handler in unwind-cxx.h is wrongly declared as extern std::terminate_handler __unexpected_handler; should be extern std::unexpected_handler __unexpected_handler;
[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Fixed on master with r13-1450-gd2a89809452e.
[Bug target/106902] [11/12 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 Martin Liška changed: What|Removed |Added Summary|[11/12/13 Regression] |[11/12 Regression] Program |Program compiled with -O3 |compiled with -O3 -mfma |-mfma produces different|produces different result |result | CC||linkw at gcc dot gnu.org --- Comment #4 from Martin Liška --- Started with r11-4637-gf5e18dd9c7dacc96.
[Bug tree-optimization/106896] [13 Regression] ICE in to_sreal_scale, at profile-count.cc:339 since r13-2288-g61c4c989034548f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106896 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2022-09-12 Summary|[13 Regression] ICE in |[13 Regression] ICE in |to_sreal_scale, at |to_sreal_scale, at |profile-count.cc:339|profile-count.cc:339 since ||r13-2288-g61c4c989034548f4 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Btw. started with r13-2288-g61c4c989034548f4.
[Bug tree-optimization/106896] [13 Regression] ICE in to_sreal_scale, at profile-count.cc:339 since r13-2288-g61c4c989034548f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106896 --- Comment #3 from Martin Liška --- I think you may want to use something like: bb->count.probability_in (ENTRY_BLOCK_PTR_FOR_FN (cfun)->count).to_sreal()
[Bug libstdc++/106908] libsupc++ wrong declaration of __unexpected_handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106908 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- Not a bug, this is intentional. std::unexpected_handler does not exist in C++17 and later, so using terminate_handler means the code compiles for any version of C++. The two types are identical, so it doesn't matter.
[Bug libstdc++/106908] libsupc++ wrong declaration of __unexpected_handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106908 --- Comment #2 from ralphengels at gmail dot com --- ah my bad then i just thought it looked suspicious especially since i been having problems building gnat. For some reason it tries to link to the static libgcc library and aborts due to an exception. So i had to change the GCC_LINKER_FLAGS to force -shared-libgcc. so when i spotted this i assumed a typo might have occured breaking the exception handlers.
[Bug c++/106909] New: error: control flow in the middle of basic block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106909
Bug ID: 106909
Summary: error: control flow in the middle of basic block
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Created attachment 53563
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53563&action=edit
C++ source code
The attached legal C++ code does this:
$ ../results/bin/g++ -c -g -O2 -w bug847.cc
/home/dcb36/rpmbuild/BUILD/capnproto-c++-0.9.1/src/capnp/../kj/parse/common.h:727:7:
error: control flow in the middle of basic block 23
727 | operator()(Input& input) const {
| ^~~~
/home/dcb36/rpmbuild/BUILD/capnproto-c++-0.9.1/src/capnp/../kj/parse/common.h:727:7:
internal compiler error: verify_flow_info failed
0xb264bb verify_flow_info()
../../trunk.git/gcc/cfghooks.cc:284
0x109fc1b checking_verify_flow_info()
../../trunk.git/gcc/cfghooks.h:214
I will have a go at identifying a git range.
[Bug tree-optimization/106909] error: control flow in the middle of basic block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106909 --- Comment #1 from David Binderman --- Git range seems to be cdcc27c1ca9c485c..a0f83501182de68f, some 30 commits.
[Bug tree-optimization/106909] [13 Regression] error: control flow in the middle of basic block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106909 Andrew Pinski changed: What|Removed |Added Version|12.0|13.0 Summary|error: control flow in the |[13 Regression] error: |middle of basic block |control flow in the middle ||of basic block Target Milestone|--- |13.0
[Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86491 --- Comment #14 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8ef5fa4c56c82dfbd6e8fc5e4e08c4be843abc3e commit r13-2627-g8ef5fa4c56c82dfbd6e8fc5e4e08c4be843abc3e Author: Jonathan Wakely Date: Thu Jun 30 17:53:26 2022 +0100 c++: Refer to internal linkage for -Wsubobject-linkage [PR86491] Since C++11 relaxed the requirement for template arguments to have external linkage, it's possible to get -Wsubobject-linkage warnings without using any anonymous namespaces. This confuses users when they get diagnostics that refer to an anonymous namespace that doesn't exist in their code. This changes the diagnostic to say "has internal linkage" for C++11 and later, if the type isn't actually a member of the anonymous namespace. Making that distinction involved renaming the current decl_anon_ns_mem_p to something that better expresses its semantics. For C++98 template arguments declared with 'static' are ill-formed anyway, so the only way this warning can arise is via anonymous namespaces. That means the existing wording is accurate for C++98 and so we can keep it. PR c++/86491 gcc/cp/ChangeLog: * decl2.cc (constrain_class_visibility): Adjust wording of -Wsubobject-linkage for cases where anonymous namespaces aren't used. * tree.cc (decl_anon_ns_mem_p): Now only true for actual anonymous namespace members, rename old semantics to... (decl_internal_context_p): ...this. * cp-tree.h, name-lookup.cc, pt.cc: Adjust. gcc/testsuite/ChangeLog: * g++.dg/warn/anonymous-namespace-3.C: Use separate dg-warning directives for C++98 and everything else. * g++.dg/warn/Wsubobject-linkage-5.C: New test.
[Bug c++/106910] New: roundss not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106910
Bug ID: 106910
Summary: roundss not vectorized
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pilarlatiesa at gmail dot com
Target Milestone: ---
GCC 7 and newer optimize `std::floor(float)` into `vroundss` with -O2 and
-march=skylake, which is great.
However, I can see in Compiler Explorer that the following example:
```
#include
struct TVec { float x, y; };
struct TKey { int i, j; };
class TDom
{
private:
static int Floor(float const x)
{ return static_cast(std::floor(x)); }
public:
TKey CalcKey(TVec const &) const;
};
TKey TDom::CalcKey(TVec const &r) const
{ return {Floor(r.x), Floor(r.y)}; }
```
produces:
```
vxorps %xmm1, %xmm1, %xmm1
vroundss$9, (%rsi), %xmm1, %xmm0
vroundss$9, 4(%rsi), %xmm1, %xmm1
vunpcklps %xmm1, %xmm0, %xmm0
vcvttps2dq %xmm0, %xmm2
vmovq %xmm2, %rax
ret
```
Couldn’t the pair of `vroundss` have been merged into a single `vroundps`?
[Bug tree-optimization/106868] [12/13 Regression] Bogus -Wdangling-pointer warning with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106868
--- Comment #2 from Martin Sebor ---
(In reply to Richard Biener from comment #1)
> Confirmed.
>
> [local count: 1073741824]:
> alloc (&q);
> q.0_1 = q;
> *p_4(D) = q.0_1;
> q ={v} {CLOBBER(eol)};
> a_8 = __builtin_memcpy (q.0_1, "", 1);
> *a_8 = 0;
> return;
...
> we somehow confuse q.0_1 = q; as assigning the address of the object 'q'.
The reason for the false positive is plain to see in the IL: the memcpy call is
passed a copy of the clobbered q. It then returns another copy of the same q
which is then used to dereference whatever the pointer points to. The warning
is due to the (known) mismatch between how the optimizers and the warning
interpret clobbers: (IIUC) the optimizers treat it as the value of the assigned
variable alone becoming indeterminate, while the warning as all copies of it
becoming so.
[Bug target/106910] roundss not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106910 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||missed-optimization Last reconfirmed||2022-09-12 --- Comment #1 from Andrew Pinski --- On x86_64: /app/example.cpp:19:35: missed: function is not vectorizable. /opt/compiler-explorer/gcc-trunk-20220912/include/c++/13.0.0/cmath:261:28: missed: not vectorized: relevant stmt not supported: _9 = __builtin_floorf (_1); While on aarch64, GCC can handle the SLP just fine: vect__1.7_12 = MEM [(float *)r_4(D)]; vect__9.8_13 = .FLOOR (vect__1.7_12); vect__10.9_14 = (vector(2) int) vect__9.8_13; MEM [(int *)&D.25164] = vect__10.9_14; So this is a target backend improvement that is needed.
[Bug c++/106567] [13 Regression] An array with a dependent type and initializer-deduced bound is treated as an array of unknown bound when captured in a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org
[Bug tree-optimization/106868] [12/13 Regression] Bogus -Wdangling-pointer warning with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106868
--- Comment #3 from Martin Sebor ---
(In reply to Martin Sebor from comment #2)
...
Actually, scratch that, sorry. Richard is right that the false positive is due
to a bug in the warning code. The following patch resolves it:
diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
index 04aa849a4b1..79093b46906 100644
--- a/gcc/gimple-ssa-warn-access.cc
+++ b/gcc/gimple-ssa-warn-access.cc
@@ -4467,6 +4467,7 @@ pass_waccess::gimple_call_return_arg_ref (gcall *call)
{
access_ref aref;
if (m_ptr_qry.get_ref (arg, call, &aref, 0)
+ && aref.deref < 0
&& DECL_P (aref.ref))
return aref.ref;
}
[Bug fortran/106911] New: ICE in gfc_convert_mpz_to_signed, at fortran/simplify.cc:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106911 Bug ID: 106911 Summary: ICE in gfc_convert_mpz_to_signed, at fortran/simplify.cc:193 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 program p integer, parameter :: a = 10 integer, parameter :: b = 20 interface subroutine s integer, parameter :: c = ishftc(1_1, a, b) end end interface end $ gfortran-13-20220911 -c z1.f90 f951: internal compiler error: in gfc_convert_mpz_to_signed, at fortran/simplify.cc:193 0x8846e1 gfc_convert_mpz_to_signed(__mpz_struct*, int) ../../gcc/fortran/simplify.cc:193 0x88a75a gfc_simplify_ishftc(gfc_expr*, gfc_expr*, gfc_expr*) ../../gcc/fortran/simplify.cc:4031 0x808f4a do_simplify ../../gcc/fortran/intrinsic.cc:4677 0x813dc8 gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.cc:4942 0x7f9c2c gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.cc:2228 0x813f7e gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.cc:5092 0x869578 resolve_unknown_f ../../gcc/fortran/resolve.cc:2990 0x869578 resolve_function ../../gcc/fortran/resolve.cc:3347 0x869578 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.cc:7194 0x7f8e04 gfc_reduce_init_expr(gfc_expr*) ../../gcc/fortran/expr.cc:3163 0x7fbd90 gfc_match_init_expr(gfc_expr**) ../../gcc/fortran/expr.cc:3211 0x7e5d2b variable_decl ../../gcc/fortran/decl.cc:3028 0x7e5d2b gfc_match_data_decl() ../../gcc/fortran/decl.cc:6331 0x8519c3 match_word ../../gcc/fortran/parse.cc:67 0x8519c3 decode_statement ../../gcc/fortran/parse.cc:378 0x85340a next_free ../../gcc/fortran/parse.cc:1399 0x85340a next_statement ../../gcc/fortran/parse.cc:1631 0x8556f4 parse_spec ../../gcc/fortran/parse.cc:3986 0x8550ae parse_interface ../../gcc/fortran/parse.cc:3849 0x8550ae parse_spec ../../gcc/fortran/parse.cc:4123
[Bug fortran/106911] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.cc:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106911 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- Errors detected : $ cat z2.f90 program p integer, parameter :: a = 10 integer, parameter :: b = 20 integer, parameter :: c = ishftc(1_1, a, b) end $ cat z3.f90 program p integer, parameter :: a = 10 integer, parameter :: b = 20 interface subroutine s import :: a, b integer, parameter :: c = ishftc(1_1, a, b) end end interface end
[Bug c/106912] New: [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106912
Bug ID: 106912
Summary: [13 Regression] ICE in vect_transform_loops, at
tree-vectorizer.cc:1032
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20220703 and 20220710, at -O1+,
with file gcc.target/aarch64/simd_pcs_attribute-3.c :
$ cat z1.c
__attribute__ ((__simd__))
__attribute__ ((__nothrow__ , __leaf__ , __const__))
double foo (double x);
void bar(double *f, int n)
{
int i;
for (i = 0; i < n; i++)
f[i] = foo(f[i]);
}
double foo(double x)
{
return x * x / 3.0;
}
$ gcc-13-20220911 -c z1.c -O2 -fPIC -ftree-vectorize -fprofile-generate
during GIMPLE pass: vect
z1.c: In function 'bar':
z1.c:4:6: internal compiler error: in vect_transform_loops, at
tree-vectorizer.cc:1032
4 | void bar(double *f, int n)
| ^~~
0xf5afe7 vect_transform_loops
../../gcc/tree-vectorizer.cc:1032
0xf5b394 try_vectorize_loop_1
../../gcc/tree-vectorizer.cc:1153
0xf5b394 try_vectorize_loop
../../gcc/tree-vectorizer.cc:1185
0xf5b904 execute
../../gcc/tree-vectorizer.cc:1299
[Bug c/106913] New: [13 Regression] ICE in dump_bb_info, at cfg.cc:796
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106913
Bug ID: 106913
Summary: [13 Regression] ICE in dump_bb_info, at cfg.cc:796
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20220828 and 20220904, at -O0,
with file gcc.dg/pr51879.c (and several others) :
$ cat z1.c # alias pr51879.c
int bar (int);
void baz (int);
void
foo (int y)
{
int a;
if (y == 6)
a = bar (7);
else
a = bar (7);
baz (a);
}
$ gcc-13-20220911 -c z1.c -O0 -da -Wall
during RTL pass: jump
dump file: z1.c.257r.jump
z1.c: In function 'foo':
z1.c:12:1: internal compiler error: in dump_bb_info, at cfg.cc:796
12 | }
| ^
0x9433ec dump_bb_info(_IO_FILE*, basic_block_def*, int, dump_flag, bool, bool)
../../gcc/cfg.cc:796
0x965f97 dump_bb(_IO_FILE*, basic_block_def*, int, dump_flag)
../../gcc/cfghooks.cc:299
0x9661cf dump_flow_info(_IO_FILE*, dump_flag)
../../gcc/cfghooks.cc:361
0x1c019cd execute
../../gcc/cfgcleanup.cc:3239
[Bug c/106914] New: [13 Regression] ICE in operator[], at vec.h:889
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106914 Bug ID: 106914 Summary: [13 Regression] ICE in operator[], at vec.h:889 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20220828 and 20220904, at -O2+, with file gcc.target/aarch64/sve/mask_load_slp_1.c : (-mavx512vl or option -mavx2 etc.) $ gcc-13-20220911 -c mask_load_slp_1.c -O2 -mavx512vl -fprofile-generate during GIMPLE pass: vect mask_load_slp_1.c: In function 'mask_slp_int64_t_8_2': mask_load_slp_1.c:34:1: internal compiler error: in operator[], at vec.h:889 34 | mask_slp_##TYPE_COND##_8_##ALT_VAL (int *restrict x, int *restrict y, \ | ^ mask_load_slp_1.c:81:1: note: in expansion of macro 'MASK_SLP_8' 81 | MASK_SLP_8(int64_t, 2) | ^~ 0x11cce67 vec::operator[](unsigned int) ../../gcc/vec.h:889 0x11cce67 vec::operator[](unsigned int) ../../gcc/vec.h:1498 0x11cce67 vect_transform_slp_perm_load_1 ../../gcc/tree-vect-slp.cc:8144 0x11d1eb2 vect_optimize_slp_pass::internal_node_cost(_slp_tree*, int, unsigned int) ../../gcc/tree-vect-slp.cc:4508 0x11d2cc1 vect_optimize_slp_pass::forward_pass() ../../gcc/tree-vect-slp.cc:4999 0x11e261c vect_optimize_slp_pass::run() ../../gcc/tree-vect-slp.cc:5548 0x11e26f7 vect_optimize_slp(vec_info*) ../../gcc/tree-vect-slp.cc:5568 0x11b4840 vect_analyze_loop_2 ../../gcc/tree-vect-loop.cc:2477 0x11b558b vect_analyze_loop_1 ../../gcc/tree-vect-loop.cc:2980 0x11b5d4f vect_analyze_loop(loop*, vec_info_shared*) ../../gcc/tree-vect-loop.cc:3134 0x11f8177 try_vectorize_loop_1 ../../gcc/tree-vectorizer.cc:1067 0x11f8177 try_vectorize_loop ../../gcc/tree-vectorizer.cc:1185 0x11f8a94 execute ../../gcc/tree-vectorizer.cc:1299
[Bug c++/106893] [12/13 Regression] auto deduces wrong type for function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106893 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug fortran/106915] New: ICE/segfault during parsing with modules and invalid code in malloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106915 Bug ID: 106915 Summary: ICE/segfault during parsing with modules and invalid code in malloc Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Created attachment 53564 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53564&action=edit Testcase the following code ICEs either in variant (A) with: corrupted size vs. prev_size ... 0x7f18078ba08f ??? /build/glibc-SzIz7B/glibc-2.31/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x7f180790ca63 malloc_consolidate /build/glibc-SzIz7B/glibc-2.31/malloc/malloc.c:4492 0x7f180790ec82 _int_malloc Or in Variant (B) with: Error: Expecting END MODULE statement at (1) malloc(): mismatching next->prev_size (unsorted) malloc(): mismatching next->prev_size (unsorted) gfortran: internal compiler error: Aborted signal terminated program f951 The second variant seems to work also without -fopenmp, even though it has 'USE omp_lib'.
[Bug target/101322] ICE in copy_to_mode_reg, at explow.c:651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101322 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:15ae5487dfd3f437b47a26d6198c8e1257fec2fc commit r11-10251-g15ae5487dfd3f437b47a26d6198c8e1257fec2fc Author: Peter Bergner Date: Wed Aug 31 21:14:36 2022 -0500 rs6000: Don't ICE when we disassemble an MMA variable [PR101322] When we expand an MMA disassemble built-in with C++ using a pointer that is cast to a valid MMA type, the type isn't passed down to the expand machinery and we end up using the base type of the pointer which leads to an ICE. This patch enforces we always use the correct MMA type regardless of the pointer type being used. 2022-08-31 Peter Bergner gcc/ PR target/101322 * config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Enforce the use of a valid MMA pointer type. gcc/testsuite/ PR target/101322 * g++.target/powerpc/pr101322.C: New test. (cherry picked from commit 2985049049f12b0aa3366ca244d387820385b9e8)
[Bug c++/106651] [C++23] P1169 - static operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106651
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Created attachment 53565
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53565&action=edit
gcc13-pr106651-wip.patch
WIP patch which has parts of the changes implemented.
What is missing is [over.match.best.general]/1 and [over.best.ics.general]
changes and the library side, which means e.g. for the testcase from the paper:
struct less {
static constexpr auto operator()(int i, int j) -> bool {
return i < j;
}
using P = bool(*)(int, int);
operator P() const { return operator(); }
};
static_assert(less{}(1, 2));
we ICE.
Testcase I've been playing with that compiles now:
template
struct S
{
static constexpr bool operator() (T const& x, T const& y) { return x < y; };
};
template
void
bar (T &x)
{
x (1, 2);
}
void
foo ()
{
auto a = [](int x, int y) static { return x + y; };
bar (*a);
auto b = [](T x, U y) static { return x + y; };
b (1, 2L);
S s;
s(1, 2);
}
[Bug c++/106567] [13 Regression] An array with a dependent type and initializer-deduced bound is treated as an array of unknown bound when captured in a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106567 --- Comment #6 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:7c989a8ed47228bdd494a2f0d1f6fdd325f953d7 commit r13-2628-g7c989a8ed47228bdd494a2f0d1f6fdd325f953d7 Author: Jason Merrill Date: Mon Sep 12 12:59:46 2022 -0400 c++: lambda capture of array with deduced bounds [PR106567] We can't use the type of an array variable directly if we haven't deduced its length yet. PR c++/106567 gcc/cp/ChangeLog: * lambda.cc (type_deducible_expression_p): Check array_of_unknown_bound_p. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-array4.C: New test.
[Bug fortran/106916] New: ICE/segfault during parsing with modules and invalid code in gfc_free_namespace when using the same symbol twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106916 Bug ID: 106916 Summary: ICE/segfault during parsing with modules and invalid code in gfc_free_namespace when using the same symbol twice Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- f951: internal compiler error: in gfc_free_namespace, at fortran/symbol.cc:4039 0x686c77 gfc_free_namespace(gfc_namespace*&) ../../repos/gcc/gcc/fortran/symbol.cc:4039 0xa29daf gfc_free_symbol(gfc_symbol*&) ../../repos/gcc/gcc/fortran/symbol.cc:3085 0xa29e85 gfc_release_symbol(gfc_symbol*&) ../../repos/gcc/gcc/fortran/symbol.cc:3127 for the invalid attached testcase. -fopenmp is in theory required. There are two issues: * The same symbol is used twice, once use associated and once newly defined in an interface block. * There is a tailing '::' module omp_lib_target use omp_lib implicit none (type, external) interface logical function omp_target_is_present(ptr, device_num) type(*), dimension(..) :: end function omp_target_is_present end interface end module omp_lib_target
[Bug modula2/106917] New: modula-2 fails to bootstrap with the modula-2 branch ,20220912
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106917 Bug ID: 106917 Summary: modula-2 fails to bootstrap with the modula-2 branch ,20220912 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- the modula-2 branch 20220912 fails to build: echo "GM2_FOR_TARGET " /bin/bash ../../src/gcc/m2/tools-src/makeSystem -fiso \ ../../src/gcc/m2/gm2-libs-iso/SYSTEM.def \ ../../src/gcc/m2/gm2-libs-iso/SYSTEM.mod \ -I../../src/gcc/m2/gm2-libs-iso:../../src/gcc/m2/gm2-libs \ "" /home/packages/gcc/snap/gcc-snapshot-20220912/build/gcc/m2/gm2-libs-iso/SYSTEM.d ef /bin/bash ../../src/gcc/m2/tools-src/makeSystem -fpim \ ../../src/gcc/m2/gm2-libs-coroutines/SYSTEM.def \ ../../src/gcc/m2/gm2-libs-coroutines/SYSTEM.mod \ -I../../src/gcc/m2/gm2-libs-coroutines:../../src/gcc/m2/gm2-libs-iso:../../src/gcc/ m2/gm2-libs \ "" /home/packages/gcc/snap/gcc-snapshot-20220912/build/gcc/m2/gm2-libs-coroutines/S YSTEM.def GM2_FOR_TARGET echo "GCC_FOR_TARGET /home/packages/gcc/snap/gcc-snapshot-20220912/build/./gcc/xgcc -B/home/pack ages/gcc/snap/gcc-snapshot-20220912/build/./gcc/ -fno-checking" GCC_FOR_TARGET /home/packages/gcc/snap/gcc-snapshot-20220912/build/./gcc/xgcc -B/home/packages/g cc/snap/gcc-snapshot-20220912/build/./gcc/ -fno-checking /bin/bash ../../src/gcc/m2/tools-src/makeSystem -fpim \ ../../src/gcc/m2/gm2-libs/SYSTEM.def \ ../../src/gcc/m2/gm2-libs/SYSTEM.mod \ -I../../src/gcc/m2/gm2-libs \ "" /home/packages/gcc/snap/gcc-snapshot-20220912/build/gcc/m2/gm2-libs/SYSTEM.def parameter 5 of makeSystem is incorrect, GM2_FOR_TARGET was unset make[5]: *** [../../src/gcc/m2/Make-lang.in:1469: /home/packages/gcc/snap/gcc-snapshot-20220912/ build/gcc/m2/gm2-libs-iso/SYSTEM.def] Error 1 make[5]: *** Waiting for unfinished jobs parameter 5 of makeSystem is incorrect, GM2_FOR_TARGET was unset make[5]: *** [../../src/gcc/m2/Make-lang.in:1476: /home/packages/gcc/snap/gcc-snapshot-20220912/build/gcc/m2/gm2-libs-coroutines/SYSTEM.def] Error 1 parameter 5 of makeSystem is incorrect, GM2_FOR_TARGET was unset make[5]: *** [../../src/gcc/m2/Make-lang.in:1462: /home/packages/gcc/snap/gcc-snapshot-20220912/build/gcc/m2/gm2-libs/SYSTEM.def] Error 1
[Bug tree-optimization/106909] [13 Regression] error: control flow in the middle of basic block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106909 --- Comment #2 from David Binderman --- Created attachment 53566 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53566&action=edit C++ source code After an hour of reduction, this is what remains.
[Bug libstdc++/106320] [10 regression] build failure (due to view requirement changes?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106320 --- Comment #9 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:db19cfdac8ede93172aecc58612171c239c993ad commit r13-2629-gdb19cfdac8ede93172aecc58612171c239c993ad Author: Patrick Palka Date: Mon Sep 12 15:05:04 2022 -0400 libstdc++: Add already-accepted testcase [PR106320] Although PR106320 affected only the 10 and 11 branches, and the testcase from there is already correctly accepted on trunk and the 12 branch, we still should add the testcase to trunk/12 too for inter-branch consistency. PR libstdc++/106320 libstdc++-v3/ChangeLog: * testsuite/std/ranges/adaptors/join.cc (test13): New test.
[Bug libstdc++/106320] [10 regression] build failure (due to view requirement changes?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106320 --- Comment #10 from CVS Commits --- The releases/gcc-12 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:f323610375f4f87098f98b501ab01d033c930558 commit r12-8757-gf323610375f4f87098f98b501ab01d033c930558 Author: Patrick Palka Date: Mon Sep 12 15:05:04 2022 -0400 libstdc++: Add already-accepted testcase [PR106320] Although PR106320 affected only the 10 and 11 branches, and the testcase from there is already correctly accepted on trunk and the 12 branch, we still should add the testcase to trunk/12 too for inter-branch consistency. PR libstdc++/106320 libstdc++-v3/ChangeLog: * testsuite/std/ranges/adaptors/join.cc (test13): New test. (cherry picked from commit db19cfdac8ede93172aecc58612171c239c993ad)
[Bug libstdc++/106320] [10 regression] build failure (due to view requirement changes?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106320 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Patrick Palka --- Fixed.
[Bug c++/106756] [CWG1699] Overbroad friendship for nested classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106756
Jason Merrill changed:
What|Removed |Added
Summary|[13 Regression] Overbroad |[CWG1699] Overbroad
|friendship for nested |friendship for nested
|classes |classes
Last reconfirmed||2022-09-12
Ever confirmed|0 |1
Status|UNCONFIRMED |SUSPENDED
--- Comment #3 from Jason Merrill ---
(In reply to S. Davis Herring from comment #2)
> That said, one can make a similar argument along the lines of "B is a
> member-declaration of A, and so f is part of a member-declaration itself",
Exactly.
> which puts us back on the old question of whether it matters whether the
> friend is defined inside the class. Indeed, GCC still rejects the example
> modified to use
>
> int f(A::B*) {return A::i;}
Yes, because there the definition of f is not (part of) a member-declaration.
Friends defined in the class body are different in various ways from normal
functions that happen to be friends; it makes sense to me for this to be one
such.
Suspending pending the resolution of CWG1699.
[Bug tree-optimization/106912] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032 since r13-1575-gcf3a120084e94614
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106912 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-09-12 Status|UNCONFIRMED |NEW Summary|[13 Regression] ICE in |[13 Regression] ICE in |vect_transform_loops, at|vect_transform_loops, at |tree-vectorizer.cc:1032 |tree-vectorizer.cc:1032 ||since ||r13-1575-gcf3a120084e94614 --- Comment #1 from Martin Liška --- Started with r13-1575-gcf3a120084e94614.
[Bug rtl-optimization/106913] [13 Regression] ICE in dump_bb_info, at cfg.cc:796 since r13-2263-gf71abacfed170852
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106913 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-09-12 Status|UNCONFIRMED |ASSIGNED Summary|[13 Regression] ICE in |[13 Regression] ICE in |dump_bb_info, at cfg.cc:796 |dump_bb_info, at cfg.cc:796 ||since ||r13-2263-gf71abacfed170852 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r13-2263-gf71abacfed170852, but I can take a look.
[Bug tree-optimization/106914] [13 Regression] ICE in operator[], at vec.h:889 since r13-2288-g61c4c989034548f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106914
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
||richard.sandiford at arm dot
com
Summary|[13 Regression] ICE in |[13 Regression] ICE in
|operator[], at vec.h:889|operator[], at vec.h:889
||since
||r13-2288-g61c4c989034548f4
Ever confirmed|0 |1
Last reconfirmed||2022-09-12
Status|UNCONFIRMED |NEW
--- Comment #1 from Martin Liška ---
Reduced to:
$ cat mask.i
int *mask_slp_int64_t_8_2_x, *mask_slp_int64_t_8_2_y, *mask_slp_int64_t_8_2_z;
void
__attribute__mask_slp_int64_t_8_2() {
for (int i; i; i += 8) {
mask_slp_int64_t_8_2_x[i + 6] =
mask_slp_int64_t_8_2_y[i + 6] ? mask_slp_int64_t_8_2_z[i] : 1;
mask_slp_int64_t_8_2_x[i + 7] =
mask_slp_int64_t_8_2_y[i + 7] ? mask_slp_int64_t_8_2_z[i + 7] : 2;
}
}
$ gcc mask.i -c -O2 -mavx512vl -fprofile-generate
during GIMPLE pass: vect
mask.i: In function ‘__attribute__mask_slp_int64_t_8_2’:
mask.i:4:1: internal compiler error: in operator[], at vec.h:889
4 | __attribute__mask_slp_int64_t_8_2() {
| ^
0x7fafce vec::operator[](unsigned int)
/home/marxin/Programming/gcc/gcc/vec.h:889
0x7fbab5 vec::operator[](unsigned int)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:8144
0x7fbab5 vec::operator[](unsigned int)
/home/marxin/Programming/gcc/gcc/vec.h:1498
0x7fbab5 vect_transform_slp_perm_load_1
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:8144
0x121ba09 vect_optimize_slp_pass::internal_node_cost(_slp_tree*, int, unsigned
int)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:4508
0x121c811 vect_optimize_slp_pass::forward_pass()
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:4998
0x122af4c vect_optimize_slp_pass::run()
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:5548
0x122b013 vect_optimize_slp(vec_info*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:5568
0x122b013 vect_optimize_slp(vec_info*)
/home/marxin/Programming/gcc/gcc/tree-vect-slp.cc:5564
0x1203fde vect_analyze_loop_2
/home/marxin/Programming/gcc/gcc/tree-vect-loop.cc:2477
0x1204e4f vect_analyze_loop_1
/home/marxin/Programming/gcc/gcc/tree-vect-loop.cc:2978
0x1205691 vect_analyze_loop(loop*, vec_info_shared*)
/home/marxin/Programming/gcc/gcc/tree-vect-loop.cc:3132
0x1240d3c try_vectorize_loop_1
/home/marxin/Programming/gcc/gcc/tree-vectorizer.cc:1067
0x1240d3c try_vectorize_loop
/home/marxin/Programming/gcc/gcc/tree-vectorizer.cc:1183
0x12412e4 execute
/home/marxin/Programming/gcc/gcc/tree-vectorizer.cc:1299
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug fortran/106916] ICE/segfault during parsing with modules and invalid code in gfc_free_namespace when using the same symbol twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106916 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-12 CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started likely since r12-2985-g76bb3c50dd43a5f8.
[Bug fortran/106915] ICE/segfault during parsing with modules and invalid code in malloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106915 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Likely started with r9-3442-gb4439561c4019cf3.
[Bug fortran/106915] ICE/segfault during parsing with modules and invalid code in malloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106915 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-09-12 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/93259] Unsized temporary array initialization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93259
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:6bcca5f642eb950a3cef024ea49a35e4792306f6
commit r13-2631-g6bcca5f642eb950a3cef024ea49a35e4792306f6
Author: Jason Merrill
Date: Mon Sep 12 14:14:24 2022 -0400
c++: cast to array of unknown bound [PR93259]
We already know to treat a variable of array-of-unknown-bound type as
dependent, we should do the same for arr{}.
PR c++/93259
gcc/cp/ChangeLog:
* pt.cc (type_dependent_expression_p): Treat a compound
literal of array-of-unknown-bound type like a variable.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-array17.C: New test.
[Bug c++/106893] [12/13 Regression] auto deduces wrong type for function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106893 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:03381beccb52c0e2c15da3b8b8dfa3bb6eb71df9 commit r13-2632-g03381beccb52c0e2c15da3b8b8dfa3bb6eb71df9 Author: Jason Merrill Date: Mon Sep 12 13:47:34 2022 -0400 c++: auto member function and auto variable [PR106893] As with PR105623, we need to call mark_single_function sooner to resolve the type of a BASELINK. PR c++/106893 PR c++/90451 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Call mark_single_function. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/auto-fn65.C: New test.
[Bug c++/90451] [9/10/11/12 Regression] "static" function which added "deprecated" print deprecated warning >1 times (twice or even 3 times)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90451 --- Comment #13 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:03381beccb52c0e2c15da3b8b8dfa3bb6eb71df9 commit r13-2632-g03381beccb52c0e2c15da3b8b8dfa3bb6eb71df9 Author: Jason Merrill Date: Mon Sep 12 13:47:34 2022 -0400 c++: auto member function and auto variable [PR106893] As with PR105623, we need to call mark_single_function sooner to resolve the type of a BASELINK. PR c++/106893 PR c++/90451 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Call mark_single_function. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/auto-fn65.C: New test.
[Bug tree-optimization/106909] [13 Regression] error: control flow in the middle of basic block since r13-2541-g78ef801b7263606d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106909 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-09-12 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|[13 Regression] error: |[13 Regression] error: |control flow in the middle |control flow in the middle |of basic block |of basic block since ||r13-2541-g78ef801b7263606d --- Comment #3 from Martin Liška --- Started with r13-2541-g78ef801b7263606d.
[Bug driver/106897] driver: support -gz=zstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106897 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- I can work on that as I added zstd compression for LTO bytecode some time ago.
[Bug c/91092] Error on implicit function declarations by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092 --- Comment #21 from Sam James --- Followers of this bug may be interested to learn: 1. Clang has made this change in LLVM 15 (as well as some other related changes: https://releases.llvm.org/15.0.0/tools/clang/docs/ReleaseNotes.html#improvements-to-clang-s-diagnostics); 2. There's discussion ongoing at https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-implicit-function-declaration/65213 wrt the breakage to configure scripts.
[Bug c++/90451] [9/10/11/12 Regression] "static" function which added "deprecated" print deprecated warning >1 times (twice or even 3 times)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90451 --- Comment #14 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:999638cb7b126d33d1ea6548c69ba387b7d7a270 commit r12-8758-g999638cb7b126d33d1ea6548c69ba387b7d7a270 Author: Jason Merrill Date: Mon Sep 12 13:47:34 2022 -0400 c++: auto member function and auto variable [PR106893] As with PR105623, we need to call mark_single_function sooner to resolve the type of a BASELINK. PR c++/106893 PR c++/90451 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Call mark_single_function. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/auto-fn65.C: New test.
[Bug c++/106893] [12 Regression] auto deduces wrong type for function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106893 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:999638cb7b126d33d1ea6548c69ba387b7d7a270 commit r12-8758-g999638cb7b126d33d1ea6548c69ba387b7d7a270 Author: Jason Merrill Date: Mon Sep 12 13:47:34 2022 -0400 c++: auto member function and auto variable [PR106893] As with PR105623, we need to call mark_single_function sooner to resolve the type of a BASELINK. PR c++/106893 PR c++/90451 gcc/cp/ChangeLog: * decl.cc (cp_finish_decl): Call mark_single_function. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/auto-fn65.C: New test.
[Bug c++/93259] Unsized temporary array initialization problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93259
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:8f37a44483870e0db8cd6437ae9716cbe28b7f59
commit r12-8759-g8f37a44483870e0db8cd6437ae9716cbe28b7f59
Author: Jason Merrill
Date: Mon Sep 12 14:14:24 2022 -0400
c++: cast to array of unknown bound [PR93259]
We already know to treat a variable of array-of-unknown-bound type as
dependent, we should do the same for arr{}.
PR c++/93259
gcc/cp/ChangeLog:
* pt.cc (type_dependent_expression_p): Treat a compound
literal of array-of-unknown-bound type like a variable.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist-array17.C: New test.
[Bug fortran/106918] New: Cannot use structure constructor with component allocatable character array of deferred length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106918 Bug ID: 106918 Summary: Cannot use structure constructor with component allocatable character array of deferred length Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: guez at lmd dot ens.fr Target Milestone: --- gcc version 12.0.1 20220319 (experimental) [master r12-7719-g8ca61ad148f] (Ubuntu 12-20220319-1ubuntu1) Configured with: ../src/configure -v --with-pkgversion='Ubuntu 12-20220319-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-12-OcsLtf/gcc-12-12-20220319/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-OcsLtf/gcc-12-12-20220319/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu GNU Fortran (Ubuntu 11.2.0-19ubuntu1) 11.2.0 Here is a test program: $ cat test_coord_def.f90 character(len = :), allocatable:: attr_name(:) type coord_def character(len = :), allocatable:: attr_name(:) end type coord_def type(coord_def) coordinates attr_name = ["units"] print *, 'attr_name: "', attr_name, '"' coordinates = coord_def(attr_name) print *, 'coordinates%attr_name: "', coordinates%attr_name, '"' end The compilation command is: $ gfortran-12 test_coord_def.f90 There is no compilation message. The execution fails: $ ./a.out attr_name: "units" Operating system error: Cannot allocate memory Memory allocation failure in xrealloc Error termination. Backtrace: #0 0x1538fa556ae0 in ??? #1 0x1538fa557659 in ??? #2 0x1538fa557834 in ??? #3 0x1538fa555fee in ??? #4 0x1538fa7ba355 in ??? #5 0x1538fa7ab1b9 in ??? #6 0x1538fa7b3c00 in ??? #7 0x1538fa7b90ae in ??? #8 0x1538fa7ba105 in ??? #9 0x1538fa7ab8a8 in ??? #10 0x555fac4a76d8 in ??? #11 0x555fac4a7751 in ??? #12 0x1538fa334d8f in __libc_start_call_main at ../sysdeps/nptl/libc_start_call_main.h:58 #13 0x1538fa334e3f in __libc_start_main_impl at ../csu/libc-start.c:392 #14 0x555fac4a7114 in ??? #15 0x in ??? I think the source code is valid. Note that if I replace the structure constructor by an equivalent assignment to the component, the problem disappears: $ cat test_coord_def.f90 character(len = :), allocatable:: attr_name(:) type coord_def character(len = :), allocatable:: attr_name(:) end type coord_def type(coord_def) coordinates attr_name = ["units"] print *, 'attr_name: "', attr_name, '"' coordinates%attr_name = attr_name !!coordinates = coord_def(attr_name) print *, 'coordinates%attr_name: "', coordinates%attr_name, '"' end $ gfortran-12 test_coord_def.f90 $ ./a.out attr_name: "units" coordinates%attr_name: "units" Also, for additional information, there is no problem with ifort 19.1.
[Bug c++/101906] Constant evaluation failure in concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101906 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c3ba0eaaa223f7b8208d279e3f39ff134912f9e9 commit r13-2633-gc3ba0eaaa223f7b8208d279e3f39ff134912f9e9 Author: Patrick Palka Date: Tue Jun 7 14:19:53 2022 -0400 c++: template-id arguments are evaluated [PR101906] Here we're neglecting to clear cp_unevaluated_operand when substituting into the arguments of the alias template-id 'skip<(T(), 0), T>' with T=A, which means cp_unevaluated_operand remains set during mark_used for A::A() and so we don't synthesize it. Later constant evaluation for the substituted template argument '(A(), 0)' (from coerce_template_parms) fails with "'constexpr A::A()' used before its definition" since it was never synthesized. This doesn't happen with a class template because tsubst_aggr_type clears cp_unevaluated_operand during substitution thereof. But since template arguments are generally manifestly constant-evaluated, which in turn are evaluated even in an unevaluated operand, we should be clearing cp_unevaluated_operand more broadly whenever substituting into any set of template arguments. To that end this patch makes us clear it during tsubst_template_args. PR c++/101906 gcc/cp/ChangeLog: * pt.cc (tsubst_template_args): Set cp_evaluated here. (tsubst_aggr_type): Not here. gcc/testsuite/ChangeLog: * g++.dg/template/evaluated1.C: New test. * g++.dg/template/evaluated1a.C: New test. * g++.dg/template/evaluated1b.C: New test. * g++.dg/template/evaluated1c.C: New test.
[Bug c++/101906] Constant evaluation failure in concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101906 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.0 --- Comment #4 from Patrick Palka --- Fixed for GCC 13, thanks for the bug report.
[Bug target/106919] New: [13 Regression] RTL check: expected code 'set' or 'clobber', have 'if_then_else' in s390_rtx_costs, at config/s390/s390.cc:3672on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106919 Bug ID: 106919 Summary: [13 Regression] RTL check: expected code 'set' or 'clobber', have 'if_then_else' in s390_rtx_costs, at config/s390/s390.cc:3672on s390x-linux-gnu Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen with trunk 20220912 on s390x-linux-gnu during RTL pass: ce1 ../../../src/libgcc/libgcc2.c: In function '__multi3': ../../../src/libgcc/libgcc2.c:538:1: internal compiler error: RTL check: expected code 'set' or 'clobber', have 'if_then_else' in s390_rtx_costs, at config/s390/s390.cc:3672 538 | } | ^ 0x2b6a7dd s390_rtx_costs ../../src/gcc/config/s390/s390.cc:3672 0x232e3cd rtx_cost(rtx_def*, machine_mode, rtx_code, int, bool) ../../src/gcc/rtlanal.cc:4601 0x2307a2f set_rtx_cost ../../src/gcc/rtl.h:2925 0x23388e5 seq_cost(rtx_insn const*, bool) ../../src/gcc/rtlanal.cc:5788 0x39a24ad default_noce_conversion_profitable_p(rtx_insn*, noce_if_info*) ../../src/gcc/ifcvt.cc:814 0x39a973b noce_try_cmove ../../src/gcc/ifcvt.cc:1864 0x39b4bc5 noce_process_if_block ../../src/gcc/ifcvt.cc:3964 0x39b6e99 noce_find_if_block ../../src/gcc/ifcvt.cc:4521 0x39b794f find_if_header ../../src/gcc/ifcvt.cc:4726 0x39bbbd5 if_convert ../../src/gcc/ifcvt.cc:5873 0x39bbe4d rest_of_handle_if_conversion ../../src/gcc/ifcvt.cc:5938 0x39bbf61 execute ../../src/gcc/ifcvt.cc:5978 Configured with: -v --with-pkgversion='Ubuntu 20220912-1ubuntu1' --with-bugurl='file:///usr/share/doc/gcc-snapshot/README.Bugs' --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix= --enable-shared --enable-linker-build-id --disable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch=z13 --with-tune=z15 --enable-s390-excess-float-precision --with-long-double-128 --enable-multilib --enable-checking=yes,extra,rtl --build=s390x-linux-gnu --host=s390x-linux-gnu --target=s390x-linux-gnu
[Bug tree-optimization/106905] [13 Regression] ia64: ICE in in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:8412 on zstd-1.5.2 since r13-2503-gc13223b790bbc5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106905
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #2 from Arseny Solokha ---
It also can be reproduced for x86_64 when compiling the following testcase,
reduced from gcc/testsuite/gcc.target/i386/pr103144-mul-2.c, w/
-march=silvermont -O2 -fvect-cost-model=dynamic:
void
foo_mul_peel (int *a, int b)
{
int i;
for (i = 0; i < 7; ++i)
{
b *= 2;
a[i] = b;
}
}
[Bug tree-optimization/106905] [13 Regression] ia64: ICE in in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:8412 on zstd-1.5.2 since r13-2503-gc13223b790bbc5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106905
--- Comment #3 from Hongtao.liu ---
in vectorizable_nonlinear_induction, we prevent variable peeling by only
checking LOOP_VINFO_MASK_SKIP_NITERS (loop_vinfo).
But when "!vect_use_loop_mask_for_alignment_p (loop_vinfo) &&
LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) < 0", vectorizer will also do
variable peeling for epilog, and it hits gcc_assert in
vect_peel_nonlinear_iv_init.
I'm testing
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index 8f88f1755be..9c434b66c5b 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -8646,8 +8646,10 @@ vectorizable_nonlinear_induction (loop_vec_info
loop_vinfo,
/* Also doens't support peel for neg when niter is variable.
??? generate something like niter_expr & 1 ? init_expr : -init_expr? */
niters_skip = LOOP_VINFO_MASK_SKIP_NITERS (loop_vinfo);
- if (niters_skip != NULL_TREE
- && TREE_CODE (niters_skip) != INTEGER_CST)
+ if ((niters_skip != NULL_TREE
+ && TREE_CODE (niters_skip) != INTEGER_CST)
+ || (!vect_use_loop_mask_for_alignment_p (loop_vinfo)
+ && LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) < 0))
{
if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
[Bug tree-optimization/106905] [13 Regression] ia64: ICE in in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:8412 on zstd-1.5.2 since r13-2503-gc13223b790bbc5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106905
--- Comment #4 from Hongtao.liu ---
(In reply to Arseny Solokha from comment #2)
> It also can be reproduced for x86_64 when compiling the following testcase,
> reduced from gcc/testsuite/gcc.target/i386/pr103144-mul-2.c, w/
> -march=silvermont -O2 -fvect-cost-model=dynamic:
>
> void
> foo_mul_peel (int *a, int b)
> {
> int i;
>
> for (i = 0; i < 7; ++i)
> {
> b *= 2;
> a[i] = b;
> }
> }
Thanks for the testcase.
I can confirm it's the same issue in #c3
[Bug testsuite/106345] Some ppc64le tests fail with -mcpu=power9 -mtune=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345 --- Comment #11 from CVS Commits --- The releases/gcc-12 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:19e217a2b9d08508203b6e645b67ab63b17af5f8 commit r12-8761-g19e217a2b9d08508203b6e645b67ab63b17af5f8 Author: Kewen Lin Date: Tue Sep 6 20:37:57 2022 -0500 rs6000/test: Fix empty TU in some cases of effective targets [PR106345] As the failure of test case gcc.target/powerpc/pr92398.p9-.c in PR106345 shows, some test sources for some powerpc effective targets use empty translation unit wrongly. The test sources could go with options like "-ansi -pedantic-errors", then those effective target checkings will fail unexpectedly with the error messages like: error: ISO C forbids an empty translation unit [-Wpedantic] This patch is to fix empty TUs with one dummy function definition accordingly. PR testsuite/106345 gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_effective_target_powerpc_sqrt): Add a function definition to avoid pedwarn about empty translation unit. (check_effective_target_has_arch_pwr5): Likewise. (check_effective_target_has_arch_pwr6): Likewise. (check_effective_target_has_arch_pwr7): Likewise. (check_effective_target_has_arch_pwr8): Likewise. (check_effective_target_has_arch_pwr9): Likewise. (check_effective_target_has_arch_pwr10): Likewise. (check_effective_target_has_arch_ppc64): Likewise. (check_effective_target_ppc_float128): Likewise. (check_effective_target_ppc_float128_insns): Likewise. (check_effective_target_powerpc_vsx): Likewise. (cherry picked from commit 7a43e52a48b6403a99d3e8ab3105869b4b3c081e)
[Bug testsuite/106345] Some ppc64le tests fail with -mcpu=power9 -mtune=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:5cb02a5f803d522cfdc8a517ae9afef4d65353f8 commit r11-10253-g5cb02a5f803d522cfdc8a517ae9afef4d65353f8 Author: Kewen Lin Date: Tue Sep 6 20:37:57 2022 -0500 rs6000/test: Fix empty TU in some cases of effective targets [PR106345] As the failure of test case gcc.target/powerpc/pr92398.p9-.c in PR106345 shows, some test sources for some powerpc effective targets use empty translation unit wrongly. The test sources could go with options like "-ansi -pedantic-errors", then those effective target checkings will fail unexpectedly with the error messages like: error: ISO C forbids an empty translation unit [-Wpedantic] This patch is to fix empty TUs with one dummy function definition accordingly. PR testsuite/106345 gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_effective_target_powerpc_sqrt): Add a function definition to avoid pedwarn about empty translation unit. (check_effective_target_has_arch_pwr5): Likewise. (check_effective_target_has_arch_pwr6): Likewise. (check_effective_target_has_arch_pwr7): Likewise. (check_effective_target_has_arch_pwr8): Likewise. (check_effective_target_has_arch_pwr9): Likewise. (check_effective_target_has_arch_pwr10): Likewise. (check_effective_target_has_arch_ppc64): Likewise. (check_effective_target_ppc_float128): Likewise. (check_effective_target_ppc_float128_insns): Likewise. (check_effective_target_powerpc_vsx): Likewise. (cherry picked from commit 7a43e52a48b6403a99d3e8ab3105869b4b3c081e)
[Bug tree-optimization/106909] [13 Regression] error: control flow in the middle of basic block since r13-2541-g78ef801b7263606d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106909 Martin Liška changed: What|Removed |Added Attachment #53563|0 |1 is obsolete|| Attachment #53566|0 |1 is obsolete|| --- Comment #4 from Martin Liška --- Created attachment 53567 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53567&action=edit Reduced test-case
[Bug testsuite/106345] Some ppc64le tests fail with -mcpu=power9 -mtune=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345 --- Comment #13 from CVS Commits --- The releases/gcc-10 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:12d28957b613d8c9b74e7841d73945025a7f0ccb commit r10-10982-g12d28957b613d8c9b74e7841d73945025a7f0ccb Author: Kewen Lin Date: Tue Sep 6 20:37:57 2022 -0500 rs6000/test: Fix empty TU in some cases of effective targets [PR106345] As the failure of test case gcc.target/powerpc/pr92398.p9-.c in PR106345 shows, some test sources for some powerpc effective targets use empty translation unit wrongly. The test sources could go with options like "-ansi -pedantic-errors", then those effective target checkings will fail unexpectedly with the error messages like: error: ISO C forbids an empty translation unit [-Wpedantic] This patch is to fix empty TUs with one dummy function definition accordingly. PR testsuite/106345 gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_effective_target_has_arch_pwr5): Add a function definition to avoid pedwarn about empty translation unit. (check_effective_target_has_arch_pwr6): Likewise. (check_effective_target_has_arch_pwr7): Likewise. (check_effective_target_has_arch_pwr8): Likewise. (check_effective_target_has_arch_pwr9): Likewise. (check_effective_target_has_arch_ppc64): Likewise. (check_effective_target_ppc_float128): Likewise. (check_effective_target_ppc_float128_insns): Likewise. (check_effective_target_powerpc_vsx): Likewise. (cherry picked from commit 7a43e52a48b6403a99d3e8ab3105869b4b3c081e)
[Bug testsuite/106345] Some ppc64le tests fail with -mcpu=power9 -mtune=power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106345 Kewen Lin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Kewen Lin --- Should be fixed everywhere.
[Bug target/106910] roundss not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106910 Richard Biener changed: What|Removed |Added Blocks||53947 CC||crazylht at gmail dot com Target|x86_64 |x86_64-*-* --- Comment #2 from Richard Biener --- Probably missing patterns for V2SFmode here. Hmm, we don't seem to have any vector mode patterns here but possibly rely on ix86_builtin_vectorized_function which indeed doesn't have any V2SFmode support. The vectorizer would go the direct internal fn way for those, querying the floor optab but the x86 backend only has scalar modes supported for the rounding optabs. The backend should modernize itself, get rid of the ix86_builtin_vectorized_function parts for those functions and instead rely on define_expands with vector modes. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/106912] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032 since r13-1575-gcf3a120084e94614
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106912 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|NEW |ASSIGNED Priority|P3 |P1 Target Milestone|--- |13.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Confirmed, we have # .MEM = VDEF <.MEM> vect__5.57_58 = foo.simdclone.0 (vect__4.56_57); here. IIRC I filed a bugreport about simdclones not being const when the scalar version is, in this case it's possibly IPA pure const not updating the clones before materializing them!? That said, the not vectorized variant is just _5 = foo (_4); and without -fprofile-generate the vectorized variant also keeps 'const'. I will look at this again after Cauldron. Have to dig to where the simdclone is actually generated.
[Bug c/106920] New: -Warray-bound false positive regression with -O2 or -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106920
Bug ID: 106920
Summary: -Warray-bound false positive regression with -O2 or
-Os
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: npfhrotynz-ptnqh.myvf at noclue dot notk.org
Target Milestone: ---
Hello,
I think I've run into a false positive on this file:
https://source.codeaurora.org/external/imx/imx-atf/tree/plat/imx/imx8m/hab.c?h=lf_v2.6
I could trim it down to this
#include
typedef void hab_rvt_entry_t(void);
int main() {
hab_rvt_entry_t *a;
a = ((hab_rvt_entry_t *)(*(unsigned long *)(0x908)));
a();
return 0;
}
$ gcc -O2 -Warray-bounds -c t.c
t.c: In function ‘main’:
t.c:7:34: warning: array subscript 0 is outside array bounds of ‘long unsigned
int[0]’ [-Warray-bounds]
7 | a = ((hab_rvt_entry_t *)(*(unsigned long *)(0x908)));
| ~^~
According to godbolt this passed on 11.3 and starts emitting the warning on
12.1 (it doesn't have 12.0) and still emits it on trunk.
Note the warning requires -O2, -O3 or -Os to be emitted.
The problem seems to be that it considers an arbitrary address casted to u64*
to be a u64[0] ?
If so that might be a problem for quite a few embedded products as that is
quite common when dealing with hardware registers.
(and who doesn't love products that compile with -Werror for release builds...)
Thanks!
[Bug rtl-optimization/106913] [13 Regression] ICE in dump_bb_info, at cfg.cc:796 since r13-2263-gf71abacfed170852
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106913 Richard Biener changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |13.0 --- Comment #2 from Richard Biener --- That looks like we fail to clear an auto_bb_flag but verification should also catch that earlier ... huh. Maybe we fail to verify that for ENTRY/EXIT. I have a patch.
[Bug tree-optimization/106914] [13 Regression] ICE in operator[], at vec.h:889 since r13-2288-g61c4c989034548f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106914 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0 Priority|P3 |P1
[Bug target/106919] [13 Regression] RTL check: expected code 'set' or 'clobber', have 'if_then_else' in s390_rtx_costs, at config/s390/s390.cc:3672on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106919 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug c/106920] -Warray-bound false positive regression with -O2 or -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106920 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-13 Blocks||56456 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed, that was an intended change to catch errors with accessing a subobject of an object at nullptr. There's some related duplicate where we discuss workarounds. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug c++/106921] New: [11/12.1] -O1 and -fipa-icf -fpartial-inlining causes wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106921
Bug ID: 106921
Summary: [11/12.1] -O1 and -fipa-icf -fpartial-inlining causes
wrong code
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lutztonineubert at gmail dot com
Target Milestone: ---
Short summary:
The following code returns 1 if compiled with -O2 (which is wrong) and does
return 0 if compiled without optimization.
```
#include
#include
#include
#define GCC_VERSION (__GNUC__ * 1 \
+ __GNUC_MINOR__ * 100 \
+ __GNUC_PATCHLEVEL__)
static_assert(GCC_VERSION == 110300);
template
class bitset {
private:
using word_t = size_t;
static constexpr size_t bits_per_word = sizeof(word_t) * 8;
static constexpr size_t number_of_words = (Bits / bits_per_word) + (((Bits %
bits_per_word) == 0) ? 0 : 1);
public:
bool all_first(size_t n) const {
{
if (n > Bits) {
#ifdef RETURN_INSTEAD_TERMINATE
return false;
#else
std::terminate();
#endif
}
size_t i = 0;
for (; n > bits_per_word; n -= bits_per_word, i++) {
if (words_[i] != ~word_t{0}) {
return false;
}
}
word_t last_word = words_[i];
for (; n != 0; n--) {
if ((last_word & 1) != 1) {
return false;
}
last_word >>= 1;
}
return true;
}
}
void fill() noexcept {
for (auto& word : words_) {
word = ~word_t{0};
}
}
private:
std::array words_{};
};
volatile int X = 0;
int main() {
if (X == 1) {
bitset<123> bitset;
static_cast(bitset.all_first(123));
} else {
bitset<256> bitset;
bitset.fill();
if (!bitset.all_first(255)) {
return 1;
}
}
return 0;
}
```
See: https://gcc.godbolt.org/z/bEexjrKP4
This issue does not exist in GCC 10 or GCC > 12.1. I couldn't test if it does
work in GCC 11.3.1 (or the trunk of it).
Additional:
* I could also trigger the issue with -O1 -fipa-icf -fpartial-inlining
* If we do a return false instead of a std::terminate, no wrong code is
generated.
I am sorry, but I couldn't reduced the code any further - this already took so
much time to figure out it is a compiler bug.
[Bug tree-optimization/106909] [13 Regression] error: control flow in the middle of basic block since r13-2541-g78ef801b7263606d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106909 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Richard Biener --- [local count: 1073741824]: _80 = SR.96_116(D); # DEBUG this => SR.96_116(D) # DEBUG firstElement => ptrCopy_79(D) # DEBUG elementCount => sizeCopy_83(D) # DEBUG capacity => sizeCopy_83(D) # DEBUG INLINE_ENTRY dispose # DEBUG firstElement => ptrCopy_79(D) # DEBUG elementCount => sizeCopy_83(D) # DEBUG capacity => sizeCopy_83(D) # DEBUG disposer => SR.96_116(D) # DEBUG INLINE_ENTRY dispose _81 = MEM[(const struct ArrayDisposer *)SR.96_116(D)]._vptr.ArrayDisposer; _82 = *_81; __builtin_unreachable (); # DEBUG firstElement => NULL # DEBUG elementCount => NULL # DEBUG capacity => NULL # DEBUG disposer => NULL # DEBUG this => NULL # DEBUG firstElement => NULL # DEBUG elementCount => NULL # DEBUG capacity => NULL after some folding. I fear this is the general gimple_build_builtin_unreachable which is now generally used but esp. folding should _not_ mark the call as control altering but leave that to CFG fixup (CFG cleanup doesn't catch this since it only looks at the last stmt of BBs). I'm fixing up in the use.
