[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027 --- Comment #6 from LIU Hao --- That's not a GCC bug. That's because you have installed libraries to the default but wrong location.
[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027 --- Comment #7 from LIU Hao --- The .la files generated by libtool are usually nonsense (https://fedoraproject.org/wiki/Changes/RemoveLaFiles). If you run `make install` by hand then you may delete them by hand. Some packagers (e.g. makepkg on Arch Linux and MSYS2) purge them before packaging so they can never get installed, but some don't (e.g. dpkg-deb on Debian).
[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #23 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:d71b20fc30965ba8326ad9363d0aca9d61eb4ed3
commit r13-4581-gd71b20fc30965ba8326ad9363d0aca9d61eb4ed3
Author: Martin Liska
Date: Fri Nov 25 13:05:56 2022 +0100
i386: fix assert (__builtin_cpu_supports ("x86-64") >= 0)
Similar story as PR103661, we again return a negative number
for __builtin_cpu_supports:
Documentation says:
int __builtin_cpu_supports(const char *feature)
This function returns a positive integer if the run-time CPU supports
feature and returns 0 otherwise.
while we return -2147483648.
Moreover, I noticed "x86-64" is not a valid option for __builtin_cpu_is,
but for __builtin_cpu_supports.
PR target/107551
gcc/ChangeLog:
* config/i386/i386-builtins.cc (fold_builtin_cpu): Use same path
as for PR103661.
* doc/extend.texi: Fix "x86-64" use.
gcc/testsuite/ChangeLog:
* gcc.target/i386/builtin_target.c: Add more checks.
[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551 Martin Liška changed: What|Removed |Added Known to fail||12.2.0 Known to work||13.0 --- Comment #24 from Martin Liška --- Fixed on master so far.
[Bug c++/107977] [11/12/13 Regression] ICE: in add_specializations, at cp/module.cc:13186 with -fdump-ada-spec -fmodule-header since r11-6084-g4efde6781bba8d64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107977 Martin Liška changed: What|Removed |Added Summary|ICE: in |[11/12/13 Regression] ICE: |add_specializations, at |in add_specializations, at |cp/module.cc:13186 with |cp/module.cc:13186 with |-fdump-ada-spec |-fdump-ada-spec |-fmodule-header |-fmodule-header since ||r11-6084-g4efde6781bba8d64 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org, ||nathan at gcc dot gnu.org Last reconfirmed||2022-12-09 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r11-6084-g4efde6781bba8d64.
[Bug target/107984] ICE: in verify_target_availability, at sel-sched.cc:1553 with -O2 -fselective-scheduling2 -mabi=ms -mavx512vl since r9-5221-gd8fcab689435a29d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107984 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-12-09 Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Summary|ICE: in |ICE: in |verify_target_availability, |verify_target_availability, |at sel-sched.cc:1553 with |at sel-sched.cc:1553 with |-O2 -fselective-scheduling2 |-O2 -fselective-scheduling2 |-mabi=ms -mavx512vl |-mabi=ms -mavx512vl since ||r9-5221-gd8fcab689435a29d --- Comment #1 from Martin Liška --- Started with r9-5221-gd8fcab689435a29d, it was rejected before the revision.
[Bug c++/107990] ICE: in vague_linkage_p, at cp/decl2.cc:2231 with -fno-elide-constructors -fno-weak and lambdas since r6-67-gefb5e8170a77bb24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107990 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|ICE: in vague_linkage_p, at |ICE: in vague_linkage_p, at |cp/decl2.cc:2231 with |cp/decl2.cc:2231 with |-fno-elide-constructors |-fno-elide-constructors |-fno-weak and lambdas |-fno-weak and lambdas since ||r6-67-gefb5e8170a77bb24 Last reconfirmed||2022-12-09 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- With -std=c++14, it started with r6-67-gefb5e8170a77bb24.
[Bug c/107993] ICE: tree check: expected string_cst, have integer_cst in get_target_clone_attr_len, at tree.cc:14872
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107993 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Martin Liška --- Mine then.
[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark with r10-5090-ga9a4edf0e71bba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409 --- Comment #12 from Rama Malladi --- I found difference in dumps at various stages of the compilation for the mainline GCC and with update_max_bb_count() commented. Here are the details: Mainline: Commit ID: 63a42ffc0833553fbcb84b50cf0fd2d867b8a92f There was difference in the dumps for these 2 stages: "einline" and "earlydebug" Since we use LTO for this build of 519.lbm_r build, I found these differences in these stages of the link-time optimizer: "vect", "slp1", "ivopts", "earlydebug", "debug" Also, this perf drop of 5%-6% with update_max_bb_count() code was observed only on ARM64 instances (Graviton3) and not on x86_64 instances (Intel Xeon). I ran the other SPEC cpu2017_fprate benchmarks on ARM64 with this code commented on GCC mainline and I haven't observed any perf regression. So, maybe worth a fix. Thank you.
[Bug driver/108022] [11/12/13 regression] -frecord-gcc-switches doesn't record preprocessor macros since r11-5739-g7caa49706316e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108022 --- Comment #5 from Martin Liška --- Yes, -ggdb3 seems to me like a reasonable solution. Note you can always strip the debuginfo into a separate file.
[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark with r10-5090-ga9a4edf0e71bba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409 --- Comment #13 from Martin Liška --- Note the mentioned revision is a fix and yes, sometimes these revisions can end up with a regression as profile estimation is a complex guess.
[Bug sanitizer/108029] New: GCC'ASAN at -O0 failed to detect a memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108029
Bug ID: 108029
Summary: GCC'ASAN at -O0 failed to detect a memory leak
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
For the following code, GCC trunk at -O0 won't report the memory leak. However,
-O1 and above can successfully report the leak. I checked the assembly code at
-O0, which indeed allocated the memory.
This issue seems to start from GCC-9, GCC-8 can detect the leak at all
optimization levels.
Clang can also detect it at -O0.
Compiler explorer: https://godbolt.org/z/vxoxxY55x
% cat a.c
short a = 1;
int main() {
int *b = malloc(sizeof(int));
for (;a<1;a++) {
int *c = &b[0];
free(b);
int d[1];
int **e = malloc(sizeof &d);
e[0] = &c;
if (a || b[0]) {
*c = 4 ^ *c;
*c = 5;
}
}
}
%
% gcc-tk -O0 -fsanitize=address a.c
% ASAN_OPTIONS=detect_leaks=1 ./a.out
%
% gcc-tk -O1 -fsanitize=address a.c
% ASAN_OPTIONS=detect_leaks=1 ./a.out
=
==2169810==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7fe9fc8a98bf in __interceptor_malloc
../../../../gcc/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x401234 in main
(/zdata/shaoli/sanitizertesting_UseAfterFree/mutate/bugs/gcc/a.out+0x401234)
SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
%
[Bug sanitizer/108029] GCC'ASAN at -O0 failed to detect a memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108029 Martin Liška changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Martin Liška --- I can see the leak with both gcc-12 and gcc master.
[Bug sanitizer/108029] GCC'ASAN at -O0 failed to detect a memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108029 --- Comment #2 from Li Shaohua --- (In reply to Martin Liška from comment #1) > I can see the leak with both gcc-12 and gcc master. Interesting, because I tested using Compiler explorer. On my local machines, some gcc-12 -O0 won't report, but some do.
[Bug sanitizer/108029] GCC'ASAN at -O0 failed to detect a memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108029 --- Comment #3 from Li Shaohua --- (In reply to Li Shaohua from comment #2) > (In reply to Martin Liška from comment #1) > > I can see the leak with both gcc-12 and gcc master. > > Interesting, because I tested using Compiler explorer. On my local machines, > some gcc-12 -O0 won't report, but some do. Specifically, gcc-12.1.1 won't report, but gcc-12.1.0 does.
[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027 --- Comment #8 from cqwrteur --- (In reply to LIU Hao from comment #7) > The .la files generated by libtool are usually nonsense > (https://fedoraproject.org/wiki/Changes/RemoveLaFiles). If you run `make > install` by hand then you may delete them by hand. Some packagers (e.g. > makepkg on Arch Linux and MSYS2) purge them before packaging so they can > never get installed, but some don't (e.g. dpkg-deb on Debian). if I delete them by hand, then gcc could not build anymore since build scripts of libstdc++ would complain .la do not exist
[Bug libstdc++/108030] New: `std::experimental::simd` not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030 Bug ID: 108030 Summary: `std::experimental::simd` not inlined Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: bernhardmgruber at gmail dot com Target Milestone: --- Created attachment 54052 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54052&action=edit Diff we applied to a local copy of the headers. We tried to explicitely vectorize a C++ function using `std::experimental::simd` in our particle-in-cell simulation [picongpu](https://github.com/ComputationalRadiationPhysics/picongpu). The function is already called from a long call tree of functions marked `__attribute__((always_inline))`. Profiling the code shows that several constructs of `std::experimental::simd` where not inlined, leading to catastrophic performance (several times slower than scalar code). We compiled, among other flags, with: ``` -g -march=native -mtune=native -fopenmp -O3 -DNDEBUG -pthread -std=c++17 ``` We mostly used multiplication/addition as well as the broadcast and generator constructors of SIMD types. We saw several calls to `_S_multiplies` (IIRC) and `_S_generate`/`_S_generator` that were not inlined, depending on whether we used `std::experimental::native_simd` or `std::experimental::fixed_size_simd`. Upon inspection of the `` headers, we saw that several functions are not annotated with `_GLIBCXX_SIMD_INTRINSIC` or other ways to force inlining. We think this is a missed optimization opportunity. We tried `-finline-limit=100` without success. We thus applied `_GLIBCXX_SIMD_INTRINSIC` and `__attribute__((always_inline))` to functions from the SIMD headers that showed up in the profiler (perf) until all calls were inlined. Please apply further attributes to SIMD intrinsics to force their inlining. Mind, that this also affects lambda expressions. I have attached a diff which our changes to the SIMD headers, but we also bulk replaced several declaration specifiers, so we may have added more force-inlines than potentially necessary.
[Bug libstdc++/108030] `std::experimental::simd` not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030 Matthias Kretz (Vir) changed: What|Removed |Added Ever confirmed|0 |1 CC||mkretz at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-09 --- Comment #1 from Matthias Kretz (Vir) --- All of these omissions where actually conscious choices. I had hoped the compiler would make the right choice about inlining in these cases, because I can think of uses of stdx::simd where inlining these functions would not be optimal. However, if the compiler decides against inlining, the result can potentially exhibit catastrophic performance, like you experienced. This defeats the purpose of the type and makes using it a liability. You don't have to fear for `int * int` to ever turn into a function call either. So going forward I'll adjust the always_inline policy for simd to follow: "simd is like a builtin type. Primary operations (i.e. not math functions, etc.) are never function calls. This is independent of element type and ABI tag." The consequence is, that, like for builtin types, the user must consider how to split large functions into smaller ones.
[Bug libstdc++/108030] `std::experimental::simd` not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030 Matthias Kretz (Vir) changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mkretz at gcc dot gnu.org Target Milestone|--- |13.0
[Bug middle-end/107976] ICE: SIGSEGV (stack overflow) in emit_case_dispatch_table (stmt.cc:783) with large --param=jump-table-max-growth-ratio-for-speed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107976 --- Comment #4 from Zdenek Sojka --- Thank you for having a look. If anything is done with the param limits, jump-table-max-growth-ratio-for-size should probably receive the same care.
[Bug target/108031] New: riscv: Access of members of a global structure is not optimized in atomic operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108031
Bug ID: 108031
Summary: riscv: Access of members of a global structure is not
optimized in atomic operations
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
Consider the following test code:
struct s {
int a;
int b;
};
struct s s;
int f(void)
{
return __atomic_fetch_add(&s.a, 1, 0) + __atomic_fetch_add(&s.b, 1, 0);
}
Using gcc -O2 -S -o - test.c yields:
f:
lui a5,%hi(s)
li a4,1
addia5,a5,%lo(s)
amoadd.w a0,a4,0(a5)
lui a5,%hi(s+4) <-- this should be: addi a5, a5, 4
addia5,a5,%lo(s+4) <-- this should be removed
amoadd.w a3,a4,0(a5)
add a0,a0,a3
ret
This seems to be a backend issue since on arm we have for example (gcc
-march=armv7-a -O2 -S -o - test.c):
f:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
movwr3, #:lower16:.LANCHOR0
movtr3, #:upper16:.LANCHOR0
.L2:
ldrex r0, [r3]
add r2, r0, #1
strex r1, r2, [r3]
cmp r1, #0
bne .L2
add r3, r3, #4
.L3:
ldrex r2, [r3]
add r1, r2, #1
strex ip, r1, [r3]
cmp ip, #0
bne .L3
add r0, r0, r2
bx lr
clang produces (clang -O2 -S -o - test.c --target=riscv32):
f:
lui a0, %hi(s)
addia0, a0, %lo(s)
li a1, 1
amoadd.wa2, a1, (a0)
addia0, a0, 4
amoadd.wa0, a1, (a0)
add a0, a0, a2
ret
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 --- Comment #12 from Ben Barrowes --- I use these intermediate files during the software analysis process, but then delete them later. They are useful for me to have. When I am given a makefile, it is often 1000's loc. I am not sure I want to go in and modify it such as you suggest below and tell the customer it is for their own good. I'd rather be able to set a couple of switches to the preprocessor and get what I want. gfortran already allows to create a *.d file in each directory for each file. Is that poor software design as well? And when gfortran files are preprocessed all into a *.f90 file, except when they are not (see Thomas's email below), is that poor software design? ifort allows for the creation of these intermediate preprocessed files, creating *.i and *.i90 files. IBM XL allows this as well using the -d switch: https://www.ibm.com/docs/en/xl-fortran-aix/16.1.0?topic=preprocessor-passing-fortran-files-through-c And the intermediate filename becomes Ffilename.f* Can gfortran be modified to have the option to do this as well?
[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551
--- Comment #25 from CVS Commits ---
The releases/gcc-12 branch has been updated by Martin Liska
:
https://gcc.gnu.org/g:5ec102e3290ff1cac457420a1219fa1ca370
commit r12-8966-g5ec102e3290ff1cac457420a1219fa1ca370
Author: Martin Liska
Date: Fri Nov 25 13:05:56 2022 +0100
i386: fix assert (__builtin_cpu_supports ("x86-64") >= 0)
Similar story as PR103661, we again return a negative number
for __builtin_cpu_supports:
Documentation says:
int __builtin_cpu_supports(const char *feature)
This function returns a positive integer if the run-time CPU supports
feature and returns 0 otherwise.
while we return -2147483648.
Moreover, I noticed "x86-64" is not a valid option for __builtin_cpu_is,
but for __builtin_cpu_supports.
PR target/107551
gcc/ChangeLog:
* config/i386/i386-builtins.cc (fold_builtin_cpu): Use same path
as for PR103661.
* doc/extend.texi: Fix "x86-64" use.
gcc/testsuite/ChangeLog:
* gcc.target/i386/builtin_target.c: Add more checks.
(cherry picked from commit d71b20fc30965ba8326ad9363d0aca9d61eb4ed3)
[Bug target/107551] __builtin_cpu_supports returns a negative integer for "x86-64"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107551 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #26 from Martin Liška --- Fixed for gcc-12 branch.
[Bug target/107714] MVE: Invalid addressing mode generated for VLD2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107714 Stam Markianos-Wright changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Version|12.2.0 |13.0 Known to fail||11.3.1, 12.2.1 Ever confirmed|0 |1 Last reconfirmed|2022-11-17 00:00:00 |2022-12-09
[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #9 from Jakub Jelinek --- Created attachment 54053 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54053&action=edit gcc13-pr107997.patch Untested fix.
[Bug libstdc++/108030] `std::experimental::simd` not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I bet by adding too many always_inline functions that call normal inlines that is what is bound to happen, one runs into inline growth limits. It is better to use always_inline on the leaf functions rather than on what calls them.
[Bug target/108031] riscv: Access of members of a global structure is not optimized in atomic operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108031 Andrew Pinski changed: What|Removed |Added Component|middle-end |target Severity|normal |enhancement
[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753 fiesh at zefix dot tv changed: What|Removed |Added CC||fiesh at zefix dot tv --- Comment #8 from fiesh at zefix dot tv --- Created attachment 54054 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54054&action=edit Two preprocessed files reproducing the issue only at -O3 I seem to also have run into this bug, but maybe my test case is different. Compiling like this results in the same ICE: % avr-g++ -O3 -o pheat pheat-IPAddress.ii pheat-Print.ii -flto -mmcu=atmega2560 A lower optimization level does not suffice to trigger it.
[Bug middle-end/108031] riscv: Access of members of a global structure is not optimized in atomic operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108031 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|target |middle-end Target|riscv*-*-* |riscv*-*-* aarch64-*-* Last reconfirmed||2022-12-09 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- On aarch64 and -O2 -fno-section-anchors -march=armv8.1-a we get: adrpx1, s mov w2, 1 add x1, x1, :lo12:s ldadd w2, w0, [x1] adrpx1, s+4 add x1, x1, :lo12:s+4 ldadd w2, w2, [x1] add w0, w0, w2 On riscv32 with -O2 -msmall-data-limit=0 (note I wish -G was used on riscv like every other target so I don't have to remember what the riscv specific option name is): lui a5,%hi(.LANCHOR0) addia5,a5,%lo(.LANCHOR0) li a4,1 amoadd.w a0,a4,0(a5) addia5,a5,4 amoadd.w a3,a4,0(a5) add a0,a0,a3
[Bug c++/108032] New: internal compiler error : in final_scan_insn_1, at final.c:3079
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108032 Bug ID: 108032 Summary: internal compiler error : in final_scan_insn_1, at final.c:3079 Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ramesh.rajender at mavenir dot com Target Milestone: --- Error: = IScpCmiApp.cpp: In member function ‘virtual void IScpCmiApp::_ZThn23947680_N10IScpCmiAppD1Ev()’: IScpCmiApp.cpp:7128:1: internal compiler error: in final_scan_insn_1, at final.c:3079 7128 | } Sample Code: = IScpCmiApp::IScpCmiApp(): AsCommonCmi< CMI >(INTERFACE_ISCP), TasRegionCmi, IScpCmiApp >::TasRegionCmi(INTERFACE_ISCP), HASyncCmi< CMI >(INTERFACE_ISCP), TasDiamCmi,IScpCmiApp>::TasDiamCmi(INTERFACE_ISCP), CtasDiamAppInterfaceMap,IScpCmiApp>::CtasDiamAppInterfaceMap(INTERFACE_ISCP), RestApiTemplates,IScpCmiApp>::RestApiTemplates(INTERFACE_ISCP)
[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753 --- Comment #9 from fiesh at zefix dot tv --- I forgot to mention that my test case requires -flto to be present.
[Bug target/108032] internal compiler error : in final_scan_insn_1, at final.c:3079
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108032 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2022-12-09 Ever confirmed|0 |1 Component|c++ |target --- Comment #1 from Andrew Pinski --- /* If we have a length attribute, this instruction should have been split in shorten_branches, to ensure that we would have valid length info for the splitees. */ gcc_assert (!HAVE_ATTR_length); Can you read https://gcc.gnu.org/bugs/ and provide what is requested there?
[Bug c++/107977] ICE: in add_specializations, at cp/module.cc:13186 with -fdump-ada-spec -fmodule-header since r11-6084-g4efde6781bba8d64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107977 Andrew Pinski changed: What|Removed |Added Summary|[11/12/13 Regression] ICE: |ICE: in |in add_specializations, at |add_specializations, at |cp/module.cc:13186 with |cp/module.cc:13186 with |-fdump-ada-spec |-fdump-ada-spec |-fmodule-header since |-fmodule-header since |r11-6084-g4efde6781bba8d64 |r11-6084-g4efde6781bba8d64 --- Comment #2 from Andrew Pinski --- This is not a regression as -fmodule-header didn't exist before that revision.
[Bug target/108032] internal compiler error : in final_scan_insn_1, at final.c:3079
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108032 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Also note that GCC 9.x is not supported anymore.
[Bug libstdc++/108030] `std::experimental::simd` not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030 --- Comment #3 from Matthias Kretz (Vir) --- (In reply to Jakub Jelinek from comment #2) > I bet by adding too many always_inline functions that call normal inlines > that is what is bound to happen, one runs into inline growth limits. It is > better to use always_inline on the leaf functions rather than on what calls > them. How is the inline growth limit determined? I mean, in the cases where it really hurts, the resulting function compiles down to a single instruction (plus parameter passing boilerplate). The optimizer cannot know about the number of instructions, so what is the measure it uses? Especially with the helper functions necessary to work with parameter packs / index_sequence, it's not enough to use always_inline on the leaf functions. E.g. any simd binary operator basically should be [[gnu::always_inline, gnu::flatten]]. However, simd maybe shouldn't use 'flatten' for functions that call a user-provided callable (e.g. the simd generator constructor).
[Bug target/108033] New: -G should be an alias to -msmall-data-limit=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108033 Bug ID: 108033 Summary: -G should be an alias to -msmall-data-limit= Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: riscv*-*-* -G is the more generic option name and someone coming from MIPS, or another embedded target, they will know about -G before they know about -msmall-data-limit= option.
[Bug target/108033] -G should be an alias to -msmall-data-limit=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108033 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug libstdc++/108030] `std::experimental::simd` not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108030 --- Comment #4 from Jakub Jelinek --- (In reply to Matthias Kretz (Vir) from comment #3) > (In reply to Jakub Jelinek from comment #2) > > I bet by adding too many always_inline functions that call normal inlines > > that is what is bound to happen, one runs into inline growth limits. It is > > better to use always_inline on the leaf functions rather than on what calls > > them. > > How is the inline growth limit determined? I mean, in the cases where it > really hurts, the resulting function compiles down to a single instruction > (plus parameter passing boilerplate). The optimizer cannot know about the > number of instructions, so what is the measure it uses? I've CCed Honza, who should know the answers. The inliner can't know if say some builtin will fold into a single instruction or not, it uses some heuristics on GIMPLE IL sizes. Bet -fdump-ipa-inline-details contain all the reasons, but at least for me those dumps are hard to read.
[Bug preprocessor/104471] ICE with -nostdinc: NULL directory in find_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104471 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-09 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug preprocessor/104471] ICE with -nostdinc: NULL directory in find_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104471
--- Comment #2 from Andrew Pinski ---
This patch should fix the issue (I might get to it in a few weeks though):
diff --git a/libcpp/files.cc b/libcpp/files.cc
index a18b1caf48d..eb90fa4f65a 100644
--- a/libcpp/files.cc
+++ b/libcpp/files.cc
@@ -177,7 +177,7 @@ static bool read_file_guts (cpp_reader *pfile, _cpp_file
*file,
static bool read_file (cpp_reader *pfile, _cpp_file *file,
location_t loc);
static struct cpp_dir *search_path_head (cpp_reader *, const char *fname,
-int angle_brackets, enum include_type);
+int angle_brackets, enum include_type, bool =
true);
static const char *dir_name_of_file (_cpp_file *file);
static void open_file_failed (cpp_reader *pfile, _cpp_file *file, int,
location_t);
@@ -1026,7 +1026,7 @@ _cpp_mark_file_once_only (cpp_reader *pfile, _cpp_file
*file)
nothing left in the path, returns NULL. */
static struct cpp_dir *
search_path_head (cpp_reader *pfile, const char *fname, int angle_brackets,
- enum include_type type)
+ enum include_type type, bool canerror)
{
cpp_dir *dir;
_cpp_file *file;
@@ -1055,7 +1055,7 @@ search_path_head (cpp_reader *pfile, const char *fname,
int angle_brackets,
return make_cpp_dir (pfile, dir_name_of_file (file),
pfile->buffer ? pfile->buffer->sysp : 0);
- if (dir == NULL)
+ if (canerror && dir == NULL)
cpp_error (pfile, CPP_DL_ERROR,
"no include path in which to search for %s", fname);
@@ -2144,7 +2144,9 @@ bool
_cpp_has_header (cpp_reader *pfile, const char *fname, int angle_brackets,
enum include_type type)
{
- cpp_dir *start_dir = search_path_head (pfile, fname, angle_brackets, type);
+ cpp_dir *start_dir = search_path_head (pfile, fname, angle_brackets, type,
false);
+ if (!start_dir)
+return false;
_cpp_file *file = _cpp_find_file (pfile, fname, start_dir, angle_brackets,
_cpp_FFK_HAS_INCLUDE, 0);
return file->err_no != ENOENT;
[Bug target/104951] avx512fintrin.h(9146): error: identifier "__builtin_ia32_rndscaless_round" is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104951 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #3 from Andrew Pinski --- Not a GCC bug so closing.
[Bug c++/105509] [compatibility] f16 suffix not supported in C++ mode - unable to find numeric literal operator ‘operator""f16’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105509 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 106652. f16 was added for GCC 13. *** This bug has been marked as a duplicate of bug 106652 ***
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652 Andrew Pinski changed: What|Removed |Added CC||thiago at kde dot org --- Comment #19 from Andrew Pinski --- *** Bug 105509 has been marked as a duplicate of this bug. ***
[Bug c++/105595] Coroutines can trigger -Wsubobject-linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105595 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-12-09 --- Comment #2 from Andrew Pinski --- Confirmed. I noticed this also when reducing a different testcase.
[Bug c++/106650] [C++23] P2280 - Using unknown references in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106650 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-09 --- Comment #1 from Andrew Pinski --- .
[Bug c++/106653] [C++23] P2582 - Class template argument deduction from inherited constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106653 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-12-09 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- .
[Bug c++/106657] [C++23] P2460 - Relax requirements on wchar_t to match existing practices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106657 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-12-09 --- Comment #1 from Andrew Pinski --- .
[Bug c++/106658] [C++23] P2590 - Explicit lifetime management
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106658 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-09 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- .
[Bug libstdc++/106852] Implement C++23 P2465R3 Standard Library Modules std and std.compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106852 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103524 Last reconfirmed||2022-12-09 --- Comment #2 from Andrew Pinski --- .
[Bug web/108034] New: cannot use bug alias name in see also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108034 Bug ID: 108034 Summary: cannot use bug alias name in see also Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- If you try to use an alias name for a bug in the see also, you get an error message saying it is not an URL. I would have expected to do a search for the alias before reporting that error.
[Bug web/107333] bugzilla see also should support savannah bug URLs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107333 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569 --- Comment #43 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #42) > On #c0 foo, this was previously optimized in dom2 which optimized > _4 = ABS_EXPR ; > _3 = _4 u> 1.79769313486231570814527423731704356798070567525844996599e+308; > _5 = ~_3; > if (_4 u> 1.79769313486231570814527423731704356798070567525844996599e+308) > goto ; [0.00%] > else > goto ; [100.00%] > >[count: 0]: > __builtin_unreachable (); > >[local count: 1073741824]: > return _5; > without any frange related stuff as: > - if (_4 u> 1.79769313486231570814527423731704356798070567525844996599e+308) > + if (_3 != 0) > and > - return _5; > + return 1; > > But because __builtin_unreachable () is now removed earlier (vrp1 already; > without providing useful global range though), we don't do that anymore. Hmm. its because when vrp1 removes the branch to builtin_unreachable, it calculates the global range of _4 as the union of all the ranges at each use.. this is to avoid issues where the unreachable call may not post-dominate an earlier use. THe initial use of _4 still is resolved to only [0, max] so we end up only using that for the range. Im experimenting with doing things the same way, except NOT removing the branch in VRP, but continuing to set the global range the way we do. I might also be able to revisit the branch *after* all the globals have been set, and see if the globals values now cause the condition to fold, and if they do, remove them only then... ThIs would leave the above case for DOM2 (or someone else to resolve). It seems like it might be a reasonable balance... ie, we only remove the unreachable in VRP1 if we can determine with 100% positivity that setting the global value will result in the branch being able to remove. Its also possible it could also just be left... and another pass should remove it shortly as it folds away... and certainly by VRP2 time... Anyway, I'll try it a few ways and see what seems to work best.
[Bug libstdc++/108035] New: std::source_location::function_name() provides an empty string when used with clang++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108035 Bug ID: 108035 Summary: std::source_location::function_name() provides an empty string when used with clang++ Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danhan at live dot ie Target Milestone: --- I ran this minimal example from cppreference https://en.cppreference.com/w/cpp/utility/source_location on godbolt https://godbolt.org/z/jYMYb8ez6 and source_location::function_name() returned an empty string where if the same code is compiled with gcc it returns what appears to be the value of __PRETTY_FUNCTION__ for the caller of the log(...) function, as both have __PRETTY_FUNCTION__ as an internal I would have expected the behavior to be the same. Consequentally I have posted this on the llvm bugtracker as well :) https://github.com/llvm/llvm-project/issues/59422
[Bug c/108036] New: Spurious warning for zero-sized array parameters to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036
Bug ID: 108036
Summary: Spurious warning for zero-sized array parameters to a
function
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: colomar.6.4.3 at gmail dot com
Target Milestone: ---
It's interesting to pass pointers to one past the end of an array to a
function, acting as a sentinel value that serves as an alternative to the size
of the buffer. It helps chaining string copy functions, for example:
char *
ustr2stpe(char *dst, const char *restrict src, size_t n, char past_end[0])
{
bool trunc;
char *end;
ptrdiff_t len;
if (dst == past_end)
return past_end;
trunc = false;
len = strnlen(src, n);
if (len > past_end - dst - 1) {
len = past_end - dst - 1;
trunc = true;
}
end = mempcpy(dst, src, len);
*end = '\0';
return trunc ? past_end : end;
}
However, if you use array syntax for it, which clarifies where it points to,
the GCC complains, not at the function implementation, but at call site:
#define nitems(arr) (sizeof((arr)) / sizeof((arr)[0]))
int
main(void)
{
char pre[4] = "pre.";
char *post = ".post";
char *src = "some-long-body.post";
char dest[100];
char *p, *past_end;
past_end = dest + nitems(dest);
p = dest;
p = ustr2stpe(p, pre, nitems(pre), past_end);
p = ustr2stpe(p, src, strlen(src) - strlen(post), past_end);
p = ustr2stpe(p, "", 0, past_end);
if (p == past_end)
fprintf(stderr, "truncation\n");
puts(dest); // "pre.some-long-body"
}
$ cc -Wall -Wextra ustr2stpe.c
ustr2stpe.c: In function ‘main’:
ustr2stpe.c:43:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
43 | p = ustr2stpe(p, pre, nitems(pre), past_end);
| ^~~~
ustr2stpe.c:43:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
ustr2stpe.c:44:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
44 | p = ustr2stpe(p, src, strlen(src) - strlen(post), past_end);
| ^~~
ustr2stpe.c:44:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
ustr2stpe.c:45:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
45 | p = ustr2stpe(p, "", 0, past_end);
| ^
ustr2stpe.c:45:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
ustr2stpe.c:43:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
43 | p = ustr2stpe(p, pre, nitems(pre), past_end);
| ^~~~
ustr2stpe.c:43:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
ustr2stpe.c:44:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
44 | p = ustr2stpe(p, src, strlen(src) - strlen(post), past_end);
| ^~~
ustr2stpe.c:44:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
ustr2stpe.c:45:13: warning: ‘ustr2stpe’ accessing 1 byte in a region of size 0
[-Wstringop-overflow=]
45 | p = ustr2stpe(p, "", 0, past_end);
| ^
ustr2stpe.c:45:13: note: referencing argument 4 of type ‘char[0]’
ustr2stpe.c:10:1: note: in a call to function ‘ustr2stpe’
10 | ustr2stpe(char *dst, const char *restrict src, size_t n, char
past_end[0])
| ^
The warnings are invalid. While it's true that I'm referencing a pointer of
size 0, it's false that I'm "accessing 1 byte" in that region. I guess this is
all about the bogus design of 'static' in ISO C, where you can have an array
parameter of size 0, which is very use
[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997 --- Comment #10 from Jan-Benedict Glaw --- I gave that patch a try: GCC build is successful, as is the Linux build afterwards using that toolchain. (Cannot test the resulting kernel of course---I don't have the hardware.)
[Bug libstdc++/108035] libstdc++ implementation of std::source_location::function_name() provides an empty string when used with clang++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108035 --- Comment #1 from Jakub Jelinek --- That looks solely like a clang issue. It implements the builtin gcc has added for - __builtin_source_location () - but fills in _M_function_name with just "" rather than a pretty name.
[Bug libstdc++/108035] libstdc++ implementation of std::source_location::function_name() provides an empty string when used with clang++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108035 --- Comment #2 from Jonathan Wakely --- Right, if Clang doesn't provide a name then there's nothing libstdc++ can do about it.
[Bug c/108037] New: prefer for affinity with OMP_PROC_BIND=true to match "spread" instead of "close"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108037
Bug ID: 108037
Summary: prefer for affinity with OMP_PROC_BIND=true to match
"spread" instead of "close"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yhe at lbl dot gov
Target Milestone: ---
With gcc version 11.2.0 (same for a few previous versions too), it seems that
OMP_PROC_BIND=true does the same affinity as OMP_PROC_BIND=close. When there
are multiple hyperthreads per physical core, and when OMP_PLACES=threads is
set, it will end up with multiple threads bind on the same physical core, which
is not optimal.
I would like to propose OMP_PROC_BIND=true use the same affinity as
OMP_PROC_SPREAD, which is seen in a few other compilers (nvidia, cray, for
example).
Below are some sample affinity output on an Intel Haswell node (32 physical
cores, 2 hyperthreads each).
% numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46
48 50 52 54 56 58 60 62
node 0 size: 257592 MB
node 0 free: 188196 MB
node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47
49 51 53 55 57 59 61 63
node 1 size: 257527 MB
node 1 free: 173862 MB
node distances:
node 0 1
0: 10 21
1: 21 10
% gcc --version
gcc (GCC) 11.2.0 20210728 (Cray Inc.)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
% more hello-omp.c
#include
#include
int main ()
{
#pragma omp parallel
printf("Hello World... from thread = %d\n", omp_get_thread_num());
}
% gcc -fopenmp hello-omp.c -o hello
% export OMP_NUM_THREADS=4
% export OMP_PLACES=threads
% export OMP_DISPLAY_AFFINITY=true
% export OMP_PROC_BIND=true
% ./hello |sort -k4n
level 1 thread 0x154f3d80 affinity 0
level 1 thread 0x1490b700 affinity 32
level 1 thread 0x1470a700 affinity 1
level 1 thread 0x14509700 affinity 33
Hello World... from thread = 0
Hello World... from thread = 1
Hello World... from thread = 2
Hello World... from thread = 3
% export OMP_PROC_BIND=close
% ./hello |sort -k4n
level 1 thread 0x154f3d80 affinity 0
level 1 thread 0x1490b700 affinity 32
level 1 thread 0x1470a700 affinity 1
level 1 thread 0x14509700 affinity 33
Hello World... from thread = 0
Hello World... from thread = 1
% export OMP_PROC_BIND=spread
% ./hello |sort -k4n
level 1 thread 0x154f3d80 affinity 0
level 1 thread 0x1490b700 affinity 8
level 1 thread 0x1470a700 affinity 16
level 1 thread 0x14509700 affinity 24
Hello World... from thread = 0
Hello World... from thread = 1
Hello World... from thread = 2
Hello World... from thread = 3
When setting OMP_PLACES=cores, even when OMP_PROC_BIND=true still does the same
as OMP_PROC_BIND=close, the affinity for pure OpenMP codes would be fine.
However, it is still preferred that OMP_PROC_BIND=true to use the same affinity
as OMP_PROC_BIND=spread for optimal process and thread affinity for hybrid
MPI/OpenMP codes.
% export OMP_PLACES=cores
% export OMP_PROC_BIND=true
%./hello |sort -k4n
level 1 thread 0x154f3d80 affinity 0,32
level 1 thread 0x1490b700 affinity 1,33
level 1 thread 0x1470a700 affinity 2,34
level 1 thread 0x14509700 affinity 3,35
Hello World... from thread = 0
Hello World... from thread = 1
Hello World... from thread = 2
Hello World... from thread = 3
% export OMP_PROC_BIND=close
% ./hello |sort -k4n
level 1 thread 0x154f3d80 affinity 0,32
level 1 thread 0x1490b700 affinity 1,33
level 1 thread 0x1470a700 affinity 2,34
level 1 thread 0x14509700 affinity 3,35
Hello World... from thread = 0
Hello World... from thread = 1
Hello World... from thread = 2
Hello World... from thread = 3
% export OMP_PROC_BIND=spread
% ./hello |sort -k4n
level 1 thread 0x154f3d80 affinity 0,32
level 1 thread 0x1490b700 affinity 8,40
level 1 thread 0x1470a700 affinity 16,48
level 1 thread 0x14509700 affinity 24,56
Hello World... from thread = 0
Hello World... from thread = 1
Hello World... from thread = 2
Hello World... from thread = 3
[Bug libstdc++/108035] libstdc++ implementation of std::source_location::function_name() provides an empty string when used with clang++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108035 Andrew Pinski changed: What|Removed |Added See Also||https://github.com/llvm/llv ||m-project/issues/59422 Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- As mentioned there is nothing GCC's libstdc++ can be done if clang/llvm's __builtin_source_location implementation does not fill in the function name.
[Bug c/108036] Spurious warning for zero-sized array parameters to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 --- Comment #1 from Andrew Pinski --- Created attachment 54055 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54055&action=edit Full testcase that actually compiles
[Bug middle-end/108036] [11/12/13 Regression] Spurious warning for zero-sized array parameters to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 --- Comment #2 from Andrew Pinski --- Created attachment 54056 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54056&action=edit Reduced testcase
[Bug middle-end/108036] [11/12/13 Regression] Spurious warning for zero-sized array parameters to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |11.4 Ever confirmed|0 |1 Last reconfirmed||2022-12-09
[Bug middle-end/108036] [11/12/13 Regression] Spurious warning for zero-sized array parameters to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 --- Comment #3 from Alejandro Colomar --- Hi Andrew! Just a few nitpicks: - In the first testcase you posted, the [] is missing the 0: [0]. - In the reduced test case, you call the pointer to one past the end as 'end'. That is misleading, since 'end' is commonly also used for pointers to the last byte in an array, normally the NUL byte in strings. Using the term 'end' meaning one-past-the-end is likely to end up in off-by-one errors. So much that I found a few of them for exactly that reason this week :) This last point is why I like using array syntax, so I can clrealy specify 'end[1]' and 'past_end[0]', and they are clearly different things. Cheers, Alex
[Bug middle-end/108036] [11/12/13 Regression] Spurious warning for zero-sized array parameters to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 --- Comment #4 from Andrew Pinski --- (In reply to Alejandro Colomar from comment #3) > - In the reduced test case, you call the pointer to one past the end as > 'end'. That is misleading, since 'end' is commonly also used for pointers > to the last byte in an array, normally the NUL byte in strings. In the C++ standard, the function end() returns one past the last element of an array. So I am not misusing the name end here. Just using it different from you.
[Bug middle-end/108036] [11/12/13 Regression] Spurious warning for zero-sized array parameters to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108036 --- Comment #5 from Alejandro Colomar --- Interesting. Thanks for clarifying :)
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
kargl at gcc dot gnu.org changed:
What|Removed |Added
Severity|normal |enhancement
Priority|P3 |P5
--- Comment #13 from kargl at gcc dot gnu.org ---
(In reply to Ben Barrowes from comment #12)
> Can gfortran be modified to have the option to do this as well?
Sure, gfortran can be modified. The nontrivial part is that there are very few
active contributors to gfortran. I suspect your patch would be much
appreciated.
Until then, you can modify your Makefile with very minor changes to stuff
intermediate files into subdirectories.
% ls
Makefilea1.f90 b1.f90 c1.f90 d1.f90
% cat Makefile
FC = gfortran11
PP = preprocessed/
FF = -c -cpp -save-temps -dumpdir ${PP}
IN = f90
NAMES = a1 b1 c1 d1
all:
mkdir -p ${PP}
.for i in ${NAMES}
${FC} ${FF} $i.${IN}
.endfor
clean:
@rm -rf ${PP} *.o
% make
mkdir -p preprocessed/
gfortran11 -c -cpp -save-temps -dumpdir preprocessed/ a1.f90
gfortran11 -c -cpp -save-temps -dumpdir preprocessed/ b1.f90
gfortran11 -c -cpp -save-temps -dumpdir preprocessed/ c1.f90
gfortran11 -c -cpp -save-temps -dumpdir preprocessed/ d1.f90
% ls
Makefilea1.ob1.oc1.od1.o
a1.f90 b1.f90 c1.f90 d1.f90 preprocessed/
% ls preprocessed/
a1.f90 a1.sb1.f90 b1.sc1.f90 c1.sd1.f90 d1.s
[Bug c++/107495] GCC does not consider the right contextual implicit conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107495 --- Comment #3 from Andrew Pinski --- (In reply to Giuseppe D'Angelo from comment #1) > Variation of the above: The testcase in comment #1 is almost definitely the same as PR 59328. Note the testcase in comment #0 is also rejected by clang ...
[Bug libgcc/107675] [13 Regression] GCC-13 is significantly slower to startup on C++ statically linked programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675 m.cencora at gmail dot com changed: What|Removed |Added CC||m.cencora at gmail dot com --- Comment #14 from m.cencora at gmail dot com --- A comment to Thomas proposed patch "[PATCH] initialize fde objects lazily" You cannot use 'relaxed' atomic load in is_object_initialized - as thread performing such load will not observe/synchronize with any modifications (other than atomic variable itself) performed by other threads. Excerpt from cppreference: Relaxed operation: there are no synchronization or ordering constraints imposed on other reads or writes, only this operation's atomicity is guaranteed.
[Bug c++/107579] [11/12/13 Regression] ICE on fold-expression on .* member access operator since r12-2862-g9707d2e5dbb92d2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107579 --- Comment #7 from Patrick Palka --- This is essentially a dup of PR100295, except here the unevaluated context is a requires-expr instead of sizeof, and r12-2862 exposed this bug by making us correctly recognize a requires-expr as an unevaluated context during cp_walk_subtrees
[Bug fortran/107872] ICE on recursive DT with DTIO since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #3) > Created attachment 53975 [details] > Fix for this PR > > I am tied up with my finalization work at present. If somebody else wishes > to commit the patch, be my guest. I'll submit the patch on your behalf to the ML, if you don't mind.
[Bug target/108038] New: GCC generates poor code for select of consecutive constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108038
Bug ID: 108038
Summary: GCC generates poor code for select of consecutive
constants
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
CC: rzinsly at ventanamicro dot com
Target Milestone: ---
Target: riscv-64
This testcase:
typedef signed long int __int64_t;
#define X(OP, OPN) __int64_t test##OPN(__int64_t x, __int64_t y) { __int64_t
cmp; cmp = (x OP y) ? 2 : 3; return cmp; }
X(>,GT)
X(<,LT)
typedef unsigned long int __uint64_t;
#define XU(OP, OPN) __uint64_t test##OPN(__uint64_t x, __uint64_t y) {
__uint64_t cmp; cmp = (x OP y) ? 2 : 3; return cmp; }
X(>,GTU)
X(<,LTU)
Compiled for rv64 with -O2 -march=rv64gc_zba gets this code for the first test.
The others are similar in having the extraneous xori.
testGT:
sgt a0,a0,a1# 25[c=4 l=4] *sgt_didi
xoria0,a0,1 # 27[c=4 l=4] xordi3/1
addia0,a0,2 # 16[c=4 l=4] adddi3/1
ret # 35[c=0 l=4] simple_return
But ISTM we could generate this instead:
testGT:
sgt a0,a1,a0# 24[c=4 l=4] *riscv.md:2535
addia0,a0,2 # 16[c=4 l=4] adddi3/1
ret # 32[c=0 l=4] simple_return
I think the key is this:
Trying 25 -> 27:
25: r139:DI=r140:DI>r141:DI
REG_DEAD r141:DI
REG_DEAD r140:DI
27: r134:DI=r139:DI^0x1
REG_DEAD r139:DI
Failed to match this instruction:
(set (reg:DI 134 [ ])
(le:DI (reg:DI 140)
(reg:DI 141)))
We can invert the condition and swap the operands with something like this:
(define_insn ""
[(set (match_operand:GPR 0 "register_operand" "=r")
(any_le:GPR (match_operand:X 1 "register_operand" " r")
(match_operand:X 2 "register_operand" "r")))]
""
"sgt\t%0,%2,%1"
[(set_attr "type" "slt")
(set_attr "mode" "")])
We probably need another pattern to handle the LT/LTU cases which want to
match:
rying 24 -> 25:
24: r139:DI=r140:DI
[Bug fortran/107872] ICE on recursive DT with DTIO since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from anlauf at gcc dot gnu.org --- Assigning to you, Paul, then, after submitting to the ML: https://gcc.gnu.org/pipermail/fortran/2022-December/058603.html
[Bug rtl-optimization/108039] New: Unnecessary extension on riscv-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108039
Bug ID: 108039
Summary: Unnecessary extension on riscv-64
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
CC: rzinsly at ventanamicro dot com
Target Milestone: ---
Target: riscv-64
Compile the following code for rv64 with -O2:
typedef signed long int int64_t;
void replace_weaker_arc(int *id1, int *id2, int64_t number)
{
*id1 = number;
*id2 = number;
}
We generate:
replace_weaker_arc:
sext.w a2,a2
sw a2,0(a0)
sw a2,0(a1)
ret
The key insns (from cse1 dump) are:
(insn 8 5 9 2 (set (reg:DI 134 [ _1 ])
(sign_extend:DI (subreg:SI (reg/v:DI 137 [ number ]) 0))) "j.c":4:10
116 {extendsidi2}
(nil))
(insn 9 8 10 2 (set (mem:SI (reg/v/f:DI 135 [ id1 ]) [1 *id1_4(D)+0 S4 A32])
(subreg/s/u:SI (reg:DI 134 [ _1 ]) 0)) "j.c":4:10 178 {*movsi_internal}
(nil))
(insn 10 9 0 2 (set (mem:SI (reg/v/f:DI 136 [ id2 ]) [1 *id2_6(D)+0 S4 A32])
(subreg/s/u:SI (reg:DI 134 [ _1 ]) 0)) "j.c":5:10 178 {*movsi_internal}
(nil))
fwprop tries to propagate insn 8 into insns 9 and 10, but that fails the
complexity check:
cannot propagate from insn 8 into insn 9: would increase complexity of pattern
cannot propagate from insn 8 into insn 10: would increase complexity of pattern
But propagation in this case allows us to eliminate a subreg & extension, so
it's profitable.
I haven't tested it, but something like this captures the RTL propagation
generates and the fact that it should simplify. We may need to tighten it a
little by verifying modes:
diff --git a/gcc/fwprop.cc b/gcc/fwprop.cc
index fc652ab9a1f..a86e9320908 100644
--- a/gcc/fwprop.cc
+++ b/gcc/fwprop.cc
@@ -258,6 +258,14 @@ fwprop_propagation::classify_result (rtx old_rtx, rtx
new_rtx)
return CONSTANT | PROFITABLE;
}
+ /* Allow replacements where we are able to eliminate a
+ (subreg (any_extend (...)). */
+ if (GET_CODE (old_rtx) == SUBREG
+ && (GET_CODE (SUBREG_REG (old_rtx)) == SIGN_EXTEND
+ || GET_CODE (SUBREG_REG (old_rtx)) == ZERO_EXTEND)
+ && XEXP (SUBREG_REG (old_rtx), 0) == new_rtx)
+return PROFITABLE;
[Bug rtl-optimization/108039] Unnecessary extension on riscv-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108039 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization
[Bug rtl-optimization/108039] Unnecessary extension on riscv-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108039
Andrew Pinski changed:
What|Removed |Added
Target|riscv-64|riscv64 aarch64
Last reconfirmed||2022-12-09
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed. You can reproduce the issue on aarch64 with a slightly modified
testcase:
void replace_weaker_arc(short *id1, short *id2, long long number)
{
*id1 = number;
*id2 = number;
}
[Bug c++/108040] New: -fdevirtualize causes part of function to be missing in output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108040 Bug ID: 108040 Summary: -fdevirtualize causes part of function to be missing in output Product: gcc Version: 12.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alvinhochun at gmail dot com Target Milestone: --- Created attachment 54057 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54057&action=edit preprocessed source file Using MSYS2 UCRT64 GCC 12.2.0 $ g++ -v Using built-in specs. COLLECT_GCC=C:\msys64\ucrt64\bin\g++.exe COLLECT_LTO_WRAPPER=C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-12.2.0/configure --prefix=/ucrt64 --with-local-prefix=/ucrt64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/ucrt64/include --libexe cdir=/ucrt64/lib --enable-bootstrap --enable-checking=release --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=po six --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts --enable-libstdcxx-time --disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-multilib --disable-rpath --disable-win32-registry --disa ble-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/ucrt64 --with-mpfr=/ucrt64 --with-mpc=/ucrt64 --with-isl=/ucrt64 --with-pkgversion='Rev6, Built by MSYS2 project' --with-bugurl=https://git hub.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --disable-libstdcxx-debug --with-boot-ldflags=-static-libstdc++ --with-stage1-ldflags=-static-libstdc++ Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (Rev6, Built by MSYS2 project) I compiled the original source with the following commands: $ g++ -DCATCH_CONFIG_COLOUR_ANSI -D_WIN32_WINNT=0x0602 -ID:/dev/mingw-winrt/cppwinrt/test -ID:/dev/mingw-winrt/cppwinrt/test/../cppwinrt -IC:/msys64/home/Alvin/cppwinrt_rel/test/cppwinrt -O2 -g -DNDEBUG -fno-omit-frame-pointer -fdiagnostics-color=always -mcx16 -O1 -finline-functions -finline-small-functions -findirect-inlining -fno-devirtualize -std=gnu++20 -MD -MT test/test/CMakeFiles/test-out_params_bad.dir/out_params_bad.cpp.obj -MF 'test\test\CMakeFiles\test-out_params_bad.dir\out_params_bad.cpp.obj.d' D:/dev/mingw-winrt/cppwinrt/test/test/out_params_bad.cpp -g0 -S -o ../good.s -fverbose-asm -save-temps $ g++ -DCATCH_CONFIG_COLOUR_ANSI -D_WIN32_WINNT=0x0602 -ID:/dev/mingw-winrt/cppwinrt/test -ID:/dev/mingw-winrt/cppwinrt/test/../cppwinrt -IC:/msys64/home/Alvin/cppwinrt_rel/test/cppwinrt -O2 -g -DNDEBUG -fno-omit-frame-pointer -fdiagnostics-color=always -mcx16 -O1 -finline-functions -finline-small-functions -findirect-inlining -fno-devirtualize -std=gnu++20 -MD -MT test/test/CMakeFiles/test-out_params_bad.dir/out_params_bad.cpp.obj -MF 'test\test\CMakeFiles\test-out_params_bad.dir\out_params_bad.cpp.obj.d' D:/dev/mingw-winrt/cppwinrt/test/test/out_params_bad.cpp -g0 -S -o ../bad.s -fdevirtualize -fverbose-asm -save-temps I then compared `good.s` and `bad.s` and checked inside the function `static void C_A_T_C_H_T_E_S_T_0()` (_ZL19C_A_T_C_H_T_E_S_T_0v). At around `D:/dev/mingw-winrt/cppwinrt/test/test/out_params_bad.cpp:211`, `bad.s` is missing a large chunk of the function (all the way to the function epilogue) compared to `good.s`. The only difference is that `bad.s` is compiled with `-fdevirtualize`. Attached the preprocessed source with gzip compression.
[Bug rtl-optimization/108039] Unnecessary extension storing same value twice to small location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108039 --- Comment #2 from Andrew Pinski --- I did something similar years ago: https://gcc.gnu.org/pipermail/gcc-patches/2010-October/297761.html https://gcc.gnu.org/pipermail/gcc-patches/2010-October/297762.html
[Bug fortran/107872] ICE on recursive DT with DTIO since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872 --- Comment #8 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:01254aa2eb766c7584fd047568d7277d4d65d067 commit r13-4585-g01254aa2eb766c7584fd047568d7277d4d65d067 Author: Paul Thomas Date: Fri Dec 9 22:13:45 2022 +0100 Fortran: ICE on recursive derived types with allocatable components [PR107872] gcc/fortran/ChangeLog: PR fortran/107872 * resolve.cc (derived_inaccessible): Skip over allocatable components to prevent an infinite loop. gcc/testsuite/ChangeLog: PR fortran/107872 * gfortran.dg/pr107872.f90: New test.
[Bug target/104921] aarch64: Assembler failure with vbfmlalbq_lane_f32 intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104921 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-12-09 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/108041] New: ivopts results in extra instruction in simple loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108041
Bug ID: 108041
Summary: ivopts results in extra instruction in simple loop
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: law at gcc dot gnu.org
CC: rzinsly at ventanamicro dot com
Target Milestone: ---
ivopts seems to make a bit of a mess out of this code resulting in the loop
having an unnecessary instruction. Compile with rv64 -O2:
typedef struct network
{
long nr_group, full_groups, max_elems;
} network_t;
void marc_arcs(network_t* net)
{
while (net->full_groups < 0) {
net->full_groups = net->nr_group + net->full_groups;
net->max_elems--;
}
}
After slp1 we have this loop:
;; basic block 3, loop depth 0
;;pred: 2
_1 = net_8(D)->nr_group;
net__max_elems_lsm.4_16 = net_8(D)->max_elems;
;;succ: 4
;; basic block 4, loop depth 1
;;pred: 7
;;3
# _13 = PHI <_2(7), _11(3)>
# net__max_elems_lsm.4_5 = PHI <_4(7), net__max_elems_lsm.4_16(3)>
_2 = _1 + _13;
_4 = net__max_elems_lsm.4_5 + -1;
if (_2 < 0)
goto ; [89.00%]
else
goto ; [11.00%]
;;succ: 7
;;5
;; basic block 7, loop depth 1
;;pred: 4
goto ; [100.00%]
;;succ: 4
;; basic block 5, loop depth 0
;;pred: 4
# _12 = PHI <_2(4)>
# _17 = PHI <_4(4)>
net_8(D)->full_groups = _12;
net_8(D)->max_elems = _17;
;;succ: 6
Of particular interest is the max_elems computation into _4. We accumulate it
in the loop, then do the final store after the loop (thank you LSM!). After
ivopts we have:
;; basic block 3, loop depth 0
;;pred: 2
_1 = net_8(D)->nr_group;
net__max_elems_lsm.4_16 = net_8(D)->max_elems;
_22 = net__max_elems_lsm.4_16 + -1;
ivtmp.10_21 = (unsigned long) _22;
;;succ: 4
;; basic block 4, loop depth 1
;;pred: 7
;;3
# _13 = PHI <_2(7), _11(3)>
# ivtmp.10_3 = PHI
_2 = _1 + _13;
_4 = (long int) ivtmp.10_3;
ivtmp.10_18 = ivtmp.10_3 - 1;
if (_2 < 0)
goto ; [89.00%]
else
goto ; [11.00%]
;;succ: 7
;;5
;; basic block 7, loop depth 1
;;pred: 4
goto ; [100.00%]
;;succ: 4
;; basic block 5, loop depth 0
;;pred: 4
# _12 = PHI <_2(4)>
# _17 = PHI <_4(4)>
net_8(D)->full_groups = _12;
net_8(D)->max_elems = _17;
;;succ: 6
Note the introduction of the IV and its relationship to _4. Essentially we
compute both in the loop even _4 is always one greater than the IV. Worse yet,
the IV is only used to compute _4! And since they differ by 1, we actually
compute both and keep them alive resulting in this final code for rv64:
.L3:
add a5,a5,a2
mv a3,a4
addia4,a4,-1
blt a5,zero,.L3
sd a5,8(a0)
sd a3,16(a0)
Note how we had to "stash away" the value of a4 before the decrement so that we
could store it after the loop. The induction variable doesn't really buy us
anything in this loop -- it's actively harmful. Not using the IV would
probably be best. Second best would be to realize that _4 (aka a3) can be
derived from the IV (a4) after the loop by adding 1.
[Bug libgcc/107675] [13 Regression] GCC-13 is significantly slower to startup on C++ statically linked programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675 --- Comment #15 from Thomas Neumann --- > You cannot use 'relaxed' atomic load in is_object_initialized - as thread > performing such load will not observe/synchronize with any modifications > (other than atomic variable itself) performed by other threads. you are right, this has to be acquire. Very unfortunate. I thought we would get away with relaxed because we double-check anyway, but with relaxed we might miss the writes to the other fields of object. On systems with strong memory order it does not matter, but on ARM this will make the check slower.
[Bug target/104921] aarch64: Assembler failure with vbfmlalbq_lane_f32 intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104921
--- Comment #2 from Andrew Pinski ---
(define_insn "aarch64_bfmlal_lanev4sf"
[(set (match_operand:V4SF 0 "register_operand" "=w")
(plus: V4SF (match_operand:V4SF 1 "register_operand" "0")
(unspec:V4SF [(match_operand:V8BF 2 "register_operand" "w")
(match_operand:VBF 3 "register_operand" "w")
(match_operand:SI 4 "const_int_operand" "n")]
BF_MLA)))]
"TARGET_BF16_SIMD"
{
operands[4] = aarch64_endian_lane_rtx (mode, INTVAL (operands[4]));
return "bfmlal\\t%0.4s, %2.8h, %3.h[%4]";
}
[(set_attr "type" "neon_fp_mla_s_scalar_q")]
)
Operand 3 should have be:
(match_operand:VBF 3 "register_operand" "x")
[Bug target/104921] aarch64: Assembler failure with vbfmlalbq_lane_f32 intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104921
--- Comment #3 from Andrew Pinski ---
The following patterns has the same problem too:
(define_insn "aarch64_bfdot_lane"
[(set (match_operand:VDQSF 0 "register_operand" "=w")
(plus:VDQSF
(unspec:VDQSF
[(match_operand: 2 "register_operand" "w")
(match_operand:VBF 3 "register_operand" "w")
(match_operand:SI 4 "const_int_operand" "n")]
UNSPEC_BFDOT)
(match_operand:VDQSF 1 "register_operand" "0")))]
"TARGET_BF16_SIMD"
{
int nunits = GET_MODE_NUNITS (mode).to_constant ();
int lane = INTVAL (operands[4]);
operands[4] = gen_int_mode (ENDIAN_LANE_N (nunits / 2, lane), SImode);
return "bfdot\t%0., %2., %3.2h[%4]";
}
[(set_attr "type" "neon_dot")]
That is operand 3 should be using "x" constraint.
[Bug ipa/108000] Assert during ipa-cp with AutoFDO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108000 Eugene Rozenfeld changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Eugene Rozenfeld --- Fixed by https://gcc.gnu.org/g:7410032a772a9e77b620b091c2b551b68113a179 .
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 --- Comment #14 from Ben Barrowes --- Thanks for engaging, and thanks for the suggestion. I might be able to do this over the winter. Could you give me a hint as to where to look. Which files.
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
--- Comment #15 from Steve Kargl ---
On Sat, Dec 10, 2022 at 01:47:44AM +, barrowes at alum dot mit.edu wrote:
>
> Thanks for engaging, and thanks for the suggestion. I might be able to do this
> over the winter. Could you give me a hint as to where to look. Which files.
>
I suspect that you should start by understand gcc/fortran/lang-specs.h.
That's where most of the the filename suffixes are defined. In particular,
this chuck of code
/* Identical to gcc.cc (cpp_options), but omitting %(cpp_unique_options)
and -fpch-preprocess on -save-temps. */
#define CPP_ONLY_OPTIONS"%1 %{m*} %{f*} %{g*:%{!g0:%{g*} \
%{!fno-working-directory:-fworking-directory}}} \
%{std*&ansi&trigraphs} %{W*&pedantic*} %{w} \
%{O*} %{undef}"
[Bug fortran/107995] ICE: Segmentation fault, without backtrace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107995
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Priority|P3 |P4
Ever confirmed|0 |1
Last reconfirmed||2022-12-10
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
This patch prevents the ICE. It has been regression tested, and not regression
occurred. AFAICT, a statement function cannot be a dummy argument.
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index d3e199535b3..8f9eabf0f1c 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -1334,6 +1334,9 @@ gfc_check_dummy_characteristics (gfc_symbol *s1,
gfc_symbol *s2,
if (s1 == NULL || s2 == NULL)
return s1 == s2 ? true : false;
+ if (s1->attr.proc == PROC_ST_FUNCTION || s2->attr.proc == PROC_ST_FUNCTION)
+return false;
+
/* Check type and rank. */
if (type_must_agree)
{
[Bug middle-end/108042] New: [10/11/12/13 Regression] weakref on an extern decl is incorrectly ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108042
Bug ID: 108042
Summary: [10/11/12/13 Regression] weakref on an extern decl is
incorrectly ignored
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
From:
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Common-Function-Attributes.html#index-weakref-function-attribute
Without a target given as an argument to weakref or to alias, weakref is
equivalent to weak (in that case the declaration may be extern).
Testcase:
```
void KNOWNNOTOBEAFUNCTION(void) __attribute__((weakref));
int main() {
if (KNOWNNOTOBEAFUNCTION)
__builtin_abort();
else
return 0;
}
```
This should pass.
[Bug middle-end/108042] [10/11/12/13 Regression] weakref on an extern decl is incorrectly ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108042 Andrew Pinski changed: What|Removed |Added Known to work||4.5.3 Known to fail||4.6.0 --- Comment #1 from Andrew Pinski --- This started to fail with r169288 . Reported originally at https://gcc.gnu.org/pipermail/gcc/2022-December/240283.html .
[Bug c/108043] New: [13 Regression] ICE: in fold_convert_loc, at fold-const.cc:2618 on invalid function braced initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108043
Bug ID: 108043
Summary: [13 Regression] ICE: in fold_convert_loc, at
fold-const.cc:2618 on invalid function braced
initializer
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Created attachment 54058
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54058&action=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c
testcase.c: In function 'foo':
testcase.c:6:3: internal compiler error: in fold_convert_loc, at
fold-const.cc:2618
6 | (F){};
| ^
0x6ef305 fold_convert_loc(unsigned int, tree_node*, tree_node*)
/repo/gcc-trunk/gcc/fold-const.cc:2618
0xd58d59 pop_init_level(unsigned int, int, obstack*, unsigned int)
/repo/gcc-trunk/gcc/c/c-typeck.cc:9371
0xd7d018 c_parser_braced_init
/repo/gcc-trunk/gcc/c/c-parser.cc:5784
0xd7d383 c_parser_postfix_expression_after_paren_type
/repo/gcc-trunk/gcc/c/c-parser.cc:10945
0xd77f70 c_parser_cast_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:8659
0xd77fef c_parser_binary_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:8449
0xd7944b c_parser_conditional_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:8147
0xd79c64 c_parser_expr_no_commas
/repo/gcc-trunk/gcc/c/c-parser.cc:8061
0xd79f11 c_parser_expression
/repo/gcc-trunk/gcc/c/c-parser.cc:11385
0xd7a657 c_parser_expression_conv
/repo/gcc-trunk/gcc/c/c-parser.cc:11425
0xd6f1cf c_parser_statement_after_labels
/repo/gcc-trunk/gcc/c/c-parser.cc:6790
0xd71714 c_parser_compound_statement_nostart
/repo/gcc-trunk/gcc/c/c-parser.cc:6305
0xd96ec4 c_parser_compound_statement
/repo/gcc-trunk/gcc/c/c-parser.cc:6114
0xd98ef8 c_parser_declaration_or_fndef
/repo/gcc-trunk/gcc/c/c-parser.cc:2850
0xda07c3 c_parser_external_declaration
/repo/gcc-trunk/gcc/c/c-parser.cc:1925
0xda11f3 c_parser_translation_unit
/repo/gcc-trunk/gcc/c/c-parser.cc:1779
0xda11f3 c_parse_file()
/repo/gcc-trunk/gcc/c/c-parser.cc:24596
0xe0d2b1 c_common_parse_file()
/repo/gcc-trunk/gcc/c-family/c-opts.cc:1248
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-r13-4583-20221209191939-g71b31d13757-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/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 --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-4583-20221209191939-g71b31d13757-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221209 (experimental) (GCC)
[Bug target/108044] New: [13 Regression] ICE: in extract_constrain_insn, at recog.cc:2692 (insn does not satisfy its constraints) at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108044
Bug ID: 108044
Summary: [13 Regression] ICE: in extract_constrain_insn, at
recog.cc:2692 (insn does not satisfy its constraints)
at -O
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
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 54059
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54059&action=edit
reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O testcase.c
testcase.c: In function 'foo':
testcase.c:9:1: error: insn does not satisfy its constraints:
9 | }
| ^
(insn 20 19 18 2 (set (mem/c:DI (plus:DI (reg/f:DI 7 sp)
(const_int -16 [0xfff0])) [2 %sfp+-8 S8 A64])
(const_int -9223372036854775808 [0x8000]))
"testcase.c":8:49 82 {*movdi_internal}
(nil))
during RTL pass: cprop_hardreg
testcase.c:9:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2692
0x77a82b _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x77a8b1 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:118
0x769601 extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2692
0x12ff6b3 copyprop_hardreg_forward_1
/repo/gcc-trunk/gcc/regcprop.cc:826
0x1300b9f execute
/repo/gcc-trunk/gcc/regcprop.cc:1408
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-r13-4583-20221209191939-g71b31d13757-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/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 --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-4583-20221209191939-g71b31d13757-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221209 (experimental) (GCC)
[Bug analyzer/108045] New: analyzer: false positive memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108045 Bug ID: 108045 Summary: analyzer: false positive memory leak Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: jamie.bainbridge at gmail dot com Target Milestone: --- Created attachment 54060 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54060&action=edit minimal reproducer The analyzer detects a memory leak here, but I don't think there is one. It seems not to have understood that I've kept the reference to "new_scr" (and its child allocation) in the global "ctx->scr" when I swap the pointers on line 80/81 with: struct screen_s *old_scr = ctx->scr; ctx->scr = new_scr; I found that if I omit the body of resize_screen() and place its instructions directly in main(), then the analyzer doesn't report anything is wrong. It seems the extra layer of indirection with the resize_screen() function trips it up. This problem happens with GCC 11.3.0, 12.1.0, and 13.0-20221209 nightly from Compiler Explorer. Full output from CE nightly below, using these options: -v -save-temps -g3 -Og -std=c99 -Wall -Wextra -Wpedantic -fanalyzer Using built-in specs. COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/gcc Target: x86_64-linux-gnu Configured with: ../gcc-trunk-20221209/configure --prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap --enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada,objc,obj-c++,d --enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix --with-pkgversion=Compiler-Explorer-Build-gcc-e6110da479951b759a12c5618f5304187b650326-binutils-2.38 --enable-libstdcxx-backtrace=yes Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.0.0 20221209 (experimental) (Compiler-Explorer-Build-gcc-e6110da479951b759a12c5618f5304187b650326-binutils-2.38) COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s' '-masm=intel' '-S' '-v' '-save-temps' '-g3' '-Og' '-std=c99' '-Wall' '-Wextra' '-Wpedantic' '-fanalyzer' '-mtune=generic' '-march=x86-64' '-dumpdir' '/app/' /opt/compiler-explorer/gcc-trunk-20221209/bin/../libexec/gcc/x86_64-linux-gnu/13.0.0/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu -iprefix /opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/x86_64-linux-gnu/13.0.0/ -dD -masm=intel -mtune=generic -march=x86-64 -std=c99 -Wall -Wextra -Wpedantic -fdiagnostics-color=always -fanalyzer -g -g3 -fworking-directory -Og -fpch-preprocess -o /app/output.i ignoring nonexistent directory "/opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/x86_64-linux-gnu/13.0.0/../../../../x86_64-linux-gnu/include" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/13.0.0/include" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/13.0.0/include-fixed/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/13.0.0/include-fixed" ignoring nonexistent directory "/opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/13.0.0/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/x86_64-linux-gnu/13.0.0/include /opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/x86_64-linux-gnu/13.0.0/include-fixed/x86_64-linux-gnu /opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/x86_64-linux-gnu/13.0.0/include-fixed /usr/local/include /opt/compiler-explorer/gcc-trunk-20221209/bin/../lib/gcc/../../include /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s' '-masm=intel' '-S' '-v' '-save-temps' '-g3' '-Og' '-std=c99' '-Wall' '-Wextra' '-Wpedantic' '-fanalyzer' '-mtune=generic' '-march=x86-64' '-dumpdir' '/app/' /opt/compiler-explorer
[Bug c/108043] [13 Regression] ICE: in fold_convert_loc, at fold-const.cc:2618 on invalid function braced initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108043 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Target Milestone|--- |13.0
[Bug c/108043] [13 Regression] ICE: in fold_convert_loc, at fold-const.cc:2618 on invalid function braced initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108043 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-12-10 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. Either introduced by: r13-2205-g14cfa01755a66a or r13-3930-gb556d1773db717
[Bug preprocessor/105207] Translation phase 2: splicing physical source lines to form logical source lines may not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105207 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Dup of bug 55242. *** This bug has been marked as a duplicate of bug 55242 ***
[Bug preprocessor/55242] continued lines not always merged into one long line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55242 Andrew Pinski changed: What|Removed |Added CC||pavel.morozkin at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 105207 has been marked as a duplicate of this bug. ***
