[Bug c++/113916] New: gcc allows overriding a non-deleted private base class dtor with a deleted defaulted dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113916
Bug ID: 113916
Summary: gcc allows overriding a non-deleted private base class
dtor with a deleted defaulted dtor
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rush102333 at gmail dot com
Target Milestone: ---
The following code seems invaild, because when the base class dtor is private,
it's natural that the explicitly defaulted derived class dtor should be defined
as deleted since it can't be defined as anything else. Then the question comes
that you can't override a non-deleted function(the virtual, though
inaccessible, base class dtor) with a deleted function(the explicitly defaulted
and implicitly deleted derived dtor).
Actually, we've confirmed that Clang rejects it. But it works well in
gcc_13.2.0.
~~~
class Base
{
virtual ~Base() = default;
};
class Derived : public Base
{
~Derived() override = default;
};
~~~
We're not sure but we tend to believe that it would more likely be a bug of
gcc.
Clang 17.0.1 rejects the code by complaining that:
~~~
:8:5: warning: explicitly defaulted destructor is implicitly deleted
[-Wdefaulted-function-deleted]
8 | ~Derived() override = default;
| ^
:6:17: note: destructor of 'Derived' is implicitly deleted because base
class 'Base' has an inaccessible destructor
6 | class Derived : public Base
| ^
:8:27: note: replace 'default' with 'delete'
8 | ~Derived() override = default;
| ^~~
| delete
:8:5: error: deleted function '~Derived' cannot override a non-deleted
function
8 | ~Derived() override = default;
| ^
:3:13: note: overridden virtual function is here
3 | virtual ~Base() = default;
| ^
:6:17: note: destructor of 'Derived' is implicitly deleted because base
class 'Base' has an inaccessible destructor
6 | class Derived : public Base
| ^
1 warning and 1 error generated.
~~~
Please check https://godbolt.org/z/4Tvc9Tfsz
[Bug target/113915] [14 regression] glibc's _dl_find_object_update_1 miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915 --- Comment #10 from Andrew Pinski --- (In reply to Andrew Pinski from comment #9) > This should work, I think: With that I get on the reduced testcase: ``` f: @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. cmp r0, #0 bxeqlr mov r3, #0 str r3, [r0] bx lr ``` Which looks 100% correct now.
[Bug target/113915] [14 regression] glibc's _dl_find_object_update_1 miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915 --- Comment #9 from Andrew Pinski --- (In reply to Andrew Pinski from comment #8) > (In reply to Andrew Pinski from comment #7) > > cannot be conditional executed. > > That is because most of the insn patterns in sync.md don't have > [(set_attr "conds" "nocond")]) > > on them > > Someone will have to submit that patch after testing, I don't have the > bandwidth to do it though. Actually wait that is the not fix. This should work, I think: ``` diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc index c44047c377a..d55ea59a727 100644 --- a/gcc/config/arm/arm.cc +++ b/gcc/config/arm/arm.cc @@ -25611,11 +25611,12 @@ arm_final_prescan_insn (rtx_insn *insn) case INSN: /* Instructions using or affecting the condition codes make it -fail. */ +fail or ones which cannot be predicable. */ scanbody = PATTERN (this_insn); if (!(GET_CODE (scanbody) == SET || GET_CODE (scanbody) == PARALLEL) - || get_attr_conds (this_insn) != CONDS_NOCOND) + || get_attr_conds (this_insn) != CONDS_NOCOND + || get_attr_predicable (this_insn) != PREDICABLE_YES) fail = TRUE; break; ```
[Bug target/113915] [14 regression] glibc's _dl_find_object_update_1 miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > cannot be conditional executed. That is because most of the insn patterns in sync.md don't have [(set_attr "conds" "nocond")]) on them Someone will have to submit that patch after testing, I don't have the bandwidth to do it though.
[Bug target/113915] [14 regression] glibc's _dl_find_object_update_1 miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
--- Comment #7 from Andrew Pinski ---
Seems like the code in arm_final_prescan_insn does not realize arm_atomic_store
cannot be conditional.
That is:
```
(insn 10 9 11 (set (mem/v:SI (reg/v/f:SI 0 r0 [orig:116 aD.6109 ] [116]) [-1
S4 A32])
(unspec_volatile:SI [
(reg:SI 3 r3 [117])
] VUNSPEC_STR)) "/app/example.cpp":5:3 3064 {arm_atomic_storesi}
(expr_list:REG_DEAD (reg:SI 3 r3 [117])
(expr_list:REG_DEAD (reg/v/f:SI 0 r0 [orig:116 aD.6109 ] [116])
(nil
```
cannot be conditional executed.
[Bug target/113915] [14 regression] glibc's _dl_find_object_update_1 miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-02-14
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #6 from Andrew Pinski ---
Reduced testcase:
```
[[gnu::noipa]]
void f(int *a)
{
if (a)
__atomic_store_n (a, 0, __ATOMIC_RELAXED);
}
void main()
{
f((int*)0);
}
```
Trunk produces:
```
cmp r0, #0
movne r3, #0
str r3, [r0]
bx lr
```
Which is totally wrong.
[Bug target/113915] [14 regression] glibc miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915 Andrew Pinski changed: What|Removed |Added Severity|normal |blocker
[Bug target/113915] [14 regression] glibc miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617 Orion Poplawski changed: What|Removed |Added CC||orion at nwra dot com --- Comment #15 from Orion Poplawski --- Just a comment that a fix for this would be nice to have as it's currently blocking builds of vtk and paraview in Fedora. Thanks!
[Bug target/113915] [14 regression] glibc miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
--- Comment #5 from Sam James ---
(In reply to Sam James from comment #0)
> glibc seems to go from 30 failing innocent tests (*) to over 400 between
> gcc-13 and gcc-14. Bisected to r14-4365-g0731889c026bfe which fixed PR111235.
>
> It's hard to know where to start with this. I'll try the usual bisection of
> objects and then pragmas although I fear the (necessary) complexities of
> glibc's build system may make my usual method tricky. We'll see...
>
Indeed, optimize("O0") pragma for _dl_find_object_update_1 in
dl-find_object.c/o avoids the crash. O1/O2 fail.
[Bug target/113915] [14 regression] glibc miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915 --- Comment #4 from Sam James --- better bt: ``` begin: no errors [New LWP 250625] Thread 2.1 "ld-linux-armhf." received signal SIGSEGV, Segmentation fault. [Switching to LWP 250624] _dl_find_object_update_1 (count=, loaded=) at dl-find_object.c:777 777 atomic_store_relaxed (_seg->previous->size, 0); (gdb) bt #0 _dl_find_object_update_1 (count=, loaded=) at dl-find_object.c:777 #1 _dl_find_object_update (new_map=new_map@entry=0xf7fbc158) at dl-find_object.c:805 #2 0xf7fd3650 in dl_open_worker_begin (a=0xfffeec20) at dl-open.c:756 #3 0xf7fc7f54 in __GI__dl_catch_exception (exception=0xf7fa, exception@entry=0xfffeea30, operate=0xf7fc7f54 <__GI__dl_catch_exception+112>, args=0xfffeea38, args@entry=0xfffeec20) at dl-catch.c:237 #4 0xf7fd2a78 in dl_open_worker (a=0xfffeec20) at dl-open.c:803 #5 0xf7fc7f54 in __GI__dl_catch_exception (exception=0xf7f2902c <__GI___libc_unwind_link_get+76>, exception@entry=0xfffeec14, operate=0xf7fc7f54 <__GI__dl_catch_exception+112>, args=0xfffeec14, args@entry=0xfffeec18) at dl-catch.c:237 #6 0xf7fd2e5c in _dl_open (file=0xf7f983a0 "libgcc_s.so.1", mode=-2147483646, caller_dlopen=0xf7f2902c <__GI___libc_unwind_link_get+76>, nsid=nsid@entry=-2, argc=1, argv=0xfffef1b4, env=0xfffef1bc) at dl-open.c:905 #7 0xf7f79364 in do_dlopen (ptr=0xfffeee78) at dl-libc.c:95 #8 0xf7fc7f54 in __GI__dl_catch_exception (exception=0xfffeee64, exception@entry=0xfffeee2c, operate=0xf7fc7f54 <__GI__dl_catch_exception+112>, args=0xfffeee34, args@entry=0xf7fa411c ) at dl-catch.c:237 #9 0xf7fc80b0 in _dl_catch_error (objname=0xfffeee60, objname@entry=0xfffeee58, errstring=0xfffeee64, errstring@entry=0xfffeee5c, mallocedp=0xfffeee5f, mallocedp@entry=0xfffeee57, operate=, args=0xfffeee78, args@entry=0xfffeee70) at dl-catch.c:256 #10 0xf7f792c0 in dlerror_run (operate=, args=args@entry=0xfffeee70) at dl-libc.c:45 #11 0xf7f79538 in __libc_dlopen_mode (name=, mode=mode@entry=-2147483646) at dl-libc.c:162 #12 0xf7f2902c in __GI___libc_unwind_link_get () at unwind-link.c:51 #13 0xf7eb3300 in __pthread_cancel (th=4158874656) at pthread_cancel.c:99 #14 0xf7fc1468 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) ```
[Bug target/113915] [14 regression] glibc miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915 --- Comment #3 from Sam James --- On glibc trunk (491e55beab7457ed310a4a47496f4a333c5d1032), I can reproduce with: ``` CC=/tmp/gcc/bin/gcc CXX=/tmp/gcc/bin/g++ ~/git/glibc/configure --prefix=/usr make -j$(nproc) make test t=posix/tst-getopt-cancel ``` ``` Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7a-unknown-linux-gnueabihf/14/lto-wrapper Target: armv7a-unknown-linux-gnueabihf Configured with: /var/tmp/portage/sys-devel/gcc-14.0.1_pre20240204-r1/work/gcc-14-20240204/configure --host=armv7a-unknown-linux-gnueabihf --build=armv7a-unknown-linux-gnueabihf --prefix=/usr --bindir=/usr/armv7a-unknown-linux-gnueabihf/gcc-bin/14 --includedir=/usr/lib/gcc/armv7a-unknown-linux-gnueabihf/14/include --datadir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabihf/14 --mandir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabihf/14/man --infodir=/usr/share/gcc-data/armv7a-unknown-linux-gnueabihf/14/info --with-gxx-include-dir=/usr/lib/gcc/armv7a-unknown-linux-gnueabihf/14/include/g++-v14 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/armv7a-unknown-linux-gnueabihf/14/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=yes,extra --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 14.0.1_pre20240204-r1 p20' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --with-float=hard --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --without-isl --enable-default-pie --enable-host-pie --disable-host-bind-now --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.1 20240204 (experimental) (Gentoo 14.0.1_pre20240204-r1 p20) ```
[Bug target/113915] [14 regression] glibc miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=28745 CC||fw at gcc dot gnu.org --- Comment #2 from Sam James --- _dl_find_object_update uses a bunch of atomics so the bisect result seems reasonable. It is possible that there's something wrong on the glibc side here, like in https://sourceware.org/bugzilla/show_bug.cgi?id=28745.
[Bug target/113915] [14 regression] glibc miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915 --- Comment #1 from Sam James --- glibc's WAIT_FOR_DEBUGGER support for tests seems broken, as it drops me into a waiting process with: ``` /var/tmp/portage/sys-libs/glibc-2.38-r10/work/build-arm-armv7a-unknown-linux-gnueabihf-nptl/posix/tst-getopt-cancel.gdb:6: Error in sourced command file: 'wait_for_debugger' has unknown type; cast it to its declared type ``` Can't manually set wait_for_debugger either. Whatever. Trying manually, we get (without very good debugging symbols yet): ``` Thread 2.1 "ld-linux-armhf." received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xf7e33020 (LWP 4162410)] 0xf7fcc524 in _dl_find_object_update () from /var/tmp/portage/sys-libs/glibc-2.38-r10/work/build-arm-armv7a-unknown-linux-gnueabihf-nptl/elf/ld-linux-armhf.so.3 (gdb) bt #0 0xf7fcc524 in _dl_find_object_update () from /var/tmp/portage/sys-libs/glibc-2.38-r10/work/build-arm-armv7a-unknown-linux-gnueabihf-nptl/elf/ld-linux-armhf.so.3 #1 0xf7fd4320 in dl_open_worker_begin () from /var/tmp/portage/sys-libs/glibc-2.38-r10/work/build-arm-armv7a-unknown-linux-gnueabihf-nptl/elf/ld-linux-armhf.so.3 #2 0xf7fc8f68 in _dl_catch_exception () from /var/tmp/portage/sys-libs/glibc-2.38-r10/work/build-arm-armv7a-unknown-linux-gnueabihf-nptl/elf/ld-linux-armhf.so.3 #3 0xf7fd37c4 in dl_open_worker () from /var/tmp/portage/sys-libs/glibc-2.38-r10/work/build-arm-armv7a-unknown-linux-gnueabihf-nptl/elf/ld-linux-armhf.so.3 #4 0xf7fc8f68 in _dl_catch_exception () from /var/tmp/portage/sys-libs/glibc-2.38-r10/work/build-arm-armv7a-unknown-linux-gnueabihf-nptl/elf/ld-linux-armhf.so.3 #5 0xf7fd3b94 in _dl_open () from /var/tmp/portage/sys-libs/glibc-2.38-r10/work/build-arm-armv7a-unknown-linux-gnueabihf-nptl/elf/ld-linux-armhf.so.3 #6 0xf7f80528 in do_dlopen () from /var/tmp/portage/sys-libs/glibc-2.38-r10/work/build-arm-armv7a-unknown-linux-gnueabihf-nptl/libc.so.6 #7 0xf7fc8f68 in _dl_catch_exception () from /var/tmp/portage/sys-libs/glibc-2.38-r10/work/build-arm-armv7a-unknown-linux-gnueabihf-nptl/elf/ld-linux-armhf.so.3 #8 0xf7fc90c4 in _dl_catch_error () from /var/tmp/portage/sys-libs/glibc-2.38-r10/work/build-arm-armv7a-unknown-linux-gnueabihf-nptl/elf/ld-linux-armhf.so.3 #9 0xf7f8044c in dlerror_run () from /var/tmp/portage/sys-libs/glibc-2.38-r10/work/build-arm-armv7a-unknown-linux-gnueabihf-nptl/libc.so.6 #10 0xf7f80744 in __libc_dlopen_mode () from /var/tmp/portage/sys-libs/glibc-2.38-r10/work/build-arm-armv7a-unknown-linux-gnueabihf-nptl/libc.so.6 #11 0xf7f3601c in __libc_unwind_link_get () from /var/tmp/portage/sys-libs/glibc-2.38-r10/work/build-arm-armv7a-unknown-linux-gnueabihf-nptl/libc.so.6 #12 0xf7eb21a0 in pthread_cancel@GLIBC_2.4 () from /var/tmp/portage/sys-libs/glibc-2.38-r10/work/build-arm-armv7a-unknown-linux-gnueabihf-nptl/libc.so.6 #13 0xf7fc2828 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) ```
[Bug target/113915] New: [14 regression] glibc miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915 Bug ID: 113915 Summary: [14 regression] glibc miscompiled for armv7a since r14-4365-g0731889c026bfe Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org CC: ramana at gcc dot gnu.org, wilco at gcc dot gnu.org Target Milestone: --- glibc seems to go from 30 failing innocent tests (*) to over 400 between gcc-13 and gcc-14. Bisected to r14-4365-g0731889c026bfe which fixed PR111235. It's hard to know where to start with this. I'll try the usual bisection of objects and then pragmas although I fear the (necessary) complexities of glibc's build system may make my usual method tricky. We'll see... I've bisected using glibc's posix/tst-getopt-cancel test as it had easy output to grep for: ``` $ cat ./posix/tst-getopt-cancel.out begin: no errors Didn't expect signal from child: got `Segmentation fault' ``` (*) just from sandboxing stuff, they're normally not there and should be unrelated given they happened w/ 13.
[Bug c++/113545] ICE in label_matches with constexpr function with switch-statement and converted (nonconstant, cast address) input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113545 --- Comment #5 from Hans-Peter Nilsson --- Thank you!
Acoustic Instrument
Hello, I'm offering my late husband's Yamaha Baby Grand Piano to any passionate music enthusiast. Please inform me if you are interested or know someone who would appreciate having this instrument. Thanks, Sarenaa Fuller
[Bug driver/36312] should refuse to overwrite input file with output file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312 --- Comment #24 from Andrew Pinski --- (In reply to Riccardo Mutschlechner from comment #21) > Not sure if this is the best place to start, but here goes. I've noticed > another similar issue. > > Let's say you've compiled a binary, `test`, from a source `test.c`. If you > then flip the arguments to gcc by mistake, `gcc -o test.c test` rather than > `gcc -o test test.c`, you will overwrite the source file by trying to > compile the binary, thus losing it permanently without some other backup. That is PR 80182 really.
[Bug c++/113914] GCC accepts user-defined integer-literal that does not fit in any type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113914 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Known to fail||4.7.1 Last reconfirmed||2024-02-13 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. Looks not to be a regression either.
[Bug c++/113914] New: GCC accepts user-defined integer-literal that does not fit in any type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113914 Bug ID: 113914 Summary: GCC accepts user-defined integer-literal that does not fit in any type Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: janschultke at googlemail dot com Target Milestone: --- > int operator""_zero(unsigned long long); > int x = 0x1_zero; This code is ill-formed but GCC does not emit a diagnostic (https://godbolt.org/z/r9KrGGafY). Note that as per https://eel.is/c++draft/lex.ext#3, this is treated like a call: > operator""_zero(0x1000...000ULL) However, the ULL-suffixed integer-literal would be ill-formed. Clang reject this.
[Bug target/90155] aarch64: too much quoting in diagnostic for %d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90155 --- Comment #2 from Andrew Pinski --- Patch finally submitted: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645516.html
[Bug c++/113760] [DR1693] gcc rejects valid empty-declaration in pedantic mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760 --- Comment #17 from Marek Polacek --- Partially fixed for GCC 14. Leaving this open for more changes in GCC 15.
[Bug c++/113760] [DR1693] gcc rejects valid empty-declaration in pedantic mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760 --- Comment #16 from GCC Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:6fec511f2d23cc70ab29d1ba79c2415ab51bcb60 commit r14-8967-g6fec511f2d23cc70ab29d1ba79c2415ab51bcb60 Author: Marek Polacek Date: Tue Feb 13 16:21:32 2024 -0500 c++: adjust the extra ; warning [PR113760] A minimal fix to quash an extra ; warning. I have a more complete patch for GCC 15. DR 1693 PR c++/113760 gcc/cp/ChangeLog: * parser.cc (cp_parser_member_declaration): Only pedwarn about an extra semicolon in C++98. gcc/testsuite/ChangeLog: * g++.dg/semicolon-fixits.C: Run in C++98 only. * g++.dg/warn/pedantic2.C: Adjust dg-warning. * g++.old-deja/g++.jason/parse11.C: Adjust dg-error. * g++.dg/DRs/dr1693-1.C: New test. * g++.dg/DRs/dr1693-2.C: New test.
[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 --- Comment #7 from Jerry DeLisle --- Submitted for approval.
[Bug target/113913] [14] RISC-V: suboptimal code gen for intrinsic vcreate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113913
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-02-13
Keywords||ra
--- Comment #1 from Andrew Pinski ---
This looks like a subreg issue:
```
(insn 18 17 8 2 (set (reg:RVVM2SF 134 [ ])
(if_then_else:RVVM2SF (unspec:RVVMF16BI [
(const_vector:RVVMF16BI repeat [
(const_int 1 [0x1])
])
(reg:DI 138)
(const_int 2 [0x2]) repeated x2
(const_int 1 [0x1])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(const_vector:RVVM2SF repeat [
(const_double:SF 0.0 [0x0.0p+0])
])
(unspec:RVVM2SF [
(reg:DI 0 zero)
] UNSPEC_VUNDEF))) "/app/example.c":12:10 3943
{*pred_broadcastrvvm2sf_imm}
(expr_list:REG_DEAD (reg:DI 138)
(expr_list:REG_DEAD (reg:SI 67 vtype)
(expr_list:REG_DEAD (reg:SI 66 vl)
(expr_list:REG_DEAD (reg:DI 0 zero)
(expr_list:REG_EQUAL (const_vector:RVVM2SF repeat [
(const_double:SF 0.0 [0x0.0p+0])
])
(nil)))
(insn 8 18 9 2 (set (subreg:RVVM1SF (reg:RVVM2SF 134 [ ]) 0)
(reg:RVVM1SF 139)) "/app/example.c":12:10 2591 {*movrvvm1sf_whole}
(expr_list:REG_DEAD (reg:RVVM1SF 139)
(nil)))
(insn 9 8 13 2 (set (subreg:RVVM1SF (reg:RVVM2SF 134 [ ]) [16, 16])
(reg:RVVM1SF 140)) "/app/example.c":12:10 2591 {*movrvvm1sf_whole}
(expr_list:REG_DEAD (reg:RVVM1SF 140)
(nil)))
```
Confirmed. There are others like this too.
Though I wonder if we emit:
(clobber (reg:RVVM2SF 134 [ ]))
When expanding __riscv_vcreate_v_f32m1_f32m2 and friends. If that might help.
The other thing is init-reg gets in the way and adds:
```
(insn 17 16 18 2 (set (reg:DI 138)
(unspec:DI [
(const_int 8 [0x8])
] UNSPEC_VLMAX)) "/app/example.c":6:10 -1
(nil))
(insn 18 17 8 2 (set (reg:RVVM2HF 134 [ ])
(if_then_else:RVVM2HF (unspec:RVVMF8BI [
(const_vector:RVVMF8BI repeat [
(const_int 1 [0x1])
])
(reg:DI 138)
(const_int 2 [0x2]) repeated x2
(const_int 1 [0x1])
(reg:SI 66 vl)
(reg:SI 67 vtype)
] UNSPEC_VPREDICATE)
(const_vector:RVVM2HF repeat [
(const_double:HF 0.0 [0x0.0p+0])
])
(unspec:RVVM2HF [
(reg:DI 0 zero)
] UNSPEC_VUNDEF))) "/app/example.c":6:10 -1
(expr_list:REG_EQUAL (const_vector:RVVM2HF repeat [
(const_double:HF 0.0 [0x0.0p+0])
])
(nil)))
```
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #11 from Joseph S. Myers --- As I said in comment#2, I prefer a constant suffix for __int128 to the wb/uwb hack - I think it's cleaner, as well as allowing int128_t to work properly on all the targets that support __int128 but have not so far had an ABI for _BitInt defined, or not had such an ABI implemented in GCC. (I also think it's time to chase up target maintainers for all the architectures that don't yet have _BitInt support, which is almost all of them, inviting them to sort out an ABI definition either locally in GCC, in conjunction with other implementations or in an actual ABI document, as appropriate depending on the extent to which GCC for that target tries to interoperate with other implementations or externally defined ABIs, and then add the support, but that's a separate matter.)
[Bug target/113913] New: [14] RISC-V: suboptimal code gen for intrinsic vcreate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113913
Bug ID: 113913
Summary: [14] RISC-V: suboptimal code gen for intrinsic vcreate
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ewlu at rivosinc dot com
Target Milestone: ---
godbolt: https://godbolt.org/z/svPsddaTd
Functions like
vfloat16m2_t
test_vcreate_v_f16m1_f16m2 (vfloat16m1_t v0, vfloat16m1_t v1)
{
return __riscv_vcreate_v_f16m1_f16m2 (v0, v1);
}
are generating code like
test_vcreate_v_f16m1_f16m2:
vmv1r.v v11,v8
vmv1r.v v10,v9
vmv1r.v v8,v11
vmv1r.v v9,v10
ret
which should be optimized away into a nop like later functions in the testcase
test_vcreate_v_i64m2_i64m8:
ret
[Bug testsuite/113899] Vect module test failures while running on remote host due to default dg-do set to compile and additional-sources being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113899 --- Comment #3 from Andrew Pinski --- Note I do think there is something wrong with your remote testing too but that is only slightly related. check_sse_hw_available should still be returning 1 there since SSE should always be available for x86_64-linux. You might want to check the full log to see why check_sse_hw_available is not working. Maybe it is not picking up the libraries or something like that. Maybe the run testcases are failing but you might not be noticing that.
[Bug testsuite/113899] Vect module test failures while running on remote host due to default dg-do set to compile and additional-sources being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113899 --- Comment #2 from Andrew Pinski --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645507.html
[Bug target/113912] push2/pop2 generated when stack isn't aligned to 16 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113912 H.J. Lu changed: What|Removed |Added Target Milestone|--- |14.0 Last reconfirmed||2024-02-13 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- A patch is at https://patchwork.sourceware.org/project/gcc/list/?series=30889
[Bug fortran/113866] ice in generic_simplify_COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113866 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14.
[Bug middle-end/113904] [OpenMP][5.0][5.1] Dynamic context selector 'user={condition(expr)}' not handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904 --- Comment #4 from sandra at gcc dot gnu.org --- Dynamic selectors are completely broken on mainline, since the patches that at least partially implements this feature for metadirectives has not been approved or committed yet. I'm also very much aware that there is not even a proposed patch to make this work for "declare variant" yet, although the metadirectives work provides the underlying primitives that ought to be adaptable for "declare variant" as well. I suggest not messing around with incremental fixes meanwhile that would step on the already-posted patches which cannot be considered until GCC 14 has branched. https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642005.html
[Bug testsuite/113899] Vect module test failures while running on remote host due to default dg-do set to compile and additional-sources being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113899
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Summary|Vect module test failures |Vect module test failures
|while running on remote |while running on remote
|host|host due to default dg-do
||set to compile and
||additional-sources being
||used
Ever confirmed|0 |1
Last reconfirmed||2024-02-13
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Andrew Pinski ---
Confirmed.
Basically the testcases with additional-sources should always have a `{ dg-do
run } ` set for them instead of doing the default (which can either be run or
compile depending on what target-supports.exp sets).
There is only 2 testcases which uses additional-sources:
gcc.dg/vect/vect-simd-clone-10.c
gcc.dg/vect/vect-simd-clone-12.c
So I am going to fix those 2 to use `{ dg-do run }`
[Bug target/113912] New: push2/pop2 generated when stack isn't aligned to 16 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113912
Bug ID: 113912
Summary: push2/pop2 generated when stack isn't aligned to 16
bytes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com
Target Milestone: ---
Target: x86-64
[hjl@gnu-cfl-3 apx-1]$ cat x.c
extern int bar (int);
void foo ()
{
int a,b,c,d,e,f,i;
a = bar (5);
b = bar (a);
c = bar (b);
d = bar (c);
e = bar (d);
f = bar (e);
for (i = 1; i < 10; i++)
{
a += bar (a + i) + bar (b + i) +
bar (c + i) + bar (d + i) +
bar (e + i) + bar (f + i);
}
}
[hjl@gnu-cfl-3 apx-1]$ make
/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-gitlab-debug/build-x86_64-linux/gcc/ -mapxf
-O2 -mpreferred-stack-boundary=3 -fomit-frame-pointer -S x.c
[hjl@gnu-cfl-3 apx-1]$ cat x.s
.file "x.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
pushp %r15
.cfi_def_cfa_offset 16
.cfi_offset 15, -16
movl$5, %edi
push2p %r13, %r14
.cfi_def_cfa_offset 32
.cfi_offset 14, -24
.cfi_offset 13, -32
push2p %rbp, %r12
.cfi_def_cfa_offset 48
.cfi_offset 12, -40
.cfi_offset 6, -48
pushp %rbx
.cfi_def_cfa_offset 56
.cfi_offset 3, -56
movl$1, %ebx
subq$8, %rsp
.cfi_def_cfa_offset 64
callbar
movl%eax, %edi
movl%eax, %r12d
callbar
movl%eax, %edi
movl%eax, %r15d
callbar
movl%eax, %edi
movl%eax, %r14d
callbar
movl%eax, %edi
movl%eax, %r13d
callbar
movl%eax, %edi
movl%eax, (%rsp)
callbar
movl%eax, 4(%rsp)
.p2align 4,,10
.p2align 3
.L2:
leal(%r12,%rbx), %edi
callbar
leal(%r15,%rbx), %edi
movl%eax, %ebp
callbar
leal(%r14,%rbx), %edi
addl%eax, %ebp
callbar
leal0(%r13,%rbx), %edi
addl%eax, %ebp
callbar
addl%ebx, (%rsp), %edi
addl%eax, %ebp
callbar
addl%ebx, 4(%rsp), %edi
addl$1, %ebx
addl%eax, %ebp
callbar
addl%eax, %ebp
addl%ebp, %r12d
cmpl$10, %ebx
jne .L2
addq$8, %rsp
.cfi_def_cfa_offset 56
popp%rbx
.cfi_def_cfa_offset 48
pop2p %r12, %rbp
.cfi_restore 12
.cfi_restore 6
.cfi_def_cfa_offset 32
pop2p %r14, %r13
.cfi_restore 14
.cfi_restore 13
.cfi_def_cfa_offset 16
popp%r15
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 14.0.1 20240213 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-3 apx-1]$
With -mpreferred-stack-boundary=3, the coming stack is 8-byte aligned.
push2/pop2
shouldn't be generated in this case.
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #10 from Jakub Jelinek --- #if 42 == ((__int128) +42wb) && -35 == ((__int128) +-35wb) #else #warning warn #endif works with both gcc and clang if __BITINT_MAXWIDTH__ >= 128. That said, for UINT128_C it would need to use __uint128_t rather than unsigned __int128, as the latter doesn't work in preprocessor expressions, as that is interpreted as ((0 0) +42wb) then.
[Bug fortran/113911] [14 Regression] Length is lost passing deferred-length character to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911 --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #4) > Running f951 on the testcase under valgrind shows (among others) a > frontend memleak in gfc_resolve_substring_charlen, obviously fixed by Slash that. It produces many regressions in the testsuite...
[Bug fortran/113911] [14 Regression] Length is lost passing deferred-length character to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911
--- Comment #4 from anlauf at gcc dot gnu.org ---
Running f951 on the testcase under valgrind shows (among others) a
frontend memleak in gfc_resolve_substring_charlen, obviously fixed by
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 44f89f6afb4..b1f36efb10b 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -5392,11 +5392,7 @@ gfc_resolve_substring_charlen (gfc_expr *e)
end = NULL;
if (!start || !end)
-{
- gfc_free_expr (start);
- gfc_free_expr (end);
- return;
-}
+goto cleanup;
/* Length = (end - start + 1).
Check first whether it has a constant length. */
@@ -5431,6 +5427,10 @@ gfc_resolve_substring_charlen (gfc_expr *e)
/* Make sure that the length is simplified. */
gfc_simplify_expr (e->ts.u.cl->length, 1);
gfc_resolve_expr (e->ts.u.cl->length);
+
+cleanup:
+ gfc_free_expr (start);
+ gfc_free_expr (end);
}
[Bug middle-end/113904] [OpenMP][5.0][5.1] Dynamic context selector 'user={condition(expr)}' not handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904
--- Comment #3 from Tobias Burnus ---
See comment 1 for remaining to-do items.
I also note that the Fortran resolution comes too early - during parsing - as
the following shows:
module m
implicit none
contains
subroutine test
!$omp declare variant (foo) match(user={condition(myTrue)})
!$omp declare variant (bar) match(user={condition(myCond(1).and.myCond(2))})
logical, parameter :: myTrue = .true.
end
subroutine foo; end
subroutine bar; end
logical function myCond(i)
integer :: i
myCond = i < 3
end
end module m
This fails with the complete bogus:
5 | !$omp declare variant (foo) match(user={condition(myTrue)})
| 1
Error: property must be a constant logical expression at (1)
As 'myTrue' is a scalar logical PARAMETER.
The problem is just that this is not known when parsing '!$omp' - for that
reason, Fortran separates parsing and resolution, which the current code does
not handle as it comes way too early.
* * *
Otherwise: It looks as if - except for simple variable names (and probablyalso
for functions calls w/o arguments) - we want to introduce an internal aux
function like:
logical function __m_MOD_test_DV_cond1() result(res)
res = myCond(1).and.myCond(2)
end
which is then called when evaluating the run-time expression.
With header files and, possibly, also C++ modules, we might be able to always
inline the condition - with Fortran modules probably not, such that an aux
function would be needed for the generic case.
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #9 from Jens Gustedt --- (In reply to Jakub Jelinek from comment #8) > > #define INT128_C(N) ((__int128)+ N ## W) > > You mean WB? Yes, probably ;-) > > With that observation you easily also create `MIN` and `MAX` macros > > > > #define INT128_MAX (INT128_C(1) << 126) > > That is certainly not the right INT128_MAX. Yes, again, sorry. I should not post these things when I am too tired. But I hope you get the idea that some form of constant expression with some bit operations will do the trick.
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #8 from Jakub Jelinek --- (In reply to Jens Gustedt from comment #7) > (In reply to Joseph S. Myers from comment #5) > > ... including __INT128_C and __UINT128_C > > defined to use an appropriate constant suffix. > > You don't need a specific suffix for these types if you have `_BitInt(128)`, > there is no need to invest thoughts or development time in this. > Something like > > #define INT128_C(N) ((__int128)+ N ## W) You mean WB? > With that observation you easily also create `MIN` and `MAX` macros > > #define INT128_MAX (INT128_C(1) << 126) That is certainly not the right INT128_MAX. The right value is INT128_C (170141183460469231731687303715884105727) while INT128_C(1) << 126 is just INT128_C (85070591730234615865843651857942052864).
[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 --- Comment #6 from Jerry DeLisle --- I have reapplied the patch in comment #3 and it regression tests fine and appears to fix the issue. I have need to work up the test case and submit this for approval.
[Bug target/113876] ICE: in ix86_expand_epilogue, at config/i386/i386.cc:10101 with -O -mpreferred-stack-boundary=3 -finstrument-functions -mapxf -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113876 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from H.J. Lu --- Fixed.
[Bug target/113876] ICE: in ix86_expand_epilogue, at config/i386/i386.cc:10101 with -O -mpreferred-stack-boundary=3 -finstrument-functions -mapxf -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113876 --- Comment #3 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:ab71fd7ac7a2307723117c796e7ae4d7e9711058 commit r14-8966-gab71fd7ac7a2307723117c796e7ae4d7e9711058 Author: H.J. Lu Date: Tue Feb 13 11:58:00 2024 -0800 x86-64: Use push2/pop2 only if the incoming stack is 16-byte aligned Since push2/pop2 requires 16-byte stack alignment, don't use them if the incoming stack isn't 16-byte aligned. gcc/ PR target/113876 * config/i386/i386.cc (ix86_pro_and_epilogue_can_use_push2pop2): Return false if the incoming stack isn't 16-byte aligned. gcc/testsuite/ PR target/113876 * gcc.target/i386/pr113876.c: New test.
[Bug fortran/113911] [14 Regression] Length is lost passing deferred-length character to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911
--- Comment #3 from anlauf at gcc dot gnu.org ---
The following semi-obvious patch seems to fix it:
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 2181990aa04..7fc409140b0 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -11531,7 +11607,7 @@ gfc_trans_deferred_array (gfc_symbol * sym,
gfc_wrapped_block * block)
if (sym->ts.type == BT_CHARACTER
&& !INTEGER_CST_P (sym->ts.u.cl->backend_decl))
{
- if (sym->ts.deferred && !sym->ts.u.cl->length)
+ if (sym->ts.deferred && !sym->ts.u.cl->length && !sym->attr.dummy)
gfc_add_modify (, sym->ts.u.cl->backend_decl,
build_zero_cst (TREE_TYPE
(sym->ts.u.cl->backend_decl)));
gfc_conv_string_length (sym->ts.u.cl, NULL, );
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #7 from Jens Gustedt --- (In reply to Joseph S. Myers from comment #5) > ... including __INT128_C and __UINT128_C > defined to use an appropriate constant suffix. You don't need a specific suffix for these types if you have `_BitInt(128)`, there is no need to invest thoughts or development time in this. Something like #define INT128_C(N) ((__int128)+ N ## W) would do. If 128 is more than `INTMAX_WIDTH` the resulting constants are exempted by C23 of being suitable for preprocessor arithmetic. But if it is indeed 128, the expression still is an integer constant expression, even in the preprocessor. With that observation you easily also create `MIN` and `MAX` macros #define INT128_MAX (INT128_C(1) << 126) #define INT128_MIN (-INT128_MAX - 1)
[Bug target/113876] ICE: in ix86_expand_epilogue, at config/i386/i386.cc:10101 with -O -mpreferred-stack-boundary=3 -finstrument-functions -mapxf -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113876 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-13 Target Milestone|--- |14.0 CC||crazylht at gmail dot com Ever confirmed|0 |1 --- Comment #2 from H.J. Lu --- A patch is at https://patchwork.sourceware.org/project/gcc/list/?series=30888
[Bug middle-end/113904] [OpenMP][5.0][5.1] Dynamic context selector 'user={condition(expr)}' not handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904
--- Comment #2 from GCC Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:a5d34b60c949e85aa3e213872fbc42f4eee7457b
commit r14-8965-ga5d34b60c949e85aa3e213872fbc42f4eee7457b
Author: Tobias Burnus
Date: Tue Feb 13 20:55:26 2024 +0100
OpenMP: Reject non-const 'condition' trait in Fortran
OpenMP 5.0 only permits constant expressions for the 'condition' trait
in context selectors; this is relaxed in 5.2 but not implemented. In order
to avoid wrong code, it is now rejected.
Additionally, in Fortran, 'condition' should not accept an integer
expression, which is now ensured. Additionally, as 'device_num' should be
a conforming device number, there is now a check on the value.
PR middle-end/113904
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_context_selector): Handle splitting of
OMP_TRAIT_PROPERTY_EXPR into
OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_omp_context_selector): Handle splitting of
OMP_TRAIT_PROPERTY_EXPR into
OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
gcc/fortran/ChangeLog:
* trans-openmp.cc (gfc_trans_omp_declare_variant): Handle splitting
of
OMP_TRAIT_PROPERTY_EXPR into
OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
* openmp.cc (gfc_match_omp_context_selector): Likewise; rejects
non-const device_num/condition; improve diagnostic.
gcc/ChangeLog:
* omp-general.cc (struct omp_ts_info): Update for splitting of
OMP_TRAIT_PROPERTY_EXPR into
OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
* omp-selectors.h (enum omp_tp_type): Replace
OMP_TRAIT_PROPERTY_EXPR by OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/declare-variant-1.f90: Change 'condition'
trait's
argument from integer to a logical expression.
* gfortran.dg/gomp/declare-variant-11.f90: Likewise.
* gfortran.dg/gomp/declare-variant-12.f90: Likewise.
* gfortran.dg/gomp/declare-variant-13.f90: Likewise.
* gfortran.dg/gomp/declare-variant-2.f90: Likewise.
* gfortran.dg/gomp/declare-variant-2a.f90: Likewise.
* gfortran.dg/gomp/declare-variant-3.f90: Likewise.
* gfortran.dg/gomp/declare-variant-4.f90: Likewise.
* gfortran.dg/gomp/declare-variant-6.f90: Likewise.
* gfortran.dg/gomp/declare-variant-8.f90: Likewise.
* gfortran.dg/gomp/declare-variant-20.f90: New test.
[Bug fortran/113911] [14 Regression] Length is lost passing deferred-length character to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911
--- Comment #2 from anlauf at gcc dot gnu.org ---
Looking at the tree-dump before and after r14-8947, I see:
- a change in the main program that seems to be desirable:
bitsizetype D.4340;
sizetype D.4341;
+ *_c6 = 0;
D.4339 = *_c6;
D.4340 = (bitsizetype) (sizetype) NON_LVALUE_EXPR <*_c6> * 8;
D.4341 = (sizetype) NON_LVALUE_EXPR <*_c6>;
- a change in the subroutine that kills the length:
__attribute__((fn spec (". w w ")))
void deferred (character(kind=1)[1:*_c5] * & restrict c5, struct
array01_character(kind=1) & restrict c6, integer(kind=8) * _c5, integer(kind=8)
* _c6)
{
integer(kind=8) D.4339;
bitsizetype D.4340;
sizetype D.4341;
+ *_c6 = 0;
D.4339 = *_c6;
D.4340 = (bitsizetype) (sizetype) NON_LVALUE_EXPR <*_c6> * 8;
D.4341 = (sizetype) NON_LVALUE_EXPR <*_c6>;
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #6 from Jens Gustedt --- (In reply to Joseph S. Myers from comment #5) > Compiler and library are not in practice independent for this issue ... For this particular issue they are indeed independent. As said, I have proof of concept that it works with patches for musl, only gcc is whining because it doesn't understand the `w128` flag. Otherwise, it is fully functional. Again, I am not asking that gcc implements full support for the `int128_t` type alias. I am only asking that `w128` is recognized if and only if the compiler has `__int128` and if so, does the right diagnosis for the argument type. And this has nothing to do with free standing, only with hosted environments. This is not enabling `int128_t` but enabling C libraries to provide `int128_t` on top of `__int128` if they are able to fill in the gaps. And indeed, once there is `_BitInt(128)` in the compiler and then the library provides the `w128` an `wf128` flags, everything is indeed easily filled. For freestanding which doesn't need things are even simpler, they only need `_BitInt(128)` to provide the `.._C` macros if they know that they have `__int128`.
[Bug c++/113760] [DR1693] gcc rejects valid empty-declaration in pedantic mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #15 from Marek Polacek --- Patch posted. I don't foresee it being part of GCC 14. https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645494.html
[Bug fortran/113911] [14 Regression] Length is lost passing deferred-length character to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911 --- Comment #1 from anlauf at gcc dot gnu.org --- Created attachment 57418 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57418=edit Testcase Extended testcase that works with gcc-13. The deferred-length dummy may be optional or not; both fail the same way.
[Bug fortran/113866] ice in generic_simplify_COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113866 --- Comment #4 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f4935df217ad89f884f908f39086b322e80123d0 commit r14-8961-gf4935df217ad89f884f908f39086b322e80123d0 Author: Harald Anlauf Date: Tue Feb 13 20:19:10 2024 +0100 Fortran: fix passing of optional dummies to bind(c) procedures [PR113866] PR fortran/113866 gcc/fortran/ChangeLog: * trans-expr.cc (gfc_conv_procedure_call): When passing an optional dummy argument to an optional dummy argument of a bind(c) procedure and the dummy argument is passed via a CFI descriptor, no special presence check and passing of a default NULL pointer is needed. gcc/testsuite/ChangeLog: * gfortran.dg/bind_c_optional-2.f90: New test.
[Bug rtl-optimization/113903] sched1 should schedule across EBBS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113903 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement CC||pinskia at gcc dot gnu.org
[Bug c++/106009] [modules] internal compiler error: in import_entity_index with templated local enum in header unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106009
Patrick Palka changed:
What|Removed |Added
Last reconfirmed||2024-02-13
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords||ice-checking,
||ice-on-valid-code
--- Comment #3 from Patrick Palka ---
FWIW also crash from import_entity_index if we use an undefined local struct:
template
void format_decimal(T) {
struct blah;
}
but not if we define it:
template
void format_decimal(T) {
struct blah {};
}
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 99568, which changed state. Bug 99568 Summary: ICE when compiling basic module: internal compiler error: in module_may_redeclare, at cp/module.cc:18453 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99568 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/99568] ICE when compiling basic module: internal compiler error: in module_may_redeclare, at cp/module.cc:18453
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99568 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- Seems this is fixed since GCC 12 at least.
[Bug fortran/113911] [14 Regression] Length is lost passing deferred-length character to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |14.0
[Bug fortran/113911] New: [14 Regression] Length is lost passing deferred-length character to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113911 Bug ID: 113911 Summary: [14 Regression] Length is lost passing deferred-length character to subroutine Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- As reported in https://gcc.gnu.org/pipermail/fortran/2024-February/060224.html the following testcase regressed after commit r14-8947: program p implicit none integer, parameter :: n = 100, l = 10 character(l) :: a = 'a234567890', b(n) = 'bcdefghijk' character(:), allocatable :: d, e(:) allocate (d, source=a) allocate (e, source=b) print *, len (d), len (e), size (e) call not_bindc_optional_deferred (d, e) deallocate (d, e) contains subroutine not_bindc_optional_deferred (c5, c6) character(:), allocatable, optional :: c5, c6(:) if (.not. present (c5) .or. .not. present (c6)) stop 6 print *, len (c5), len (c6), size (c6) if (len (c5) /= l .or. len (c6) /= l) stop 84 end end Expected: 10 10 100 10 10 100 After above commit: 10 10 100 10 0 100 STOP 84
[Bug target/113871] psrlq is not used for PERM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871 Uroš Bizjak changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Status|NEW |ASSIGNED --- Comment #4 from Uroš Bizjak --- Created attachment 57417 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57417=edit Proposed patch Patch in testing.
[Bug c++/113706] c-c++-common/pr103798-2.c FAILs as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706 Jason Merrill changed: What|Removed |Added Component|tree-optimization |c++ CC||jason at gcc dot gnu.org --- Comment #7 from Jason Merrill --- I think this is a front-end issue.
[Bug tree-optimization/113787] [12/13/14 Regression] Wrong code at -O with ipa-modref on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #15 from Jan Hubicka ---
>
> IVOPTs does the above but it does it (or should) as
>
> offset = (uintptr) - (uintptr)
> val = *((T *)((uintptr)base1 + i + offset))
>
> which is OK for points-to as no POINTER_PLUS_EXPR is involved so the
> resulting pointer points to both base1 and base2 (which isn't optimal
> but correct).
>
> If we somehow get back a POINTER_PLUS that's where things go wrong.
>
> Doing the above in C code would be valid input so we have to treat
> it correctly (OK, the standard only allows back-and-forth
> pointer-to-integer casts w/o any adjustment, but of course we relax
> this).
OK. Modrefs tracks base pointer for accesses and tries to prove that
they are function parameters. This should immitate ivopts:
void
__attribute__ ((noinline))
set(int *a, unsigned long off)
{
*(int *)((unsigned long)a + off) = 1;
}
int
test ()
{
int a;
int b = 0;
set (, (unsigned long) - (unsigned long));
return b;
}
Here set gets following gimple at modref2 time:
__attribute__((noinline))
void set (int * a, long unsigned int off)
{
long unsigned int a.0_1;
long unsigned int _2;
int * _3;
[local count: 1073741824]:
a.0_1 = (long unsigned int) a_4(D);
_2 = a.0_1 + off_5(D);
_3 = (int *) _2;
*_3 = 1;
return;
}
This is not pattern matched so modref does not think the access has a as
a base:
stores:
Base 0: alias set 1
Ref 0: alias set 1
Every access
While for:
void
__attribute__ ((noinline))
set(int *a, unsigned long off)
{
*(a+off/sizeof(int))=1;
}
we produce:
__attribute__((noinline))
void set (int * a, long unsigned int off)
{
sizetype _1;
int * _2;
[local count: 1073741824]:
_1 = off_3(D) & 18446744073709551612;
_2 = a_4(D) + _1;
*_2 = 1;
return;
}
And this is understood:
stores:
Base 0: alias set 1
Ref 0: alias set 1
access: Parm 0
If we consider it correct to optimize out the conversion from and to
pointer type, then I suppose any addition of pointer and integer which
we do not see means that we need to give up on tracking base completely.
I guess PTA gets around by tracking points-to set also for non-pointer
types and consequently it also gives up on any such addition.
But what we really get from relaxing this?
>
> IVOPTs then in putting all of the stuff into 'offset' gets at
> trying a TARGET_MEM_REF based on a NULL base but that's invalid.
> We then resort to a LEA (ADDR_EXPR of TARGET_MEM_REF) to compute
> the address which gets us into some phishy argument that it's
> not valid to decompose ADDR_EXPR of TARGET_MEM_REF to
> POINTER_PLUS of the TARGET_MEM_REF base and the offset. But
> that's how it is (points-to treats (address of) TARGET_MEM_REF
> as pointing to anything ...).
>
> > A quick fix would be to run IPA modref before ivopts, but I do not see how
> > such
> > transformation can work with rest of alias analysis (PTA etc)
>
> It does. Somewhere IPA modref interprets things wrongly, I didn't figure
> out here though.
I guess PTA gets around by tracking points-to set also for non-pointer
types and consequently it also gives up on any such addition.
I think it is ipa-prop.c::unadjusted_ptr_and_unit_offset. It accepts
pointer_plus expression, but does not look through POINTER_PLUS.
We can restrict it further, but tracking base pointer is quite useful,
so it would be nice to not give up completely.
Honza
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
[Bug target/113876] ICE: in ix86_expand_epilogue, at config/i386/i386.cc:10101 with -O -mpreferred-stack-boundary=3 -finstrument-functions -mapxf -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113876
Jakub Jelinek changed:
What|Removed |Added
Summary|ICE: in |ICE: in
|ix86_expand_epilogue, at|ix86_expand_epilogue, at
|config/i386/i386.cc:10101 |config/i386/i386.cc:10101
|with -O |with -O
|-mpreferred-stack-boundary= |-mpreferred-stack-boundary=
|3 -finstrument-functions|3 -finstrument-functions
|-mapxf -mcmodel=large and |-mapxf -mcmodel=large
|_BitInt() |
CC||hjl.tools at gmail dot com,
||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Doesn't need UB in the testcase to reproduce,
/* { dg-options "-O -mpreferred-stack-boundary=3 -finstrument-functions -mapxf
-mcmodel=large" } */
_BitInt(129)
bar (void)
{
return 0;
}
ICEs too.
And it doesn't have to do anything together with _Bitint either,
/* { dg-options "-O -mpreferred-stack-boundary=3 -finstrument-functions -mapxf
-mcmodel=large" } */
void
bar (unsigned long *p)
{
p[0] = 0;
p[1] = 0;
p[2] = 0;
}
ICEs the same.
[Bug middle-end/113904] [OpenMP][5.0][5.1] Dynamic context selector 'user={condition(expr)}' not handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113904
--- Comment #1 from Tobias Burnus ---
Patch for rejecting non-const arguments in Fortran (wrong-code bit) to bring it
in line with C/C++:
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645488.html
* * *
TODO as follow up:
* Permit non-constant values for 'condition' and also for 'device_num'
-> Middle end changes + update all front ends accordingly
* For C/C++, consider rejecting nonconforming device numbers, if
known at compile time, i.e. only permit positive numbers and
omp_initial_device_number (= -1) and omp_invalid_device_number (GCC: -4).
Cf. OpenMP Issue 3832 for the 'conforming' bit.
[Current spec wording only permits 0 ... < omp_get_num_devices(),
i.e. neither the host (= omp_initial_device and == omp_get_num_devices())
or omp_invalid_device_number are not permitted as explicit value;
however, if absent, it is as if the trait appeared with the
default-device-var ICV, which permits the discussed values.]
-> If device_num(-4) (= omp_invalid_device_number), the selector can be
folded to not matching.
* Possible testcases for some of the features discussed here:
- https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645472.html
- the OpenMP 6.0 Examples' program_control/sources/dispatch.1.{c,f90}
[Bug fortran/113883] allocatable length parameter used but is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113883 --- Comment #4 from Steve Kargl --- On Tue, Feb 13, 2024 at 04:51:02AM +, cvs-commit at gcc dot gnu.org wrote: > The trunk branch has been updated by Jerry DeLisle : > > https://gcc.gnu.org/g:6caec7d9ec37e60e718a12934c85bac9c12757ac > Thanks, Jerry.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #24 from Jakub Jelinek ---
static inline int
foo (int len, void *indata, void *outdata)
{
if (len < 0 || (len & 7) != 0)
return 0;
if (len != 0 && indata != outdata)
__builtin_memcpy (outdata, indata, len);
return len;
}
static inline int
bar (int len, void *indata, void *outdata)
{
if (len < 0 || (len & 1) != 0)
return 0;
if (len != 0 && indata != outdata)
__builtin_memcpy (outdata, indata, len);
return len;
}
int (*volatile p1) (int, void *, void *) = foo;
int (*volatile p2) (int, void *, void *) = bar;
__attribute__((noipa)) int
baz (int len, void *indata, void *outdata)
{
if ((len & 6) != 0)
bar (len, indata, outdata);
else
foo (len, indata, outdata);
}
int
main ()
{
char buf[13] = "abcdefghijkl";
p2 (6, buf, buf + 6);
if (__builtin_strcmp (buf, "abcdefabcdef"))
__builtin_abort ();
}
Reproduces the wrong range in bar, but still doesn't crash nor abort. So I
probably need some different size of the copying.
[Bug c++/113612] [13/14 Regression] ICE: SIGSEGV in get_template_info (pt.cc:378) or tree_check (tree.h:3611)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113612 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jason Merrill --- Fixed for 13.3/14.
[Bug c++/113612] [13/14 Regression] ICE: SIGSEGV in get_template_info (pt.cc:378) or tree_check (tree.h:3611)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113612 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ef7738d2d0ee0103946e5243aa7e5c8ad2fb0c6d commit r13-8324-gef7738d2d0ee0103946e5243aa7e5c8ad2fb0c6d Author: Jason Merrill Date: Mon Feb 12 21:00:53 2024 -0500 c++: variable partial spec redeclaration [PR113612] If register_specialization finds a previous declaration and throws the new one away, we shouldn't still add the new one to DECL_TEMPLATE_SPECIALIZATIONS. PR c++/113612 gcc/cp/ChangeLog: * pt.cc (process_partial_specialization): Return early on redeclaration. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/var-templ85.C: New test. (cherry picked from commit 19ac327de421fe05916e234e3450e6e1cc5c935c)
[Bug c++/113612] [13/14 Regression] ICE: SIGSEGV in get_template_info (pt.cc:378) or tree_check (tree.h:3611)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113612 --- Comment #5 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:19ac327de421fe05916e234e3450e6e1cc5c935c commit r14-8960-g19ac327de421fe05916e234e3450e6e1cc5c935c Author: Jason Merrill Date: Mon Feb 12 21:00:53 2024 -0500 c++: variable partial spec redeclaration [PR113612] If register_specialization finds a previous declaration and throws the new one away, we shouldn't still add the new one to DECL_TEMPLATE_SPECIALIZATIONS. PR c++/113612 gcc/cp/ChangeLog: * pt.cc (process_partial_specialization): Return early on redeclaration. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/var-templ85.C: New test.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #23 from Jakub Jelinek --- (In reply to Andrew Pinski from comment #22) > (In reply to Andrew Pinski from comment #21) > > Yep that is the same descriptions as what is happening in PR 113665. > > Specifically https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665#c5 . Indeed. But this bug is a P1 while the other one P2.
[Bug tree-optimization/113910] [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from Andrew Pinski --- >>Configure with --enable-checking=release to disable checks. I'm seeing the same slowdown with release builds of GCC 12.3.0 and 13.2.0. > Can you try that if you are comparing compile times? > Some of the slow down is definitely related to that: >> tree SSA verifier : 12.28 ( 1%) 0.02 ( 0%) 12.12 ( 1%) 0 ( 0%) >> tree STMT verifier : 18.62 ( 1%) 0.00 ( 0%) 18.79 ( 1%) 0 ( 0%) >> CFG verifier : 9.77 ( 0%) 0.01 ( 0%) 10.01 ( 1%) 0 ( 0%) >> verify RTL sharing : 12.45 ( 1%) 0.01 ( 0%) 12.46 ( 1%) 0 ( 0%) > > > For an example. 13.2.0 takes real 19.59 user 16.05 sys3.43 but was still in the half-hour range with the original full set of flags. I'll retry that and report.
[Bug target/113742] ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx set) in riscv_macro_fusion_pair_p, at config/riscv/riscv.cc:8416 with -O2 -finstrument-functions -mtune=sifive-p600-se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113742 --- Comment #2 from GCC Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:7eac19be5f7dd92fcbcfe13f6edbb4f9bd45c15c commit r14-8959-g7eac19be5f7dd92fcbcfe13f6edbb4f9bd45c15c Author: Monk Chiang Date: Tue Feb 13 09:02:12 2024 -0700 Re: [PATCH] RISC-V: Fix macro fusion for auipc+add, when identifying UNSPEC_AUIPC. [PR113742] gcc/ChangeLog: PR target/113742 * config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Fix recognizes UNSPEC_AUIPC for RISCV_FUSE_LUI_ADDI. gcc/testsuite/ChangeLog: * gcc.target/riscv/pr113742.c: New test.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #22 from Andrew Pinski --- (In reply to Andrew Pinski from comment #21) > Yep that is the same descriptions as what is happening in PR 113665. Specifically https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113665#c5 .
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #21 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #20)
> Ah, I think it is IPA-ICF.
> What happens is that fnsplit splits the uprv_copyArray{16,32,64} functions,
> where the
> inline part does what is actually different among the functions,
...
> Now IPA-ICF comes, doesn't care about ranges, merges all 3 into one and
> picks there
> the most unfortunate case, the case from the copyData64 part with N 8.
> Later on we inline this back into the functions, the function splitting was
> useless.
Yep that is the same descriptions as what is happening in PR 113665.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
Jakub Jelinek changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #20 from Jakub Jelinek ---
Ah, I think it is IPA-ICF.
What happens is that fnsplit splits the uprv_copyArray{16,32,64} functions,
where the
inline part does what is actually different among the functions, i.e. the
tests which among other do the early out for
length<0 || (length&1)!=0
or
length<0 || (length&3)!=0
or
length<0 || (length&7)!=0
among other things, and then the *.part.0 parts which are exactly the same for
the 3 functions IL wise, except for the unfortunately differences in the
ranges.
So, essentially just
[local count: 132713219]:
_2 = length_1(D) != 0;
_5 = inData_3(D) != outData_4(D);
_6 = _2 & _5;
if (_6 != 0)
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 43795362]:
# RANGE [irange] unsigned int [N, 2147483647] MASK 0x7ffe VALUE 0x0
length.43_7 = (unsigned int) length_1(D);
# USE = anything
# CLB = anything
memcpy (outData_4(D), inData_3(D), length.43_7);
[local count: 132713219]:
[local count: 132713219]:
# RANGE [irange] int [0, 0][N, +INF] MASK 0x7fff VALUE 0x0
# _8 = PHI
return _8;
where N is 2, 4 or 8.
Now IPA-ICF comes, doesn't care about ranges, merges all 3 into one and picks
there
the most unfortunate case, the case from the copyData64 part with N 8.
Later on we inline this back into the functions, the function splitting was
useless.
So, the question is what to do in IPA-ICF. Should we punt on range
differences, reset all ranges or try to merge the ranges from all the functions
merged together?
I think the last would be best.
[Bug tree-optimization/113910] [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 Andrew Pinski changed: What|Removed |Added Keywords||compile-time-hog --- Comment #4 from Andrew Pinski --- >Configure with --enable-checking=release to disable checks. Can you try that if you are comparing compile times? Some of the slow down is definitely related to that: > tree SSA verifier : 12.28 ( 1%) 0.02 ( 0%) 12.12 ( > 1%) 0 ( 0%) > tree STMT verifier : 18.62 ( 1%) 0.00 ( 0%) 18.79 ( > 1%) 0 ( 0%) > CFG verifier : 9.77 ( 0%) 0.01 ( 0%) 10.01 ( > 1%) 0 ( 0%) > verify RTL sharing : 12.45 ( 1%) 0.01 ( 0%) 12.46 ( > 1%) 0 ( 0%) For an example.
[Bug target/113909] gcc.target/i386/pr113689-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113909 --- Comment #1 from H.J. Lu --- It fails on Solaris because of: sol2.h:#undef NO_PROFILE_COUNTERS Just skip these tests for Solaris.
[Bug c/113887] no support for %w128 length modifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113887 --- Comment #5 from Joseph S. Myers --- Compiler and library are not in practice independent for this issue. GCC typically provides for freestanding compilations and forwards to a libc version for hosted compilations, and in both cases it needs to know what the types are for correct format checking (for example, whether int64_t is long or long long) - and it needs to know that even in files that didn't include , and preferably the types should be the same for hosted and freestanding. In fact it needs to know the types even when not compiling C or C++ - Fortran ISO_C_BINDING supports those types (though the Fortran standard has a specific list, not mentioning int128_t or general intN_t). And to properly support implementation - whether in GCC's or one provided by libc - any int128_t support should come with all the associated predefined macros - including __INT128_C and __UINT128_C defined to use an appropriate constant suffix.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #19 from Jakub Jelinek ---
Diffing the -fdump-{tree,ipa}-all-alias dumps from r14-5108 and r14-5109,
085i.fnsummary still looks good (the 2/4/8 in the ranges corresponds to whether
it is in 16/32/64 suffixed/infixed function).
But the inline dump already contains presumably bogus
@@ -2426,7 +2426,7 @@ int32_t uprv_copyArray16 (const struct U
goto ; [67.00%]
[local count: 43795362]:
- # RANGE [irange] unsigned int [1, 2147483647] MASK 0x7ff8 VALUE 0x0
+ # RANGE [irange] unsigned int [8, 2147483647] MASK 0x7ff8 VALUE 0x0
length.37_21 = (unsigned int) length_14(D);
# USE = anything
# CLB = anything
@@ -2437,7 +2437,7 @@ int32_t uprv_copyArray16 (const struct U
_7 = _25;
[local count: 1073741824]:
- # RANGE [irange] int32_t [0, +INF] MASK 0x7fff VALUE 0x0
+ # RANGE [irange] int32_t [0, 0][2, +INF] MASK 0x7fff VALUE 0x0
# _6 = PHI <0(4), _7(12)>
return _6;
and
@@ -2660,7 +2660,7 @@ int32_t uprv_copyArray32 (const struct U
goto ; [67.00%]
[local count: 43795362]:
- # RANGE [irange] unsigned int [1, 2147483647] MASK 0x7ff8 VALUE 0x0
+ # RANGE [irange] unsigned int [8, 2147483647] MASK 0x7ff8 VALUE 0x0
length.37_21 = (unsigned int) length_14(D);
# USE = anything
# CLB = anything
@@ -2671,7 +2671,7 @@ int32_t uprv_copyArray32 (const struct U
_7 = _25;
[local count: 1073741824]:
- # RANGE [irange] int32_t [0, +INF] MASK 0x7fff VALUE 0x0
+ # RANGE [irange] int32_t [0, 0][4, +INF] MASK 0x7fff VALUE 0x0
# _6 = PHI <0(4), _7(12)>
return _6;
hunks, the return in those cases looks still right, but the length before
memcpy looks wrong.
[Bug tree-optimization/113910] [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 --- Comment #3 from Rainer Orth --- Created attachment 57416 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57416=edit GCC 14.0.1 -ftime-report output
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=113665 --- Comment #18 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #17) > What seems wrong is that the 8 in the ranges somehow leaks into copyData16 > during IPA. > IPA-ICF? If IPA-ICF, then PR 113665 is similar in nature.
[Bug tree-optimization/113910] [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 --- Comment #2 from Rainer Orth --- Created attachment 57415 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57415=edit GCC 11.4.0 -ftime-report output
[Bug tree-optimization/113910] [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 --- Comment #1 from Rainer Orth --- Created attachment 57414 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57414=edit preprocessed input
[Bug tree-optimization/113910] New: [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 Bug ID: 113910 Summary: [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Target: sparcv9-sun-solaris2.11 After GCC 11, compile time for LLVM's lib/Target/AMDGPU/Disassembler/AMDGPUDisassembler.cpp on 64-bit Solaris/SPARC regressed by a factor of 25: cc1plus -fpreprocessed AMDGPUDisassembler.cpp.ii -quiet -mcpu=v9 -O -std=c++17 -ftime-report -o AMDGPUDisassembler.cpp.s * GCC 11.4.0: real2:14.94 user2:09.96 sys4.83 * GCC 14.0.1: real 33:03.33 user 32:57.32 sys5.52 I'm attaching the preprocessed input and -ftime-report output for both.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #17 from Jakub Jelinek ---
One set of range changes in evrp is more precise ranges in return values of
uprv_swapArray{16,32,64}, those contain early return 0 if
length<0 || (length&1)!=0
or
length<0 || (length&3)!=0
or
length<0 || (length&7)!=0
so changing those return ranges from [0, +INF] to [0, 0][4, +INF] (for the
second, 2 or 8 instead of 4 for the first/last) seems completely reasonable.
And uprv_copyArray{16,32,64} has something very similar,
length<0 || (length&{1,3,7})!=0 early exit and length > 0 guarded memcpy.
So, even there it is completely reasonable to change
- # RANGE [irange] unsigned int [1, 2147483647] MASK 0x7ff8 VALUE 0x0
+ # RANGE [irange] unsigned int [8, 2147483647] MASK 0x7ff8 VALUE 0x0
length.37_10 = (unsigned int) length_25(D);
memcpy (outData_26(D), inData_24(D), length.37_10);
for the copy and
- # RANGE [irange] int32_t [0, +INF] MASK 0x7fff VALUE 0x0
+ # RANGE [irange] int32_t [0, 0][8, +INF] MASK 0x7fff VALUE 0x0
# _12 = PHI <0(4), 0(9), length_25(D)(12)>
return _12;
for the return, but naturally copyData16 uses 2 instead of 8 and copyData32 4
instead of 8.
What seems wrong is that the 8 in the ranges somehow leaks into copyData16
during IPA.
IPA-ICF?
[Bug tree-optimization/111457] [14 Regression] Dead Code Elimination Regression since r14-3407-g936a12331a2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111457 Filip Kastl changed: What|Removed |Added CC||pheeck at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Keywords|needs-bisection | --- Comment #2 from Filip Kastl --- Indeed. Current trunk successfully eliminates the call to foo. gcc testcase.c -S -O2 main: movl$0, a(%rip) xorl%eax, %eax movl$6, b(%rip) movl$0, d(%rip) ret Setting this as fixed.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #16 from Sam James ---
(In reply to Jakub Jelinek from comment #14
> So it certainly doesn't surprise me some length < 8 check is optimized away
> given the above range info. The question is if it is correct and what
> values the length actually get at runtime if you e.g. compile with -O0.
(gdb) b uprv_copyArray16
Breakpoint 1 at 0xf770e71b: file udataswp.cpp, line 147.
(gdb) b uprv_copyArray64
Breakpoint 2 at 0xf770e7ba: file udataswp.cpp, line 164.
(gdb) r
Breakpoint 1, uprv_copyArray16 (ds=0x5655e4f0, inData=0xf32a4010, length=2,
outData=0xf7f24094, pErrorCode=0xc47c) at udataswp.cpp:147
147 if(pErrorCode==nullptr || U_FAILURE(*pErrorCode)) {
(gdb) c
Continuing.
Breakpoint 1, uprv_copyArray16 (ds=0x5655e4f0, inData=0xf32a4014, length=4,
outData=0xf7f24098, pErrorCode=0xc47c) at udataswp.cpp:147
147 if(pErrorCode==nullptr || U_FAILURE(*pErrorCode)) {
(gdb) c
Continuing.
[Inferior 1 (process 2861598) exited normally]
(gdb)
Oops.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #15 from Andrew Pinski --- Note the range part looks correct when taking the mask into account so I am suspecting the mask is messed up. Let me see if I could spot it later today.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #14 from Jakub Jelinek --- There are significant differences in the ranges starting with evrp. Even optimized has: --- pr113907.ii.261t.optimized_ 2024-02-13 09:52:13.090609512 -0500 +++ pr113907.ii.261t.optimized 2024-02-13 09:53:35.691479080 -0500 @@ -576,7 +576,7 @@ int32_t uprv_copyArray16 (const struct U goto ; [67.00%] [local count: 43795362]: - # RANGE [irange] unsigned int [2, 2147483647] MASK 0x7ff8 VALUE 0x0 + # RANGE [irange] unsigned int [8, 2147483647] MASK 0x7ff8 VALUE 0x0 length.37_21 = (unsigned int) length_14(D); memcpy (outData_15(D), inData_13(D), length.37_21); @@ -676,14 +676,14 @@ int32_t uprv_copyArray64 (const struct U goto ; [67.00%] [local count: 43795362]: - # RANGE [irange] unsigned int [1, 2147483647] MASK 0x7ff8 VALUE 0x0 + # RANGE [irange] unsigned int [8, 2147483647] MASK 0x7ff8 VALUE 0x0 length.37_21 = (unsigned int) length_14(D); memcpy (outData_15(D), inData_13(D), length.37_21); [local count: 88917857]: [local count: 1073741824]: - # RANGE [irange] int32_t [0, +INF] MASK 0x7fff VALUE 0x0 + # RANGE [irange] int32_t [0, 0][8, +INF] MASK 0x7fff VALUE 0x0 # _6 = PHI <0(7), length_14(D)(10)> return _6; @@ -776,14 +776,14 @@ int32_t uprv_copyArray32 (const struct U goto ; [67.00%] [local count: 43795362]: - # RANGE [irange] unsigned int [1, 2147483647] MASK 0x7ff8 VALUE 0x0 + # RANGE [irange] unsigned int [8, 2147483647] MASK 0x7ff8 VALUE 0x0 length.37_21 = (unsigned int) length_14(D); memcpy (outData_15(D), inData_13(D), length.37_21); [local count: 88917857]: [local count: 1073741824]: - # RANGE [irange] int32_t [0, +INF] MASK 0x7fff VALUE 0x0 + # RANGE [irange] int32_t [0, 0][4, +INF] MASK 0x7fff VALUE 0x0 # _6 = PHI <0(7), length_14(D)(10)> return _6; So it certainly doesn't surprise me some length < 8 check is optimized away given the above range info. The question is if it is correct and what values the length actually get at runtime if you e.g. compile with -O0.
[Bug tree-optimization/113895] [14 Regression] ice in in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895
--- Comment #8 from Zhendong Su ---
Another likely related one (though ICE during a different pass and at a
different location):
[519] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.1 20240213 (experimental) (GCC)
[520] %
[520] % gcctk -O1 small.c
during GIMPLE pass: fre
small.c: In function ‘main’:
small.c:8:1: internal compiler error: in copy_reference_ops_from_ref, at
tree-ssa-sccvn.cc:1165
8 | }
| ^
0x863773 copy_reference_ops_from_ref
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:1165
0x1298f9a valueize_shared_reference_ops_from_ref
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:1858
0x1298f9a valueize_shared_reference_ops_from_ref
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:1853
0x1298f9a vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**, tree_node*, bool)
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:4063
0x129d8b4 visit_reference_op_load
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:5852
0x129d8b4 visit_stmt
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:6373
0x129df5f process_bb
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:8145
0x129f81e do_rpo_vn_1
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:8746
0x12a1253 execute
../../gcc-trunk/gcc/tree-ssa-sccvn.cc:8907
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.
[521] %
[521] % cat small.c
extern void f();
char a[1][1], b;
int main() {
int c = -1U;
if (b)
f(a[c][b]);
return 0;
}
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #13 from Sam James --- (In reply to Andrew Pinski from comment #11) > Does -fwrapv help? no (and ubsan suppresses the crash, everything works fine w/ no ubsan output)
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #12 from Sam James --- -O2 -march=i686 -std=c++11 -m32 -fPIC
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #11 from Andrew Pinski --- Does -fwrapv help? If so does -fsanitize=undefined say anything?
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #10 from Jakub Jelinek --- g++ command line for that TU? -O2 -march=i686 -std=c++14 -m32 ?
[Bug target/112548] [14 regression] 5% exec time regression in 429.mcf on AMD zen4 CPU (since r14-5076-g01c18f58d37865)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112548 --- Comment #5 from Filip Kastl --- (In reply to Robin Dapp from comment #4) > Judging by the graph it looks like it was slow before, then got faster and > now slower again. Is there some more info on why it got faster in the first > place? Did the patch reverse something or is it rather a secondary effect? > I don't have a zen4 handy to check. Don't know if this helps but I bisected the speedup to g:b583a2940af90d03f535648fef111cb158933f7d.
[Bug target/113909] gcc.target/i386/pr113689-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113909 Rainer Orth changed: What|Removed |Added Target Milestone|--- |14.0
[Bug target/113909] New: gcc.target/i386/pr113689-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113909 Bug ID: 113909 Summary: gcc.target/i386/pr113689-1.c etc. FAIL Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: hjl.tools at gmail dot com Target Milestone: --- Target: i?86-pc-solaris2.11, amd64-pc-solaris2.11 3 tests FAIL since 20240206 on 64-bit Solaris/x86: FAIL: gcc.target/i386/pr113689-1.c (test for excess errors) UNRESOLVED: gcc.target/i386/pr113689-1.c compilation failed to produce executable FAIL: gcc.target/i386/pr113689-2.c (test for excess errors) UNRESOLVED: gcc.target/i386/pr113689-2.c compilation failed to produce executable FAIL: gcc.target/i386/pr113689-3.c (test for excess errors) UNRESOLVED: gcc.target/i386/pr113689-3.c compilation failed to produce executable Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr113689-1.c:43:1: sorry, unimplemented: no register available for profiling '-mcmodel=large' Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr113689-2.c:26:1: sorry, unimplemented: profiling '-mcmodel=large' with PIC is not supported Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr113689-3.c:15:1: sorry, unimplemented: profiling '-mcmodel=large' with PIC is not supported I wonder if they only PASS on Linux/x86_64, so the tests should be restricted to that target rather than skipping or xfailing it everywhere else.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #9 from Sam James --- (In reply to Sam James from comment #4) > Created attachment 57409 [details] > udataswp.ii.xz > > It goes wrong in common/udataswp.cpp's uprv_copyArray16 and uprv_copyArray64. > ah, uprv_copyArray64 -> uprv_copyArray16 as the memcpy impl
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #8 from Sam James --- Created attachment 57413 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57413=edit udataswp.o (bad, r14-5109-ga291237b628f41)
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #7 from Sam James --- Created attachment 57412 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57412=edit udataswp.o (good, r14-5108-g751fc7bcdcdf25)
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #6 from Sam James --- Created attachment 57411 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57411=edit udataswp.cpp.262r.expand (bad)
