[Bug tree-optimization/114246] [11/12/13/14 Regression] ICE: verify_gimple failed: invalid argument to gimple call with __builtin_memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114246 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 --- Mine.
[Bug lto/114241] False-positive -Wodr warning when using -flto and -fno-semantic-interposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114241 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||13.2.1 Last reconfirmed||2024-03-06 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed also with GCC 13. I guess we're optimizing things in a strange (invalid) way before WPA and get confused because of that. Honza?
[Bug tree-optimization/114251] New: [14 regression] ICE when building python-3.12.2's Hacl_Hash_SHA2.c (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114251 Bug ID: 114251 Summary: [14 regression] ICE when building python-3.12.2's Hacl_Hash_SHA2.c (tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- Created attachment 57625 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57625=edit Hacl_Hash_SHA2.i ``` $ gcc -c Hacl_Hash_SHA2.i -O2 -march=znver2 -fprofile-generate during GIMPLE pass: slp ./Modules/_hacl/Hacl_Hash_SHA2.c: In function ‘sha512_update’: ./Modules/_hacl/Hacl_Hash_SHA2.c:269:24: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 0x55e2e7432cd4 tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/tree.cc:9005 0x55e2e65ba852 tree_class_check(tree_node*, tree_code_class, char const*, int, char const*) /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/tree.h:3767 0x55e2e65ba852 useless_type_conversion_p(tree_node*, tree_node*) /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/gimple-expr.cc:85 0x55e2e7e82a8e verify_gimple_assign_binary /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/tree-cfg.cc:4305 0x55e2e7e2bf9b verify_gimple_in_cfg(function*, bool, bool) /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/tree-cfg.cc:5599 0x55e2e7ca5a38 execute_function_todo /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2088 0x55e2e7ca5a38 do_per_function /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:1687 0x55e2e7ca5a38 execute_todo /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2142 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions. ``` ``` Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-14.0./work/gcc-14.0./configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python --enable-languages=c,c++,fortran,rust --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 14.0. p, commit c8305c9bdf09abe3e2f89783fe62f2e4049468fa' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=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 --disable-cet --disable-systemtap --enable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --with-isl --disable-isl-version-check --enable-default-pie --enable-host-pie --enable-host-bind-now --enable-default-ssp --disable-fixincludes --with-build-config='bootstrap-O3 bootstrap-lto' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240305 (experimental) 8776468d9e57ace5f832c1368243a6dbce9984d5 (Gentoo Hardened 14.0. p, commit c8305c9bdf09abe3e2f89783fe62f2e4049468fa) ```
[Bug tree-optimization/114250] [14 regression] ICE when building glslang-1.3.275 (error: invalid types in nop conversion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114250 Sam James changed: What|Removed |Added Attachment #57623|0 |1 is obsolete|| --- Comment #2 from Sam James --- Created attachment 57624 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57624=edit reduced.ii
[Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since r14-9193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #11 from Richard Biener ---
(In reply to Richard Biener from comment #10)
> (In reply to Andrew Macleod from comment #9)
> > Created attachment 57620 [details]
> > proposed patch
> >
> > Does this solve your problem if there is an active ranger? it bootstraps
> > with no regressions
>
> I'll check what it does.
So it does seem to help, not on the testcases ultimate outcome, but for the
important bits of the analysis. With adding an active ranger around IVOPTs
with
diff --git a/gcc/tree-ssa-loop-ivopts.cc b/gcc/tree-ssa-loop-ivopts.cc
index 7cae5bdefea..626fc5bf5d7 100644
--- a/gcc/tree-ssa-loop-ivopts.cc
+++ b/gcc/tree-ssa-loop-ivopts.cc
@@ -132,6 +132,7 @@ along with GCC; see the file COPYING3. If not see
#include "tree-vectorizer.h"
#include "dbgcnt.h"
#include "cfganal.h"
+#include "gimple-range.h"
/* For lang_hooks.types.type_for_mode. */
#include "langhooks.h"
@@ -8280,6 +8281,8 @@ tree_ssa_iv_optimize (void)
tree_ssa_iv_optimize_init ();
mark_ssa_maybe_undefs ();
+ enable_ranger (cfun);
+
/* Optimize the loops starting with the innermost ones. */
for (auto loop : loops_list (cfun, LI_FROM_INNERMOST))
{
@@ -8292,6 +8295,8 @@ tree_ssa_iv_optimize (void)
tree_ssa_iv_optimize_loop (, loop, toremove);
}
+ disable_ranger (cfun);
+
/* Remove eliminated IV defs. */
release_defs_bitset (toremove);
I then see the following difference with a ranger-debug dump during IVOPTs:
11 range_of_expr(_12)
- TRUE : (11) range_of_expr (_12) [irange] int VARYING
+ TRUE : (11) range_of_expr (_12) [irange] int [0, +INF]
...
Base:(long unsigned int) (int) ((unsigned int) _12 + 1) * 2
Step:2
Biv: N
- Overflowness wrto loop niter:Overflow
+ Overflowness wrto loop niter:No-overflow
...
-74 range_of_expr(_103)
- TRUE : (74) range_of_expr (_103) [irange] int VARYING
+64 range_of_expr(_103)
+ TRUE : (64) range_of_expr (_103) [irange] int [-INF, 0]
Analyzing # of iterations of loop 1
exit condition [1, + , 1](no_overflow) <= _103
- bounds on difference of bases: -2147483649 ... 2147483646
+ bounds on difference of bases: -2147483649 ... -1
result:
zero if _103 < 0
-# of iterations (unsigned int) _103, bounded by 2147483647
+# of iterations (unsigned int) _103, bounded by 0
So the important part is that it got the fact that _12 is positive. As
analyzed in earlier comments I think that's all we can do, we don't know
anything about the other variable involved and thus can't avoid the
unsigned punning during SCEV analysis.
I think it's a good change, let's keep it queued for stage1 at this point
unless we really know a case it helps to avoid a regression with
r14-9193-ga0b1798042d033
For testing, what's the "easiest" pass/thing to do to recompute global
ranges now? In the past I'd schedule EVRP but is there now a ranger
API to do this? Just to see if full global range compute before IVOPTs
would help.
[Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since r14-9193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151 --- Comment #10 from Richard Biener --- (In reply to Andrew Macleod from comment #9) > Created attachment 57620 [details] > proposed patch > > Does this solve your problem if there is an active ranger? it bootstraps > with no regressions I'll check what it does. > ITs pretty minimal, and basically we invokes the cache's version of > range_of_expr if there is no context. I tweaked it such that if there is > no context, and the def has not been calculated yet, it calls range_of_def, > and combines it with any SSA_NAME_RANGE_INFO that may have pre-existed. All > without invoking any new lookups. > > This seems relatively harmless and does not spawn new dynamic lookups. As > long as it resolves your issue... If it still does not work, and we > require the def to actually be evaluated, I will look into that. we prpbably > should do that anyway. There appears to be a cycle when this is invoked > from the loop analysis, probably because folding of PHIs uses loop info... > and back and forth we go. Yeah, I ran into this as well. > I'd probably need to add a flag to the ranger > instantiation to tell it to avoid using loop info. I've quickly tried to detect active discovery in SCEV but it wasn't as easy as I thought. > Are we looking to fix this in this release? I think the full evaluation has to wait for stage1 because of that recursion issue. I'm also sure we're going to need ways to _not_ do this, so maybe a clearer separation in the API is warranted. As I see it when you call range_of_expr without context you get the same result as if using the global range query so maybe it should be a different API from the start (the one that is now without context) and range_of_expr without context using a conservative default (the definition point).
[Bug tree-optimization/114250] [14 regression] ICE when building glslang-1.3.275 (error: invalid types in nop conversion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114250 --- Comment #1 from Sam James --- Created attachment 57623 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57623=edit reduced.ii
[Bug c++/114245] Defaulted virtual destructors that do no work overwrite the vtable with `-O0`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114245 --- Comment #2 from Andrew Pinski --- I am trying to understand the issue of having the vtable writing to the object. Is the issue you have an order issue where an object is destroyed but still in use else where, that sounds like an undefined behavior in your code. >you easily run into static de-init fiasco issues Yes this sounds like you are runing into what I have described as being undefined behavior. Changing GCC here just works around the broken code which I doubt is a good idea. If you need a specific order, across TUs, well C++ does not define them. GCC does have an init_priority attribute which could be used here to fix the issue as earlier initializations are deconstructed later.
[Bug c++/114245] Defaulted virtual destructors that do no work overwrite the vtable with `-O0`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114245 --- Comment #1 from Andrew Pinski --- Created attachment 57622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57622=edit Full testcase Next time please attach or paste inline the full testcase rather than just linking to godbolt.
[Bug tree-optimization/114246] [11/12/13/14 Regression] ICE: verify_gimple failed: invalid argument to gimple call with __builtin_memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114246 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #2 from Andrew Pinski --- GCC 9's dse got it correct: ``` __builtin_memcpy ([(void *) + 1B], , 1); ```
[Bug tree-optimization/114246] [11/12/13/14 Regression] ICE: verify_gimple failed: invalid argument to gimple call with __builtin_memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114246
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-03-06
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed. we start out with:
```
__builtin_memcpy (, [(void *) + -1B], 2);
_4 = MEM[(char * {ref-all})];
MEM[(char * {ref-all})] = _4;
```
And DSE converts it into:
```
__builtin_memcpy ( [(void *) + 1B], (char *) , 1);
_4 = MEM[(char * {ref-all})];
MEM[(char * {ref-all})] = _4;
```
[Bug tree-optimization/114246] [11/12/13/14 Regression] ICE: verify_gimple failed: invalid argument to gimple call with __builtin_memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114246 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.5 CC||pinskia at gcc dot gnu.org
[Bug tree-optimization/114250] New: [14 regression] ICE when building glslang-1.3.275 (error: invalid types in nop conversion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114250 Bug ID: 114250 Summary: [14 regression] ICE when building glslang-1.3.275 (error: invalid types in nop conversion) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- Created attachment 57621 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57621=edit disassemble.ii.xz Not sure if this is a dupe of PR114249 but I figured I'd file it for the testcase if nothing else. ``` $ gcc -c /var/tmp/portage/dev-util/glslang-1.3.275/work/glslang-vulkan-sdk-1.3.275.0/SPIRV/disassemble.cpp -O3 -fno-semantic-interposition -march=znver2 /var/tmp/portage/dev-util/glslang-1.3.275/work/glslang-vulkan-sdk-1.3.275.0/SPIRV/disassemble.cpp: In member function ‘void spv::SpirvStream::disassembleInstruction(spv::Id, spv::Id, spv::Op, int)’: /var/tmp/portage/dev-util/glslang-1.3.275/work/glslang-vulkan-sdk-1.3.275.0/SPIRV/disassemble.cpp:340:6: error: invalid types in nop conversion 340 | void SpirvStream::disassembleInstruction(Id resultId, Id /*typeId*/, Op opCode, int numOperands) | ^~~ unsigned long <<< error >>> _1800 = (unsigned long) _1973; during GIMPLE pass: slp /var/tmp/portage/dev-util/glslang-1.3.275/work/glslang-vulkan-sdk-1.3.275.0/SPIRV/disassemble.cpp:340:6: internal compiler error: verify_gimple failed 0x5611a3ee60b8 verify_gimple_in_cfg(function*, bool, bool) /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/tree-cfg.cc:5663 0x5611a562cd44 execute_function_todo /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2088 0x5611a562cd44 do_per_function /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:1687 0x5611a562cd44 execute_todo /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2142 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions. ``` ``` Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-14.0./work/gcc-14.0./configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python --enable-languages=c,c++,fortran,rust --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 14.0. p, commit c8305c9bdf09abe3e2f89783fe62f2e4049468fa' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=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 --disable-cet --disable-systemtap --enable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --with-isl --disable-isl-version-check --enable-default-pie --enable-host-pie --enable-host-bind-now --enable-default-ssp --disable-fixincludes --with-build-config='bootstrap-O3 bootstrap-lto' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240305 (experimental) 8776468d9e57ace5f832c1368243a6dbce9984d5 (Gentoo Hardened 14.0. p, commit c8305c9bdf09abe3e2f89783fe62f2e4049468fa) ```
[Bug libfortran/105456] Child I/O does not propage iostat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456 --- Comment #6 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:21edfb0051ed8d0ff46d5638c2bce2dd71f26d1f commit r14-9328-g21edfb0051ed8d0ff46d5638c2bce2dd71f26d1f Author: Jerry DeLisle Date: Tue Mar 5 20:49:23 2024 -0800 Fortran: Add user defined error messages for UDTIO. The defines IOMSG_LEN and MSGLEN were redundant so these are combined into IOMSG_LEN as defined in io.h. The remainder of the patch adds checks for when a user defined derived type IO procedure sets the IOSTAT or IOMSG variables independent of the librrary defined I/O messages. PR libfortran/105456 libgfortran/ChangeLog: * io/io.h (IOMSG_LEN): Moved to here. * io/list_read.c (MSGLEN): Removed MSGLEN. (convert_integer): Changed MSGLEN to IOMSG_LEN. (parse_repeat): Likewise. (read_logical): Likewise. (read_integer): Likewise. (read_character): Likewise. (parse_real): Likewise. (read_complex): Likewise. (read_real): Likewise. (check_type): Likewise. (list_formatted_read_scalar): Adjust to IOMSG_LEN. (nml_read_obj): Add user defined error message. * io/transfer.c (unformatted_read): Add user defined error message. (unformatted_write): Add user defined error message. (formatted_transfer_scalar_read): Add user defined error message. (formatted_transfer_scalar_write): Add user defined error message. * io/write.c (list_formatted_write_scalar): Add user defined error message. (nml_write_obj): Add user defined error message. gcc/testsuite/ChangeLog: * gfortran.dg/pr105456-nmlr.f90: New test. * gfortran.dg/pr105456-nmlw.f90: New test. * gfortran.dg/pr105456-ruf.f90: New test. * gfortran.dg/pr105456-wf.f90: New test. * gfortran.dg/pr105456-wuf.f90: New test.
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #13 from Jerry DeLisle --- Any luck getting a reduced case?
[Bug tree-optimization/114249] [14 regression] ICE when building lvm2-2.03.22 (error: invalid types in nop conversion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114249 --- Comment #4 from Sam James --- my guess is r14-9316-g7890836de20912
[Bug tree-optimization/114151] [14 Regression] weird and inefficient codegen and addressing modes since r14-9193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151 --- Comment #9 from Andrew Macleod --- Created attachment 57620 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57620=edit proposed patch Does this solve your problem if there is an active ranger? it bootstraps with no regressions ITs pretty minimal, and basically we invokes the cache's version of range_of_expr if there is no context. I tweaked it such that if there is no context, and the def has not been calculated yet, it calls range_of_def, and combines it with any SSA_NAME_RANGE_INFO that may have pre-existed. All without invoking any new lookups. This seems relatively harmless and does not spawn new dynamic lookups. As long as it resolves your issue... If it still does not work, and we require the def to actually be evaluated, I will look into that. we prpbably should do that anyway. There appears to be a cycle when this is invoked from the loop analysis, probably because folding of PHIs uses loop info... and back and forth we go.I'd probably need to add a flag to the ranger instantiation to tell it to avoid using loop info. Are we looking to fix this in this release?
[Bug fortran/108680] Wrong DTIO arguments with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-06 Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 CC||jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- Taking a quick look at this one. Yes it handles -fdefault-integer-8 incorrectly. I agree with Steve in that this is not a Standard Fortran feature. The right way to allow changing kinds is to use a parameter defined with for example select_integer_kind in a module or something and have that parameter used everywhere. Obviously not conveniant. Regardless even if one declares integer 8 everywhere, the vlist is screwed up. Adding to my list.
[Bug tree-optimization/114249] [14 regression] ICE when building lvm2-2.03.22 (error: invalid types in nop conversion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114249 --- Comment #3 from Andrew Pinski --- This is a very recent failure since g:264e3ad419cf71b10e7951a23750ac3507e21df9 worked .
[Bug tree-optimization/114249] [14 regression] ICE when building lvm2-2.03.22 (error: invalid types in nop conversion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114249
--- Comment #2 from Sam James ---
Reduced:
```
enum { SEG_THIN_POOL } read_only;
struct {
unsigned skip_block_zeroing;
unsigned ignore_discard;
unsigned no_discard_passdown;
unsigned error_if_no_space;
} _thin_pool_emit_segment_line_seg;
void dm_snprintf();
void _emit_segment() {
int features =
(_thin_pool_emit_segment_line_seg.error_if_no_space ? 1 : 0) +
(read_only ? 1 : 0) +
(_thin_pool_emit_segment_line_seg.ignore_discard ? 1 : 0) +
(_thin_pool_emit_segment_line_seg.no_discard_passdown ? 1 : 0) +
(_thin_pool_emit_segment_line_seg.skip_block_zeroing ? 1 : 0);
dm_snprintf(features);
}
```
[Bug fortran/109105] Error-prone format string building in resolve.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109105 Jerry DeLisle changed: What|Removed |Added Status|WAITING |NEW Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle --- So I don't lose it.
[Bug target/93802] gcc generates a rlwinm/or pair instead of a single rlwimi (powerpc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93802 HaoChen Gui changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||guihaoc at gcc dot gnu.org --- Comment #2 from HaoChen Gui --- It's already fixed by f4a3cea3fb02. Now it generates a single rlwimi. rlwimi 3,3,16,0,31-16
[Bug libfortran/105361] Incorrect end-of-file condition for derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle --- Triaging the list of 1300 gforran bugs and spotted this one, so getting on my list. (Especially since I have been buried in the related code).
[Bug libfortran/106295] INQUIRE statement bus error at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106295 Jerry DeLisle changed: What|Removed |Added Resolution|--- |INVALID CC||jvdelisle at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #5 from Jerry DeLisle --- I think this should be closed. Dont mix libraries.
[Bug libstdc++/77776] C++17 std::hypot implementation is poor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #19 from g.peterh...@t-online.de ---
> So, no need to use frexp/ldexp, just comparisons of hi above against sqrt of
> (max finite / 3), in that case scale by multiplying all 3 args by some
> appropriate scale constant, and similarly otherwise if lo1 is too small by
> some large scale.
I don't really know. With frexp/ldexp you probably get the highest accuracy
(even if it is probably slower) instead of doing it manually. The problem is to
determine suitable scaling factors and to adjust the (return)values
accordingly. I have implemented both cases.
Error
* In the case (x==y && y==z), x*std::sqrt(T(3)) must not simply be returned, as
this can lead to an overflow (inf).
Generally
* Instead of using fmin/fmax to determine the values hi,lo1,lo0, it is better
to sort x,y,z. This is faster and clearer and no additional variables need to
be introduced.
* It also makes sense to consider the case (x==0 && y==0 && z==0).
Optimizations
* You were probably wondering why I wrote "if (std::isinf(x) | std::isinf(y) |
std::isinf(z))", for example. This is intentional. The problem is that gcc
almost always produces branch code for logical operations, so *a lot* of
conditional jumps. By using arithmetic operations, so instead of || && just |
&, I can get it to generate only actually necessary conditional jumps or
cmoves. branchfree code is always better.
template
constexpr T hypot3_exp(T x, T y, T z) noexcept
{
using limits = std::numeric_limits;
constexpr T
zero = 0;
x = std::abs(x);
y = std::abs(y);
z = std::abs(z);
if (std::isinf(x) | std::isinf(y) | std::isinf(z)) [[unlikely]]
return limits::infinity();
if (std::isnan(x) | std::isnan(y) | std::isnan(z)) [[unlikely]]
return limits::quiet_NaN();
if ((x==zero) & (y==zero) & (z==zero)) [[unlikely]]
return zero;
if ((y==zero) & (z==zero)) [[unlikely]]
return x;
if ((x==zero) & (z==zero)) [[unlikely]]
return y;
if ((x==zero) & (y==zero)) [[unlikely]]
return z;
auto sort = [](T& a, T& b, T& c)constexpr noexcept -> void
{
if (a > b) std::swap(a, b);
if (b > c) std::swap(b, c);
if (a > b) std::swap(a, b);
};
sort(x, y, z); // x <= y <= z
int
exp = 0;
z = std::frexp(z, );
y = std::ldexp(y, -exp);
x = std::ldexp(x, -exp);
T
sum = x*x + y*y;
sum += z*z;
return std::ldexp(std::sqrt(sum), exp);
}
template
constexpr T hypot3_scale(T x, T y, T z) noexcept
{
using limits = std::numeric_limits;
auto prev_power2 = [](const T value)constexpr noexcept -> T
{
return std::exp2(std::floor(std::log2(value)));
};
constexpr T
sqrtmax = std::sqrt(limits::max()),
scale_up= prev_power2(sqrtmax),
scale_down = T(1) / scale_up,
zero= 0;
x = std::abs(x);
y = std::abs(y);
z = std::abs(z);
if (std::isinf(x) | std::isinf(y) | std::isinf(z)) [[unlikely]]
return limits::infinity();
if (std::isnan(x) | std::isnan(y) | std::isnan(z)) [[unlikely]]
return limits::quiet_NaN();
if ((x==zero) & (y==zero) & (z==zero)) [[unlikely]]
return zero;
if ((y==zero) & (z==zero)) [[unlikely]]
return x;
if ((x==zero) & (z==zero)) [[unlikely]]
return y;
if ((x==zero) & (y==zero)) [[unlikely]]
return z;
auto sort = [](T& a, T& b, T& c)constexpr noexcept -> void
{
if (a > b) std::swap(a, b);
if (b > c) std::swap(b, c);
if (a > b) std::swap(a, b);
};
sort(x, y, z); // x <= y <= z
const T
scale = (z > sqrtmax) ? scale_down : (z < 1) ? scale_up : 1;
x *= scale;
y *= scale;
z *= scale;
T
sum = x*x + y*y;
sum += z*z;
return std::sqrt(sum) / scale;
}
regards
Gero
[Bug tree-optimization/114249] [14 regression] ICE when building lvm2-2.03.22 (error: invalid types in nop conversion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114249 --- Comment #1 from Andrew Pinski --- I think the different functions are due to inlining differences between -O2 and -O3 and the ICE is due to code in _load_node as dm_tree_preload_children calls _load_node .
[Bug tree-optimization/114249] [14 regression] ICE when building lvm2-2.03.22 (error: invalid types in nop conversion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114249 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||ice-on-valid-code CC||pinskia at gcc dot gnu.org
[Bug libfortran/93727] Fortran 2018: EX edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Severity|enhancement |normal CC||jvdelisle at gcc dot gnu.org
[Bug tree-optimization/114249] New: [14 regression] ICE when building lvm2-2.03.22 (error: invalid types in nop conversion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114249 Bug ID: 114249 Summary: [14 regression] ICE when building lvm2-2.03.22 (error: invalid types in nop conversion) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- Created attachment 57619 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57619=edit libdm-deptree.i.xz It ICEs on two different functions with -O2 vs -O3. ``` $ gcc -c ./libdm-deptree.i -O2 libdm-deptree.c: In function ‘dm_tree_preload_children’: libdm-deptree.c:2894:5: error: invalid types in nop conversion 2894 | int dm_tree_preload_children(struct dm_tree_node *dnode, | ^~~~ unsigned int <<< error >>> _890 = (unsigned int) _1319; during GIMPLE pass: slp libdm-deptree.c:2894:5: internal compiler error: verify_gimple failed 0x559de62d4070 verify_gimple_in_cfg(function*, bool, bool) /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/tree-cfg.cc:5663 0x559de784ba38 execute_function_todo /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2088 0x559de784ba38 do_per_function /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:1687 0x559de784ba38 execute_todo /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2142 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions. ``` ``` $ gcc -c ./libdm-deptree.i -O3 libdm-deptree.c: In function ‘_load_node’: libdm-deptree.c:2774:12: error: invalid types in nop conversion 2774 | static int _load_node(struct dm_tree_node *dnode) |^~ unsigned int <<< error >>> _1341 = (unsigned int) _1452; during GIMPLE pass: slp libdm-deptree.c:2774:12: internal compiler error: verify_gimple failed 0x5568ddc14070 verify_gimple_in_cfg(function*, bool, bool) /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/tree-cfg.cc:5663 0x5568df18ba38 execute_function_todo /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2088 0x5568df18ba38 do_per_function /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:1687 0x5568df18ba38 execute_todo /usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2142 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://bugs.gentoo.org/> for instructions. ``` ``` Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-14.0./work/gcc-14.0./configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python --enable-languages=c,c++,fortran,rust --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 14.0. p, commit c8305c9bdf09abe3e2f89783fe62f2e4049468fa' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=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 --disable-cet --disable-systemtap --enable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --with-isl --disable-isl-version-check --enable-default-pie --enable-host-pie --enable-host-bind-now --enable-default-ssp --disable-fixincludes --with-build-config='bootstrap-O3 bootstrap-lto' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240305 (experimental) 8776468d9e57ace5f832c1368243a6dbce9984d5 (Gentoo Hardened 14.0. p, commit c8305c9bdf09abe3e2f89783fe62f2e4049468fa) ```
[Bug ipa/114215] -Os or -Oz inlining seems wrong for vague linkage functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114215 --- Comment #8 from cqwrteur --- (In reply to Andrew Pinski from comment #5) > Still waiting on a full application rather then small benchmark type > sources. The heurstic here is that if you call operator[] multiple times, it > might be better not to inline it for size reasons. llvm actually makes different decision here. Probably GCC thinks __builtin_trap is expensive despite it is not.
[Bug c++/104113] invalid template argument causes the type to become int which confuses the rest of the diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104113 Andrew Pinski changed: What|Removed |Added CC||f.heckenb...@fh-soft.de --- Comment #10 from Andrew Pinski --- *** Bug 114248 has been marked as a duplicate of this bug. ***
[Bug c++/114248] invalid "scalar object" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114248 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup *** This bug has been marked as a duplicate of bug 104113 ***
[Bug c++/114248] invalid "scalar object" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114248 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Andrew Pinski --- There are a few other diagnostic bugs like this one. Basically the front end is setting the type of the bad decl to int after an error instead of treating as a bad object. Iirc this is done before the gcc/front end had a notion of an error mark node.
[Bug c++/114248] New: invalid "scalar object" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114248
Bug ID: 114248
Summary: invalid "scalar object" error
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: f.heckenb...@fh-soft.de
Target Milestone: ---
% cat test.cpp
// #pragma GCC diagnostic ignored "-Wnarrowing"
// #pragma GCC diagnostic warning "-Wnarrowing"
template struct S
{
S (int, int) { }
};
// template <> using S <-1> = int;
int main ()
{
S <-1> i { 1, 2 };
}
% g++ test.cpp
test.cpp: In function 'int main()':
test.cpp:13:8: error: narrowing conversion of '-1' from 'int' to 'unsigned int'
[-Wnarrowing]
13 | S <-1> i { 1, 2 };
|^
test.cpp:13:10: error: scalar object 'i' requires one element in initializer
13 | S <-1> i { 1, 2 };
| ^
The first error is correct, of course, but the second one is not because "i" is
not scalar.
Sure, the declaration of "i" is wrong, but this leaves two possible
conclusions:
- We don't know what "i" is meant to be, so any claim about it is unjustified.
- We see that the type of "i" is meant to be an instance of S which is a
struct, and not scalar. AFAIK, even potential specializations of S cannot
change this fact (cf. the commented-out line which is doubly wrong).
Interestingly, when turning the first error off or into a warning (cf. one of
the commented-out pragmas), the second error disappears as well.
I would have expected that those options/pragmas merely control if the
narrowing problem is reported, and if so, whether it causes the compilation to
fail, but apparently it does influence gcc's representation of "i" afterwards
as well.
But that's just a side note actually -- even with a clearly wrong declaration
of "i" such as
S <""> i { 1, 2 };
gcc gives the "scalar" error which it shouldn't.
[Bug sanitizer/97696] ICE since ASAN_MARK does not handle poly_int sized varibales
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97696 --- Comment #5 from Rama Malladi --- Thank you Richard for this patch/ fix.
[Bug debug/114186] Incorrect CTF generated for multidimensional array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114186 --- Comment #2 from GCC Commits --- The master branch has been updated by Indu Bhagat : https://gcc.gnu.org/g:5d24bf3afd1bea3e51b87fb7ff24c21e29913999 commit r14-9325-g5d24bf3afd1bea3e51b87fb7ff24c21e29913999 Author: Cupertino Miranda Date: Thu Feb 29 10:56:13 2024 -0800 ctf: fix incorrect CTF for multi-dimensional array types PR debug/114186 DWARF DIEs of type DW_TAG_subrange_type are linked together to represent the information about the subsequent dimensions. The CTF processing was so far working through them in the opposite (incorrect) order. While fixing the issue, refactor the code a bit for readability. co-authored-By: Indu Bhagat gcc/ PR debug/114186 * dwarf2ctf.cc (gen_ctf_array_type): Invoke the ctf_add_array () in the correct order of the dimensions. (gen_ctf_subrange_type): Refactor out handling of DW_TAG_subrange_type DIE to here. gcc/testsuite/ PR debug/114186 * gcc.dg/debug/ctf/ctf-array-6.c: Add test.
[Bug ipa/114247] RISC-V: miscompile at -O3 and IPA SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||ABI
Last reconfirmed||2024-03-05
Component|target |ipa
Ever confirmed|0 |1
Summary|RISC-V: miscompile at -O3 |RISC-V: miscompile at -O3
||and IPA SRA
--- Comment #1 from Andrew Pinski ---
I think this is an IPA SRA issue.
The IR looks like:
j.constprop.isra (65535);
That is wrong for signed short ...
If I try manually I get:
j12 (-1);
```
void j.constprop.isra (short int ISRA.10)
{
...
}
```
IS there another target where the upper bits of the register are defined?
[Bug c++/110323] [11/12/13/14 Regression] Code for explicit instantiation of template method of template class not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110323 --- Comment #5 from Marek Polacek --- VAL is constexpr, which implies const, which in the global scope implies static. Then constrain_visibility_for_template makes "struct conditional<(B == VAL), int, float>" non-TREE_PUBLIC. So with extern constexpr int VAL = 1; the test works again.
[Bug target/114247] New: RISC-V: miscompile at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114247
Bug ID: 114247
Summary: RISC-V: miscompile at -O3
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick at rivosinc dot com
Target Milestone: ---
Testcase:
int printf(const char *, ...);
union a {
unsigned short b;
int c;
signed short d;
};
int e, f = 1, g;
long h;
const int **i;
void j(union a k, int l, unsigned m) {
const int *a[100];
i = [0];
h = k.d;
}
static int o(union a k) {
k.d = -1;
while (1)
if (f)
break;
j(k, g, e);
return 0;
}
int main() {
union a n = {1};
o(n);
printf("dec: %ld\n", h);
printf("hex: %lX\n", h);
}
Commands:
> riscv64-unknown-linux-gnu-gcc -O3 red.c -o red.out -fno-strict-aliasing
> -fwrapv -fno-aggressive-loop-optimizations
> qemu-riscv64 red.out
dec: 65535
hex:
> riscv64-unknown-linux-gnu-gcc -O2 red.c -o red.out -fno-strict-aliasing
> -fwrapv -fno-aggressive-loop-optimizations
> qemu-riscv64 red.out
dec: -1
hex:
This testcase looks very suspect but AFAICT it doesn't contain any UB.
Found via fuzzer
[Bug c++/110323] [11/12/13/14 Regression] Code for explicit instantiation of template method of template class not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110323 --- Comment #4 from Marek Polacek --- Ah -- if we walk into TYPE_CONTEXT (t) (here: struct conditional), then in min_vis_r we determine the visibility as VISIBILITY_ANON. Without it, it remains VISIBILITY_DEFAULT.
[Bug c++/110323] [11/12/13/14 Regression] Code for explicit instantiation of template method of template class not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110323 --- Comment #3 from Marek Polacek --- This makes a difference for some reason: --- a/gcc/cp/tree.cc +++ b/gcc/cp/tree.cc @@ -5542,7 +5542,7 @@ cp_walk_subtrees (tree *tp, int *walk_subtrees_p, walk_tree_fn func, break; case TYPENAME_TYPE: - WALK_SUBTREE (TYPE_CONTEXT (t)); + //WALK_SUBTREE (TYPE_CONTEXT (t)); WALK_SUBTREE (TYPENAME_TYPE_FULLNAME (t)); *walk_subtrees_p = 0; break;
[Bug libstdc++/114244] Need to use round when parsing fractional seconds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2024-03-05
[Bug c++/110323] [11/12/13/14 Regression] Code for explicit instantiation of template method of template class not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110323
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek ---
Started with r11-291-g0f50f6daa14018:
commit 0f50f6daa140186a048cbf33f54f4591eabf5f12
Author: Jason Merrill
Date: Mon May 11 15:46:59 2020 -0400
c++: tree walk into TYPENAME_TYPE.
```
template
struct conditional { using type = T; };
template
struct conditional { using type = F; };
constexpr int VAL = 1;
struct foo {
template
void bar(typename conditional::type arg) {
}
};
template void foo::bar<1>(int arg);
```
[Bug rtl-optimization/114243] [avr] -fsplit-wide-types bloats code by more than 50%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114243 --- Comment #2 from Andrew Pinski --- Subreg improvements to ra is planned for gcc 15 as the riscv folks are running into it for vector modes in some cases. Maybe that will improves the situation here.
[Bug target/81473] [avr] build fails due to INT8_MIN and friends.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81473 --- Comment #4 from Georg-Johann Lay --- This was fixed long ago.
[Bug rtl-optimization/114243] [avr] -fsplit-wide-types bloats code by more than 50%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114243 --- Comment #1 from Georg-Johann Lay --- May be related to PR110093. As Vladimir noted in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110093#c5 the problem is that data flow analysis cannot cope with the subregs generated from lower-subregs, and register alloc chokes at it.
[Bug c++/114229] [modules] duplicate vtable symbols when including stl in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114229 --- Comment #3 from Patrick Palka --- In the reduced testcase the vtable for basic_streambuf should get emitted only from 114229_d but it seems to get emitted from 114229_b too.
[Bug tree-optimization/114246] New: [11/12/13/14 Regression] ICE: verify_gimple failed: invalid argument to gimple call with __builtin_memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114246 Bug ID: 114246 Summary: [11/12/13/14 Regression] ICE: verify_gimple failed: invalid argument to gimple call with __builtin_memcpy() Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 57618 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57618=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O testcase.c testcase.c: In function 'foo': testcase.c:8:1: error: invalid argument to gimple call 8 | } | ^ (char *) # .MEM_3 = VDEF <.MEM_2(D)> __builtin_memcpy ( [(void *) + 1B], (char *) , 1); during GIMPLE pass: dse testcase.c:8:1: internal compiler error: verify_gimple failed 0x155f0bd verify_gimple_in_cfg(function*, bool, bool) /repo/gcc-trunk/gcc/tree-cfg.cc:5663 0x13cde04 execute_function_todo /repo/gcc-trunk/gcc/passes.cc:2088 0x13ce35e execute_todo /repo/gcc-trunk/gcc/passes.cc:2142 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9323-20240305175124-g8776468d9e5-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-9323-20240305175124-g8776468d9e5-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.1 20240305 (experimental) (GCC)
[Bug c++/114245] New: Defaulted virtual destructors that do no work overwrite the vtable with `-O0`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114245
Bug ID: 114245
Summary: Defaulted virtual destructors that do no work
overwrite the vtable with `-O0`
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mwinkler at blizzard dot com
Target Milestone: ---
https://godbolt.org/z/Ge135h6qh
Use the godbolt for reference against all the 3 major compilers,
GCC/Clang/MSVC.
The following bug report is only for `-O0` builds.
Optimized builds end up removing the dead vtable stores but we require our
debug builds to behave the same as release builds.
Given a virtual destructor that is defaulted and does no work GCC will
overwrite the vtable with the current objects most constructed type.
This behaviour isn't required by MSVC or Itanium CXX ABI or the C++ std but it
would be nice to have all 3 major compilers agree here especially since MSVC
and Clang both have this behaviour.
```
struct Base { virtual ~Base() = default; };
struct Derived : Base { virtual ~Derived() = default; };
```
In the example above `~Derived` will overwrite the vtable with the vtable for
Derived. `~Base` will overwrite the vtable with the vtable for Base.
If you have a global object of `Derived` you easily run into static de-init
fiasco issues since these objects are also registered with `__cxa_atexit`.
Clang and MSVC for defaulted virtual destructors do not overwrite the vtable in
the generated destructors even though they still register with `__cxa_atexit`
so the running of the destructor ends up being a nop.
Clang also has the `[[clang::no_destroy]]` attribute.
We have a workaround on GCC by doing the following for such global objects.
```
union NoDestroy
{
Derived v;
constexpr NoDestroy() : v() {}
~NoDestroy() {}
};
```
There are two solutions that will work for our use case.
Add a similar attribute like `[[clang::no_destroy]]` to mark certain global
objects that should not be registered with `__cxa_atexit`. I couldn't find such
a similar attribute in the GCC docs.
Have GCC behave like MSVC and Clang here when optimizations are disabled and
have defaulted virtual destructors not overwrite the vtable.
Thanks :).
[Bug c++/114229] [modules] duplicate symbols when including stl in submodule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114229
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=112820
Ever confirmed|0 |1
Last reconfirmed||2024-03-05
Known to fail||13.2.0, 14.0
Status|UNCONFIRMED |NEW
--- Comment #2 from Patrick Palka ---
Confirmed, thanks for the bug report. Reduced (needs -fno-module-lazy):
$ cat 114229_a.C
module;
template struct basic_streambuf { virtual void overflow() { } };
extern template struct basic_streambuf;
export module modA;
export basic_streambuf *p;
$ cat 114229_b.C
export module modB;
import modA;
$ cat 114229_c.C
import modA;
import modB;
int main() { }
$ cat 114229_d.C
template struct basic_streambuf { virtual void overflow() { } };
template struct basic_streambuf;
$ g++ -Wno-global-module -fmodules-ts -fno-module-lazy 114229_*.C
/usr/bin/ld: /tmp/ccNDPhFZ.o:(.rodata+0x0): multiple definition of `vtable for
basic_streambuf'; /tmp/ccW7B4xy.o:(.rodata+0x0): first defined here
PR112820 also was extern template related.
[Bug c++/114242] Coroutine with lambda-coroutine and operator new does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242 --- Comment #5 from Andreas Fertig --- My latest conclusion is that my code is indeed invalid. In the case of the lambda, I have a class type. http://eel.is/c++draft/dcl.fct.def.coroutine#4 says that in such a case, p1 is an lvalue of *this. If I modify my original example, g++ and MSVC accept the code, but Clang now rejects it: https://compiler-explorer.com/z/1hhxfYW1v I will open an issue there and let them confirm. But I think we can close this issue for g++.
[Bug sanitizer/97696] ICE since ASAN_MARK does not handle poly_int sized varibales
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97696 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:fca6f6fddb22b8665e840f455a7d0318d4575227 commit r14-9324-gfca6f6fddb22b8665e840f455a7d0318d4575227 Author: Richard Sandiford Date: Tue Mar 5 19:48:25 2024 + asan: Handle poly-int sizes in ASAN_MARK [PR97696] This patch makes the expansion of IFN_ASAN_MARK let through poly-int-sized objects. The expansion itself was already generic enough, but the tests for the fast path were too strict. gcc/ PR sanitizer/97696 * asan.cc (asan_expand_mark_ifn): Allow the length to be a poly_int. gcc/testsuite/ PR sanitizer/97696 * gcc.target/aarch64/sve/pr97696.c: New test.
[Bug rtl-optimization/90706] [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 --- Comment #24 from Georg-Johann Lay --- (In reply to Georg-Johann Lay from comment #23) > As it appears, this bug is not fixed completely. For the -mmcu=avrtiny > architecture, there is still bloat for even the smallest test cases like: Different story, f'up to PR113927.
[Bug middle-end/105533] UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #2 from David Binderman --- I see something similar when attempting a bootstrap with asan & ubsan on current gcc trunk: gcc/expmed.cc:3288:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int' Configure is: ../trunk/configure \ --disable-multilib \ --disable-werror \ --with-build-config=bootstrap-asan \ --with-build-config=bootstrap-ubsan \ --enable-checking=df,extra,fold,rtl,yes \ --enable-languages=c,c++,fortran And there are extra flags added to the top level Makefile: sed 's;-O2;-O3 -march=native;' < Makefile > Makefile.tmp diff Makefile Makefile.tmp mv Makefile.tmp Makefile I wonder if this is a regression for gcc-14.
[Bug c++/114242] Coroutine with lambda-coroutine and operator new does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242 --- Comment #4 from Andreas Fertig --- Thanks for looking into the issue! While CWG 2585 tweaks the wording, my reading is that the code should be valid even with C++20. Regardless of that, without the lambda, the code compiles and uses a custom allocator. After playing with the test case, I could reduce it to having only a coroutine-lambda with a promise_type that has a custom operator new: https://compiler-explorer.com/z/W53nKsfxG Sorry for not having that done initially! I suspect this case wasn't implemented (because it isn't obvious?).
[Bug c++/114242] Coroutine with lambda-coroutine and operator new does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242 Andrew Pinski changed: What|Removed |Added Keywords||C++-coroutines, ||rejects-valid Alias||cwg2585 Blocks||94404 --- Comment #3 from Andrew Pinski --- Yes it looks like GCC does not implement CWG 2585. https://cplusplus.github.io/CWG/issues/2585.html Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 [Bug 94404] [meta-bug] C++ core issues
[Bug c++/114242] Coroutine with lambda-coroutine and operator new does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242 --- Comment #2 from Andrew Pinski --- Created attachment 57617 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57617=edit testcase
[Bug c++/114242] Coroutine with lambda-coroutine and operator new does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242 --- Comment #1 from Andrew Pinski --- Note IIRC C++26 (maybe even 23) changed in this area over C++20 and GCC is following (the initial?) C++20 rules.
[Bug target/113510] [14 Regression] [ARM Thumb] ICE in extract_constrain_insn with CPU cortex-m23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Richard Earnshaw --- Fixed
[Bug target/113510] [14 Regression] [ARM Thumb] ICE in extract_constrain_insn with CPU cortex-m23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510 --- Comment #8 from GCC Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:067a012bde15bfb62d9af309d9d524ebfe91b705 commit r14-9322-g067a012bde15bfb62d9af309d9d524ebfe91b705 Author: Richard Earnshaw Date: Tue Mar 5 17:21:43 2024 + arm: check for low register before applying peephole [PR113510] For thumb1, when using a peephole to fuse mov reg, #const add reg, reg, SP into add reg, SP, #const we must first check that reg is a low register, otherwise we will ICE when trying to recognize the resulting insn. gcc/ChangeLog: PR target/113510 * config/arm/thumb1.md (peephole2 to fuse mov imm/add SP): Use low_register_operand.
[Bug target/113510] [14 Regression] [ARM Thumb] ICE in extract_constrain_insn with CPU cortex-m23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113510 Richard Earnshaw changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Richard Earnshaw --- mine
[Bug libstdc++/114244] New: Need to use round when parsing fractional seconds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114244
Bug ID: 114244
Summary: Need to use round when parsing fractional seconds
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: howard.hinnant at gmail dot com
Target Milestone: ---
I'm not sure if this is a bug or just QOI. But consider:
#include
#include
#include
using time_point_t = std::chrono::sys_time;
time_point_t decrypt(std::string s) {
time_point_t tp;
std::istringstream in(s);
in >> parse("%Y%m%d-%T", tp);
return tp;
}
int main() {
std::cout << decrypt("20240304-13:00:00.002");
}
I expect the output to be:
2024-03-04 13:00:00.002
but it is:
2024-03-04 13:00:00.001
I believe the issue is the use of duration_cast or
time_point_cast somewhere under the parse (not sure exactly
where). Since 0.002 is not exactly representable in floating point, we're
getting a truncate towards zero because this parses as just barely under 0.002.
I highly recommend the use of round when converting floating point
based durations and time_points to integral based.
[Bug testsuite/113611] [14 Regression] gcc.dg/pr110279-1.c fails on cross build since gcc-14-5779-g746344dd538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113611 Richard Earnshaw changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Richard Earnshaw --- I don't see how this can be a regression. > --with-fpu=vfpv3-d16 FMA was added in vfpv4. If I change the fpu to add this then the test generates the relevant comments in the dump file. Arguably this test should check that the target has FMA instructions before running, but that's a different issue.
[Bug c++/98881] [modules] internal compiler error: in tpl_parms_fini, at cp/module.cc:9933
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98881 --- Comment #5 from Pilar Latiesa --- (In reply to Pilar Latiesa from comment #4) > I can no longer reproduce the issue with 11.3 or 12.1 Because those were releases that didn't have checking enabled.
[Bug tree-optimization/111839] [12/13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r12-2097-g9f34b780b0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111839
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Slightly cleaned up.
long a, *d, *h;
int b, c, e, g, i;
signed char f = -26;
int
main ()
{
long j;
for (c = 0; c != 7; ++c)
{
long k = 0;
long l = k;
long **m =
for (; f + i != 0; i++)
h =
g = h != (*m = );
int *n =
*n = g;
while (e)
while (a)
++a;
}
if (b != 1)
__builtin_abort ();
}
I'd say this is just invalid code.
In the c == 0 iteration, h is set to address of l, local in the loop (many
times).
But when that l var goes out of the scope at the end of the iteration, the h
pointer pointing to it becomes invalid, it doesn't point to any valid object.
In the c == 1 iteration, it isn't reinitialized, so I think using it for the
comparison is UB.
ASan use-after-scope can't catch such sort of thing, it can catch stuff when
such pointer is dereferenced, but that is not the case here. Plus, when l
starts lifetime in the c == 1 and later iterations, it would be unpoisoned
again and nothing would be reported even if it was dereferenced.
This is essentially
int *p;
int
main ()
{
for (int i = 0; i < 10; ++i)
{
int l = 0;
if (i == 0)
p =
*p = 42;
}
}
which isn't reported with -fsanitize=address -fsanitize-address-use-after-scope
-g
by either gcc or clang, yet is clearly undefined behavior. The earlier
testcase
doesn't dereference but IMHO has the same problem.
[Bug rtl-optimization/114243] New: -fsplit-wide-types bloats code by more than 50%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114243 Bug ID: 114243 Summary: -fsplit-wide-types bloats code by more than 50% Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- Created attachment 57616 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57616=edit pi-sigma.c: C99 test case Compile the attached test case with: $ avr-gcc pi-sigma.c -c -Os -mmcu=atmega8 -fstack-usage && avr-size pi-sigma.o Then the code sizes are for respective versions of the compiler: avr-gcc-v8: 624 avr-gcc-v14: 1008 which is an increase of code size of more than 60% ! The stack usage also increases by a lot. According to pi-sigma.su: avr-gcc-v8: --- pi-sigma.c:80:7:sigma 30 static pi-sigma.c:86:7:pi_n14 static avr-gcc-v14: pi-sigma.c:80:7:sigma 86 static pi-sigma.c:86:7:pi_n36 static That is for the 1st function the stack use almost triples! With -fno-split-wide-types the performace of v14 code is similar to v8. Target: avr Configured with: ../../source/gcc-master/configure --target=avr --disable-nls --with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared --enable-languages=c,c++ Thread model: single Supported LTO compression algorithms: zlib gcc version 14.0.1 20240303 (experimental) (GCC)
[Bug libstdc++/114240] sys_days not being parsed with only a date in the stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
--- Comment #3 from Jonathan Wakely ---
So this would fix it:
--- a/libstdc++-v3/include/bits/chrono_io.h
+++ b/libstdc++-v3/include/bits/chrono_io.h
@@ -2826,7 +2826,9 @@ namespace __detail
__offset = &__off;
using __format::_ChronoParts;
auto __need = _ChronoParts::_Year | _ChronoParts::_Month
- | _ChronoParts::_Day | _ChronoParts::_TimeOfDay;
+ | _ChronoParts::_Day;
+ if constexpr (ratio_less_v)
+ __need |= _ChronoParts::_TimeOfDay;
__detail::_Parser_t<_Duration> __p(__need);
if (__p(__is, __fmt, __abbrev, __offset))
{
A similar fix is needed for the from_stream overload for local_time, but
utc_time, gps_time and tai_time will be fixed by changing the sys_time
overload.
[Bug c++/114242] New: Coroutine with lambda-coroutine and operator new does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114242
Bug ID: 114242
Summary: Coroutine with lambda-coroutine and operator new does
not compile
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: src at andyf dot de
Target Milestone: ---
Hello,
the following code is accepted by Clang but rejected by g++ and MSVC:
https://compiler-explorer.com/z/7P548dGG3
Once the lambda inside the coroutine isn't used, the code compiles with all
three compilers.
My reading of http://eel.is/c++draft/dcl.fct.def.coroutine#9.1 is that the
custom operator new should be picked in all cases.
G++'s error:
```
: In lambda function:
:54:15: error: 'operator new' is provided by
'std::__n4861::__coroutine_traits_impl::promise_type' {aka
'Generator::promise_type'} but is not usable with the function signature
'coro(std::span)::)>'
54 | auto lamb = [](std::span) -> Generator {
| ^
```
suggests that the compiler tries to look up an operator new with only size as
an argument.
[Bug lto/114241] New: False-positive -Wodr warning when using -flto and -fno-semantic-interposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114241
Bug ID: 114241
Summary: False-positive -Wodr warning when using -flto and
-fno-semantic-interposition
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: abbeyj+gcc at gmail dot com
Target Milestone: ---
When building the following example, a `-Wodr` warning is shown. I don't think
the code violates the ODR so this warning is unexpected. This reproducer
consists of 3 files.
d.h:
```
class A {
public:
virtual ~A();
virtual void a1();
};
class B : public A {
public:
void a1();
virtual void b1() = 0;
virtual void b2() = 0;
};
class C : public B {
};
class D : public C {
public:
void b1();
void b2();
};
```
foo.cpp:
```
#include "d.h"
void foo() {
D x;
}
```
bar.cpp:
```
#include "d.h"
void B::a1() {
}
void bar() {
D y;
}
```
Build using:
g++ -fPIC -fno-semantic-interposition -flto -c foo.cpp
g++ -fPIC -fno-semantic-interposition -flto -c bar.cpp
g++ -shared foo.o bar.o -o lib.so
Output:
> d.h:14:7: warning: virtual table of type ‘struct C’ violates one definition
> rule [-Wodr]
>14 | class C : public B {
> | ^
> d.h:14:7: note: the conflicting type defined in another translation unit has
> virtual table with more entries
>14 | class C : public B {
> | ^
The warning message here is not great as it refers to "another translation
unit" but never names either of the two translation units involved. In this
reduced example there are only two translation units but when there are many
translation units involved it is more difficult to figure out where the problem
is coming from.
The bigger issue is that I don't think this warning should have been issued at
all. I can't see any way that the code is violating the ODR.
The earliest version that I've been able to reproduce with is 8.4
Godbolt link: https://godbolt.org/z/ncnqPMdzq
[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307 --- Comment #6 from Richard Biener --- Thanks, so keeping this open but it will likely end up INVALID.
[Bug ipa/111958] [11/12/13/14 Regression] Line number debugging information indicates wrong file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111958
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
(In reply to Richard Biener from comment #3)
> which we first ICF and then inline back. So it looks like when
> "materializing"
> the alias clone for getegid we get a wrong location (or the location for the
> alias clone is broken / not initialized?)
I think we don't set it at all (i.e. keep it UNKNOWN_LOCATION), after all, it
doesn't correspond to any particular source line in the function, e.g. even
just trying to use a location of a particular return stmt is wrong, the
function could have multiple returns.
So it is even in -fdump-{tree,ipa}-all-lineno dumps
retval.5_4 = setgid (gid_2(D)); [tail call]
return retval.5_4;
The unistd.h locus appears during expansion, seems to match the
DECL_SOURCE_LOCATION of the first declaration of the function or something like
that.
ICF is simply very much harmful to all the locations in the function, if it is
not inlined back, we have have the elsewhere tracked problem that the merged
function can have solely locations/scopes etc. of one of the functions and not
the others,
if it is inlined back, the debug info will pretend that another function has
been inlined into the current one even when that is not true.
The latter perhaps could be improved by somehow just noting to turn a function
into the thunk at the end of IPA passes and if we'd in between decide to inline
itself back into the function, somehow arrange to use the original body rather
than the thunk with the other function inlined into it. Similarly for
fnsplit...
[Bug target/112337] arm: ICE in arm_effective_regno when compiling for MVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337 Richard Earnshaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Richard Earnshaw --- Should now be fixed.
[Bug libstdc++/114240] sys_days not being parsed with only a date in the stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240 --- Comment #2 from Howard Hinnant --- In my date lib I just presumed 00:00:00 time of day when parsing time_points, unless the parse produced another time of day. Though I must admit that this didn't come through in the spec. So there is a little grey area here. We're going to hit the same issue for other timepoints as well: local_time, utc_time, etc.
[Bug target/112337] arm: ICE in arm_effective_regno when compiling for MVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337 --- Comment #16 from GCC Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:2ba3171f161452df476485272cc966bc523d9859 commit r14-9321-g2ba3171f161452df476485272cc966bc523d9859 Author: Saurabh Jha Date: Tue Jan 30 15:03:36 2024 + Fix testcase pr112337.c to check the options [PR112337] gcc.target/arm/pr112337.c was failing to validate that adding MVE options was compatible with the test environment, so add the missing checks. gcc/testsuite/ChangeLog: PR target/112337 * gcc.target/arm/pr112337.c: Check for, then use the right MVE options.
[Bug target/112337] arm: ICE in arm_effective_regno when compiling for MVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337 Richard Earnshaw changed: What|Removed |Added Target Milestone|--- |14.0
[Bug libstdc++/114240] sys_days not being parsed with only a date in the stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
--- Comment #1 from Jonathan Wakely ---
I think the problem is that I just have some generic logic that assumes all
sys_time specializations are a date time, and so require both a date and a
time. But obviously for sys_days we only need a date.
template>
basic_istream<_CharT, _Traits>&
from_stream(basic_istream<_CharT, _Traits>& __is, const _CharT* __fmt,
sys_time<_Duration>& __tp,
basic_string<_CharT, _Traits, _Alloc>* __abbrev = nullptr,
minutes* __offset = nullptr)
{
minutes __off{};
if (!__offset)
__offset = &__off;
using __format::_ChronoParts;
auto __need = _ChronoParts::_Year | _ChronoParts::_Month
| _ChronoParts::_Day | _ChronoParts::_TimeOfDay;
This should depend on _Duration::period.
[Bug tree-optimization/114239] [14 regression] ice: error: definition in block does not dominate use in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114239 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |14.0 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-03-05 --- Comment #2 from Richard Biener --- Confirmed. This is the peeled early exit reduction epilog case. I will have a look tomorrow.
[Bug libstdc++/114240] sys_days not being parsed with only a date in the stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-03-05 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug tree-optimization/114236] introduce unnecessary store operation when unrolling a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114236 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Executing store motion of MEM[(short int *)_16] from loop 2 Re-issueing dependent store of *g_70.2_4 from loop 2 on exit 4 -> 5 Moving statement The extra store is required to enable sinking of the store to g_16 as we don't know whether g_70 points to aliased memory. I think we fail to realize that *g_70 is loop invariant as well, but what you observe is a feature - it allows reducing the number of stores to g_16.
[Bug libstdc++/114240] New: sys_days not being parsed with only a date in the stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114240
Bug ID: 114240
Summary: sys_days not being parsed with only a date in the
stream
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: howard.hinnant at gmail dot com
Target Milestone: ---
#include
#include
#include
int main(int argc, char**argv){
std::istringstream ssStart{"2024-01-01"};
std::istringstream ssEnd("2024-02-01");
ssStart.exceptions(std::ios::failbit);
std::chrono::sys_days tStart, tEnd;
ssStart >> std::chrono::parse("%Y-%m-%d ", tStart);
ssEnd >> std::chrono::parse("%Y-%m-%d ", tEnd);
auto tDays = tEnd-tStart;
std::cout << ssStart.str() << "," << ssEnd.str() << "," << tDays.count() <<
std::endl;
}
Expected output:
2024-01-01,2024-02-01,31
Actual output:
terminate called after throwing an instance of 'std::__ios_failure'
what(): basic_ios::clear: iostream error
I expected this function: http://eel.is/c++draft/time.clock.system.nonmembers#6
to successfully parse the days-precision time_point because there is sufficient
information in the stream to form a valid date.
Demo: https://wandbox.org/permlink/FrtMteIddnb4ogpZ
[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307
--- Comment #5 from Jonathan Wakely ---
return EnumeratorRange(Enumerator(std::views::single(Intersection(;
This creates a temporary Intersection object, then copies that into a
single_view object. Then that is copied into an Enumerator object which looks
like:
Enumerator {
single_view range_;
optional::_Iterator> begin_;
};
The range_ member is the copy of std::views::single(Intersection()) and the
begin_ member is initially empty.
Then that Enumerator is copied into an EnumeratorRange which calls Next() on
the new copy, which sets its begin_ member to point to the range_ member. Then
the EnumeratorRange is returned.
So I think it's expected that the Enumerator points to itself, because of the
call to its Next() member.
BUT, the self-referential pointer is set to the address of the range_ member
before the return value is copied, and so goes out of scope when that object is
copied via registers and then copied again into the automatic variable in
main().
So yes, I think it's invalid for the same reason as PR 109945 comment 25
explains, and indeed giving any of the objects a non-trivial destructor
prevents it being copied via registers and so the pointer isn't invalidated.
[Bug c++/43167] Warnings should not be disabled when instantiating templates defined in system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167 Jonathan Wakely changed: What|Removed |Added CC||jlame646 at gmail dot com --- Comment #22 from Jonathan Wakely --- *** Bug 114237 has been marked as a duplicate of this bug. ***
[Bug c++/114237] GCC emits no narrowing conversion warning when call is made indirectly through std::invoke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114237 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- dup *** This bug has been marked as a duplicate of bug 43167 ***
[Bug c++/114237] GCC emits no narrowing conversion warning when call is made indirectly through std::invoke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114237 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Jonathan Wakely --- The conversion happens in a system header, so is suppressed without -Wsystem-headers There are existing bug reports about -Wconversion warnings being suppressed in system headers.
[Bug tree-optimization/114009] [11/12/13/14 Regression] Missed optimization: (!a) * a => 0 when a=(a/2)*2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 57615 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57615=edit gcc14-pr114009.patch Untested fix.
[Bug tree-optimization/114234] [14 Regression] verify_ssa failure with early-break vectorisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114234 Tamar Christina changed: What|Removed |Added Last reconfirmed||2024-03-05 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Tamar Christina --- started with commit g:324d2907c86f05e40dc52d226940308f53a956c2 Author: Richard Biener Date: Mon Mar 4 09:46:13 2024 +0100 tree-optimization/114192 - scalar reduction kept live with early break vect The following fixes a missing replacement of the reduction value used in the epilog, causing the scalar reduction to be kept live across the early break exit path. PR tree-optimization/114192 * tree-vect-loop.cc (vect_create_epilog_for_reduction): Use the appropriate def for the live out stmt in case of an alternate exit. the reduction seems to propagate out a single value for both exits: # a_39 = PHI but since the PHI nodes carry their reduction values in the exits we have different reduction statements, so using the same reduction value for all exit is wrong. should be # a_39 = PHI
[Bug tree-optimization/114009] [11/12/13/14 Regression] Missed optimization: (!a) * a => 0 when a=(a/2)*2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009 --- Comment #3 from Jakub Jelinek --- That said, I fail to see why the a/2*2 in there matters. a*!a is simply always 0 for integral types, both signed and unsigned, including signed 1-bit precision. If a is 0, the result is 0*1 (or for the last one 0*-1), if a is non-zero, then the result is a*0.
[Bug target/114232] [14 regression] ICE when building rr-5.7.0 with LTO on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232 --- Comment #26 from Jan Hubicka --- > I think optimize_function_for_size_p (cfun) isn't always true if > optimize_size is since it looks at the function-specific setting > of that flag, so you'd have to use opt_for_fn (cfun, optimize_size). When we initialize obtabs, we do it for a givn optimization_node setting, so opt_for_fn (cfun, optimize_size) should be equal to optimize_size. Honza
[Bug target/114232] [14 regression] ICE when building rr-5.7.0 with LTO on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232 --- Comment #25 from Uroš Bizjak --- Created attachment 57614 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57614=edit Proposed patch Proposed patch that changes optimize_function_for_size_p (cfun) to optimize_size.
[Bug tree-optimization/114239] ice: error: definition in block does not dominate use in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114239 --- Comment #1 from Sam James --- The testcase is the same as in PR113555 - so should've added to test suite I suppose. Indeed ICEs on trunk.
[Bug c/114239] New: ice: error: definition in block does not dominate use in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114239
Bug ID: 114239
Summary: ice: error: definition in block does not dominate use
in block
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
int ip4_getbit_a, ip4_getbit_pos, ip4_clrbit_pos;
void ip4_clrbit(int *a) { *a &= ip4_clrbit_pos; }
typedef struct {
char pxlen;
int prefix
} net_addr_ip4;
void fib_get_chain();
int trie_match_longest_ip4();
int trie_match_next_longest_ip4(net_addr_ip4 *n) {
int __trans_tmp_1;
while (n->pxlen) {
n->pxlen--;
ip4_clrbit(>prefix);
__trans_tmp_1 = ip4_getbit_a >> ip4_getbit_pos;
if (__trans_tmp_1)
return 1;
}
return 0;
}
void net_roa_check_ip4_trie_tab() {
net_addr_ip4 px0;
for (int _n = trie_match_longest_ip4(); _n;
_n = trie_match_next_longest_ip4())
fib_get_chain();
}
on x86_64, does this:
$ ../results/bin/gcc -c -O3 -march=znver3 -w ~/cvise/bug1021.c
/home/dcb38/cvise/bug1021.c: In function ‘net_roa_check_ip4_trie_tab’:
/home/dcb38/cvise/bug1021.c:20:6: error: definition in block 19 does not
dominate use in block 14
20 | void net_roa_check_ip4_trie_tab() {
| ^~
for SSA_NAME: _117 in statement:
px0__lsm.22_47 = PHI <_117(14), _117(19)>
PHI argument
_117
for PHI node
px0__lsm.22_47 = PHI <_117(14), _117(19)>
during GIMPLE pass: vect
/home/dcb38/cvise/bug1021.c:20:6: internal compiler error: verify_ssa failed
The bug first seems to occur sometime between g:1e74ce8983fd4926
and g:71244316cf714725, which is 42 commits.
[Bug tree-optimization/114234] [14 Regression] verify_ssa failure with early-break vectorisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114234 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org, ||tnfchris at gcc dot gnu.org --- Comment #2 from Sam James --- That second one is probably worth its own PR.
[Bug tree-optimization/114234] [14 Regression] verify_ssa failure with early-break vectorisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114234
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #1 from David Binderman ---
For this C code:
int ip4_getbit_a, ip4_getbit_pos, ip4_clrbit_pos;
void ip4_clrbit(int *a) { *a &= ip4_clrbit_pos; }
typedef struct {
char pxlen;
int prefix
} net_addr_ip4;
void fib_get_chain();
int trie_match_longest_ip4();
int trie_match_next_longest_ip4(net_addr_ip4 *n) {
int __trans_tmp_1;
while (n->pxlen) {
n->pxlen--;
ip4_clrbit(>prefix);
__trans_tmp_1 = ip4_getbit_a >> ip4_getbit_pos;
if (__trans_tmp_1)
return 1;
}
return 0;
}
void net_roa_check_ip4_trie_tab() {
net_addr_ip4 px0;
for (int _n = trie_match_longest_ip4(); _n;
_n = trie_match_next_longest_ip4())
fib_get_chain();
}
on x86_64, does this:
$ ../results/bin/gcc -c -O3 -march=znver3 -w ~/cvise/bug1021.c
/home/dcb38/cvise/bug1021.c: In function ‘net_roa_check_ip4_trie_tab’:
/home/dcb38/cvise/bug1021.c:20:6: error: definition in block 19 does not
dominate use in block 14
20 | void net_roa_check_ip4_trie_tab() {
| ^~
for SSA_NAME: _117 in statement:
px0__lsm.22_47 = PHI <_117(14), _117(19)>
PHI argument
_117
for PHI node
px0__lsm.22_47 = PHI <_117(14), _117(19)>
during GIMPLE pass: vect
/home/dcb38/cvise/bug1021.c:20:6: internal compiler error: verify_ssa failed
The bug first seems to occur sometime between g:1e74ce8983fd4926
and g:71244316cf714725, which is 42 commits.
[Bug testsuite/101461] [12/13/14 regression] gcc.target/powerpc/fold-vec-load-builtin_vec_xl test cases fail after r12-2266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101461 Kewen Lin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||linkw at gcc dot gnu.org --- Comment #4 from Kewen Lin --- Already fixed by r12-2889-g8464894c86b03e.
[Bug target/114232] [14 regression] ICE when building rr-5.7.0 with LTO on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232 --- Comment #24 from Jakub Jelinek --- (In reply to rguent...@suse.de from comment #22) > I think optimize_function_for_size_p (cfun) isn't always true if > optimize_size is since it looks at the function-specific setting > of that flag, so you'd have to use opt_for_fn (cfun, optimize_size). I think the insn-flags.h macros and actual insn conditions are checked when the corresponding function is current, and at that point opt_for_fn (cfun, optimize_size) should be the same as optimize_size. Even the set_cfun hook first sets the option and then tries to initialize optab and compares it against the global one.
[Bug target/114232] [14 regression] ICE when building rr-5.7.0 with LTO on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232 --- Comment #23 from Uroš Bizjak --- (In reply to Jan Hubicka from comment #21) > Looking at the prototype patch, why need to change also the splitters? Purely for implementation reasons, we check for general resp. SSE register in the operand predicates, so there is no need to use additional insn constraints.
[Bug target/114232] [14 regression] ICE when building rr-5.7.0 with LTO on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232 --- Comment #22 from rguenther at suse dot de --- On Tue, 5 Mar 2024, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232 > > --- Comment #17 from Jakub Jelinek --- > Either change those too, or the splitter needs some variant what to do if > there > is a mismatch. > Though, optimize_size implies optimize_function_for_size_p (cfun), so if a > named pattern uses && optimize_size and the insn it splits into uses > optimize_function_for_size_p (cfun), it shouldn't fail. The other direction > is > not always true, optimize_function_for_size_p (cfun) can be true just because > the function > is cold, not just because it is -Os. I think optimize_function_for_size_p (cfun) isn't always true if optimize_size is since it looks at the function-specific setting of that flag, so you'd have to use opt_for_fn (cfun, optimize_size).
[Bug tree-optimization/114238] New: Multiple 554.roms_r run-time regressions (4%-20%) since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114238
Bug ID: 114238
Summary: Multiple 554.roms_r run-time regressions (4%-20%)
since r14-9193-ga0b1798042d033
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Blocks: 26163
Target Milestone: ---
Host: x86_64-linux, aarch64-linux
Target: x86_64-linux, aarch64-linux
Our LNT instance has detected that runtime of benchmark 554.roms_r
from the SPEC 2017 FPUrate suite regressed on all machines on most
configurations by 4-20%.
For example:
simple -O2 -flto on AMD Zen 3 regressed by 14%:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=470.537.0
on Zen2 -O2 -flto regression is the worst, 20%:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=298.537.0
-Ofast -march=native -flto on AMD Zen 4 regressed by 7%:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=959.537.0
-Ofast -march=native on AMD Zen 2 regressed by 17%:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=295.537.0
but it also happens on Intel Skylake:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=800.537.0
or Aarch64:
https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=587.537.0
and there are smaller regressions on the PGO configurations too.
I have bisected the Zen3 -O2 -flto case to r14-9193-ga0b1798042d033
(Richard Biener: tree-optimization/114074 - CHREC multiplication and
undefined overflow). I have then verified that the zen 4 -Ofast
-march=natice -flto and zen 2 -Ofast -march=native cases have also
been introduces by it:
commit a0b1798042d033fd2cc2c806afbb77875dd2909b
Author: Richard Biener
Date: Mon Feb 26 13:33:21 2024 +0100
tree-optimization/114074 - CHREC multiplication and undefined overflow
When folding a multiply CHRECs are handled like {a, +, b} * c
is {a*c, +, b*c} but that isn't generally correct when overflow
invokes undefined behavior. The following uses unsigned arithmetic
unless either a is zero or a and b have the same sign.
I've used simple early outs for INTEGER_CSTs and otherwise use
a range-query since we lack a tree_expr_nonpositive_p and
get_range_pos_neg isn't a good fit.
PR tree-optimization/114074
* tree-chrec.h (chrec_convert_rhs): Default at_stmt arg to NULL.
* tree-chrec.cc (chrec_fold_multiply): Canonicalize inputs.
Handle poly vs. non-poly multiplication correctly with respect
to undefined behavior on overflow.
* gcc.dg/torture/pr114074.c: New testcase.
* gcc.dg/pr68317.c: Adjust expected location of diagnostic.
* gcc.dg/vect/vect-early-break_119-pr114068.c: Do not expect
loop to be vectorized.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug tree-optimization/114009] [11/12/13/14 Regression] Missed optimization: (!a) * a => 0 when a=(a/2)*2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114009 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Is the regression marker added for the r11-2550-gca2b8c082c4f16919071c9f8de8db0b33b54c405 change: movl%edi, %eax - xorl%edx, %edx + movl$0, %edx shrl$31, %eax addl%edi, %eax + addl$1, %edi andl$-2, %eax - sete%dl - imull %edx, %eax + cmpl$2, %edi + cmova %edx, %eax movl%eax, w(%rip) ret or for the r12-5392-g527e54a431473cc497204226a21f2831d2375e66 change: - movl%edi, %eax - movl$0, %edx - shrl$31, %eax - addl%edi, %eax - addl$1, %edi - andl$-2, %eax - cmpl$2, %edi - cmova %edx, %eax + leal1(%rdi), %eax + movl%edi, %edx + cmpl$2, %eax + setbe %al + shrl$31, %edx + addl%edi, %edx + movzbl %al, %eax + sarl%edx + imull %edx, %eax + addl%eax, %eax or both? I don't think we ever optimized this without -fwrapv to just 0.
[Bug target/114232] [14 regression] ICE when building rr-5.7.0 with LTO on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114232 --- Comment #21 from Jan Hubicka --- Looking at the prototype patch, why need to change also the splitters? My original goal was to use splitters to expand to faster code sequences while having patterns necessary for both variants. This makes it possible to use optimize_insn_for_size/speed and make decisions using BB profile, since we will not ICE if the hotness of BB changes later.
