[Bug target/94193] New: powerpc: Provide fegetround/feraiseexcept/feclearexcept builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94193 Bug ID: 94193 Summary: powerpc: Provide fegetround/feraiseexcept/feclearexcept builtins Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: adhemerval.zanella at linaro dot org Target Milestone: --- For hard-float powerpc, GCC should support inline code generation for the fegetround, feraiseexcept, and feclearexcept. These optimization has been provided by glibc through fenvinline and glibc idea is to remove both the headers and the header optimizations [1]. [1] https://sourceware.org/pipermail/libc-alpha/2020-March/111752.html
[Bug target/94194] New: x86: Provide feraiseexcept builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94194 Bug ID: 94194 Summary: x86: Provide feraiseexcept builtins Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: adhemerval.zanella at linaro dot org Target Milestone: --- GCC should support inline code generation for feraiseexcept. These optimization has been provided by glibc through fenv.h and glibc idea is to remove both the headers and the optimization [1]. [1] https://sourceware.org/pipermail/libc-alpha/2020-March/111753.html
[Bug target/94194] x86: Provide feraiseexcept builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94194 --- Comment #2 from Adhemerval Zanella --- Afaik the libc implementation is free to set any macro value for FE_*, although glibc and other implementations I am awre of try to make is related to architecture values when it does make sense (and it also tend to simplify the implementation). So I would expect that the compiler either would need to export a system-neutral value (GCC_FE_* or something related) with the drawback it would not be a direct replacement for the system library call (as other builtins tend to be) or define functions that does not use input arguments (something like __builtin_feraiseexcept_div_by_zero). For -fno-trapping-math I would expect to be a nop in such a scenario, although I haven't given much thought about it. However, I opened this bug more to check if this optimization would be worth implementing. My take is to remove it from glibc installed headers [1], and my impression is this should not add much from the compiler side of view as well. [1] https://sourceware.org/pipermail/libc-alpha/2020-March/111775.html
[Bug target/94204] New: m68k: Provide builtins for mathemactical functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94204 Bug ID: 94204 Summary: m68k: Provide builtins for mathemactical functions Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: adhemerval.zanella at linaro dot org Target Milestone: --- For hard-float, GCC should support inline code generation for the trunc, floor, ceil, isinf, finite, scalbn, isnan, scalbln, nearbyint, lrint, and sincos. These optimization has been provided by glibc through mathinline.h headers and glibc idea is to remove both the header and the optimizations [1]. [1] https://sourceware.org/pipermail/libc-alpha/2018-March/092351.html
[Bug rtl-optimization/92657] New: High stack usage due ftree-ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657 Bug ID: 92657 Summary: High stack usage due ftree-ch Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: adhemerval.zanella at linaro dot org Target Milestone: --- Created attachment 47351 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47351&action=edit High stack usage due ftree-ch The code snippet (gcc_free_ch_stack.c) shows a high stack usage. With GCC 9.2.1 I see the resulting stack usage using -fstack-usage along with -O2: arm 632 aarch64 448 powerpc 912 powerpc64le 560 s390600 s390x 632 i3861376 x86_64 784 The same issue also shows in master branch. It seems that it is due -ftree-ch pass with feeds -ftree-loop-im, -ftree-pre, -fmove-loop-invariants, and -fgcse. Andrew Pinski suggested is mostly due lack of a good estimate register pressure for loop invariant code motion. Andrew also suggested to use -fno-tree-loop-im -fno-tree-pre -fno-gcse, however even with this options the resulting stack usage does not get in par with -Os option (which disables -ftree-ch). On powerpc64le: $ ./gcc/xgcc -v 2>&1 | grep 'gcc version' gcc version 10.0.0 20191121 (experimental) (GCC) $ ./gcc/xgcc -B gcc -O2 stack_usage.c -fstack-usage -c; cat stack_usage.su stack_usage.c:157:6:mlx5e_grp_sw_update_stats 496 static $ ./gcc/xgcc -B gcc -O2 stack_usage.c -fstack-usage -c -fno-tree-loop-im -fno-tree-pre -fno-move-loop-invariants -fno-gcse; cat stack_usage.su stack_usage.c:157:6:mlx5e_grp_sw_update_stats 176 static$ ./gcc/xgcc -B gcc -Os stack_usage.c -fstack-usage -c; cat stack_usage.su $ ./gcc/xgcc -B gcc -Os stack_usage.c -fstack-usage -c; cat stack_usage.su stack_usage.c:157:6:mlx5e_grp_sw_update_stats 32 static
[Bug rtl-optimization/92657] High stack usage due ftree-ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657 --- Comment #2 from Adhemerval Zanella --- (In reply to Andrew Pinski from comment #1) > Again, this is not due to tree-ch at all. This is due to the code motion > passes move invariant load/stores out of the loop. Tree-ch pass just allows > those passes to work. > > All three (gcse, tree pre and tree lim) need to be disabled to see the > difference as all three are able to do the transformation. Sorry if I was not clear that tree-ch is not the culprit, but rather that it enabled further optimizations to increase register pressure. But as I added by disabling gcse, tree pre, and tree lim does help total stack usage, but it does not reach on same level as disabling tree-ch.
[Bug rtl-optimization/92657] High stack usage due ftree-ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657 --- Comment #3 from Adhemerval Zanella --- (In reply to Adhemerval Zanella from comment #2) > (In reply to Andrew Pinski from comment #1) > > Again, this is not due to tree-ch at all. This is due to the code motion > > passes move invariant load/stores out of the loop. Tree-ch pass just allows > > those passes to work. > > > > All three (gcse, tree pre and tree lim) need to be disabled to see the > > difference as all three are able to do the transformation. > > Sorry if I was not clear that tree-ch is not the culprit, but rather that it > enabled further optimizations to increase register pressure. But as I added > by disabling gcse, tree pre, and tree lim does help total stack usage, but > it does not reach on same level as disabling tree-ch. Ok, gcse, tree pre and tree lim are just tree of the flags that are increasing the stack. Other not enabled by Os but enabled by O2 are increasing stack usage. Maybe changing the title to "High stack usage with tree-loop-im, tree-pre, and gcse"?
[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445 Adhemerval Zanella changed: What|Removed |Added CC||adhemerval.zanella at linaro dot o ||rg --- Comment #2 from Adhemerval Zanella --- This is not really aarch64 also, all 64-bit architectures will require this fix. And indeed, the features.h header is only fixed at release, until them GLIBC sets its version to '2.23.90' (meaning 2.23 development).
[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445 --- Comment #8 from Adhemerval Zanella --- Indeed I did not take in consideration the versioned issue with interposed wrapper mainly because the idea of the patch was to fix the static compile asserts against newer glibc. I see the runtime issue as separated issue. However regarding the kernel interface, kernel accepts 64-bit msg_iovlen, msg_controllen and cmsg_len; so it is a matter if libsanitizer also want to enforce the POSIX compliance in the syscalls for Linux. One solution is as Jakub suggested is limit the check to 32-bits values, another might be to remove the compiler asserts and use the kernel interface instead of defined POSIX one. I am not sure which is better option.
[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445 --- Comment #10 from Adhemerval Zanella --- I think add versioned symbols in libsanitizer seems feasible with current supported platforms and seems to be the more complete fix. I will check on that.
[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445 --- Comment #12 from Adhemerval Zanella --- After checking the work required for enable symbol versioning wrapper on libsanitizer I am more inclined to go with always ignore the high bits (at least for backports). The versioning enablement will require some changes and I foresee it will generate some discussion in sanitizer side before a settle solution is used. Any suggestions?
[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445 --- Comment #16 from Adhemerval Zanella --- I am sorry for make you waste your time Jakub, after some deliberation I decided to revert this patch on glibc. I will close this bug after push this change on glibc side.
[Bug sanitizer/71445] libsanitizer build failure on aarch64-linux-gnu with recent glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445 --- Comment #18 from Adhemerval Zanella --- Yes, I will take care of reverting compiler-rt changes and bring the issues you raised.
[Bug sanitizer/59748] ptrace isn't instrumented on at least arm-linux-gnueabihf and powerpc-linux.gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59748 Adhemerval Zanella changed: What|Removed |Added CC||adhemerval.zanella at linaro dot o ||rg --- Comment #1 from Adhemerval Zanella --- Yes, there are not instrument even in LLVM. I am working on arm-linux-gnueabihf ptrace instrumentation.
[Bug libstdc++/48891] std functions conflicts with C functions when building with c++0x support (and using namespace std)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891 Adhemerval Zanella changed: What|Removed |Added CC||adhemerval.zanella at linaro dot o ||rg --- Comment #10 from Adhemerval Zanella --- It is being tracked by https://sourceware.org/bugzilla/show_bug.cgi?id=19439 and has been fixed by d9b965fa56350d6eea9f7f438a0714c7ffbb183f. It will be included in GLIBC 2.23.
[Bug sanitizer/71042] libtsan requires __pointer_chk_guard@GLIBC_PRIVATE (6)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71042 --- Comment #7 from Adhemerval Zanella --- I do have a better solution to fix it, since for aarch64 glibc port, the stack guard is a global variable (different than x86_64 where it in tcbhead accessible through thread pointer). We can just disable the jump fuction interposing for aarch64 and set it as unavailable, but I would prefer to use if there is no alternative. Jakub's solution can work and I will check it, but could you describe the issue with RPM with more details?
[Bug sanitizer/71042] libtsan requires __pointer_chk_guard@GLIBC_PRIVATE (6)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71042
--- Comment #9 from Adhemerval Zanella
---
Right, I wasn't aware of this RPM symbol handling. I see that guard pointer
can be obtained on aarch64 by:
uintptr_t get_guard_ptr (void)
{
jmp_buf jb;
uintptr_t expected, mangled;
setjmp (jb);
asm volatile ("adr %0, ." : "=r" (expected));
mangled = ((uintptr_t*)jb)[11];
return expected ^ mangled;
}
So I think we can add a local variable to hold its value and set
tsan_rtl_aarch64.S to use it instead.
[Bug sanitizer/71042] libtsan requires __pointer_chk_guard@GLIBC_PRIVATE (6)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71042 --- Comment #10 from Adhemerval Zanella --- I just pushed r278292 on compiler-rt and I think it should fix the issue.
[Bug target/97546] New: [SVE] ICE with -fenable-tree-bswap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97546
Bug ID: 97546
Summary: [SVE] ICE with -fenable-tree-bswap
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: adhemerval.zanella at linaro dot org
Target Milestone: ---
The reduced testcase:
--
#include
static svbool_t visinf_vo_vf(svfloat32_t d)
{
return svcmpeq_n_f32 (svptrue_b8 (),
svabs_f32_x (svptrue_b8 (), d),
__builtin_inff ());
}
const svint32_t _ZGVsNxv_ilogbf(svfloat32_t d)
{
svint32_t e = svreinterpret_s32_f32 (svdup_n_f32 (0.0f));
e = svsel_s32 (svcmpne_f32 (svptrue_b8(), d, d),
svdup_n_s32 (2147483647),
e);
e = svsel_s32 (visinf_vo_vf (d),
svdup_n_s32 (0x7fff),
e);
return e;
}
--
ICE with gcc with:
$ aarch64-unknown-linux-gnu-gcc -march=armv8.2-a+sve reproducer.c -c -O1
-fenable-tree-bswap
cc1: note: enable pass tree-bswap for functions in the range of [0, 4294967295]
during GIMPLE pass: bswap
reproducer.c: In function ‘_ZGVsNxv_ilogbf’:
reproducer.c:81:17: internal compiler error: tree check: expected integer_cst,
have poly_int_cst in find_bswap_or_nop, at gimple-ssa-store-merging.c:859
81 | const svint32_t _ZGVsNxv_ilogbf(svfloat32_t d)
| ^~~
0x692107 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-git-master/gcc/tree.c:9731
0x1849ed3 tree_int_cst_elt_check(tree_node*, int, char const*, int, char
const*)
../../gcc-git-master/gcc/tree.h:3503
0x1849ed3 find_bswap_or_nop
../../gcc-git-master/gcc/gimple-ssa-store-merging.c:859
0x1849ed3 execute
../../gcc-git-master/gcc/gimple-ssa-store-merging.c:1261
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug middle-end/111156] New: [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56 Bug ID: 56 Summary: [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: adhemerval.zanella at linaro dot org Target Milestone: --- After https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=a1558e9ad856938f165f838733955b331ebbec09, I have noticed regressions on aarch64: Running gcc:gcc.target/aarch64/sve/aarch64-sve.exp ... FAIL: gcc.target/aarch64/sve/mask_struct_store_4.c (internal compiler error: in get_group_load_store_type, at tree-vect-stmts.cc:2121) FAIL: gcc.target/aarch64/sve/mask_struct_store_4.c (test for excess errors) UNRESOLVED: gcc.target/aarch64/sve/mask_struct_store_4.c scan-assembler-not \\tst2b\\t.z[0-9] UNRESOLVED: gcc.target/aarch64/sve/mask_struct_store_4.c scan-assembler-not \\tst2d\\t.z[0-9] UNRESOLVED: gcc.target/aarch64/sve/mask_struct_store_4.c scan-assembler-not \\tst2h\\t.z[0-9] UNRESOLVED: gcc.target/aarch64/sve/mask_struct_store_4.c scan-assembler-not \\tst2w\\t.z[0-9] (As indicated by Linaro CI https://ci.linaro.org/job/tcwg_gnu_native_check_gcc--master-aarch64-build/570/artifact/artifacts/notify/mail-body.txt/*view*/)
[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
Adhemerval Zanella changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED|UNCONFIRMED
--- Comment #5 from Adhemerval Zanella
---
Reopening since this is not a duplicate of bug 36. The issue is
mask_struct_store_4.c generates the very instructions that the test is
checking:
$ ./gcc/xgcc -Bgcc -march=armv8.2-a+sve -O2 -ftree-vectorize -ffast-math
[..]/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_store_4.c -S -o - | grep
st2b
st2b{z30.b - z31.b}, p7, [x0, x5]
st2b{z28.b - z29.b}, p6, [x0, x5]
st2b{z28.b - z29.b}, p6, [x0, x5]
st2b{z28.b - z29.b}, p7, [x0, x5]
st2b{z26.b - z27.b}, p6, [x0, x5]
st2b{z26.b - z27.b}, p6, [x0, x5]
st2b{z28.b - z29.b}, p7, [x0, x5]
st2b{z26.b - z27.b}, p6, [x0, x5]
st2b{z26.b - z27.b}, p6, [x0, x5]
st2b{z28.b - z29.b}, p7, [x0, x5]
st2b{z26.b - z27.b}, p6, [x0, x5]
st2b{z26.b - z27.b}, p6, [x0, x5]
[Bug target/116195] New: arm: ICE building pr111150.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116195 Bug ID: 116195 Summary: arm: ICE building pr50.C Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: adhemerval.zanella at linaro dot org Target Milestone: --- It seems that this change triggered with Linaro CI on arm 32 bit [1]: -- Executing on host: /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-g++ /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C -mthumb -march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 -mfloat-abi=hard -mfpu=auto -fdiagnostics-plain-output -nostdinc++ -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include/arm-eabi -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/libsupc++ -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/include/backward -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -O1 -fdump-tree-forwprop1 -Wno-psabi -S -o pr50.s(timeout = 600) spawn -ignore SIGHUP /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-g++ /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C -mthumb -march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 -mfloat-abi=hard -mfpu=auto -fdiagnostics-plain-output -nostdinc++ -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include/arm-eabi -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/libsupc++ -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/include/backward -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -O1 -fdump-tree-forwprop1 -Wno-psabi -S -o pr50.s /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C: In function 'v4si f1_(v4si, v4si, v4si, v4si, v4si, v4si)': /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C:13:1: error: unrecognizable insn: (insn 22 21 26 2 (set (reg:V4SI 120 [ ]) (unspec:V4SI [ (reg:V4SI 136) (reg:V4SI 137) (subreg:V4BI (reg:HI 135) 0) ] VPSELQ_S)) "/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C":12:17 -1 (nil)) during RTL pass: vregs /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C:13:1: internal compiler error: in extract_insn, at recog.cc:2848 0x21fd635 internal_error(char const*, ...) ../../../../../../gcc/gcc/diagnostic-global-context.cc:491 0x9a0958 fancy_abort(char const*, int, char const*) ../../../../../../gcc/gcc/diagnostic.cc:1725 0x840e4d _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../../../../../gcc/gcc/rtl-error.cc:108 0x840e6f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../../../../../gcc/gcc/rtl-error.cc:116 0x83f76b extract_insn(rtx_insn*) ../../../../../../gcc/gcc/recog.cc:2848 0xf1a805 instantiate_virtual_regs_in_insn ../../../../../../gcc/gcc/function.cc:1612 0xf1a805 instantiate_virtual_regs ../../../../../../gcc/gcc/function.cc:1995 0xf1a805 execute ../../../../../../gcc/gcc/function.cc:2042 -- Accordingly to Andrew Piski, this is backend bug that was exposed by the patch. `vcond_mask_` for operand[3] uses s_register_operand which allows subreg but then it creates a VPSELQ_S unspec which uses vpr_register_operand as the operand which does not allow subreg and does not forces into a register. [1] https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/517/artifact/artifacts/00-sumfiles/
[Bug c++/114275] using std::thread within a templated function in a module fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114275 Adhemerval Zanella changed: What|Removed |Added CC||adhemerval.zanella at linaro dot o ||rg --- Comment #8 from Adhemerval Zanella --- (In reply to GCC Commits from comment #6) > The master branch has been updated by Nathaniel Shead : > > https://gcc.gnu.org/g:b5f6a56940e70838a07e885de03a92e2bd64674a > > commit r15-59-gb5f6a56940e70838a07e885de03a92e2bd64674a > Author: Nathaniel Shead > Date: Mon Apr 29 17:00:13 2024 +1000 > > c++: Fix instantiation of imported temploid friends [PR114275] > > This patch fixes a number of issues with the handling of temploid friend > declarations. > > The primary issue is that instantiations of friend declarations should > attach the declaration to the same module as the befriending class, by > [module.unit] p7.1 and [temp.friend] p2; this could be a different > module from the current TU, and so needs special handling. > > The other main issue here is that we can't assume that just because name > lookup didn't find a definition for a hidden class template, that it > doesn't exist at all: it could be a non-exported entity that we've > nevertheless streamed in from an imported module. We need to ensure > that when instantiating template friend classes that we return the same > TEMPLATE_DECL that we got from our imports, otherwise we will get later > issues with 'duplicate_decls' (rightfully) complaining that they're > different when trying to merge. > > This doesn't appear necessary for function templates due to the existing > name lookup handling already finding these hidden declarations. > > PR c++/105320 > PR c++/114275 > > gcc/cp/ChangeLog: > > * cp-tree.h (propagate_defining_module): Declare. > (lookup_imported_hidden_friend): Declare. > * decl.cc (duplicate_decls): Also check if hidden decls can be > redeclared in this module. > * module.cc (imported_temploid_friends): New. > (init_modules): Initialize it. > (trees_out::decl_value): Write it; don't consider imported > temploid friends as attached to a module. > (trees_in::decl_value): Read it. > (get_originating_module_decl): Follow the owning decl for an > imported temploid friend. > (propagate_defining_module): New. > * name-lookup.cc (get_mergeable_namespace_binding): New. > (lookup_imported_hidden_friend): New. > * pt.cc (tsubst_friend_function): Propagate defining module for > new friend functions. > (tsubst_friend_class): Lookup imported hidden friends. Check > for valid module attachment of existing names. Propagate > defining module for new classes. > > gcc/testsuite/ChangeLog: > > * g++.dg/modules/tpl-friend-10_a.C: New test. > * g++.dg/modules/tpl-friend-10_b.C: New test. > * g++.dg/modules/tpl-friend-10_c.C: New test. > * g++.dg/modules/tpl-friend-10_d.C: New test. > * g++.dg/modules/tpl-friend-11_a.C: New test. > * g++.dg/modules/tpl-friend-11_b.C: New test. > * g++.dg/modules/tpl-friend-12_a.C: New test. > * g++.dg/modules/tpl-friend-12_b.C: New test. > * g++.dg/modules/tpl-friend-12_c.C: New test. > * g++.dg/modules/tpl-friend-12_d.C: New test. > * g++.dg/modules/tpl-friend-12_e.C: New test. > * g++.dg/modules/tpl-friend-12_f.C: New test. > * g++.dg/modules/tpl-friend-13_a.C: New test. > * g++.dg/modules/tpl-friend-13_b.C: New test. > * g++.dg/modules/tpl-friend-13_c.C: New test. > * g++.dg/modules/tpl-friend-13_d.C: New test. > * g++.dg/modules/tpl-friend-13_e.C: New test. > * g++.dg/modules/tpl-friend-13_f.C: New test. > * g++.dg/modules/tpl-friend-13_g.C: New test. > * g++.dg/modules/tpl-friend-14_a.C: New test. > * g++.dg/modules/tpl-friend-14_b.C: New test. > * g++.dg/modules/tpl-friend-14_c.C: New test. > * g++.dg/modules/tpl-friend-14_d.C: New test. > * g++.dg/modules/tpl-friend-9.C: New test. > > Signed-off-by: Nathaniel Shead > Reviewed-by: Jason Merrill This has triggered some regression on aarch64 [1]: Running g++:g++.dg/modules/modules.exp ... FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17 (test for errors, line 16) FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17 (test for errors, line 19) FAIL: g++.dg/modules/tpl-friend-4_b.C -std=c++17 (internal compiler
[Bug target/112337] arm: ICE in arm_effective_regno when compiling for MVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337 Adhemerval Zanella changed: What|Removed |Added CC||adhemerval.zanella at linaro dot o ||rg --- Comment #12 from Adhemerval Zanella --- We are seeing failures for gcc/testsuite/gcc.target/arm/pr112337.c for our arm_v7a_softfp_eabi buildbot (configure with --disable-multiarch --disable-multilib --with-mode=arm --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=softfp --with-newlib): spawn -ignore SIGHUP /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-gcc /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.target/arm/pr112337.c -marm -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=softfp -fdiagnostics-plain-output -O2 -march=armv8.1-m.main+fp.dp+mve.fp -mfloat-abi=hard -S -o pr112337.s cc1: error: target CPU does not support ARM mode compiler exited with status 1 output is: cc1: error: target CPU does not support ARM mode comp_output (pruned) is: cc1: error: target CPU does not support ARM mode FAIL: gcc.target/arm/pr112337.c (test for excess errors) Excess errors: cc1: error: target CPU does not support ARM mode I am not sure if this is a test contraint failure or something else.
[Bug c/113489] New: aarch64: ICE on gcc/gcc/tree-vect-slp.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113489 Bug ID: 113489 Summary: aarch64: ICE on gcc/gcc/tree-vect-slp.cc Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: adhemerval.zanella at linaro dot org Target Milestone: --- The gcc/gcc/tree-vect-slp.cc torture testcase triggered a ICE: spawn -ignore SIGHUP /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/bin/aarch64-linux-gnu-gcc --sysroot=/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/aarch64-linux-gnu/libc /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/torture/neon-sve-bridge.c -fdiagnostics-plain-output -O2 -march=armv8.2-a+sve -lm -o ./neon-sve-bridge.exe during GIMPLE pass: slp /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/torture/neon-sve-bridge.c: In function 'svset_neonq_test': /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/torture/neon-sve-bridge.c:23:1: internal compiler error: in to_constant, at poly-int.h:588 0x8889b6 poly_int<2u, unsigned long>::to_constant() const ../../../../../../gcc/gcc/poly-int.h:588 0x1374095 poly_int<2u, unsigned long>::to_constant() const ../../../../../../gcc/gcc/poly-int.h:586 0x1374095 vectorizable_slp_permutation_1 ../../../../../../gcc/gcc/tree-vect-slp.cc:9020 0x1388372 vectorizable_slp_permutation ../../../../../../gcc/gcc/tree-vect-slp.cc:9183 0x1388372 vect_slp_analyze_node_operations_1 ../../../../../../gcc/gcc/tree-vect-slp.cc:6141 0x1388372 vect_slp_analyze_node_operations ../../../../../../gcc/gcc/tree-vect-slp.cc:6357 0x1387d51 vect_slp_analyze_node_operations ../../../../../../gcc/gcc/tree-vect-slp.cc:6336 0x1389bad vect_slp_analyze_operations(vec_info*) ../../../../../../gcc/gcc/tree-vect-slp.cc:6747 0x138ef85 vect_slp_analyze_bb_1 ../../../../../../gcc/gcc/tree-vect-slp.cc:7749 0x138ef85 vect_slp_region ../../../../../../gcc/gcc/tree-vect-slp.cc:7796 0x1391143 vect_slp_bbs ../../../../../../gcc/gcc/tree-vect-slp.cc:8007 0x13916e4 vect_slp_function(function*) ../../../../../../gcc/gcc/tree-vect-slp.cc:8129 0x139c1d2 execute ../../../../../../gcc/gcc/tree-vectorizer.cc:1533 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. compiler exited with status 1 output is: during GIMPLE pass: slp The configuration used can be found at https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-aarch64-build/1215/artifact/artifacts/08-build_abe-stage2/console.log.xy (line 356).
[Bug tree-optimization/111150] (vec CMP vec) != (vec CMP vec) should just produce (vec CMP vec) ^ (vec CMP vec)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50 Adhemerval Zanella changed: What|Removed |Added CC||adhemerval.zanella at linaro dot o ||rg --- Comment #4 from Adhemerval Zanella --- It seems that this change triggered an ICE with Linaro CI on arm 32 bit [1]: -- Executing on host: /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-g++ /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C -mthumb -march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 -mfloat-abi=hard -mfpu=auto -fdiagnostics-plain-output -nostdinc++ -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include/arm-eabi -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/libsupc++ -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/include/backward -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -O1 -fdump-tree-forwprop1 -Wno-psabi -S -o pr50.s(timeout = 600) spawn -ignore SIGHUP /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-g++ /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C -mthumb -march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 -mfloat-abi=hard -mfpu=auto -fdiagnostics-plain-output -nostdinc++ -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include/arm-eabi -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/x86_64-pc-linux-gnu/arm-eabi/gcc-gcc.git~master-stage2/arm-eabi/libstdc++-v3/include -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/libsupc++ -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/include/backward -I/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -O1 -fdump-tree-forwprop1 -Wno-psabi -S -o pr50.s /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C: In function 'v4si f1_(v4si, v4si, v4si, v4si, v4si, v4si)': /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C:13:1: error: unrecognizable insn: (insn 22 21 26 2 (set (reg:V4SI 120 [ ]) (unspec:V4SI [ (reg:V4SI 136) (reg:V4SI 137) (subreg:V4BI (reg:HI 135) 0) ] VPSELQ_S)) "/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C":12:17 -1 (nil)) during RTL pass: vregs /home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/g++.dg/tree-ssa/pr50.C:13:1: internal compiler error: in extract_insn, at recog.cc:2848 0x21fd635 internal_error(char const*, ...) ../../../../../../gcc/gcc/diagnostic-global-context.cc:491 0x9a0958 fancy_abort(char const*, int, char const*) ../../../../../../gcc/gcc/diagnostic.cc:1725 0x840e4d _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../../../../../gcc/gcc/rtl-error.cc:108 0x840e6f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../../../../../gcc/gcc/rtl-error.cc:116 0x83f76b extract_insn(rtx_insn*) ../../../../../../gcc/gcc/recog.cc:2848 0xf1a805 instantiate_virtual_regs_in_insn ../../../../../../gcc/gcc/function.cc:1612 0xf1a805 instantiate_virtual_regs ../../../../../../gcc/gcc/function.cc:1995 0xf1a805 execute ../../../../../../gcc/gcc/function.cc:2042 --
[Bug tree-optimization/114326] Missed optimization for A || B when !B implies A.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114326 Adhemerval Zanella changed: What|Removed |Added CC||adhemerval.zanella at linaro dot o ||rg --- Comment #7 from Adhemerval Zanella --- It has triggered a regression on arm32 Linaro bots [1]: --- Executing on host: /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-gcc /home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/tree-ssa/fold-xor-and-or.c -mthumb -march=armv8.1-m.main+mve.fp+fp.dp -mtune=cortex-m55 -mfloat-abi=hard -mfpu=auto -fdiagnostics-plain-output -O3 -fdump-tree-optimized -S -o fold-xor-and-or.s FAIL: gcc.dg/tree-ssa/fold-xor-and-or.c scan-tree-dump-not optimized "d1_[0-9]+.D. \\^ d2_[0-9]+.D." $ grep -e "d1_[0-9]" fold-xor-and-or.c.267t.optimized _1 = d1_4(D) ^ d2_5(D); --- It can be triggered with a cross-compiler targeting arm-linux-gnueabhf with the above flags. [1] https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m55_hard_eabi-build/650/artifact/artifacts/00-sumfiles/gcc.log.0.xz
[Bug tree-optimization/118184] New: [15 regression] glibc regression on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118184 Bug ID: 118184 Summary: [15 regression] glibc regression on aarch64 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: adhemerval.zanella at linaro dot org Target Milestone: --- Created attachment 59957 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59957&action=edit preprocessed file of the affected routine The commit https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=5ab3f091b3eb42795340d3c9cea8aaec2060693c triggered two glibc regression on aarch64: FAIL: math/test-nan-payload FAIL: stdlib/tst-strtod6 On glibc stdlib/strtod_nan_main.c where glibc handles the NaN input for strtold: 48 /* This is a system-dependent way to specify the bitmask used for 49 the NaN. We expect it to be a number which is put in the 50 mantissa of the number. */ 51 STRING_TYPE *endp; 52 unsigned long long int mant; 53 54 int save_errno = errno; 55 mant = STRTOULL (str, &endp, 0); 56 __set_errno (save_errno); 57 if (endp == cp) 58 SET_NAN_PAYLOAD (retval, mant); 59 60 out: 61 if (endptr != NULL) 62 *endptr = (STRING_TYPE *) cp; 63 return retval; 64 } When building with default -O2 the comparison at line 57 is not true, which does not net the number to NaN. Building with -O0 does not trigger this issue.
[Bug target/67771] integer-to-floating-point conversions wrongly produce -0 in FE_DOWNWARD mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67771
--- Comment #7 from Adhemerval Zanella
---
(In reply to John Paul Adrian Glaubitz from comment #6)
> (In reply to Joseph S. Myers from comment #5)
> > Various glibc functions work around this using FIX_INT_FP_CONVERT_ZERO, I
> > suppose the new log10f implementation taken from CORE-MATH needs such a
> > workaround as well.
>
> @Adhemerval: Do you think you could add such a workaround for 32-bit PowerPC?
This fixes the issues on glibc for powerpc for !HAVE_PPC_FCFID:
diff --git a/sysdeps/ieee754/flt-32/e_log10f.c
b/sysdeps/ieee754/flt-32/e_log10f.c
index 03d9e281f3..46cd5edd70 100644
--- a/sysdeps/ieee754/flt-32/e_log10f.c
+++ b/sysdeps/ieee754/flt-32/e_log10f.c
@@ -27,6 +27,7 @@ SOFTWARE.
#include
#include
#include
+#include
#include "math_config.h"
static __attribute__ ((noinline)) float
@@ -129,7 +130,12 @@ __ieee754_log10f (float x)
unsigned je = e + 1;
je = (je * 0x4d104d4) >> 28;
if (__glibc_unlikely (ux == st[je].u))
-return je;
+{
+ float r = je;
+ if (FIX_INT_FP_CONVERT_ZERO && r == -0.0f)
+return 0.0;
+ return r;
+}
double tz = asdouble (((int64_t) m | ((int64_t) 1023 << 23)) << (52 - 23));
double z = tz * ix - 1, z2 = z * z;
I will send a patch.
