[Bug driver/109627] New: [PATCH] driver: Extend 'getenv' function to allow default value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109627
Bug ID: 109627
Summary: [PATCH] driver: Extend 'getenv' function to allow
default value
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: keithp at keithp dot com
Target Milestone: ---
Created attachment 54918
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54918&action=edit
Patch implementing proposed change
Right now, a missing environment variable provided to the 'getenv'
function in a .specs file causes a fatal error. That makes writing a
spec file that uses the GCC_EXEC_PREFIX value difficult as that
variable is only set when the driver has been relocated, but not when
run from the defined location. This makes building a relocatable
toolchain difficult to extend to other ancilary pieces which use specs
files to locate header and library files adjacent to the toolchain.
This patch adds an optional third argument to the getenv function that
can be used to fall back to the standard installation path when the
driver hasn't set GCC_EXEC_PREFIX in the environment.
For example, if an alternate C library is installed in
${prefix}/extra, then this change allows the specs file to locate that
relative to the gcc directory, if gcc is located in the original
installation directory (which would leave GCC_EXEC_PREFIX unset), or
if the gcc tree has been moved to a different location (where gcc
would set GCC_EXEC_PREFIX itself):
*cpp:
-isystem %:getenv(GCC_EXEC_PREFIX ../../extra/include ${prefix}/extra/include)
I considered changing the behavior of either the %R sequence so that
it had a defined behavior when there was no sysroot defined, or making
the driver always set the GCC_EXEC_PREFIX environment variable and
decided that the approach of adding functionality to getenv where it
was previously invalid would cause the least potential for affecting
existing usage.
[Bug driver/109627] [PATCH] driver: Extend 'getenv' function to allow default value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109627 --- Comment #1 from keithp at keithp dot com --- This patch was submitted to the mailing list here: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600452.html
[Bug libstdc++/110574] --enable-cstdio=stdio_pure is incompatible with LFS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110574 --- Comment #5 from keithp at keithp dot com --- Seems like using fseeko would be a reasonable choice here -- while it's not in ISO C, it is in POSIX 2017.
[Bug c/113795] New: armv8.1m-m.main+pacbti -mbranch-protection=standard -O2 compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113795
Bug ID: 113795
Summary: armv8.1m-m.main+pacbti -mbranch-protection=standard
-O2 compile error
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: keithp at keithp dot com
Target Milestone: ---
Created attachment 57348
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57348&action=edit
Reasonably short test case.
A tail-call indirect branch is miscompiled in the attached example.
Without -mbranch-protection=standard:
```
.L2:
ldr r4, .L25+4
movsr0, #0
ldr r4, [r4, #24]
mov ip, r4
str r4, [sp, #4]
add sp, sp, #28
@ sp needed
pop {r4, r5, r6, r7, r8, r9, r10, fp, lr}
bx ip
```
With -mbranch-protection=standard:
```
.L2:
movsr0, #0
ldr r4, .L25+4
ldr r4, [r4, #24]
str r4, [sp, #4]
add sp, sp, #24
@ sp needed
pop {r4, r5, r6, r7, r8, r9, r10, fp, ip, lr}
aut ip, lr, sp
bx ip
```
Note that in the latter example, the `ip` register doesn't get copied from
`r4`, presumably because `ip` gets clobbered by the PAC operation. That leaves
the indirect branch at the end jumping to a random address.
[Bug c/113795] armv8.1m-m.main+pacbti -mbranch-protection=standard -O2 compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113795 --- Comment #1 from keithp at keithp dot com --- compiler command: arm-none-eabi-gcc \ -std=c18 \ -O2 \ -mthumb \ -march=armv8.1-m.main+pacbti+fp \ -mbranch-protection=standard \ -o \ bar.s \ -S \ bar.c
[Bug c/113795] armv8.1m-m.main+pacbti -mbranch-protection=standard -O2 compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113795 keithp at keithp dot com changed: What|Removed |Added Version|13.2.1 |14.0 --- Comment #2 from keithp at keithp dot com --- Just reproduced this with version 14.0.1 (debian unstable arm-linux-gnueabi-gcc-14 package)
[Bug libgcc/116017] New: libgcc/riscv/softfp: Fix loss of sign when truncating NaN values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116017
Bug ID: 116017
Summary: libgcc/riscv/softfp: Fix loss of sign when truncating
NaN values
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: keithp at keithp dot com
Target Milestone: ---
Created attachment 58714
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58714&action=edit
Proposed patch
Using soft float to truncate 128-bit -nan to 64-bit float loses the sign bit.
When _FP_KEEP_NANFRACP is not set, the fraction *and sign* of a NaN value are
discarded in _FP_PACK_SEMIRAW causing this problem.
I'll note that riscv is the only target which doesn't set this value, so it
could also be that the _FP_KEEPNANFRACP code is just broken?
Test application:
#include
#include
int main(void)
{
volatile long doubleld;
volatile double d;
ld = (long double) NAN;
ld = -ld;
d = ld;
printf("%a\n", d);
return signbit(d) ? 0 : 1;
}
[Bug libgcc/116017] libgcc/riscv/softfp: Fix loss of sign when truncating NaN values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116017
--- Comment #5 from keithp at keithp dot com ---
You're quite correct; conversion from double to float also loses the sign bit.
It never occurred to me that RISC-V would be different from every other GCC
target in this regard. I'll go stick a whole pile of risc-v specific code where
I needs to preserve the sign; I'm glad I don't also have to preserve the
significand. Yay for standards!
Soft float, double, long double:
test/test-nansign_rv64imac_lp64
ld: -nan (sign 1) d: nan (sign 0) f: nan (sign 0)
Hard float, soft double, long double:
test/test-nansign_rv64imafc_lp64f
ld: -nan (sign 1) d: nan (sign 0) f: nan (sign 0)
Hard float, hard double, soft long double:
test/test-nansign_rv64ifd_lp64d
ld: -nan (sign 1) d: nan (sign 0) f: nan (sign 0)
Here's the code which generated the above:
#define __STDC_WANT_IEC_60559_BFP_EXT__
#include
#include
#include
int main(void)
{
volatile long doubleld;
volatile double d;
volatile float f;
int ldbit, dbit, fbit;
charldstr[64];
chardstr[64];
charfstr[64];
ld = (long double) NAN;
ld = -ld;
ldbit = signbit(ld);
strfroml(ldstr, sizeof(ldstr), "%a", ld);
d = (double) ld;
dbit = signbit(d);
strfromd(dstr, sizeof(dstr), "%a", d);
d = (double) NAN;
d = -d;
f = (float) d;
fbit = signbit(f);
strfromf(fstr, sizeof(fstr), "%a", f);
printf("ld: %s (sign %d) d: %s (sign %d) f: %s (sign %d)\n",
ldstr, ldbit, dstr, dbit, fstr, fbit);
if (ldbit == 0 || dbit == 0 || fbit == 0)
return 1;
return 0;
}
[Bug c/120375] New: arc: -mcpu=em x >> 31 clobber of CC isn't respected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120375 Bug ID: 120375 Summary: arc: -mcpu=em x >> 31 clobber of CC isn't respected Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: keithp at keithp dot com Target Milestone: --- Created attachment 61486 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61486&action=edit foo.c source demonstrating arc nobs condition code bug Commit 3ceb109fcb045de9d78b650112399bbb7df78cdc improved code generated for shift operations on targets without a barrel shifter (-mcpu=em). For unsigned right shift by 31, this new code generates: add.f 0,r0,r0 rlc r0,0 This clobbers the condition codes, but the RTL matched for this operation doesn't include (clobber (reg:CC CC_REG)). If CC is used again, it will contain this new value. The attached test case is built with: $ gcc -mcpu=em -O2 -S foo.c -fverbose-asm -fno-delayed-branch (-fno-delayed-branch makes the asm easier to read, but the bug still occurs without it). The relevant assembly is here: # foo.c:15: if (mag > 0x7f80) brgtr3,2139095040,.L8 #, _13,, # foo.c:12: int sign = (x >> 31) & 1; add.f 0,r0,r0 # _9, _9 rlc r0,0# _2 # foo.c:17: if (mag == 0x7f80) beq_s .L9 #, Note that the first compare-and-branch is compressed to a single instruction which doesn't affect the flags. I think this is because that conversion is done *after* the shift operation is split into add.f; rlc and the condition codes are marked as clobbered. I tried adding a clobber constraint to the "si3_nobs" insn in arc.md but that causes the compiler to fail to match this insn.
[Bug c/120375] arc: -mcpu=em x >> 31 clobber of CC isn't respected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120375 --- Comment #1 from keithp at keithp dot com --- gcc was configured as follows: ./configure --enable-languages=c,c++,lto --enable-multilib --enable-multilib-space --disable-gcov --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --enable-tls --target=arc-zephyr-elf --with-system-zlib --with-gnu-as --with-gnu-ld --without-included-gettext --prefix=/opt/arc-zephyr-elf --disable-libstdcxx --with-headers=no --without-newlib AR_FOR_TARGET=arc-zephyr-elf-ar AS_FOR_TARGET=arc-zephyr-elf-as LD_FOR_TARGET=arc-zephyr-elf-ld NM_FOR_TARGET=arc-zephyr-elf-nm OBJDUMP_FOR_TARGET=arc-zephyr-elf-objdump RANLIB_FOR_TARGET=arc-zephyr-elf-ranlib READELF_FOR_TARGET=arc-zephyr-elf-readelf STRIP_FOR_TARGET=arc-zephyr-elf-strip SED=/bin/sed SHELL=/bin/bash BASH=/bin/bash CONFIG_SHELL=/bin/bash
[Bug target/120375] arc: -mcpu=em x >> 31 clobber of CC isn't respected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120375 --- Comment #2 from keithp at keithp dot com --- Created attachment 61509 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61509&action=edit arc: Clobber CC and LP when shifting without barrel shifter Devices without a barrel shifter end up using a sequence of instructions. These can use the condition codes and/or loop count register, so those need to be marked as 'clobbered'. Signed-off-by: Keith Packard
