[Bug testsuite/102719] [12 regression] several failures after r12-4337
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102719 pc at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from pc at gcc dot gnu.org --- Fixed with noted commits.
[Bug target/104901] gcc/config/rs6000/mm_malloc.h:46: incorrectLogicOperator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104901 pc at gcc dot gnu.org changed: What|Removed |Added CC||pc at gcc dot gnu.org --- Comment #5 from pc at gcc dot gnu.org --- (In reply to Segher Boessenkool from comment #4) > is this micro-optimisation useful at all, don't > posix_memalign and malloc end up the same under the covers anyway? posix_memalign returns memory aligned to a specified power-of-2 alignment. malloc returns memory aligned to some ABI minimum. (You already know this, I'm sure.) The code will use malloc if it can, and posix_memalign otherwise. There may be a slight advantage to using malloc instead of posix_memalign. The paths are indeed different. I'm not sure why the floor is raised after determining not to call malloc: -- if (__alignment == __malloc_align && __alignment == __vec_align) return malloc (__size); if (__alignment < __vec_align) __alignment = __vec_align; -- (I probably would've written the code slightly differently.) It appears to me that the identified code would be always false on a 32-bit system, where __malloc_align would be computed as 64 bits, and _vec_align as 128 bits. It would be always true on a 64-bit system (128 == 128). All that being said, I'm not sure I see any problem with the code, and maybe the analyzer is being a bit overzealous? FWIW, the code was likely taken as an analog to gcc/config/i386/pmm_malloc.h: -- if (__alignment == 1) return malloc (__size); if (__alignment == 2 || (sizeof (void *) == 8 && __alignment == 4)) __alignment = sizeof (void *); if (posix_memalign (&__ptr, __alignment, __size) == 0) return __ptr; --
[Bug target/103605] [PowerPC] fmin/fmax should be inlined always with xsmindp/xsmaxdp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103605
--- Comment #3 from pc at gcc dot gnu.org ---
Here's a test which exercises all three options:
- fmin () (glibc 2.28)
- xsmincdp (ironically, via __builtin_vsx_xsmindp)
- xsmindp (via asm)
--
$ cat xsmindp.c
#include
#include
int main (int argc) {
double d0 = argc, d1 = argc+1;
double rf, rb, rx;
printf ("(src1, src2): fmin b-in asm\n");
rf = fmin (d0, d1);
rb = __builtin_vsx_xsmindp (d0, d1);
asm ("xsmindp %0,%1,%2" : "=wa" (rx) : "wa" (d0), "wa" (d1));
printf ("(+3.0, +3.0): %+3.1f %+3.1f %+3.1f\n", rf, rb, rx);
d1 = NAN;
rf = fmin (d0, d1);
rb = __builtin_vsx_xsmindp (d0, d1);
asm ("xsmindp %0,%1,%2" : "=wa" (rx) : "wa" (d0), "wa" (d1));
printf ("(+3.0, NAN): %+3.1f %+3.1f %+3.1f\n", rf, rb, rx);
rf = fmin (d1, d0);
rb = __builtin_vsx_xsmindp (d1, d0);
asm ("xsmindp %0,%1,%2" : "=wa" (rx) : "wa" (d1), "wa" (d0));
printf ("( NAN, +3.0): %+3.1f %+3.1f %+3.1f\n", rf, rb, rx);
d0 = NAN;
rf = fmin (d0, d1);
rb = __builtin_vsx_xsmindp (d0, d1);
asm ("xsmindp %0,%1,%2" : "=wa" (rx) : "wa" (d0), "wa" (d1));
printf ("( NAN, NAN): %+3.1f %+3.1f %+3.1f\n", rf, rb, rx);
d0 = argc, d1 = argc+1;
d1 = __builtin_nans ("0");
rf = fmin (d0, d1);
rb = __builtin_vsx_xsmindp (d0, d1);
asm ("xsmindp %0,%1,%2" : "=wa" (rx) : "wa" (d0), "wa" (d1));
printf ("(+3.0, SNAN): %+3.1f %+3.1f %+3.1f\n", rf, rb, rx);
rf = fmin (d1, d0);
rb = __builtin_vsx_xsmindp (d1, d0);
asm ("xsmindp %0,%1,%2" : "=wa" (rx) : "wa" (d1), "wa" (d0));
printf ("(SNAN, +3.0): %+3.1f %+3.1f %+3.1f\n", rf, rb, rx);
d0 = __builtin_nans ("0");
rf = fmin (d0, d1);
rb = __builtin_vsx_xsmindp (d0, d1);
asm ("xsmindp %0,%1,%2" : "=wa" (rx) : "wa" (d0), "wa" (d1));
printf ("(SNAN, SNAN): %+3.1f %+3.1f %+3.1f\n", rf, rb, rx);
return 0;
}
$ /opt/gcc-nightly/trunk/bin/gcc --version
gcc (GCC) 12.0.1 20220426 (experimental) [remotes/origin/HEAD
r12-8269-gcd4acb8cd9]
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ /opt/gcc-nightly/trunk/bin/gcc -fsignaling-nans -D_WANT_SNAN -o xsmindp
xsmindp.c -O0 -lm && ./xsmindp
(src1, src2): fmin b-in asm
(+3.0, +3.0): +1.0 +1.0 +1.0
(+3.0, NAN): +1.0 +nan +1.0
( NAN, +3.0): +1.0 +1.0 +1.0
( NAN, NAN): +nan +nan +nan
(+3.0, SNAN): +nan +nan +nan
(SNAN, +3.0): +nan +1.0 +nan
(SNAN, SNAN): +nan +nan +nan
$ /opt/gcc-nightly/trunk/bin/gcc -fsignaling-nans -D_WANT_SNAN -o xsmindp
xsmindp.c -O3 -mcpu=power10 -lm && ./xsmindp
(src1, src2): fmin b-in asm
(+3.0, +3.0): +1.0 +1.0 +1.0
(+3.0, NAN): +1.0 +nan +1.0
( NAN, +3.0): +1.0 +nan +1.0
( NAN, NAN): +nan +nan +nan
(+3.0, SNAN): +nan +nan +nan
(SNAN, +3.0): +nan +1.0 +nan
(SNAN, SNAN): +nan +nan +nan
$ /opt/gcc-nightly/trunk/bin/gcc -fsignaling-nans -D_WANT_SNAN -o xsmindp
xsmindp.c -O3 -mcpu=power10 -lm -ffast-math && ./xsmindp
(src1, src2): fmin b-in asm
(+3.0, +3.0): +1.0 +1.0 +1.0
(+3.0, NAN): +nan +nan +1.0
( NAN, +3.0): +nan +nan +1.0
( NAN, NAN): +nan +nan +nan
(+3.0, SNAN): +nan +nan +nan
(SNAN, +3.0): +nan +nan +nan
(SNAN, SNAN): +nan +nan +nan
--
Without -ffast-math, the current semantics of fmin() match those of xsmindp.
With -ffast-math, the current semantics of fmin() match those of xsmincdp.
[Bug target/103605] [PowerPC] fmin/fmax should be inlined always with xsmindp/xsmaxdp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103605 --- Comment #5 from pc at gcc dot gnu.org --- I modified the testcase from comment #3 to clear-before and check-after FE_INVALID exception bit for each operation: -- $ /opt/gcc-nightly/trunk/bin/gcc -O2 -o xsmindp-test xsmindp-test.c xsmindp.c -lm && ./xsmindp-test a b (src1, src2): fmin:I b-in:I asm:I (+3.0, +3.0): +3.0;0 +3.0;0 +3.0;0 (+3.0, NAN): +3.0;0 +nan;0 +3.0;0 ( NAN, +3.0): +3.0;0 +3.0;0 +3.0;0 ( NAN, NAN): +nan;0 +nan;0 +nan;0 (+3.0, SNAN): +nan;1 +nan;1 +nan;1 (SNAN, +3.0): +nan;1 +3.0;1 +nan;1 (SNAN, SNAN): +nan;1 +nan;1 +nan;1 $ /opt/gcc-nightly/trunk/bin/gcc -O2 -ffast-math -o xsmindp-test xsmindp-test.c xsmindp.c -lm && ./xsmindp-test a b (src1, src2): fmin:I b-in:I asm:I (+3.0, +3.0): +3.0;0 +3.0;0 +3.0;0 (+3.0, NAN): +nan;0 +nan;0 +3.0;0 ( NAN, +3.0): +3.0;0 +3.0;0 +3.0;0 ( NAN, NAN): +nan;0 +nan;0 +nan;0 (+3.0, SNAN): +nan;1 +nan;1 +nan;1 (SNAN, +3.0): +3.0;1 +3.0;1 +nan;1 (SNAN, SNAN): +nan;1 +nan;1 +nan;1 -- Without -ffast-math, fmin() matches xsmindp. With -ffast-math, fmin() matches xsmincdp.
[Bug ipa/102059] Incorrect always_inline diagnostic in LTO mode with #pragma GCC target("cpu=power10")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102059 pc at gcc dot gnu.org changed: What|Removed |Added CC||pc at gcc dot gnu.org --- Comment #27 from pc at gcc dot gnu.org --- There was a commit related to this bug, but it is still in ASSIGNED state, so I'm not sure if this was to be considered "fixed", but... Chip discovered that, with a build of today's trunk, the original test case, and at least gcc.target/powerpc/pr102059-1.c still fail (I didn't try others), and it seems to be related to the presence of "-flto": -- $ gcc -c gcc/testsuite/gcc.target/powerpc/pr102059-1.c -O2 -mcpu=power8 -Wno-attributes -flto gcc/testsuite/gcc.target/powerpc/pr102059-1.c: In function 'bar': gcc/testsuite/gcc.target/powerpc/pr102059-1.c:8:1: error: inlining failed in call to 'always_inline' 'foo': target specific option mismatch 8 | foo (int *b) | ^~~ gcc/testsuite/gcc.target/powerpc/pr102059-1.c:18:8: note: called from here 18 | *a = foo (a); |^~~ $ gcc -c gcc/testsuite/gcc.target/powerpc/pr102059-1.c -O2 -mcpu=power8 -Wno-attributes $ -- The testcases included with the commit do not use "-flto", so these tests are PASSing.
[Bug target/104257] rs6000/*intrin.h headers using non-uglified automatic variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104257 pc at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pc at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-02-17
[Bug testsuite/103545] [12 regression] gcc.target/powerpc/undef-bool-2.c fails after r12-5580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103545 pc at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pc at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||pc at gcc dot gnu.org --- Comment #2 from pc at gcc dot gnu.org --- Fixed on trunk (commit above).
[Bug target/103605] New: [PowerPC] fmin/fmax should be inlined always with xsmindp/xsmaxdp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103605 Bug ID: 103605 Summary: [PowerPC] fmin/fmax should be inlined always with xsmindp/xsmaxdp Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pc at gcc dot gnu.org Target Milestone: --- -- $ gcc --version gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-2) [...] $ gcc -c -O2 fmin.c && objdump -dr fmin.o 0: 00 00 4c 3c addis r2,r12,0 0: R_PPC64_REL16_HA .TOC. 4: 00 00 42 38 addir2,r2,0 4: R_PPC64_REL16_LO .TOC.+0x4 8: a6 02 08 7c mflrr0 c: 10 00 01 f8 std r0,16(r1) 10: e1 ff 21 f8 stdur1,-32(r1) 14: 01 00 00 48 bl 14 14: R_PPC64_REL24 fmin 18: 00 00 00 60 nop 1c: 20 00 21 38 addir1,r1,32 20: 10 00 01 e8 ld r0,16(r1) 24: a6 03 08 7c mtlrr0 28: 20 00 80 4e blr $ gcc -c -O2 fmin.c -ffast-math && objdump -dr fmin.o 0: 40 14 21 f0 xsmincdp vs1,vs1,vs2 4: 20 00 80 4e blr -- And it appears that a better instruction choice in the above case is xsmindp, and it can be used with and without "-ffast-math", as it matches the semantics required of fmin. Similarly, xsmaxdp with fmax.
[Bug target/103605] [PowerPC] fmin/fmax should be inlined always with xsmindp/xsmaxdp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103605
--- Comment #1 from pc at gcc dot gnu.org ---
$ cat fmin.c
#include
double fm (double d0, double d1) {
return fmin (d0, d1);
}
[Bug testsuite/105620] [13 regression] g++.dg/tsan/pr88018.C fails after r13-456-geccbd7fcee5bbf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105620
pc at gcc dot gnu.org changed:
What|Removed |Added
CC||pc at gcc dot gnu.org
--- Comment #1 from pc at gcc dot gnu.org ---
gcc/testsuite/g++.dg/tsan/pr88018.C includes one of the files moved in the
patch:
```
// { dg-skip-if "" { *-*-* } { "*" } { "-O0" } }
// { dg-options "-fsanitize=thread -fno-ipa-pure-const -O1
-fno-inline-functions-called-once -w" }
#include "../pr69667.C"
```
I admit ignorance on the meaning or importance of the directory structure here.
Indeed the patch which moved pr69667.C was a small attempt to clean things up a
bit.
Would it be correct to move this test from g++.dg/tsan to g++.target/powerpc ?
(Or, do I need to move pr69667.C back to its original location? Or, do I need
to update the path within pr88018.C, which seems like the worst option?)
Did I miss this because I used `--disable-libsanitizer`, or because I just
missed that there was a FAIL for a test which I mistakenly thought was
unrelated to my changes? (There are a lot of FAILs to ignore.)
[Bug testsuite/105620] [13 regression] g++.dg/tsan/pr88018.C fails after r13-456-geccbd7fcee5bbf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105620 pc at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-05-18 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug target/104257] rs6000/*intrin.h headers using non-uglified automatic variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104257 pc at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from pc at gcc dot gnu.org --- Fixed on trunk (in gcc-12 window, including a subsequent fix for the fix by Jakub (Thanks!)), backported (without the issue requiring the subsequent fix) to gcc-11 and gcc-10. Closing.
[Bug testsuite/105620] [13 regression] g++.dg/tsan/pr88018.C fails after r13-456-geccbd7fcee5bbf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105620 pc at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from pc at gcc dot gnu.org --- Revert of the move of the file that caused this issue has been pushed to trunk. Marking as FIXED.
