The prototype of __sprintfkf in _sprintfkf.h did not match the function in
_sprintfkf.c. This patch fixes the prototype. I also included the
_sprintfkf.h file in _sprintfkf.c to make sure the prototype is correct and to
eliminate a warning about declaring the function without a previous
declaration.
libgcc/
2021-03-01 Michael Meissner <meissner@linux.ibm.com>
* config/rs6000/_sprintfkf.h (__sprintfkf): Fix prototype to match
the function.
* config/rs6000/_sprintfkf.c: Include _sprintfkf.h.
When these functions are called with integer minimum, there is UB on the libgcc
side. Fixed in the obvious way, the code in the end wants ABSU_EXPR behavior.
2021-02-24 Jakub Jelinek <jakub@redhat.com>
PR libgcc/99236
* libgcc2.c (__powisf2, __powidf2, __powitf2, __powixf2): Perform
negation of m in unsigned type.
As discussed in the PR, the Makefile fragment lacks a double '$' to
get the return-code from GCC invocation, resulting is CMSE support
missing from multilibs.
I checked that the simple patch proposed in the PR fixes the problem.
2021-02-23 Christophe Lyon <christophe.lyon@linaro.org>
Hau Hsu <hsuhau617@gmail.com>
PR target/99157
libgcc/
* config/arm/t-arm: Fix cmse support detection.
This patch implements conversions between _Float128 and the 3 Decimal floating
types. It does this by extendending the dfp-bit conversions to add a new
binary floating point type (KF), and doing the conversions in the same manner
as the other binary/decimal conversions.
For conversions from _Float128 to Decimal, this patch uses a function
(__sprintfkf) instead of the sprintf function to convert long double values to
strings. The __sprintfkf function determines if GLIBC 2.32 or newer is used
and calls the IEEE 128-bit version of sprintf (__sprintfieee128). If the GLIBC
is earlier than 2.32, the code will convert _Float128 to __ibm128 and then use
the normal sprintf to convert this value.
For conversions from Decimal to _Float128, this patch uses a function
(__strtokf) instead of strtold to convert the strings from the Decimal
conversion to long double. The __strtokf function determines if GLIBC 2.32 or
newer is used, and if it is, calls the IEEE 128-bit version (__strtoieee128).
If the GLIBC is earlier than 2.32, the code will call strtold and convert the
__ibm128 value to _Float128.
These functions will primarily be used if/when the default PowerPC long double
type is changed to IEEE 128-bit, but they could also be used if the user
explicitly converts _Float128 to/from a Decimal type.
libgcc/
2021-02-22 Michael Meissner <meissner@linux.ibm.com>
* config/rs6000/_dd_to_kf.c: New file.
* config/rs6000/_kf_to_dd.c: New file.
* config/rs6000/_kf_to_sd.c: New file.
* config/rs6000/_kf_to_td.c: New file.
* config/rs6000/_sd_to_kf.c: New file.
* config/rs6000/_sprintfkf.c: New file.
* config/rs6000/_sprintfkf.h: New file.
* config/rs6000/_strtokf.h: New file.
* config/rs6000/_strtokf.c: New file.
* config/rs6000/_td_to_kf.c: New file.
* config/rs6000/quad-float128.h: Add new declarations.
* config/rs6000/t-float128 (fp128_dec_funcs): New macro.
(fp128_decstr_funcs): New macro.
(ibm128_dec_funcs): New macro.
(fp128_ppc_funcs): Add the new conversions.
(fp128_dec_objs): Force Decimal <-> __float128 conversions to be
compiled with -mabi=ieeelongdouble.
(fp128_decstr_objs): Force __float128 <-> string conversions to be
compiled with -mabi=ibmlongdouble.
(ibm128_dec_objs): Force Decimal <-> __float128 conversions to be
compiled with -mabi=ieeelongdouble.
(FP128_CFLAGS_DECIMAL): New macro.
(IBM128_CFLAGS_DECIMAL): New macro.
* dfp-bit.c (DFP_TO_BFP): Add PowerPC _Float128 support.
(BFP_TO_DFP): Add PowerPC _Float128 support.
* dfp-bit.h (BFP_KIND): Add new binary floating point kind for
IEEE 128-bit floating point.
(DFP_TO_BFP): Add PowerPC _Float128 support.
(BFP_TO_DFP): Add PowerPC _Float128 support.
(BFP_SPRINTF): New macro.
On Linux, GCC emits .note.GNU-stack sections when compiling code to mark
the code as not needing or needing executable stack, missing section means
unknown. But assembly files need to be marked manually. We already
mark various *.S files in libgcc manually, but the
avx_resms64f.o
avx_resms64fx.o
avx_resms64.o
avx_resms64x.o
avx_savms64f.o
avx_savms64.o
sse_resms64f.o
sse_resms64fx.o
sse_resms64.o
sse_resms64x.o
sse_savms64f.o
sse_savms64.o
files aren't marked, so when something links it in, it will require
executable stack. Nothing in the assembly requires executable stack though.
2021-01-27 Jakub Jelinek <jakub@redhat.com>
* config/i386/savms64.h: Add .note.GNU-stack section on Linux.
* config/i386/savms64f.h: Likewise.
* config/i386/resms64.h: Likewise.
* config/i386/resms64f.h: Likewise.
* config/i386/resms64x.h: Likewise.
* config/i386/resms64fx.h: Likewise.
libgcc/ChangeLog:
PR gcov-profile/98739
* libgcov.h (gcov_topn_add_value): Do not train when
we have a merged profile with a negative number of total
value.
This allows the openrisc softfloat implementation to set exceptions.
This also sets the correct tininess after rounding value to be
consistent with hardware and simulator implementations.
libgcc/ChangeLog:
* config/or1k/sfp-machine.h (FP_RND_NEAREST, FP_RND_ZERO,
FP_RND_PINF, FP_RND_MINF, FP_RND_MASK, FP_EX_OVERFLOW,
FP_EX_UNDERFLOW, FP_EX_INEXACT, FP_EX_INVALID, FP_EX_DIVZERO,
FP_EX_ALL): New constant macros.
(_FP_DECL_EX, FP_ROUNDMODE, FP_INIT_ROUNDMODE,
FP_HANDLE_EXCEPTIONS): New macros.
(_FP_TININESS_AFTER_ROUNDING): Change to 1.
When the application sets SA_SIGINFO, the signal trampoline parameters
are different to follow POSIX.
libgcc/
* config/i386/gnu-unwind.h (x86_gnu_fallback_frame_state): Add the
posix siginfo case to struct handler_args. Detect between legacy
and siginfo from the second parameter, which is a small sigcode in
the legacy case, and a pointer in the siginfo case.
If you use a compiler with long double defaulting to 64-bit instead of 128-bit
with IBM extended double, you get linker warnings about mis-matches in the gnu
attributes for long double (PR libgcc/97543). Even if the compiler is
configured to have long double be 64 bit as the default with the configuration
option '--without-long-double-128' you get the warnings.
You also get the same issues if you use a compiler with long double defaulting
to IEEE 128-bit instead of IBM extended double (PR libgcc/97643).
The issue is the way libgcc.a/libgcc.so is built. Right now when building
libgcc under Linux, the long double size is set to 128-bits when building
libgcc. However, the gnu attributes are set, leading to the warnings.
One feature of the current GNU attribute implementation is if you have a shared
library (such as libgcc_s.so), the GNU attributes for the shared library is an
inclusive OR of all of the objects within the library. This means if any
object file that uses the -mlong-double-128 option and uses long double, the GNU
attributes for the library will indicate that it uses 128-bit IBM long
doubles. If you have a static library, you will get the warning only if you
actually reference an object file with the attribute set.
This patch does two things:
1) All of the object files that support IBM 128-bit long doubles
explicitly set the ABI to IBM extended double.
2) I turned off GNU attributes for building the shared library or for
building the IBM 128-bit long double support.
libgcc/
2020-12-03 Michael Meissner <meissner@linux.ibm.com>
PR libgcc/97543
PR libgcc/97643
* config/rs6000/t-linux (IBM128_STATIC_OBJS): New make variable.
(IBM128_SHARED_OBJS): New make variable.
(IBM128_OBJS): New make variable. Set all objects to use the
explicit IBM format, and disable gnu attributes.
(IBM128_CFLAGS): New make variable.
(gcc_s_compile): Add -mno-gnu-attribute to all shared library
modules.
This patch introduces maybe_emit_call_builtin___clear_cache for the
builtin expander machinery and the trampoline initializers to use to
clear the instruction cache, removing a source of inconsistencies and
subtle errors in low-level machinery.
I've adjusted all trampoline_init implementations that used to issue
explicit calls to __clear_cache or similar to use this new primitive.
Specifically on vxworks targets, we needed to drop the __clear_cache
symbol in libgcc, for reasons related with linking that I didn't need
to understand, and we wanted to call cacheTextUpdate directly, despite
the different calling conventions: the second argument is a length
rather than the end address.
So I introduced a target hook to enable target OS-level overriding of
builtin __clear_cache call emission, retaining nearly (*) the same
logic to govern the decision on whether to emit a call (or nothing, or
a machine-dependent insn) but enabling a call to a target
system-defined function with different calling conventions to be
issued, without having to modify .md files of the various
architectures supported by the target system to introduce or modify
clear_cache insns.
(*) I write "nearly" mainly because, when not optimizing, we'd issue a
call regardless, but since the call may now be overridden, I added it
to the set of builtins that are not directly turned into calls when
not optimizing, following the normal expansion path instead. It
wouldn't be hard to skip the emission of cache-clearing insns when not
optimizing, but it didn't seem very important, especially for the new
uses from trampoline init.
Another difference that might be relevant is that now we expand
the begin and end arguments unconditionally. This might make a
difference if they have side effects. That's prettty much impossible
at expand time, but I thought I'd mention it.
I have NOT modified targets that did not issue cache-clearing calls in
trampoline init to use the new clear_cache-calling infrastructure even
if it would expand to nothing. I have considered doing so, to have
__builtin___clear_cache and trampoline init call cacheTextUpdate on
all vxworks targets, but decided not to, since on targets that don't
do any cache clearing, cacheTextUpdate ought to be a no-op, even
though rs6000 seems to use icbi and dcbf instructions in the function
called to initialize a trampoline, but AFAICT not in the __clear_cache
builtin. Hopefully target maintainers will have a look and take
advantage of this new piece of infrastructure to remove such
(apparent?) inconsistencies. Not rs6000 and other that call asm-coded
trampoline setup instructions, for sure, but they might wish to
introduce a CLEAR_INSN_CACHE macro or a clear_cache expander if they
don't have one.
for gcc/ChangeLog
* builtins.c (default_emit_call_builtin___clear_cache): New.
(maybe_emit_call_builtin___clear_cache): New.
(expand_builtin___clear_cache): Split into the above.
(expand_builtin): Do not issue clear_cache call any more.
* builtins.h (maybe_emit_call_builtin___clear_cache): Declare.
* config/aarch64/aarch64.c (aarch64_trampoline_init): Use
maybe_emit_call_builtin___clear_cache.
* config/arc/arc.c (arc_trampoline_init): Likewise.
* config/arm/arm.c (arm_trampoline_init): Likewise.
* config/c6x/c6x.c (c6x_initialize_trampoline): Likewise.
* config/csky/csky.c (csky_trampoline_init): Likewise.
* config/m68k/linux.h (FInALIZE_TRAMPOLINE): Likewise.
* config/tilegx/tilegx.c (tilegx_trampoline_init): Likewise.
* config/tilepro/tilepro.c (tilepro_trampoline_init): Ditto.
* config/vxworks.c: Include rtl.h, memmodel.h, and optabs.h.
(vxworks_emit_call_builtin___clear_cache): New.
* config/vxworks.h (CLEAR_INSN_CACHE): Drop.
(TARGET_EMIT_CALL_BUILTIN___CLEAR_CACHE): Define.
* target.def (trampoline_init): In the documentation, refer to
maybe_emit_call_builtin___clear_cache.
(emit_call_builtin___clear_cache): New.
* doc/tm.texi.in: Add new hook point.
(CLEAR_CACHE_INSN): Remove duplicate 'both'.
* doc/tm.texi: Rebuilt.
* targhooks.h (default_meit_call_builtin___clear_cache):
Declare.
* tree.h (BUILTIN_ASM_NAME_PTR): New.
for libgcc/ChangeLog
* config/t-vxworks (LIB2ADD): Drop.
* config/t-vxworks7 (LIB2ADD): Likewise.
* config/vxcache.c: Remove.
Disable USE_PT_GNU_EH_FRAME frame unwinder support for old OS versions,
fixing compilation errors:
.../libgcc/unwind-dw2-fde-dip.c:75:21: error: unknown type name 'Elf_Phdr'
75 | # define ElfW(type) Elf_##type
| ^~~~
.../libgcc/unwind-dw2-fde-dip.c:132:9: note: in expansion of macro 'ElfW'
132 | const ElfW(Phdr) *p_eh_frame_hdr;
| ^~~~
.../libgcc/unwind-dw2-fde-dip.c:75:21: error: unknown type name 'Elf_Phdr'
75 | # define ElfW(type) Elf_##type
| ^~~~
.../libgcc/unwind-dw2-fde-dip.c:133:9: note: in expansion of macro 'ElfW'
133 | const ElfW(Phdr) *p_dynamic;
| ^~~~
.../libgcc/unwind-dw2-fde-dip.c:165:37: warning: 'struct dl_phdr_info' declared inside parameter list will not be visible outside of this definition or declaration
165 | _Unwind_IteratePhdrCallback (struct dl_phdr_info *info, size_t size, void *ptr)
| ^~~~~~~~~~~~
[...]
and producing a working cross-compiler at least with VAX/NetBSD 1.6.2.
libgcc/
* unwind-dw2-fde-dip.c [__OpenBSD__ || __NetBSD__]
(USE_PT_GNU_EH_FRAME): Do not define if !TARGET_DL_ITERATE_PHDR.
Hardware multipliers that support widening 32-bit multiplication can
be used to perform a 64-bit * 64-bit multiplication more efficiently
than a software implementation.
The following equation is used to perform 64-bit multiplication for
devices with "32bit" or "f5series" hardware multiply versions:
64bit_result = (low32_op0 * lop32_op1)
+ ((low32_op0 * high32_op1) << 32)
+ ((high32_op0 * low32_op1) << 32)
libgcc/ChangeLog:
* config/msp430/lib2hw_mul.S (mult64_hw): New.
(if MUL_32): Use mult64_hw for __muldi3.
(if MUL_F5): Use mult64_hw for __muldi3.
* config/msp430/lib2mul.c (__muldi3): New.
* config/msp430/t-msp430 (LIB2FUNCS_EXCLUDE): Define.
This patch retires ppc64-fp.c in favour of using
"LIB2_SIDITI_CONV_FUNCS = yes", which is a lot better solution than
having a copy of selected libgcc2.c functions.
* config/rs6000/t-ppc64-fp (LIB2ADD): Delete.
(LIB2_SIDITI_CONV_FUNCS): Define.
* config/rs6000/ppc64-fp.c: Delete file.
The naming scheme used by GCC to reference MSP430 hardware multiply
library functions is inconsistent.
Sometimes the "GCC" names (e.g. mulsi2) are used, other times the
"MSPABI" names (e.g. __mspabi_mpyl) are used.
Also, sometimes an identifier for the hardware multiply support is
appended to the GCC name, when the functions are defined, but this is
not required.
This patch fixes those issues, so the names used to refer to the
hardware multiply library functions follow a consistent pattern.
gcc/ChangeLog:
* config/msp430/msp430.c (msp430_output_labelref): Don't process mspabi
hwmult library function names into GCC-style names.
libgcc/ChangeLog:
* config/msp430/lib2hw_mul.S: Omit _hw* suffix from GCC names for
hwmult library functions.
gcc/testsuite/ChangeLog:
* gcc.target/msp430/rtx-cost-Os-f5series.c: Adjust test to use new
hwmult library function name.
This adds ${cpu_type}/t-lse and t-slibgcc-libgcc to the tmake_file
list for aarch64-vxworks7* configurations, as the Linux port does.
t-lse is needed by all triplets now anyway and the standard setting
for slibgcc makes sense as we are working on reintroducing PIC support
for RTPs on various targets. The VxWorks7 system environments are leaning
towards more and more similarilties with Linux in general, so the
closer configurations the better.
2020-11-02 Pat Bernardi <bernardi@adacore.com>
libgcc/
* config.host (aarch64-vxworks7*, tmake_file): Add
${cpu_type}/t-lse and t-slibgcc-libgcc.
Co-authored-by: Olivier Hainque <hainque@adacore.com>
Previously, the SEH version of _Unwind_Backtrace did unwind
the stack and call the provided callback function as intended,
but there was little the caller could do within the callback to
actually get any info about that particular level in the unwind.
Set the ra and cfa pointers, which are used by _Unwind_GetIP
and _Unwind_GetCFA, to allow using these functions from the
callacb to inspect the state at each stack frame.
2020-09-08 Martin Storsjö <martin@martin.st>
libgcc/
* unwind-seh.c (_Unwind_Backtrace): Set the ra and cfa pointers
before calling the callback.
This change extends the VxWorks support on intel CPUs to
VxWorks7r2 for x86_64 as well as x86, with a "mcmodel=large"
additional multilib for the 64bit configuration.
The support for fPIC is not functional yet for this model,
so we just don't add the corresponding multilib.
We extend the range of CPU families handled by TARGET_OS_CPP_BUILTINS,
accounting for the fact that archs older than PENTIUM4 are
not supported (any more) by VxWorks 7.
As we did for powerpc, we leverage VX_CPU_PREFIX to emit different
forms of definitions for different families of VxWorks as the system
headers's expectations has evolved between Vx 5, 6 and 7.
2020-10-27 Olivier Hainque <hainque@adacore.com>
gcc/
* config.gcc: Adjust the ix86/x86_64-wrs-vxworks filters
to apply to VxWorks 7 as well.
* config/i386/t-vxworks (MULTILIB_OPTIONS, MULTILIB_DIRNAMES):
Remove the fPIC multilib and add one for the large code model
on x86_64.
* config/i386/vxworks.h: Separate sections for TARGET_VXWORKS7,
other variants and common bits.
(TARGET_OS_CPP_BUILTINS): Augment to support a range of CPU
families. Leverage VX_CPU_PREFIX.
(CC1_SPEC): Add definition.
(STACK_CHECK_PROTECT): Use conditional expression instead of
heavier to read conditioned macro definitions.
libgcc/
* config.host: Adjust the ix86/x86_64-wrs-vxworks filters
to apply to VxWorks 7 as well.
Co-authored-by: Douglas Rupp <rupp@adacore.com>
Co-authored-by: Pat Bernardi <bernardi@adacore.com>
