[Bug target/106902] [11/12/13/14 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 --- Comment #25 from Alexander Monakov --- (In reply to Richard Biener from comment #24) > As of the patch it looks good, I wonder if we want to check for OPTIMIZE_BOTH > though since at least when no extra negations are required the contraction > should also be a win when optimizing for size? Makes sense, I'll change that (current target hooks always return true for fma). > Also I wondered about the PROP_gimple_any check - do we get into the > gimplification langhook after lowering? I see we are not resetting the > langhook after lowering (only in free-lang-data, but that only runs with > LTO). Yes, that surprised me. I caught it when analyzing ICE on slp-50.c testcase. > We probably at least should gate the langhook invocation in the gimplifier > with what you added in the patch or specify whether the gimplifier is > invoked from the middle-end via the gimplifier context. Perhaps. I'll add a comment that we want to handle -ffp-contract=on strictly during initial gimplification, to hash this out further on gcc-patches, if necessary. > If we go for c-family only the genericize entry could be another place to > handle this. That seems less convenient to me. Is IFN_FMA representable as a tree? > Did you run into any of NON_LVALUE / C_MAYBE_CONST wrappings of the > multiplication btw? No, I'm not familiar with those, so I didn't try to construct corresponding testcases.
[Bug target/109896] Missed optimisation: overflow detection in multiplication instructions for operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109896 --- Comment #6 from Jonathan Wakely --- With placement-new there's no allocation: https://gcc.godbolt.org/z/68e4PaeYz
[Bug other/109898] 'make install -j' sometimes corrupts 'dir' file for .info files due to parallel 'install-info' calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109898 --- Comment #2 from Jonathan Wakely --- (In reply to Sergei Trofimovich from comment #0) > --- gcc-12.2.0/gcc/Makefile.in2022-08-19 10:09:52.280658631 +0200 > +++ gcc-12.2.0-new/gcc/Makefile.in2023-05-04 14:35:44.401420184 +0200 > @@ -3781,6 +3781,11 @@ > fi; \ > fi > > +# We don't care about the order in which the info files are built, but > +# install-info doesn't support multiple parallel invocations writing to > +# the same `dir-file`, so we have to disable parallelism for that reason: > +.NOTPARALLEL: install-info Prerequisites of .NOTPARALLEL are ignored, so doesn't this un-parallelize building the entire gcc sub-dir?
[Bug bootstrap/105831] Nonportable syntax in "test" and "[" commands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105831 --- Comment #4 from Jonathan Wakely --- The == syntax also fails with dash, which is used as the default /bin/sh on debian: $ /bin/sh -c "test foo = foo && echo y" y $ /bin/sh -c "test foo == foo && echo y" /bin/sh: 1: test: foo: unexpected operator
[Bug ada/109881] GNAT BUG DETECTED during RTL pass, raised TYPES.UNRECOVERABLE_ERROR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109881 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2023-05-18 Status|UNCONFIRMED |NEW CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Eric Botcazou --- Still present on the mainline: /home/eric/install/gcc/lib64/gcc/x86_64-suse-linux/14.0.0/adainclude/s-stoele.adb: In function 'Zstandard.Streaming_Decompression.Read_Compressed_Data': /home/eric/install/gcc/lib64/gcc/x86_64-suse-linux/14.0.0/adainclude/s-stoele.adb:68:31: error: definition in block 5 does not dominate use in block 12 for SSA_NAME: _48 in statement: _16 = _48 & 18446744073709551608; during GIMPLE pass: ssa +===GNAT BUG DETECTED==+ | 14.0.0 20230515 (experimental) [master r14-815-gf2afe68a175] (x86_64-suse-linux) GCC error:| | verify_ssa failed
[Bug ada/109881] internal error on function returning dynamically-sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109881 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Eric Botcazou --- I'll have a look.
[Bug target/108703] insn does not satisfy its constraints: movhi_insn at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108703 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|ebotcazou at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Too pathological.
[Bug target/92902] jump tables are put into the text section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92902 Eric Botcazou changed: What|Removed |Added Assignee|ebotcazou at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|SUSPENDED --- Comment #21 from Eric Botcazou --- Probably too late to be changed now.
[Bug bootstrap/105831] Nonportable syntax in "test" and "[" commands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105831 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Jonathan Wakely --- == does work with ksh, which is used as /bin/sh on AIX, Solaris, and OpenBSD, and works with FreeBSD sh (derived from ask, I think). It doesn't work with dash, or NetBSD sh (also derived from ash, I think), or with zsh (unless you quote it as "=="). So I think we do want this change. I'll get it pushed.
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #8 from Jan Hubicka ---
We can only SRA if the address is non-escaping. Clang does not seem to need it
to optimize better:
jan@localhost:~> cat t.c
extern void q(int *);
__attribute__ ((noinline))
void
test()
{
for (int a = 0; a < 1000;a++)
if (!(a%100))
q(&a);
}
int
main()
{
for (int a = 0; a < 100;a++)
test ();
}
jan@localhost:~> cat t2.c
void q(int *a)
{
}
jan@localhost:~> gcc -O2 t.c t2.c ; perf stat ./a.out
Performance counter stats for './a.out':
2,916.73 msec task-clock:u #0.999 CPUs
utilized
0 context-switches:u #0.000 /sec
0 cpu-migrations:u #0.000 /sec
52 page-faults:u# 17.828 /sec
8,344,719,833 cycles:u #2.861 GHz
13,561,375 stalled-cycles-frontend:u#0.16% frontend
cycles idle
5,128,112,757 stalled-cycles-backend:u # 61.45% backend
cycles idle
10,050,172,242 instructions:u #1.20 insn per
cycle
#0.51 stalled cycles per
insn
2,034,043,082 branches:u # 697.370 M/sec
11,186,312 branch-misses:u #0.55% of all
branches
2.918344737 seconds time elapsed
2.917844000 seconds user
0.0 seconds sys
jan@localhost:~> clang -O2 t.c t2.c ; perf stat ./a.out
Performance counter stats for './a.out':
664.40 msec task-clock:u #0.999 CPUs
utilized
0 context-switches:u #0.000 /sec
0 cpu-migrations:u #0.000 /sec
54 page-faults:u# 81.276 /sec
2,318,095,848 cycles:u #3.489 GHz
10,417,694 stalled-cycles-frontend:u#0.45% frontend
cycles idle
1,057,731,301 stalled-cycles-backend:u # 45.63% backend
cycles idle
10,062,172,840 instructions:u #4.34 insn per
cycle
#0.11 stalled cycles per
insn
2,034,042,724 branches:u #3.061 G/sec
10,003,620 branch-misses:u #0.49% of all
branches
0.665267996 seconds time elapsed
0.665247000 seconds user
0.0 seconds sys
We do:
jmp .L3
.p2align 4,,10
.p2align 3
.L2:
movl12(%rsp), %eax
addl$1, %eax
movl%eax, 12(%rsp)
cmpl$999, %eax
jg .L7
.L3:
imull $-1030792151, %eax, %eax
addl$85899344, %eax
rorl$2, %eax
cmpl$42949672, %eax
ja .L2
leaq12(%rsp), %rdi
callq
jmp .L2
Which has stupid store-to-load dpendency in the internal loop. Clang keeps the
store but optimizes away the load:
jmp .LBB0_1
.p2align4, 0x90
.LBB0_3:# in Loop: Header=BB0_1 Depth=1
leal1(%rax), %ecx
movl%ecx, 12(%rsp)
cmpl$999, %eax # imm = 0x3E7
movl%ecx, %eax
jge .LBB0_4
.LBB0_1:# =>This Inner Loop Header: Depth=1
imull $-1030792151, %eax, %ecx# imm = 0xC28F5C29
addl$85899344, %ecx # imm = 0x51EB850
rorl$2, %ecx
cmpl$42949672, %ecx # imm = 0x28F5C28
ja .LBB0_3
# %bb.2:# in Loop: Header=BB0_1 Depth=1
movq%rbx, %rdi
callq q@PLT
movl12(%rsp), %eax
jmp .LBB0_3
Wonder what makes clang to think it needs @PLT though.
Why we do not consider the load as partially redundant with itself?
[Bug target/109697] arm: lack of MVE instruction costing causing worse codegen on a vec_duplicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109697 --- Comment #1 from CVS Commits --- The releases/gcc-13 branch has been updated by Stam Markianos-Wright : https://gcc.gnu.org/g:f9b84a16510c91af29add6cb1855306dfc8af035 commit r13-7351-gf9b84a16510c91af29add6cb1855306dfc8af035 Author: Stam Markianos-Wright Date: Thu Apr 27 15:54:16 2023 +0100 arm testsuite: XFAIL or relax registers in some tests [PR109697] This is a simple testsuite tidy-up patch, addressing to types of errors: * The vcmp vector-scalar tests failing due to the compiler's preference of vector-vector comparisons, over vector-scalar comparisons. This is due to the lack of cost model for MVE and the compiler not knowing that the RTL vec_duplicate is free in those instructions. For now, we simply XFAIL these checks. * The tests for pr108177 had strict usage of q0 and r0 registers, meaning that they would FAIL with -mfloat-abi=softf. The register checks have now been relaxed. A couple of these run-tests also had incosistent use of integer MVE with floating point vectors, so I've now changed these to use FP MVE. gcc/testsuite/ChangeLog: PR target/109697 * gcc.target/arm/mve/intrinsics/vcmpcsq_n_u16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpcsq_n_u32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpcsq_n_u8.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_u16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_u32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_u8.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpgeq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpgeq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpgtq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpgtq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmphiq_n_u16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmphiq_n_u32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmphiq_n_u8.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpleq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpleq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpltq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpltq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpneq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpneq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpneq_n_u16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpneq_n_u32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpneq_n_u8.c: XFAIL check. * gcc.target/arm/mve/pr108177-1.c: Relax registers. * gcc.target/arm/mve/pr108177-10.c: Relax registers. * gcc.target/arm/mve/pr108177-11.c: Relax registers. * gcc.target/arm/mve/pr108177-12.c: Relax registers. * gcc.target/arm/mve/pr108177-13.c: Relax registers. * gcc.target/arm/mve/pr108177-13-run.c: use mve_fp * gcc.target/arm/mve/pr108177-14.c: Relax registers. * gcc.target/arm/mve/pr108177-14-run.c: use mve_fp * gcc.target/arm/mve/pr108177-2.c: Relax registers. * gcc.target/arm/mve/pr108177-3.c: Relax registers. * gcc.target/arm/mve/pr108177-4.c: Relax registers. * gcc.target/arm/mve/pr108177-5.c: Relax registers. * gcc.target/arm/mve/pr108177-6.c: Relax registers. * gcc.target/arm/mve/pr108177-7.c: Relax registers. * gcc.target/arm/mve/pr108177-8.c: Relax registers. * gcc.target/arm/mve/pr108177-9.c: Relax registers.
[Bug tree-optimization/101856] match_arith_overflow checks only mulv4_optab/umulv4_optab tables when smul_highpart_optab/umul_highpart_optab can produce decent code too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101856 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jakub Jelinek --- Created attachment 55109 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55109&action=edit gcc14-pr101856.patch Untested fix.
[Bug target/109697] arm: lack of MVE instruction costing causing worse codegen on a vec_duplicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109697 --- Comment #2 from CVS Commits --- The master branch has been updated by Stam Markianos-Wright : https://gcc.gnu.org/g:7587c2e3844baf26255a7cc6e1d291240a1c28d3 commit r14-966-g7587c2e3844baf26255a7cc6e1d291240a1c28d3 Author: Stam Markianos-Wright Date: Thu Apr 27 15:54:16 2023 +0100 arm testsuite: XFAIL or relax registers in some tests [PR109697] Hi all, This is a simple testsuite tidy-up patch, addressing to types of errors: * The vcmp vector-scalar tests failing due to the compiler's preference of vector-vector comparisons, over vector-scalar comparisons. This is due to the lack of cost model for MVE and the compiler not knowing that the RTL vec_duplicate is free in those instructions. For now, we simply XFAIL these checks. * The tests for pr108177 had strict usage of q0 and r0 registers, meaning that they would FAIL with -mfloat-abi=softf. The register checks have now been relaxed. A couple of these run-tests also had incosistent use of integer MVE with floating point vectors, so I've now changed these to use FP MVE. gcc/testsuite/ChangeLog: PR target/109697 * gcc.target/arm/mve/intrinsics/vcmpcsq_n_u16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpcsq_n_u32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpcsq_n_u8.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_u16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_u32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_u8.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpgeq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpgeq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpgtq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpgtq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmphiq_n_u16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmphiq_n_u32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmphiq_n_u8.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpleq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpleq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpltq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpltq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpneq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpneq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpneq_n_u16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpneq_n_u32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpneq_n_u8.c: XFAIL check. * gcc.target/arm/mve/pr108177-1.c: Relax registers. * gcc.target/arm/mve/pr108177-10.c: Relax registers. * gcc.target/arm/mve/pr108177-11.c: Relax registers. * gcc.target/arm/mve/pr108177-12.c: Relax registers. * gcc.target/arm/mve/pr108177-13.c: Relax registers. * gcc.target/arm/mve/pr108177-13-run.c: use mve_fp * gcc.target/arm/mve/pr108177-14.c: Relax registers. * gcc.target/arm/mve/pr108177-14-run.c: use mve_fp * gcc.target/arm/mve/pr108177-2.c: Relax registers. * gcc.target/arm/mve/pr108177-3.c: Relax registers. * gcc.target/arm/mve/pr108177-4.c: Relax registers. * gcc.target/arm/mve/pr108177-5.c: Relax registers. * gcc.target/arm/mve/pr108177-6.c: Relax registers. * gcc.target/arm/mve/pr108177-7.c: Relax registers. * gcc.target/arm/mve/pr108177-8.c: Relax registers. * gcc.target/arm/mve/pr108177-9.c: Relax registers.
[Bug testsuite/109880] [14 regression] gcc.target/powerpc/fold-vec-extract-int.p8.c fails after r14-916-g9417b30499ce09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109880 --- Comment #2 from Ajit Kumar Agarwal --- Yes these are redundant zero extend and can be removed. I will update the tests and send the patch for review.
[Bug target/105719] RFE: fixincludes should handle Frameworks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105719 --- Comment #6 from Eric Gallager --- (In reply to Iain Sandoe from comment #4) > Created attachment 55084 [details] > Implement the use of fixed framework headers > > this was a proof-of-principle exercise while looking into issues caused by > implementing __has_feature () [PR60512]. > > This does not have any of the mechanism to *create* or *install* the fixed > headers (for my testing I just built a > CoreFoundation.framework/Headers/CFBase.h and edited bye hand to fix the > problems found). > > So, still plenty to do ;) Remind me to test this patch later; I've kind of forgotten where I was with this... distracted with other stuff... (maybe I should unassign it from myself?)
[Bug target/96795] MVE: issue with polymorphism and integer promotion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96795 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Stam Markianos-Wright : https://gcc.gnu.org/g:7d3043505c770e96d5471edee2b97c8169f26316 commit r12-9557-g7d3043505c770e96d5471edee2b97c8169f26316 Author: Stam Markianos-Wright Date: Thu Nov 10 15:02:47 2022 + arm: further fix overloading of MVE vaddq[_m]_n intrinsic It was observed that in tests `vaddq_m_n_[s/u][8/16/32].c`, the _Generic resolution would fall back to the `__ARM_undef` failure state. This is a regression since `dc39db873670bea8d8e655444387ceaa53a01a79` and `6bd4ce64eb48a72eca300cb52773e6101d646004`, but it previously wasn't identified, because the tests were not checking for this kind of failure. The above commits changed the definitions of the intrinsics from using `[u]int[8/16/32]_t` types for the scalar argument to using `int`. This allowed `int` to be supported in user code through the overloaded `#defines`, but seems to have broken the `[u]int[8/16/32]_t` types The solution implemented by this patch is to explicitly use a new _Generic mapping from all the `[u]int[8/16/32]_t` types for int. With this change, both `int` and `[u]int[8/16/32]_t` parameters are supported from user code and are handled by the overloading mechanism correctly. Note that in these scalar cases it is safe to pass the raw p, rather than the typeof-ed __p, because we are not at risk of the _Generics being exponentially expanded on the `n` scalar argument to an `_n` intrinsic. Using p instead will give a more accurate error message to the user, should something be wrong with that argument. gcc/ChangeLog: PR target/96795 * config/arm/arm_mve.h (__arm_vaddq_m_n_s8): Change types. (__arm_vaddq_m_n_s32): Likewise. (__arm_vaddq_m_n_s16): Likewise. (__arm_vaddq_m_n_u8): Likewise. (__arm_vaddq_m_n_u32): Likewise. (__arm_vaddq_m_n_u16): Likewise. (__arm_vaddq_m): Fix Overloading. (__ARM_mve_coerce3): New. (cherry picked from commit e0dd75fe90ef4cda94f431747d239d6cfcf5656f)
[Bug target/96795] MVE: issue with polymorphism and integer promotion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96795 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Stam Markianos-Wright : https://gcc.gnu.org/g:bbdf67595a57b1b029cfe17a581efe42c242b6e4 commit r12-9558-gbbdf67595a57b1b029cfe17a581efe42c242b6e4 Author: Stam Markianos-Wright Date: Thu Nov 10 15:02:52 2022 + arm: propagate fixed overloading of MVE intrinsic scalar parameters This is a mechanical patch that propagates the change proposed in my previous patch for vaddq[_m]_n across all other polymorphic MVE intrinsic overloads of scalar types. The find and Replace patterns used were: s/__ARM_mve_coerce\(__p(\d+), [u]?int(8|16|32|64)_t\) /__ARM_mve_coerce3(p$1, int)/g s/__ARM_mve_coerce2\(__p(\d+), double\) /__ARM_mve_coerce2(p$1, double)/g gcc/ChangeLog: PR target/96795 * config/arm/arm_mve.h (__arm_vaddq): Fix Overloading. (__arm_vmulq): Likewise. (__arm_vcmpeqq): Likewise. (__arm_vcmpneq): Likewise. (__arm_vmaxnmavq): Likewise. (__arm_vmaxnmvq): Likewise. (__arm_vminnmavq): Likewise. (__arm_vsubq): Likewise. (__arm_vminnmvq): Likewise. (__arm_vrshlq): Likewise. (__arm_vqsubq): Likewise. (__arm_vqdmulltq): Likewise. (__arm_vqdmullbq): Likewise. (__arm_vqdmulhq): Likewise. (__arm_vqaddq): Likewise. (__arm_vhaddq): Likewise. (__arm_vhsubq): Likewise. (__arm_vqdmlashq): Likewise. (__arm_vqrdmlahq): Likewise. (__arm_vmlasq): Likewise. (__arm_vqdmlahq): Likewise. (__arm_vmaxnmavq_p): Likewise. (__arm_vmaxnmvq_p): Likewise. (__arm_vminnmavq_p): Likewise. (__arm_vminnmvq_p): Likewise. (__arm_vfmasq_m): Likewise. (__arm_vsetq_lane): Likewise. (__arm_vcmpneq_m): Likewise. (__arm_vhaddq_x): Likewise. (__arm_vhsubq_x): Likewise. (__arm_vqrdmlashq_m): Likewise. (__arm_vqdmlashq_m): Likewise. (__arm_vmlaldavaxq_p): Likewise. (__arm_vmlasq_m): Likewise. (__arm_vqdmulhq_m): Likewise. (__arm_vqdmulltq_m): Likewise. (__arm_viwdupq_m): Likewise. (__arm_viwdupq_u16): Likewise. (__arm_viwdupq_u32): Likewise. (__arm_viwdupq_u8): Likewise. (__arm_vdwdupq_m): Likewise. (__arm_vdwdupq_u16): Likewise. (__arm_vdwdupq_u32): Likewise. (__arm_vdwdupq_u8): Likewise. (__arm_vaddlvaq): Likewise. (__arm_vaddlvaq_p): Likewise. (__arm_vaddvaq): Likewise. (__arm_vaddvaq_p): Likewise. (__arm_vcmphiq_m): Likewise. (__arm_vmladavaq_p): Likewise. (__arm_vmladavaxq): Likewise. (__arm_vmlaldavaxq): Likewise. (__arm_vrmlaldavhaq_p): Likewise. (cherry picked from commit 31df339a50c30712c1e071d2b18f304b148a3165)
[Bug target/107515] MVE: Generic functions do not accept _Float16 scalars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515 --- Comment #11 from CVS Commits --- The releases/gcc-12 branch has been updated by Stam Markianos-Wright : https://gcc.gnu.org/g:79431d45e2c25dc8608c8ddc6d2798dbcb79650a commit r12-9559-g79431d45e2c25dc8608c8ddc6d2798dbcb79650a Author: Stam Markianos-Wright Date: Thu Nov 10 15:06:47 2022 + arm: Explicitly specify other float types for _Generic overloading [PR107515] This patch adds explicit references to other float types to __ARM_mve_typeid in arm_mve.h. Resolves PR 107515: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515 gcc/ChangeLog: PR target/107515 * config/arm/arm_mve.h (__ARM_mve_typeid): Add float types. (cherry picked from commit 2fefb8931d566cc8a4cbba81601972b0d2002f95)
[Bug target/107515] MVE: Generic functions do not accept _Float16 scalars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515 --- Comment #12 from CVS Commits --- The releases/gcc-12 branch has been updated by Stam Markianos-Wright : https://gcc.gnu.org/g:c7c4dfb5989e80ffc8e8439a8d9a9ed654612b90 commit r12-9608-gc7c4dfb5989e80ffc8e8439a8d9a9ed654612b90 Author: Stam Markianos-Wright Date: Mon Jan 16 11:40:40 2023 + arm: Split up MVE _Generic associations to prevent type clashes [PR107515] With these previous patches: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606586.html https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606587.html we enabled the MVE overloaded _Generic associations to handle more scalar types, however at PR 107515 we found a new regression that wasn't detected in our testing: With glibc's posix/types.h: ``` typedef signed int __int32_t; ... typedef __int32_t int32_t; ``` We would get a `error: '_Generic' specifies two compatible types` from `__ARM_mve_coerce3` because of `type: param`, when `type` is `int` and `int32_t: param` both being the same under the hood. The same did not happen with Newlib's header sys/_stdint.h: ``` typedef long int __int32_t; ... typedef __int32_t int32_t ; ``` which worked fine, because it uses `long int`. The same could feasibly happen in `__ARM_mve_coerce2` between `__fp16` and `float16_t`. The solution here is to break the _Generic down so that the similar types don't appear at the same level, as is done in `__ARM_mve_typeid` gcc/ChangeLog: PR target/96795 PR target/107515 * config/arm/arm_mve.h (__ARM_mve_coerce2): Split types. (__ARM_mve_coerce3): Likewise. gcc/testsuite/ChangeLog: PR target/96795 PR target/107515 * gcc.target/arm/mve/intrinsics/mve_intrinsic_type_overloads-fp.c: New test. * gcc.target/arm/mve/intrinsics/mve_intrinsic_type_overloads-int.c: New test. (cherry picked from commit 8a1360e72d6c6056606aa5edd8c906c50f26de59)
[Bug target/108177] MVE predicated stores to same address get optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108177 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Stam Markianos-Wright : https://gcc.gnu.org/g:bb113a56e31159f4fbe26cc06ee25e4972ce74b5 commit r12-9610-gbb113a56e31159f4fbe26cc06ee25e4972ce74b5 Author: Andre Vieira Date: Tue Jan 24 16:59:23 2023 + arm: Make MVE masked stores read memory operand [PR 108177] This patch adds the memory operand of MVE masked stores as input operands to mimic the 'partial' writes, to prevent erroneous write-after-write optimizations as described in the PR. gcc/ChangeLog: PR target/108177 * config/arm/mve.md (mve_vstrbq_p_, mve_vstrhq_p_fv8hf, mve_vstrhq_p_, mve_vstrwq_p_v4si): Add memory operand as input operand. gcc/testsuite/ChangeLog: * gcc.target/arm/mve/pr108177-1-run.c: New test. * gcc.target/arm/mve/pr108177-1.c: New test. * gcc.target/arm/mve/pr108177-10-run.c: New test. * gcc.target/arm/mve/pr108177-10.c: New test. * gcc.target/arm/mve/pr108177-11-run.c: New test. * gcc.target/arm/mve/pr108177-11.c: New test. * gcc.target/arm/mve/pr108177-12-run.c: New test. * gcc.target/arm/mve/pr108177-12.c: New test. * gcc.target/arm/mve/pr108177-13-run.c: New test. * gcc.target/arm/mve/pr108177-13.c: New test. * gcc.target/arm/mve/pr108177-14-run.c: New test. * gcc.target/arm/mve/pr108177-14.c: New test. * gcc.target/arm/mve/pr108177-2-run.c: New test. * gcc.target/arm/mve/pr108177-2.c: New test. * gcc.target/arm/mve/pr108177-3-run.c: New test. * gcc.target/arm/mve/pr108177-3.c: New test. * gcc.target/arm/mve/pr108177-4-run.c: New test. * gcc.target/arm/mve/pr108177-4.c: New test. * gcc.target/arm/mve/pr108177-5-run.c: New test. * gcc.target/arm/mve/pr108177-5.c: New test. * gcc.target/arm/mve/pr108177-6-run.c: New test. * gcc.target/arm/mve/pr108177-6.c: New test. * gcc.target/arm/mve/pr108177-7-run.c: New test. * gcc.target/arm/mve/pr108177-7.c: New test. * gcc.target/arm/mve/pr108177-8-run.c: New test. * gcc.target/arm/mve/pr108177-8.c: New test. * gcc.target/arm/mve/pr108177-9-run.c: New test. * gcc.target/arm/mve/pr108177-9.c: New test. * gcc.target/arm/mve/pr108177-main.x: New test include. * gcc.target/arm/mve/pr108177.x: New test include. (cherry picked from commit c1093923733a1072a237f112e3239b5ebd88eadd)
[Bug target/96795] MVE: issue with polymorphism and integer promotion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96795 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Stam Markianos-Wright : https://gcc.gnu.org/g:c7c4dfb5989e80ffc8e8439a8d9a9ed654612b90 commit r12-9608-gc7c4dfb5989e80ffc8e8439a8d9a9ed654612b90 Author: Stam Markianos-Wright Date: Mon Jan 16 11:40:40 2023 + arm: Split up MVE _Generic associations to prevent type clashes [PR107515] With these previous patches: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606586.html https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606587.html we enabled the MVE overloaded _Generic associations to handle more scalar types, however at PR 107515 we found a new regression that wasn't detected in our testing: With glibc's posix/types.h: ``` typedef signed int __int32_t; ... typedef __int32_t int32_t; ``` We would get a `error: '_Generic' specifies two compatible types` from `__ARM_mve_coerce3` because of `type: param`, when `type` is `int` and `int32_t: param` both being the same under the hood. The same did not happen with Newlib's header sys/_stdint.h: ``` typedef long int __int32_t; ... typedef __int32_t int32_t ; ``` which worked fine, because it uses `long int`. The same could feasibly happen in `__ARM_mve_coerce2` between `__fp16` and `float16_t`. The solution here is to break the _Generic down so that the similar types don't appear at the same level, as is done in `__ARM_mve_typeid` gcc/ChangeLog: PR target/96795 PR target/107515 * config/arm/arm_mve.h (__ARM_mve_coerce2): Split types. (__ARM_mve_coerce3): Likewise. gcc/testsuite/ChangeLog: PR target/96795 PR target/107515 * gcc.target/arm/mve/intrinsics/mve_intrinsic_type_overloads-fp.c: New test. * gcc.target/arm/mve/intrinsics/mve_intrinsic_type_overloads-int.c: New test. (cherry picked from commit 8a1360e72d6c6056606aa5edd8c906c50f26de59)
[Bug target/108442] arm: MVE's vld1* and vst1* do not work when __ARM_MVE_PRESERVE_USER_NAMESPACE is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108442 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Stam Markianos-Wright : https://gcc.gnu.org/g:60e54b99f597a594a9ad8deaa2af1ed66eb451c7 commit r12-9611-g60e54b99f597a594a9ad8deaa2af1ed66eb451c7 Author: Murray Steele Date: Wed Dec 22 15:55:58 2021 + arm: fix __arm_vld1q_z* and __arm_vst1q_p* intrinsics [PR108442] The MVE ACLE allows for __ARM_MVE_PRESERVE_USER_NAMESPACE to be defined, which removes definitions for intrinsic functions without the __arm_ prefix. __arm_vld1q_z* and __arm_vst1q_p* are currently implemented via calls to vldr* and vstr*, which results in several compile-time errors when __ARM_MVE_PRESERVE_USER_NAMESPACE is defined. This patch replaces these with calls to their prefixed counterparts, __arm_vldr* and __arm_str*, and adds a test covering the definition of __ARM_MVE_PRESERVE_USER_NAMESPACE. gcc/ChangeLog: PR target/108442 * config/arm/arm_mve.h (__arm_vst1q_p_u8): Use prefixed intrinsic function. (__arm_vst1q_p_s8): Likewise. (__arm_vld1q_z_u8): Likewise. (__arm_vld1q_z_s8): Likewise. (__arm_vst1q_p_u16): Likewise. (__arm_vst1q_p_s16): Likewise. (__arm_vld1q_z_u16): Likewise. (__arm_vld1q_z_s16): Likewise. (__arm_vst1q_p_u32): Likewise. (__arm_vst1q_p_s32): Likewise. (__arm_vld1q_z_u32): Likewise. (__arm_vld1q_z_s32): Likewise. (__arm_vld1q_z_f16): Likewise. (__arm_vst1q_p_f16): Likewise. (__arm_vld1q_z_f32): Likewise. (__arm_vst1q_p_f32): Likewise. gcc/testsuite/ChangeLog: * gcc.target/arm/mve/general/preserve_user_namespace_1.c: New test. (cherry picked from commit f54e31ddefe3ea7146624eabcb75b1c90dc59f1a)
[Bug target/109697] arm: lack of MVE instruction costing causing worse codegen on a vec_duplicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109697 --- Comment #3 from CVS Commits --- The releases/gcc-12 branch has been updated by Stam Markianos-Wright : https://gcc.gnu.org/g:8ed701b52847e49d63634f03ec8800ff92b76dea commit r12-9621-g8ed701b52847e49d63634f03ec8800ff92b76dea Author: Stam Markianos-Wright Date: Thu Apr 27 15:54:16 2023 +0100 arm testsuite: XFAIL or relax registers in some tests [PR109697] Hi all, This is a simple testsuite tidy-up patch, addressing to types of errors: * The vcmp vector-scalar tests failing due to the compiler's preference of vector-vector comparisons, over vector-scalar comparisons. This is due to the lack of cost model for MVE and the compiler not knowing that the RTL vec_duplicate is free in those instructions. For now, we simply XFAIL these checks. * The tests for pr108177 had strict usage of q0 and r0 registers, meaning that they would FAIL with -mfloat-abi=softf. The register checks have now been relaxed. A couple of these run-tests also had incosistent use of integer MVE with floating point vectors, so I've now changed these to use FP MVE. gcc/testsuite/ChangeLog: PR target/109697 * gcc.target/arm/mve/intrinsics/vcmpcsq_n_u16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpcsq_n_u32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpcsq_n_u8.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_u16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_u32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpeqq_n_u8.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpgeq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpgeq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpgtq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpgtq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmphiq_n_u16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmphiq_n_u32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmphiq_n_u8.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpleq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpleq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpltq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpltq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpneq_n_f16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpneq_n_f32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpneq_n_u16.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpneq_n_u32.c: XFAIL check. * gcc.target/arm/mve/intrinsics/vcmpneq_n_u8.c: XFAIL check. * gcc.target/arm/mve/pr108177-1.c: Relax registers. * gcc.target/arm/mve/pr108177-10.c: Relax registers. * gcc.target/arm/mve/pr108177-11.c: Relax registers. * gcc.target/arm/mve/pr108177-12.c: Relax registers. * gcc.target/arm/mve/pr108177-13.c: Relax registers. * gcc.target/arm/mve/pr108177-13-run.c: use mve_fp * gcc.target/arm/mve/pr108177-14.c: Relax registers. * gcc.target/arm/mve/pr108177-14-run.c: use mve_fp * gcc.target/arm/mve/pr108177-2.c: Relax registers. * gcc.target/arm/mve/pr108177-3.c: Relax registers. * gcc.target/arm/mve/pr108177-4.c: Relax registers. * gcc.target/arm/mve/pr108177-5.c: Relax registers. * gcc.target/arm/mve/pr108177-6.c: Relax registers. * gcc.target/arm/mve/pr108177-7.c: Relax registers. * gcc.target/arm/mve/pr108177-8.c: Relax registers. * gcc.target/arm/mve/pr108177-9.c: Relax registers.
Stack Canary Security Issue in gcc-arm-none-eabi-9
Hello,
I encountered a security issue affecting gcc-arm-none-eabi-9, causing it to
produce ineffective stack protection. The issue is public as it was
described in a blog on May 2021
https://blog.inhq.net/posts/faulty-stack-canary-arm-systems/ by Christian
Reitter. However it was never reported as a bug in an active platform*, so
no fix was issued and no CVE was assigned to it.
As this is a major security issue I think it would be good if a CVE was
issued to alert developers and vendors still using GCC 9.
Short issue description (see Reitter's blog for comprehensive details):
Older versions of gcc-arm-none-eabi, such as
gcc-arm-none-eabi-9-2019-q4-major, have a bug where the global address of
the stack guard is placed on the stack as a canary rather than the actual
value of the stack guard. This undermines the purpose of the protection as
it makes the canary value knowable. In addition, the embedded environments
that this toolchain targets often lack Address Space Layout Randomization,
meaning the global guard address is in itself constant, making the
protection entirely ineffective.
See the following code and results built with
gcc-arm-none-eabi-9-2019-q4-major and targeting arm cortex m-33.
*Code (also attached as check_stack_protection.c):*
extern uint32_t *__stack_chk_guard;
bool check_stack_bug(uint32_t const *data, int dump_len)
{
for (int i = 0; i < dump_len; i++)
{
console_printf("%p : %p\n", &data[i], data[i]);
if (data[i] == (const uint32_t)&__stack_chk_guard)
{
console_printf(
"canary is at offset %d from dummy and equals to the
address of __stack_chk_guard\n",
i);
return true;
}
}
return false;
}
static int app_stack_guard_cmd_handler()
{
// A dummy var to get the stack frame address
uint32_t dummy = 0x57AC57AC;
bool is_buggy = check_stack_bug((uint32_t const *)&dummy, 5);
if (is_buggy)
console_printf("stack protection bug detected\n");
}
*output (also attached as output.c):*
Stack dump:
0x2013bdb8 : 0x57ac57ac
0x2013bdbc : 0x2012f83c
canary is at offset 1 from dummy and equals to the address of
__stack_chk_guard
stack protection bug detected
*binary (also attached as binary_prologue_epiloguge.txt):*
Canary setting:
8ad48: 1a 4a ldr r2, [pc, #104]
8ad4a: 83 b0 sub sp, #12
8ad4c: 12 68 ldr r2, [r2]
8ad4e: 01 92 str r2, [sp, #4]
canary check:
8ad8a: 0a 4b ldr r3, [pc, #40]
8ad8c: 1a 68 ldr r2, [r3]
8ad8e: 01 9b ldr r3, [sp, #4]
8ad90: 5a 40 eors r2, r3
Thank you,
Magal Baz
*It reported in an appeartnly inactive platform in 2020
https://answers.launchpad.net/gcc-arm-embedded/+question/689391 by Daniel
Worley.
8ad48: 1a 4a ldr r2, [pc, #104] @ 0x8adb4 <$d+0x4>
8ad4a: 83 b0 sub sp, #12
8ad4c: 12 68 ldr r2, [r2]
8ad4e: 01 92 str r2, [sp, #4]
canary check:
8ad8a: 0a 4b ldr r3, [pc, #40] @ 0x8adb4 <$d+0x4>
8ad8c: 1a 68 ldr r2, [r3]
8ad8e: 01 9b ldr r3, [sp, #4]
8ad90: 5a 40 eorsr2, r3
check_stack_protection.c
Description: Binary data
Stack dump:
0x2013bdb8 : 0x57ac57ac
0x2013bdbc : 0x2012f83c
canary is at offset 1 from dummy and equals to the address of __stack_chk_guard
stack protection bug detected
Re: Stack Canary Security Issue in gcc-arm-none-eabi-9
This mailing list is for automated email from our bugzilla database. To report a bug, please don't email the list, use bugzilla as documented at https://gcc.gnu.org/bugs/ - thanks.
Re: Stack Canary Security Issue in gcc-arm-none-eabi-9
On 18/05/23 12:01 +0100, Jonathan Wakely wrote: This mailing list is for automated email from our bugzilla database. To report a bug, please don't email the list, use bugzilla as documented at https://gcc.gnu.org/bugs/ - thanks. Note however, that GCC 9 is no longer supported by gcc.gnu.org, and the GCC project does not create CVEs. You should probably report this to vendors who are distributing gcc-arm-none-eabi-9 so they can fix it and get a CVE if needed.
[Bug target/107515] MVE: Generic functions do not accept _Float16 scalars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107515 Stam Markianos-Wright changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Stam Markianos-Wright --- Fixed on GCC12 onwards.
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #9 from Richard Biener --- Created attachment 55110 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55110&action=edit patch for the missed hoisting For the testcase in comment#6 there is a missing code hoisting from PRE which is caused by do_hoist_insertion doing /* A hoistable value must be in ANTIC_IN(block) but not in AVAIL_OUT(BLOCK). */ bitmap_initialize (&hoistable_set.values, &grand_bitmap_obstack); bitmap_and_compl (&hoistable_set.values, &ANTIC_IN (block)->values, &AVAIL_OUT (block)->values); but in reality we want to check ANTIC_OUT(block), not ANTIC_IN(block). cur.second is killed by the aggregate assignment to cur at the beginning of the block we should hoist to and that's reflected in ANTIC_IN. The attached patch properly re-computes ANTIC_OUT and uses that.
[Bug debug/109902] New: gcc/g++ emits wrong column number in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109902
Bug ID: 109902
Summary: gcc/g++ emits wrong column number in DWARF
Product: gcc
Version: 12.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: simon.farre.cx at gmail dot com
Target Milestone: ---
Created attachment 55111
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55111&action=edit
Contains GCC & clang dwarfdump output as well as simple source code.
The DWARF spec, states in paragraph 2.14 "Declaration Coordinates" (version 5,
https://dwarfstd.org/doc/DWARF5.pdf) that:
"The value of the DW_AT_decl_column attribute represents the source column
number at which the first character of the identifier of the declared object
appears. The value 0 indicates that no column has been specified."
Below is an example of contrived C++ code:
auto b = setfoo().setbar().setbaz();
gcc emits column meta data at these positions (represented by _):
auto b = setfoo_().setbar_().setbaz_();
Whereas for instance clang emits it properly, according to spec:
auto b = _setfoo()._setbar()._setbaz();
So for the following code:
" const auto res1 = b.set_foo (10).set_bar (20).set_baz (30).finalize ([]
(auto v) { return v * 2; });"
The following line number program is emitted (the line number is 66 and set_foo
begins on column position 23)
AddressLine Column File ISA Discriminator Flags
-- -- -- -- --- - -
0x00401150 66 31 1 0 0 is_stmt
0x00401161 66 44 1 0 0 is_stmt
0x0040116e 66 57 1 0 0 is_stmt
0x0040117b 66 71 1 0 0 is_stmt
0x0040126c 66 72 1 0 0 is_stmt
0x00401277 66 97 1 0 0 is_stmt
0x0040127c 66100 1 0 0 is_stmt
Where as clang emits:
0x0040114b 66 23 1 0 0 is_stmt
0x0040115e 66 36 1 0 0
0x00401171 66 49 1 0 0
0x00401179 66 62 1 0 0
0x00401430 66 0 1 0 0 is_stmt
0x0040143b 66 93 1 0 0 is_stmt prologue_end
0x0040143e 66 95 1 0 0
0x00401441 66 86 1 0 0
It's also questionable if GCC emits the correct meta data with respect to
statements, but I guess that's a different issue.
[Bug sanitizer/109882] sanitizer/common_interface_defs.h bogusly defines __has_feature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109882 --- Comment #8 from Jonathan Wakely --- Submitted upstream as https://reviews.llvm.org/D150866
[Bug c/109450] VLA struct definition vs use in the function declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109450 --- Comment #3 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618911.html
[Bug c/107557] [12/13/14 Regression] ICE -fsanitize=undefined and VLA as argument type to a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107557 --- Comment #10 from Martin Uecker --- PATCH https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618911.html
[Bug bootstrap/105831] Nonportable syntax in "test" and "[" commands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105831 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #6 from Jonathan Wakely --- Submitted as https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618914.html
[Bug c/108423] [12/13/14 Regression] ICE in make_ssa_name_fn with VLA types in arguments and inlining since r12-5338-g4e6bf0b9dd5585df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108423 --- Comment #10 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618911.html
[Bug c/106465] ICE for VLA in struct in parameter of nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106465 --- Comment #5 from Martin Uecker --- PATCH: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618911.html
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #10 from Jan Hubicka --- Thanks. I tested the patch on jpegxl and it does not help there (I guess becuase the redundancy there is partial). But it is cool we compile at least the simplified testcase well.
[Bug c++/109899] [12/13/14 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 Marek Polacek changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Keywords|needs-bisection | --- Comment #4 from Marek Polacek --- Seems to have started with r12-7069: commit 119cea98f664764cce04963243c39c8f6d797d33 Author: Jason Merrill Date: Wed Feb 2 18:36:41 2022 -0500 c++: assignment, aggregate, array [PR104300]
[Bug tree-optimization/106020] Spurious warnings about stringop overflows with -march=skylake -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020 --- Comment #13 from Matt Godbolt --- Thanks Andrew!
[Bug c++/109899] [12/13/14 Regression] ICE in check_noexcept_r, at cp/except.cc:1065
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109899 --- Comment #5 from Marek Polacek --- (gdb) up #1 0x00e5de6f in check_noexcept_r (tp=0x7fffa0a8, walk_subtrees=0x7fff9f94) at /home/mpolacek/src/gcc/gcc/cp/except.cc:1065 1065 gcc_assert (INDIRECT_TYPE_P (type)); (gdb) p type $1 = (gdb) pge void class1:: (struct class1 *)
[Bug target/109811] libjxl 0.7 is a lot slower in GCC 13.1 vs Clang 16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811 --- Comment #11 from Jan Hubicka --- I got -fprofile-use builds working and with profile we peel the innermost loop 8 times which actually gets it off the hottest spot. We get more slective on what to inline (do not inline cold calls) which may make the dependency on SRA even worse
[Bug target/109896] Missed optimisation: overflow detection in multiplication instructions for operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109896 --- Comment #7 from Thiago Macieira --- (In reply to Jonathan Wakely from comment #6) > With placement-new there's no allocation: > https://gcc.godbolt.org/z/68e4PaeYz Is the exception expected there, though?
[Bug tree-optimization/105776] Failure to recognize __builtin_mul_overflow pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105776 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 55112 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55112&action=edit gcc14-pr105776.patch Untested fix.
[Bug bootstrap/105831] Nonportable syntax in "test" and "[" commands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105831 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:95b93adcac69536bab617e045149719ec69099ae commit r14-968-g95b93adcac69536bab617e045149719ec69099ae Author: Michael Bäuerle Date: Thu May 18 10:15:49 2023 +0100 gcc: Fix nonportable shell syntax in "test" and "[" commands [PR105831] POSIX sh does not support the == for string comparisons, use = instead. gcc/ChangeLog: PR bootstrap/105831 * config/nvptx/gen-opt.sh: Use = operator instead of ==. * configure.ac: Likewise. * configure: Regenerate.
[Bug bootstrap/105831] Nonportable syntax in "test" and "[" commands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105831 --- Comment #8 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6e2fbe4f345f48ae3c8ba5bfbc1a7b783b398614 commit r14-969-g6e2fbe4f345f48ae3c8ba5bfbc1a7b783b398614 Author: Jonathan Wakely Date: Thu May 18 10:18:19 2023 +0100 gcc: Fix nonportable shell syntax in "test" and "[" commands [PR105831] POSIX sh does not support the == for string comparisons, use = instead. The gen_directive_tests script uses a bash shebang so == does work, but there's no reason this script can't just use the more portable form anyway. PR bootstrap/105831 gcc/ChangeLog: * config.gcc: Use = operator instead of ==. gcc/testsuite/ChangeLog: * gcc.test-framework/gen_directive_tests: Use = operator instead of ==.
[Bug bootstrap/105831] Nonportable syntax in "test" and "[" commands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105831 --- Comment #9 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:120e444974e12eb727eea170a3bfd80783e3851f commit r14-970-g120e444974e12eb727eea170a3bfd80783e3851f Author: Jonathan Wakely Date: Thu May 18 10:18:19 2023 +0100 contrib: Fix nonportable shell syntax in "test" and "[" commands [PR105831] POSIX sh does not support the == for string comparisons, use = instead. These contrib scripts all use a bash shebang so == does work, but there's no reason they can't just use the more portable form anyway. PR bootstrap/105831 contrib/ChangeLog: * bench-stringop: Use = operator instead of ==. * repro_fail: Likewise. contrib/reghunt/ChangeLog: * bin/reg-hunt: Use = operator instead of ==.
[Bug bootstrap/105831] Nonportable syntax in "test" and "[" commands.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105831 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #10 from Jonathan Wakely --- Fixed on trunk (and some other cases of == elsewhere). Thanks for the patch and report.
[Bug target/109903] New: Register misallocation in hand-crafted asm insn, no diagnostics produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109903
Bug ID: 109903
Summary: Register misallocation in hand-crafted asm insn, no
diagnostics produced
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitri.gorokhovik at free dot fr
Target Milestone: ---
For the source code:
#if NO_BUG
unsigned long f (unsigned long a)
{
unsigned long v;
asm ("mrs %[_1], pmccntr_eli0\n"
"\tldr x1, [%[_2]]\n"
: [_1] "=r" (v)
: [_2] "r" (a)
);
return v;
}
#else // BUG
extern void g(unsigned long);
void f (unsigned long a)
{
unsigned long v;
asm ("mrs %[_1], pmccntr_eli0\n"
"\tldr x1, [%[_2]]\n"
: [_1] "=r" (v)
: [_2] "r" (a)
);
g(v);
}
#endif
The asm output produced is:
## BUG
#APP
# 23 "bug.c" 1
mrs %rdi, pmccntr_eli0
ldr x1, [%rdi]
# 0 "" 2
#NO_APP
## NO_BUG
#APP
# 6 "bug.c" 1
mrs %rax, pmccntr_eli0
ldr x1, [%rdi]
# 0 "" 2
#NO_APP
As one can see, in the "NO BUG" case, the registers allocated to reading "the
counter" and to reading "memory", are different, whereas they are one and the
same in the "BUG" case.
This was obtained with today's trunk built for native compilation: gcc (GCC)
14.0.0 20230518 (experimental).
The example was compiled as:
gcc -S -O3 -Wall -Wextra -o bug.S bug.c
no diagnostic messages are produced.
Same was also observed with gcc-aarch64-none-linux toolchain 13.2 (from Arm
download page), so "target-related issue" might not be an entirely correct
classification for this.
[Bug target/109903] Register misallocation in hand-crafted asm insn, no diagnostics produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109903 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- You need to use an early clobber on the output constraint as documented. https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/Modifiers.html#index-earlyclobber-operand
[Bug target/109903] Register misallocation in hand-crafted asm insn, no diagnostics produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109903
--- Comment #2 from Andrew Pinski ---
That is the inline-asm should be written as:
asm ("mrs %[_1], pmccntr_eli0\n"
"\tldr x1, [%[_2]]\n"
: [_1] "=&r" (v)
: [_2] "r" (a)
: "memory");
Note since a is memory address you are writing to you should also add the
memory clobber to the inline-asm.
[Bug target/109903] Register misallocation in hand-crafted asm insn, no diagnostics produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109903 --- Comment #3 from Andrew Pinski --- One more thing, GCC does not look at the inline-asm template except while outputting the assembly.
[Bug libstdc++/109891] Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891 --- Comment #6 from Michel Morin --- True. Detectable is not correct — that's "maybe-detectable" at most, and the bug is not silent. In a code that I checked, the buggy code (`std::cout << NullCharPtr;`) is the last printing call to std::cout, so I failed to see the side-effect. The patchlet using `_GLIBCXX_DEBUG_PEDASSERT` works fine. Actually I would like `_GLIBCXX_DEBUG_ASSERT` (because I've been using `_GLIBCXX_DEBUG` but never `_GLIBCXX_DEBUG_PEDANTIC`), but I guess using `_GLIBCXX_DEBUG_PEDASSERT` rather than `_GLIBCXX_DEBUG_ASSERT` in this case is a delibarate choice.
[Bug target/109903] Register misallocation in hand-crafted asm insn, no diagnostics produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109903 --- Comment #4 from Dimitri Gorokhovik --- Hi Andrew, I'd agree more with "WONTFIX" here ;-) We are not looking for solution. We want to spare the same hassle to others. This asm doesn't write to memory, it doesn't even read any -- 'a' is passed over in the registers with aarch64 and x64_86. It is also very hard to see the need for early clobber here ... how comes the version with return value doesn't need it while the other does? The asm performs regular register loads. Certainly we are not marking all register loads with early clobbers are we? WE ended up moving 'a' to output clause, it feels barely more contorted than the early-clobber method. > GCC does not look at the inline-asm template except while outputting the > assembly. Yep, reason why I let it emit ARMv8 insns for the x64_86 target ;-)
[Bug libstdc++/109891] Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891 --- Comment #7 from Jonathan Wakely --- Oops, if I'd typed PEDASSERT not PEDANTIC, it would be a deliberate choice ;-) Yes, I think PEDASSERT fits better, based on the documented meaning of it (which even mentions the std::string((const char*)nullptr) case): https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_semantics.html
[Bug c++/98821] modules : c++tools configures with CC but code fragments assume CXX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98821 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:ae5112f230f05e8a693931a44bf2fd20bef58f85 commit r11-10792-gae5112f230f05e8a693931a44bf2fd20bef58f85 Author: Iain Sandoe Date: Tue Jul 20 14:00:38 2021 +0100 c++tools, configury: Configure with C++; test checking status [PR98821]. The c++tools configure fragments need to be built with a C++ compiler. In addition, the stand-alone server uses diagnostic mechanisms in common with GCC, but needs to define implementations for gcc_assert and supporting output functions. Signed-off-by: Iain Sandoe PR c++/98821 - modules : c++tools configures with CC but code fragments assume CXX. PR c++/98821 c++tools/ChangeLog: * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Configure using C++. Pull logic to detect enabled checking modes; default to release checking. * server.cc (AI_NUMERICSERV): Define a fallback value. (gcc_assert): New. (gcc_unreachable): New. (fancy_abort): Only build when checking is enabled. Co-authored-by: Jakub Jelinek (cherry picked from commit e4d306cf706eef83f99d510c308eda1539d05875)
[Bug c++/98821] modules : c++tools configures with CC but code fragments assume CXX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98821 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Sandoe --- fixed on relevant branches.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 98821, which changed state. Bug 98821 Summary: modules : c++tools configures with CC but code fragments assume CXX. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98821 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/106900] Regression after memchr optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106900 --- Comment #9 from Jan-Benedict Glaw --- All three target configurations reported a successful build. Thanks!
[Bug target/109903] Register misallocation in hand-crafted asm insn, no diagnostics produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109903 --- Comment #5 from Andrew Pinski --- (In reply to Dimitri Gorokhovik from comment #4) > Hi Andrew, > > I'd agree more with "WONTFIX" here ;-) We are not looking for solution. We > want to spare the same hassle to others. Why you didn't read the documentation which is documents inline-asm. And there is no way for GCC to know what you mean. > > This asm doesn't write to memory, it doesn't even read any -- 'a' is passed > over in the registers with aarch64 and x64_86. Oh I read the instruction wrong. > > It is also very hard to see the need for early clobber here ... how comes > the version with return value doesn't need it while the other does? The asm > performs regular register loads. Certainly we are not marking all register > loads with early clobbers are we? The easy and fast rule is simple. If you write to an output operand before read from an input operand, that output operand needs an early clobber. This is how I knew what the issue was right away without even looking further into what was going wrong. Even the documentation is clear here: "Means (in a particular alternative) that this operand is an earlyclobber operand, which is written before the instruction is finished using the input operands." The reason why sometimes it works sometimes it does not work is depedent on the register allocator. In the case of return and first argument registers, well usually those are the same register so the register allocator wants to minimalize the number of spills and/or register moves. > > WE ended up moving 'a' to output clause, it feels barely more contorted than > the early-clobber method. That is actually WRONG and will produce wrong code in some cases. The early clobber is the right appoarch here if you are writing to an operand before you use all of the input operands (again this is all DOCUMENTED and has been for the over 10 years now). > > > GCC does not look at the inline-asm template except while outputting the > > assembly. > Yep, reason why I let it emit ARMv8 insns for the x64_86 target ;-)
[Bug libstdc++/109891] Null pointer special handling in ostream's operator << for C-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #8 from Xi Ruoyao --- (In reply to Jonathan Wakely from comment #7) > Oops, if I'd typed PEDASSERT not PEDANTIC, it would be a deliberate choice > ;-) > > Yes, I think PEDASSERT fits better, based on the documented meaning of it > (which even mentions the std::string((const char*)nullptr) case): > https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode_semantics.html Ccan we add a "pednonnull" attribute or something to produce a -Wnonnull warning like the nonnull attribute but w/o affecting code generation as well? I remember we've discussed "adding nonnull attribute for basic_ostream::operator<<" and the idea was rejected because the nonnull attribute would throw away the null pointer check.
[Bug target/106902] [11/12/13/14 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 --- Comment #26 from Alexander Monakov --- > > Did you run into any of NON_LVALUE / C_MAYBE_CONST wrappings of the > > multiplication btw? > > No, I'm not familiar with those, so I didn't try to construct corresponding > testcases. I had a look now. My understanding is they are eliminated in c_fully_fold, so c_gimplify_expr will not encounter those trees.
[Bug target/109903] Register misallocation in hand-crafted asm insn, no diagnostics produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109903 --- Comment #6 from Dimitri Gorokhovik --- Thank you Andrew, I indeed see now the early-clobber effect of this code. It isn't that we don't read documentation (we do time to time), rather our real asm statement has more output ops and more elementary instructions in the template, so the early-clobber effect doesn't jump to the eye quite as easily. I guess we have to mask all output ops as early clobbers.
[Bug c++/105826] failure to compile namespace-scope constexpr new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105826 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-05-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/106143] Add fix-it for missing ::value on trait with std::integral_constant base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106143 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug target/106902] [11/12/13/14 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 --- Comment #27 from rguenther at suse dot de --- > Am 18.05.2023 um 10:31 schrieb amonakov at gcc dot gnu.org > : > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902 > > --- Comment #25 from Alexander Monakov --- > (In reply to Richard Biener from comment #24) >> As of the patch it looks good, I wonder if we want to check for OPTIMIZE_BOTH >> though since at least when no extra negations are required the contraction >> should also be a win when optimizing for size? > > Makes sense, I'll change that (current target hooks always return true for > fma). > >> Also I wondered about the PROP_gimple_any check - do we get into the >> gimplification langhook after lowering? I see we are not resetting the >> langhook after lowering (only in free-lang-data, but that only runs with >> LTO). > > Yes, that surprised me. I caught it when analyzing ICE on slp-50.c testcase. > >> We probably at least should gate the langhook invocation in the gimplifier >> with what you added in the patch or specify whether the gimplifier is >> invoked from the middle-end via the gimplifier context. > > Perhaps. I'll add a comment that we want to handle -ffp-contract=on strictly > during initial gimplification, to hash this out further on gcc-patches, if > necessary. > >> If we go for c-family only the genericize entry could be another place to >> handle this. > > That seems less convenient to me. Is IFN_FMA representable as a tree? Yes, that’s possible. Let’s see if others have an opinion on the ml. >> Did you run into any of NON_LVALUE / C_MAYBE_CONST wrappings of the >> multiplication btw? > > No, I'm not familiar with those, so I didn't try to construct corresponding > testcases. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641 --- Comment #17 from CVS Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:611be07e48956c8b7371eb580eef124990114fd3 commit r13-7353-g611be07e48956c8b7371eb580eef124990114fd3 Author: Harald Anlauf Date: Fri May 5 21:22:12 2023 +0200 Fortran: overloading of intrinsic binary operators [PR109641] Fortran allows overloading of intrinsic operators also for operands of numeric intrinsic types. The intrinsic operator versions are used according to the rules of F2018 table 10.2 and imply type conversion as long as the operand ranks are conformable. Otherwise no type conversion shall be performed to allow the resolution of a matching user-defined operator. gcc/fortran/ChangeLog: PR fortran/109641 * arith.cc (eval_intrinsic): Check conformability of ranks of operands for intrinsic binary operators before performing type conversions. * gfortran.h (gfc_op_rank_conformable): Add prototype. * resolve.cc (resolve_operator): Check conformability of ranks of operands for intrinsic binary operators before performing type conversions. (gfc_op_rank_conformable): New helper function to compare ranks of operands of binary operator. gcc/testsuite/ChangeLog: PR fortran/109641 * gfortran.dg/overload_5.f90: New test. (cherry picked from commit 185da7c2014ba41f38dd62cc719873ebf020b076)
[Bug fortran/109846] Pointer-valued function reference rejected as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 --- Comment #7 from CVS Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f48c546902802cf640c4f2802543acfdc702404f commit r13-7354-gf48c546902802cf640c4f2802543acfdc702404f Author: Harald Anlauf Date: Sun May 14 21:53:51 2023 +0200 Fortran: CLASS pointer function result in variable definition context [PR109846] gcc/fortran/ChangeLog: PR fortran/109846 * expr.cc (gfc_check_vardef_context): Check appropriate pointer attribute for CLASS vs. non-CLASS function result in variable definition context. gcc/testsuite/ChangeLog: PR fortran/109846 * gfortran.dg/ptr-func-5.f90: New test. (cherry picked from commit fa0569e90efe8a5cb895a3f50dd502f849940828)
[Bug fortran/109641] Gfortran fails to overload intrinsic operator (*) if operands are complex. It works with real ones.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109641 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |13.2 Resolution|--- |FIXED --- Comment #18 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14, and backported to 13-branch. Closing. Thanks for the report!
[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=89144 CC||ppalka at gcc dot gnu.org --- Comment #5 from Patrick Palka --- Seems related to PR89144 too -- there we were mishandling defining a non-dependent static std::initializer_list member variable, here we're subsequently trying to use it.
[Bug tree-optimization/106185] Spurious Wstringop-overflow in std::vector::resize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106185 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #1 from Andrew Pinski --- This looks to be fixed in GCC 13. I think there was a missed optimization which is being caught now. It would be interesting to know which patch fixed the warning (and missed optimization).
[Bug tree-optimization/106380] DCE depends on datatype used (bool vs unsigned)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106380 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-05-18 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Mine. In this case if we fold: _1 = ~s_4(D); _2 = _1 & c_5(D); to s < c Then the rest will be optimized by normally.
[Bug tree-optimization/106380] DCE depends on datatype used (bool vs unsigned)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106380 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org
[Bug tree-optimization/106381] DCE depends on used programming language (C vs C++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106381 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-05-18 Ever confirmed|0 |1 Severity|normal |enhancement Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Actually it is worse in GCC 13. Both the C and C++ front-ends produced IR does not get optimized.
[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #6 from Jason Merrill --- (In reply to Patrick Palka from comment #5) > Seems related to PR89144 too -- there we were mishandling defining a > non-dependent static std::initializer_list member variable, here we're > subsequently trying to use it. The issue there is that the initializer_list wasn't static, but here it is, so the array temporary should be as well. And presumably the problem is that we aren't representing that lifetime extension in a template. And checking the initializer gives up on trying to enforce that. But then when we try to evaluate the template argument we find that we don't have a constant value to work with, and complain. Instead, we should probably treat num as value-dependent even though it actually isn't. Or fix it to be properly evaluated by representing the lifetime extension somehow.
[Bug tree-optimization/106379] DCE depends on order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106379 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Depends on||106380 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Severity|normal |enhancement --- Comment #5 from Andrew Pinski --- _1 = ~c_5(D); _2 = _1 & s_4(D); Mine. That is `c < s`. So the same as PR 106380 . Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106380 [Bug 106380] DCE depends on datatype used (bool vs unsigned)
[Bug fortran/109904] New: linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 Bug ID: 109904 Summary: linking with -static flag generates undefined references Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Gary.White at ColoState dot edu Target Milestone: --- What follows are a portion of the undefined references when using -static with gfortran-13. I require the -static flag to be able to distribute executable to users not having gfortran on their machines. gfortran -m64 -fopenmp mark.o glabrd.o xmatrx.o tmread.o rlabrd.o blabrd.o dlabrd.o estmat.o varmat.o derivedest.o piread.o func.o saturd.o chprob.o chprob001.o chprob002.o chprob008.o chprob009.o chprob032.o chprob115.o chprob119.o chprob121.o chprob126.o chprob139.o chprob140.o chprob141.o chprob142.o chprob143.o chprob144.o chprob160.o chprob170.o chprob171.o chprob172.o chprob173.o chprob174.o chprob175.o chprob176.o chprob177.o chprob178.o chprob179.o chprob180.o chprob181.o chprob182.o chprob183.o chprob184.o rcread.o kfread.o nsread.o optmiz.o status_module.o prcisub.o prfunc.o mcmc.o hyperread.o gibbsitsub.o optimizers_module.o gaussquad.o hyper_dist_module.o profile_conf_interval_module.o data_module.o design_matrix_funcs_module.o random_values_module.o Linpack.a -o mark64.exe -static -static-libgfortran C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libgomp.a(target.o):(.text+0x94f): undefined reference to `dlopen' C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libgomp.a(target.o):(.text+0x96a): undefined reference to `dlsym' C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libgomp.a(target.o):(.text+0x99f): undefined reference to `dlclose' C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/tdm-gcc-64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libgomp.a(oacc-profiling.o):(.text+0x83d): undefined reference to `dlerror' Specifics of the installation of gfortran are: gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=C:/tdm-gcc-64/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/13.1.0/lto-wrapper.exe OFFLOAD_TARGET_NAMES=nvptx-none Target: x86_64-w64-mingw32 Configured with: ../configure --prefix=/R/winlibs64ucrt_stage/inst_gcc-13.1.0/share/gcc --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --enable-offload-targets=nvptx-none --with-pkgversion='MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders' --with-tune=generic --enable-checking=release --enable-threads=posix --disable-sjlj-exceptions --disable-libunwind-exceptions --disable-serial-configure --disable-bootstrap --enable-host-shared --enable-plugin --disable-default-ssp --disable-rpath --disable-libstdcxx-debug --disable-version-specific-runtime-libs --with-stabs --disable-symvers --enable-languages=c,c++,fortran,lto,objc,obj-c++ --disable-gold --disable-nls --disable-stage1-checking --disable-win32-registry --disable-multilib --enable-ld --enable-libquadmath --enable-libada --enable-libssp --enable-libstdcxx --enable-lto --enable-fully-dynamic-string --enable-libgomp --enable-graphite --enable-mingw-wildcard --enable-libstdcxx-time --enable-libstdcxx-pch --with-mpc=/d/Prog/winlibs64ucrt_stage/custombuilt --with-mpfr=/d/Prog/winlibs64ucrt_stage/custombuilt --with-gmp=/d/Prog/winlibs64ucrt_stage/custombuilt --with-isl=/d/Prog/winlibs64ucrt_stage/custombuilt --enable-libstdcxx-backtrace --enable-install-libiberty --enable-__cxa_atexit --without-included-gettext --with-diagnostics-color=auto --enable-clocale=generic --with-libiconv --with-system-zlib --with-build-sysroot=/R/winlibs64ucrt_stage/gcc-13.1.0/build_mingw/mingw-w64 CFLAGS='-I/d/Prog/winlibs64ucrt_stage/custombuilt/include/libdl-win32 -Wno-int-conversion' CXXFLAGS=-Wno-int-conversion LDFLAGS='-pthread -Wl,--dynamicbase -Wl,--high-entropy-va -Wl,--nxcompat -Wl,--tsaware' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.1.0 (MinGW-W64 x86_64-msvcrt-posix-seh, built by Brecht Sanders)
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #1 from Andrew Pinski --- >--enable-offload-targets=nvptx-none I suspect this might be the issue. offloading only works with targets that have dlopen . Maybe you need to link with -ldl to get it working.
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- In fact I noticed this on the configure comand line: -I/d/Prog/winlibs64ucrt_stage/custombuilt/include/libdl-win32 Please report this issue to where you got the binary builds of GCC from and ask them about providing libdl-win32 to you too.
[Bug c++/101853] [12/13/14 Regression] g++.dg/modules/xtreme-header-5_b.C ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101853 --- Comment #18 from Hans-Peter Nilsson --- (In reply to Jiu Fu Guo from comment #17) > > But "nobody" counts that close, so better say "no xtreme-header-* failures > > since r13-5702-g72058eea9d407e". > > :) Since these failures occur erratically, They did at the time for cris-elf (too), but I believe the cause of *those* failures has been fixed. > so maybe reopen this or open a > new one if the failures are reproduced. That's the idea. :) > As two xtreme-header-5_ failures (not ICE) occur in Results for 14.0.0 > 20230518: https://gcc.gnu.org/pipermail/gcc-testresults/2023-May/784674.html. Good to know, but not for cris-elf.
[Bug c++/109227] coroutines: ICE in tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.cc:11067
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109227 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I guess if var_type is ARRAY_TYPE, then it shouldn't call build_special_member_call with complete_dtor_identifier, but should do something like build_vec_delete_1 does around it. Though, seems coroutines.cc calls build_special_member_call with complete_dtor_identifier in 12 different spots, which of those could be ARRAY_TYPEs is unclear to me.
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #3 from GARY.WHITE at ColoState dot edu --- Linking with -ldl fixed the issue Where is there documentation of -ldl? Gary C. White, CWB(r) Professor Emeritus Department of Fish, Wildlife, and Conservation Biology 10 Wagar Colorado State University Fort Collins, CO 80523 (515)450-2768 Mobile gary.wh...@colostate.edu https://sites.warnercnr.colostate.edu/gwhite/ he/him/his See where we are! "Leadership is a privilege to better the lives of others. It is not an opportunity to satisfy personal greed." Mwai Kibaki -Original Message- From: pinskia at gcc dot gnu.org Sent: Thursday, May 18, 2023 12:11 PM To: White,Gary Subject: [Bug libgomp/109904] linking with -static flag generates undefined references ** Caution: EXTERNAL Sender ** https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #1 from Andrew Pinski --- >--enable-offload-targets=nvptx-none I suspect this might be the issue. offloading only works with targets that have dlopen . Maybe you need to link with -ldl to get it working. -- You are receiving this mail because: You reported the bug.
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #4 from Andrew Pinski --- (In reply to gary.wh...@colostate.edu from comment #3) > Linking with -ldl fixed the issue Where is there documentation of -ldl? -l says to link against a specified library in this case libdl; libgomp needs to open a library at runtime due to offloading support and dl* functions do that and for windows dl* functions are implemented in libdl-win32. But as I mentioned you should be asking where you got the binary toolchain instead of here.
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #5 from GARY.WHITE at ColoState dot edu --- I'm getting gfortran downloads from here: https://github.com/brechtsanders/winlibs_mingw/releases Gary C. White, CWB(r) Professor Emeritus Department of Fish, Wildlife, and Conservation Biology 10 Wagar Colorado State University Fort Collins, CO 80523 (515)450-2768 Mobile gary.wh...@colostate.edu https://sites.warnercnr.colostate.edu/gwhite/ he/him/his See where we are! "Leadership is a privilege to better the lives of others. It is not an opportunity to satisfy personal greed." Mwai Kibaki -Original Message- From: pinskia at gcc dot gnu.org Sent: Thursday, May 18, 2023 12:33 PM To: White,Gary Subject: [Bug libgomp/109904] linking with -static flag generates undefined references ** Caution: EXTERNAL Sender ** https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #4 from Andrew Pinski --- (In reply to gary.wh...@colostate.edu from comment #3) > Linking with -ldl fixed the issue Where is there documentation of -ldl? -l says to link against a specified library in this case libdl; libgomp needs to open a library at runtime due to offloading support and dl* functions do that and for windows dl* functions are implemented in libdl-win32. But as I mentioned you should be asking where you got the binary toolchain instead of here. -- You are receiving this mail because: You reported the bug.
[Bug middle-end/101807] bool0 < bool1 Should expand as !bool0 &bool1 and bool0 <= bool1 as !bool0 | bool1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101807
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Last reconfirmed||2023-05-18
Status|UNCONFIRMED |ASSIGNED
--- Comment #1 from Andrew Pinski ---
I have a patch.
It even handles:
unsigned f(unsigned a, unsigned b)
{
if (a > 1) __builtin_unreachable();
if (b > 1) __builtin_unreachable();
return a
[Bug debug/109902] gcc/g++ emits wrong column number in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109902
--- Comment #1 from Simon Farre ---
This is slightly off-topic, but still relevant to this discussion. In the
attachment,
we can see this line
" const auto res3 = b.set_foo (next_v ()).set_bar (next_v ()).set_baz (next_v
()).finalize ([] (auto v) { return v * 3; });"
-- GCC --
AddressLine Column File ISA Discriminator Flags
-- -- -- -- --- - -
0x004011ee 68 31 1 0 0 is_stmt
0x00401206 68 51 1 0 0 is_stmt
0x00401218 68 71 1 0 0 is_stmt
0x00401227 68 92 1 0 0 is_stmt
0x004012ee 68 93 1 0 0 is_stmt
0x004012f9 68118 1 0 0 is_stmt
0x00401302 68121 1 0 0 is_stmt
where as clang outputs:
AddressLine Column File ISA Discriminator Flags
-- -- -- -- --- - -
0x004011fd 68 32 1 0 0 is_stmt
0x0040120b 68 23 1 0 0
0x00401217 68 52 1 0 0
0x00401225 68 43 1 0 0
0x00401231 68 72 1 0 0
0x0040123f 68 63 1 0 0
0x00401247 68 83 1 0 0
0x00401450 68 0 1 0 0 is_stmt
0x0040145b 68116 1 0 0 is_stmt prologue_end
0x0040145f 68107 1 0 0
0x00401461 68107 1 0 0 end_sequence
As we can see, clang outputs information to the actual column meta data for
calls at parameter sites whereas GCC does not. Providing these positions in
source code opens up for "ergonomics-features", particularly in GDB as GDB can
more easily determine sites of interest to step to, set breakpoints at, etc.
[Bug other/109898] 'make install -j' sometimes corrupts 'dir' file for .info files due to parallel 'install-info' calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109898 --- Comment #3 from Sergei Trofimovich --- (In reply to Jonathan Wakely from comment #2) > (In reply to Sergei Trofimovich from comment #0) > > --- gcc-12.2.0/gcc/Makefile.in 2022-08-19 10:09:52.280658631 +0200 > > +++ gcc-12.2.0-new/gcc/Makefile.in 2023-05-04 14:35:44.401420184 +0200 > > @@ -3781,6 +3781,11 @@ > > fi; \ > > fi > > > > +# We don't care about the order in which the info files are built, but > > +# install-info doesn't support multiple parallel invocations writing to > > +# the same `dir-file`, so we have to disable parallelism for that reason: > > +.NOTPARALLEL: install-info > > Prerequisites of .NOTPARALLEL are ignored, so doesn't this un-parallelize > building the entire gcc sub-dir? When I tested on small example '.NOTPARALLEL: target' serialized exactly prerequisites of 'target' and nothing more. 'info make' seems to confirm the behaviour: """ '.NOTPARALLEL' If '.NOTPARALLEL' is mentioned as a target with no prerequisites, all targets in this invocation of 'make' will be run serially, even if the '-j' option is given. Any recursively invoked 'make' command will still run recipes in parallel (unless its makefile also contains this target). If '.NOTPARALLEL' has targets as prerequisites, then all the prerequisites of those targets will be run serially. This implicitly adds a '.WAIT' between each prerequisite of the listed targets. *Note Disabling Parallel Execution: Parallel Disable. """ Here is the test that confirms it: $ cat Makefile all: a b a: 1 2 echo a 1: sleep 1 2: sleep 1 b: 3 4 echo b 3: sleep 1 4: sleep 1 .NOTPARALLEL: a $ make -j | LANG=C ts May 18 20:34:23 sleep 1 May 18 20:34:23 sleep 1 May 18 20:34:23 sleep 1 May 18 20:34:24 sleep 1 May 18 20:34:24 echo b May 18 20:34:24 b May 18 20:34:25 echo a May 18 20:34:25 a Note how it takes 'b' 1 second to finish (due to parallelism) while 'a' takes 2 seconds (targets are sequential).
[Bug fortran/78798] [cleanup] some int-valued functions should be bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78798 --- Comment #12 from CVS Commits --- The master branch has been updated by Bernhard Reutner-Fischer : https://gcc.gnu.org/g:c072df1ab144506cd8bb0ac81fb8f1aad69f0bd2 commit r14-973-gc072df1ab144506cd8bb0ac81fb8f1aad69f0bd2 Author: Bernhard Reutner-Fischer Date: Sat Nov 6 06:48:00 2021 +0100 Fortran: Narrow return types [PR78798] gcc/fortran/ChangeLog: PR fortran/78798 * array.cc (compare_bounds): Use narrower return type. (gfc_compare_array_spec): Likewise. (is_constant_element): Likewise. (gfc_constant_ac): Likewise. * check.cc (dim_rank_check): Likewise. * cpp.cc (gfc_cpp_init_options): Likewise. (dump_macro): Likewise. * cpp.h (gfc_cpp_handle_option): Likewise. * dependency.cc (gfc_ref_needs_temporary_p): Likewise. (gfc_check_argument_dependency): Likewise. (gfc_check_fncall_dependency): Likewise. (ref_same_as_full_array): Likewise. * dependency.h (gfc_check_fncall_dependency): Likewise. (gfc_dep_resolver): Likewise. (gfc_are_equivalenced_arrays): Likewise. * expr.cc (gfc_copy_ref): Likewise. (gfc_kind_max): Likewise. (numeric_type): Likewise. * gfortran.h (gfc_at_end): Likewise. (gfc_at_eof): Likewise. (gfc_at_bol): Likewise. (gfc_at_eol): Likewise. (gfc_define_undef_line): Likewise. (gfc_wide_is_printable): Likewise. (gfc_wide_is_digit): Likewise. (gfc_wide_fits_in_byte): Likewise. (gfc_find_sym_tree): Likewise. (gfc_generic_intrinsic): Likewise. (gfc_specific_intrinsic): Likewise. (gfc_intrinsic_actual_ok): Likewise. (gfc_has_vector_index): Likewise. (gfc_numeric_ts): Likewise. (gfc_impure_variable): Likewise. (gfc_pure): Likewise. (gfc_implicit_pure): Likewise. (gfc_elemental): Likewise. (gfc_pure_function): Likewise. (gfc_implicit_pure_function): Likewise. (gfc_compare_array_spec): Likewise. (gfc_constant_ac): Likewise. (gfc_expanded_ac): Likewise. (gfc_check_digit): Likewise. * intrinsic.cc (gfc_find_subroutine): Likewise. (gfc_generic_intrinsic): Likewise. (gfc_specific_intrinsic): Likewise. * io.cc (compare_to_allowed_values): Likewise. And remove unneeded forward declaration. * parse.cc: Likewise. * parse.h (gfc_check_do_variable): Likewise. * primary.cc (gfc_check_digit): Likewise. * resolve.cc (resolve_structure_cons): Likewise. (pure_stmt_function): Likewise. (gfc_pure_function): Likewise. (impure_stmt_fcn): Likewise. (resolve_forall_iterators): Likewise. (resolve_data): Likewise. (gfc_impure_variable): Likewise. (gfc_pure): Likewise. (gfc_unset_implicit_pure): Likewise. * scanner.cc (wide_is_ascii): Likewise. (gfc_wide_toupper): Likewise. (gfc_open_included_file): Likewise. (gfc_at_end): Likewise. (gfc_at_eof): Likewise. (gfc_at_bol): Likewise. (skip_comment_line): Likewise. (gfc_gobble_whitespace): Likewise. * symbol.cc (gfc_find_symtree_in_proc): Likewise. * trans-array.cc: Likewise. * trans-decl.cc (gfc_set_decl_assembler_name): Likewise. * trans-types.cc (gfc_get_element_type): Likewise. (gfc_add_field_to_struct): Likewise. * trans-types.h (gfc_copy_dt_decls_ifequal): Likewise. (gfc_return_by_reference): Likewise. (gfc_is_nodesc_array): Likewise. * trans.h (gfc_can_put_var_on_stack): Likewise.
[Bug middle-end/101807] bool0 < bool1 Should expand as !bool0 &bool1 and bool0 <= bool1 as !bool0 | bool1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101807
--- Comment #2 from Andrew Pinski ---
Actually I need to check the cost, e.g. on MIPS, there is an one instruction
which does the less than without doing anything.
That is for:
bool f0(bool a, bool b)
{
return a
[Bug middle-end/101807] bool0 < bool1 Should expand as !bool0 &bool1 and bool0 <= bool1 as !bool0 | bool1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101807 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Actually I need to check the cost, e.g. on MIPS, there is an one instruction > which does the less than without doing anything. RISCV too ...
[Bug middle-end/101807] bool0 < bool1 Should expand as !bool0 &bool1 and bool0 <= bool1 as !bool0 | bool1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101807
--- Comment #4 from Andrew Pinski ---
Here is what I have so far without the cost model:
/* Hand bool0 CMP bool1 because bitwise operators
are normally better than comparisons. */
if (INTEGRAL_TYPE_P (type)
&& ((tree_nonzero_bits (arg0) == 1 && tree_nonzero_bits (arg1) == 1)
|| (unsignedp && TYPE_PRECISION (type) == 1)))
{
tree b0 = arg0;
tree b1 = arg1;
bool not_p = false;
bool operand1_not_p = false;
tree_code code = ERROR_MARK;
switch (ops->code)
{
case EQ_EXPR:
not_p = true;
code = BIT_XOR_EXPR;
break;
case NE_EXPR:
code = BIT_XOR_EXPR;
break;
case GT_EXPR:
std::swap (b0, b1);
code = BIT_AND_EXPR;
operand1_not_p = true;
break;
case LT_EXPR:
code = BIT_AND_EXPR;
operand1_not_p = true;
break;
case GE_EXPR:
std::swap (b0, b1);
code = BIT_IOR_EXPR;
operand1_not_p = true;
break;
case LE_EXPR:
code = BIT_IOR_EXPR;
operand1_not_p = true;
break;
default:
code = ERROR_MARK;
break;
}
if (code != ERROR_MARK)
{
tree exp;
tree one = build_int_cst (type, 1);
if (operand1_not_p)
b0 = build2_loc (loc, BIT_XOR_EXPR, type, b0, one);
exp = build2_loc (loc, code, type, b0, b1);
if (not_p)
exp = build2_loc (loc, BIT_XOR_EXPR, type, exp, one);
return expand_expr (exp, target, VOIDmode, EXPAND_NORMAL);
}
}
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #6 from GARY.WHITE at ColoState dot edu --- So using -ldl seems really quirky. Doesn't seem to work for generating 32-bit executables. Plus, not working at all on my second machine. Is there a better solution? Gary C. White, CWB(r) Professor Emeritus Department of Fish, Wildlife, and Conservation Biology 10 Wagar Colorado State University Fort Collins, CO 80523 (515)450-2768 Mobile gary.wh...@colostate.edu https://sites.warnercnr.colostate.edu/gwhite/ he/him/his See where we are! "Leadership is a privilege to better the lives of others. It is not an opportunity to satisfy personal greed." Mwai Kibaki -Original Message- From: pinskia at gcc dot gnu.org Sent: Thursday, May 18, 2023 12:33 PM To: White,Gary Subject: [Bug libgomp/109904] linking with -static flag generates undefined references ** Caution: EXTERNAL Sender ** https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #4 from Andrew Pinski --- (In reply to gary.wh...@colostate.edu from comment #3) > Linking with -ldl fixed the issue Where is there documentation of -ldl? -l says to link against a specified library in this case libdl; libgomp needs to open a library at runtime due to offloading support and dl* functions do that and for windows dl* functions are implemented in libdl-win32. But as I mentioned you should be asking where you got the binary toolchain instead of here. -- You are receiving this mail because: You reported the bug.
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #7 from Andrew Pinski --- (In reply to gary.wh...@colostate.edu from comment #6) > So using -ldl seems really quirky. Doesn't seem to work for generating > 32-bit executables. Plus, not working at all on my second machine. Is > there a better solution? Yes use a differently built gcc where libgomp does NOT depend on dl* functions. Again this is not the right place to report these issues, the correct place is where you got the binary GCC from. In your case that would be https://github.com/brechtsanders/winlibs_mingw/issues .
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #8 from GARY.WHITE at ColoState dot edu --- So send me the link where I should get the binaries from. Gary C. White, CWB(r) Professor Emeritus Department of Fish, Wildlife, and Conservation Biology 10 Wagar Colorado State University Fort Collins, CO 80523 (515)450-2768 Mobile gary.wh...@colostate.edu https://sites.warnercnr.colostate.edu/gwhite/ he/him/his See where we are! "Leadership is a privilege to better the lives of others. It is not an opportunity to satisfy personal greed." Mwai Kibaki -Original Message- From: pinskia at gcc dot gnu.org Sent: Thursday, May 18, 2023 2:59 PM To: White,Gary Subject: [Bug libgomp/109904] linking with -static flag generates undefined references ** Caution: EXTERNAL Sender ** https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #7 from Andrew Pinski --- (In reply to gary.wh...@colostate.edu from comment #6) > So using -ldl seems really quirky. Doesn't seem to work for > generating 32-bit executables. Plus, not working at all on my second > machine. Is there a better solution? Yes use a differently built gcc where libgomp does NOT depend on dl* functions. Again this is not the right place to report these issues, the correct place is where you got the binary GCC from. In your case that would be https://github.com/brechtsanders/winlibs_mingw/issues . -- You are receiving this mail because: You reported the bug.
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #9 from Andrew Pinski --- See https://gcc.gnu.org/install/binaries.html Specifically: "Please note that we did not create these binaries, nor do we support them. If you have any problems installing them, please contact their makers."
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904
--- Comment #10 from Jakub Jelinek ---
Offloading doesn't work for 32-bit architectures, the offloading target needs
to have the same wordsize as the host and e.g. nvptx 32-bit support has been
deprecated and removed some years ago.
So, don't configure offloading for 32-bit architectures.
As for adding -ldl automatically for -static linking, I think we should do:
2023-05-18 Jakub Jelinek
PR libgomp/109904
* configure.ac (link_gomp): Include also $DL_LIBS.
* configure: Regenerated.
--- libgomp/configure.ac.jj 2023-05-15 19:12:35.138624638 +0200
+++ libgomp/configure.ac2023-05-18 20:41:58.512501769 +0200
@@ -398,9 +398,9 @@ fi
# which will force linkage against -lpthread (or equivalent for the system).
# That's not 100% ideal, but about the best we can do easily.
if test $enable_shared = yes; then
- link_gomp="-lgomp %{static: $LIBS}"
+ link_gomp="-lgomp %{static: $LIBS${DL_LIBS:+ $DL_LIBS}}"
else
- link_gomp="-lgomp $LIBS"
+ link_gomp="-lgomp $LIBS${DL_LIBS:+ $DL_LIBS}"
fi
AC_SUBST(link_gomp)
--- libgomp/configure.jj2023-05-15 19:12:35.138624638 +0200
+++ libgomp/configure 2023-05-18 20:42:12.703299052 +0200
@@ -16788,9 +16788,9 @@ fi
# which will force linkage against -lpthread (or equivalent for the system).
# That's not 100% ideal, but about the best we can do easily.
if test $enable_shared = yes; then
- link_gomp="-lgomp %{static: $LIBS}"
+ link_gomp="-lgomp %{static: $LIBS${DL_LIBS:+ $DL_LIBS}}"
else
- link_gomp="-lgomp $LIBS"
+ link_gomp="-lgomp $LIBS${DL_LIBS:+ $DL_LIBS}"
fi
[Bug c++/108321] [13 regression] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108321 seurer at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED Last reconfirmed||2023-05-18 Ever confirmed|0 |1 --- Comment #3 from seurer at gcc dot gnu.org --- The problem with g++.dg/contracts/contracts-tmpl-spec2.C has never been fixed as far as I can tell. It definitely occurs with the current r13. I believe the "This is fixed after r13-4290-g138ee8f7453ffd" was referring to the other mentioned issue. g:f48c546902802cf640c4f2802543acfdc702404f, r13-7354-gf48c546902802c make -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/contracts/contracts-tmpl-spec2.C" FAIL: g++.dg/contracts/contracts-tmpl-spec2.C output pattern test # of expected passes2 # of unexpected failures1 FAIL: g++.dg/contracts/contracts-tmpl-spec2.C output pattern test Output was: contract violation in function body at g++.dg/contracts/contracts-tmpl-spec2.C:9: a > 0 [continue:on] -2 contract violation in function body at g++.dg/contracts/contracts-tmpl-spec2.C:17: a > 1 [continue:on] -3 contract violation in function none at g++.dg/contracts/contracts-tmpl-spec2.C:25: a > 0 [continue:on] 1 contract violation in function none at g++.dg/contracts/contracts-tmpl-spec2.C:32: a > 1 [continue:on] -101 contract violation in function arg0 at g++.dg/contracts/contracts-tmpl-spec2.C:39: t > 0 [continue:on] -9 contract violation in function arg0 at g++.dg/contracts/contracts-tmpl-spec2.C:46: t > 1 [continue:on] 11 contract violation in function arg1 at g++.dg/contracts/contracts-tmpl-spec2.C:53: a > 0 [continue:on] contract violation in function arg1 at g++.dg/contracts/contracts-tmpl-spec2.C:54: t > 0 [continue:on] -3 contract violation in function arg1 at g++.dg/contracts/contracts-tmpl-spec2.C:61: a > 1 [continue:on] contract violation in function arg1 at g++.dg/contracts/contracts-tmpl-spec2.C:62: t > 1 [continue:on] 14 contract violation in function ret at g++.dg/contracts/contracts-tmpl-spec2.C:69: a > 0 [continue:on] 1 contract violation in function ret at g++.dg/contracts/contracts-tmpl-spec2.C:76: a > 1 [continue:on] 3 contract violation in function ret at g++.dg/contracts/contracts-tmpl-spec2.C:76: a > 1 [continue:on] 3.30 contract violation in function g1 at g++.dg/contracts/contracts-tmpl-spec2.C:83: t > 0 [continue:on] -1 -1 contract violation in function g2 at g++.dg/contracts/contracts-tmpl-spec2.C:97: t > 0 [continue:on] -1 contract violation in function g2 at g++.dg/contracts/contracts-tmpl-spec2.C:107: t < 0 [continue:on] 1 contract violation in function g2 at g++.dg/contracts/contracts-tmpl-spec2.C:114: t < 'c' [continue:on] 100 contract violation in function G3::f at g++.dg/contracts/contracts-tmpl-spec2.C:124: t > 0 [continue:on] contract violation in function G3::f at g++.dg/contracts/contracts-tmpl-spec2.C:125: s > 0 [continue:on] G3 general T S contract violation in function G3::f at g++.dg/contracts/contracts-tmpl-spec2.C:139: t > 1 [continue:on] contract violation in function G3::f at g++.dg/contracts/contracts-tmpl-spec2.C:140: s > 1 [continue:on] G3 partial int S contract violation in function G3::f at g++.dg/contracts/contracts-tmpl-spec2.C:147: t > 2 [continue:on] contract violation in function G3::f at g++.dg/contracts/contracts-tmpl-spec2.C:148: s > 2 [continue:on] G3 full int double G3 general T S contract violation in function G3::f at g++.dg/contracts/contracts-tmpl-spec2.C:139: t > 1 [continue:on] G3 partial int S G3 full int C G3 full int C contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:173: t > 0 [continue:on] contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:174: s > 0 [continue:on] G4 general T S contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:175: x > 0 [continue:on] G4 full double double contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:206: a > 0 [continue:on] contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:207: b > 'b' [continue:on] G4 full double char contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:208: x > 1 [continue:on] contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:187: t > 'c' [continue:on] contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:188: s > 3 [continue:on] G4 partial char S contract violation in function G4::G4 at g++.dg/contracts/contracts-tmpl-spec2.C:189: x2 > 3 [continue:on] contract violation in function G5::f at g++.dg/contracts/contracts-tmpl-spec2.C:220: t > 0 [continue:on] contract violation in function G5::f at g++.dg/contracts/contracts-tmpl-spec2.C:221: s > 0 [continue:on]
[Bug c++/108321] [13 regression] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108321 --- Comment #4 from seurer at gcc dot gnu.org --- *** Bug 107915 has been marked as a duplicate of this bug. ***
[Bug other/107915] new test case g++.dg/contracts/contracts-tmpl-spec2.C in r13-4160-g2efb237ffc68ec fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107915 seurer at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from seurer at gcc dot gnu.org --- A PR on this was opened twice. *** This bug has been marked as a duplicate of bug 108321 ***
[Bug target/106471] -mpcu=generic might want to remove X86_TUNE_AVOID_FALSE_DEP_FOR_BMI now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106471 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-05-18 Status|UNCONFIRMED |NEW Summary|Strange code generation for |-mpcu=generic might want to |__builtin_ctzl()|remove ||X86_TUNE_AVOID_FALSE_DEP_FO ||R_BMI now Ever confirmed|0 |1 --- Comment #8 from Andrew Pinski --- Confirmed. I will let someone else make the decision on when this happens.
[Bug c++/106810] Unexpected constraint recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106810
--- Comment #1 from Andrew Pinski ---
Reduced down just this:
```
template
concept t = requires(a aa, b bb) { aa == bb; };
template
struct I {
using value_type = int;
using difference_type = int;
value_type& operator*() const;
I& operator++();
I operator++(int);
template S>
friend bool operator==(I, S);
};
static_assert(t>);
```
I think GCC is correct in saying this is recusive even.
