aboutsummaryrefslogtreecommitdiff
path: root/libgcc/config
AgeCommit message (Collapse)AuthorFilesLines
2021-09-03libgcc, soft-float: Fix strong_alias macro use for Darwin.Iain Sandoe1-3/+17
Darwin does not support strong symbol aliases and a work- around is provided in sfp-machine.h where a second function is created that simply calls the original. However this needs the arguments to the synthesized function to track the mode of the original function. So the fix here is to match known floating point modes from the incoming function and apply the one found to the new function args. The matching is highly specific to the current set of modes and will need adjusting should more cases be added. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> libgcc/ChangeLog: * config/i386/sfp-machine.h (alias_HFtype, alias_SFtype alias_DFtype, alias_TFtype): New. (ALIAS_SELECTOR): New. (strong_alias): Use __typeof and a _Generic selector to provide the type to the synthesized function.
2021-09-02libgcc: Enable hfmode soft-sf/df/xf/tf extensions and truncations.liuhongt5-0/+9
libgcc/ChangeLog: * config/i386/32/sfp-machine.h (_FP_NANFRAC_H): New macro. * config/i386/64/sfp-machine.h (_FP_NANFRAC_H): Ditto. * config/i386/sfp-machine.h (_FP_NANSIGN_H): Ditto. * config/i386/t-softfp: Add hf soft-fp. * config.host: Add i386/64/t-softfp. * config/i386/64/t-softfp: New file.
2021-08-31libgcc: Add missing runtime exception noticesRichard Sandiford4-2/+19
Quoting from https://gcc.gnu.org/pipermail/gcc/2021-July/236716.html: -------------------------------------------------------------------- It was pointed out to me off-list that config/aarch64/value-unwind.h is missing the runtime exception. It looks like a few other files are too; a fuller list is: libgcc/config/aarch64/value-unwind.h libgcc/config/frv/frv-abi.h libgcc/config/i386/value-unwind.h libgcc/config/pa/pa64-hpux-lib.h Certainly for the aarch64 file this was simply a mistake; it seems to have been copied from the i386 version, both of which reference the runtime exception but don't actually include it. -------------------------------------------------------------------- Similarly, frv-abi.h referenced the exception but didn't include it. pa64-hpux-lib.h was missing any reference to the exception. The decision was that this was simply a mistake [https://gcc.gnu.org/pipermail/gcc/2021-July/236717.html]: -------------------------------------------------------------------- […] It generally is considered a textual omission. The runtime library components of GCC are intended to be licensed under the runtime exception, which was granted and approved at the time of introduction. -------------------------------------------------------------------- and that we should simply change all of the files above [https://gcc.gnu.org/pipermail/gcc/2021-July/236719.html]: -------------------------------------------------------------------- Please correct the text in the files. The files in libgcc used in the GCC runtime are intended to be licensed with the runtime exception and GCC previously was granted approval for that licensing and purpose. […] The runtime exception explicitly was intended for this purpose and usage at the time that GCC received approval to apply the exception. -------------------------------------------------------------------- libgcc/ * config/aarch64/value-unwind.h: Add missing runtime exception paragraph. * config/frv/frv-abi.h: Likewise. * config/i386/value-unwind.h: Likewise. * config/pa/pa64-hpux-lib.h: Likewise.
2021-08-26rs6000: inline ldouble __gcc_qsubDavid Edelsohn1-4/+10
While performing some tests of IEEE 128 float for PPC64LE, Michael Meissner noticed that __gcc_qsub is substantially slower than __gcc_qadd. __gcc_qsub calls __gcc_add with the second operand negated. Because the functions normally are invoked through libgcc shared object, the extra PLT overhead has a large impact on the overall time of the function. This patch converts __gcc_qadd to a static inline function invoked by __gcc_qadd and __gcc_qsub. libgcc/ChangeLog: * config/rs6000/ibm-ldouble.c (ldouble_qadd_internal): Rename from __gcc_qadd. (__gcc_qadd): Call ldouble_qadd_internal. (__gcc_qsub): Call ldouble_qadd_internal with second long double argument negated.
2021-08-26cygming-crtend.c: fix build warningsJonathan Yong1-0/+6
libgcc/Changelog: * config/i386/cygming-crtend.c: Fix register_frame_ctor and register_frame_dtor warnings. Signed-off-by: Jonathan Yong <10walls@gmail.com>
2021-08-24arm: add erratum mitigation to __gnu_cmse_nonsecure_call [PR102035]Richard Earnshaw1-0/+5
Add the recommended erratum mitigation sequence to __gnu_cmse_nonsecure_call for use on Armv8-m.main devices. Since this is in the library code we cannot know in advance whether the core we are running on will be affected by this, so always enable it. libgcc: PR target/102035 * config/arm/cmse_nonsecure_call.S (__gnu_cmse_nonsecure_call): Add vlldm erratum work-around.
2021-08-15or1k: Use cmodel=large when building crtstuffStafford Horne1-0/+2
When linking gcc runtime objects into large binaries the link may fail with the below errors. This will happen even if we are building with -mcmodel=large. /home/shorne/work/openrisc/output/host/lib/gcc/or1k-buildroot-linux-uclibc/10.3.0/crtbeginS.o: in function `deregister_tm_clones': crtstuff.c:(.text+0x3c): relocation truncated to fit: R_OR1K_GOT16 against undefined symbol `_ITM_deregisterTMCloneTable' /home/shorne/work/openrisc/output/host/lib/gcc/or1k-buildroot-linux-uclibc/10.3.0/crtbeginS.o: in function `register_tm_clones': crtstuff.c:(.text+0xc0): relocation truncated to fit: R_OR1K_GOT16 against undefined symbol `_ITM_registerTMCloneTable' This patch builds the gcc crtstuff binaries always with the -mcmodel=large option to ensure they can be linked into large binaries. libgcc/ChangeLog: PR target/99783 * config.host (or1k-*, tmake_file): Add or1k/t-crtstuff. * config/or1k/t-crtstuff: New file.
2021-08-05libgcc: Honor LDFLAGS_FOR_TARGET when linking libgcc_sJakub Jelinek4-5/+4
When building gcc with some specific LDFLAGS_FOR_TARGET, e.g. LDFLAGS_FOR_TARGET=-Wl,-z,relro,-z,now those flags propagate info linking of target shared libraries, e.g. lib{ubsan,tsan,stdc++,quadmath,objc,lsan,itm,gphobos,gdruntime,gomp,go,gfortran,atomic,asan}.so.* but there is one important exception, libgcc_s.so.* linking ignores it. The following patch fixes that. Bootstrapped/regtested on x86_64-linux with LDFLAGS_FOR_TARGET=-Wl,-z,relro,-z,now and verified that libgcc_s.so.* is BIND_NOW when it previously wasn't, and without any LDFLAGS_FOR_TARGET on x86_64-linux and i686-linux. There on x86_64-linux I've verified that the libgcc_s.so.1 linking command line for -m64 is identical except for whitespace to one without the patch, and for -m32 multilib $(LDFLAGS) actually do supply there an extra -m32 that also repeats later in the @multilib_flags@, which should be harmless. 2021-08-04 Jakub Jelinek <jakub@redhat.com> * config/t-slibgcc (SHLIB_LINK): Add $(LDFLAGS). * config/t-slibgcc-darwin (SHLIB_LINK): Likewise. * config/t-slibgcc-vms (SHLIB_LINK): Likewise. * config/t-slibgcc-fuchsia (SHLIB_LDFLAGS): Remove $(LDFLAGS).
2021-08-04libgcc: Fix duplicated content of config/t-slibgcc-fuchsiaJakub Jelinek1-22/+0
The file has two identical halves, seems like twice applied patch. 2021-08-04 Jakub Jelinek <jakub@redhat.com> * config/t-slibgcc-fuchsia: Undo doubly applied patch.
2021-07-15[POWER10] __morestack calls from pcrel codeAlan Modra1-0/+41
Compiling gcc/testsuite/gcc.dg/split-*.c and others with -mcpu=power10 and linking with a non-pcrel libgcc results in crashes due to the power10 pcrel code not having r2 set for the generic-morestack.c functions called from __morestack. There is also a problem when non-pcrel code calls a pcrel libgcc. See the patch comments. A similar situation theoretically occurs with ELFv1 multi-toc executables, when __morestack might be located in a different toc group to its caller. This patch makes no attempt to fix that, since the gold linker does not support multi-toc (gold is needed for proper support of -fsplit-stack code) nor does gcc emit __morestack calls that support multi-toc. * config/rs6000/morestack.S (R2_SAVE): Define. (__morestack): Save and restore r2. Set up r2 for called functions.
2021-06-29amdgcn: Enable support for TImode for AMD GCNJulian Brown4-0/+92
This patch enables support for TImode for AMD GCN, the lack of which is currently causing a number of test failures for the target and which is also needed to support "omp_depend_kind" for OpenMP 5.0, since that is implemented as a 128-bit integer. Several libgcc support routines are built by default for the "word size" of a machine, and also for "2 * word size" of the machine. The libgcc build for AMD GCN is changed so that it builds for a "word size" of 64 bits, in order to better match the (64-bit) host compiler. However it isn't really true that we have 64-bit words -- GCN has 32-bit registers, so changing UNITS_PER_WORD unconditionally would be the wrong thing to do. Changing this setting for libgcc (only) means that support routines are built for "single word" operations that are DImode (64 bits), and those for "double word" operations are built for TImode (128 bits). That leaves some gaps regarding previous operations that were built for a "single word" size of 32 bits and a "double word" size of 64 bits (generic code doesn't cover both alternatives for all operations that might be needed). Those gaps are filled in by this patch, or by the preceding patches in the series. 2021-06-18 Julian Brown <julian@codesourcery.com> gcc/ * config/gcn/gcn.c (gcn_init_libfuncs): New function. (TARGET_INIT_LIBFUNCS): Define target hook using above function. * config/gcn/gcn.h (UNITS_PER_WORD): Define to 8 for IN_LIBGCC2, 4 otherwise. (LIBGCC2_UNITS_PER_WORD, BITS_PER_WORD): Remove definitions. (MAX_FIXED_MODE_SIZE): Change to 128. libgcc/ * config/gcn/lib2-bswapti2.c: New file. * config/gcn/lib2-divmod-di.c: New file. * config/gcn/lib2-gcn.h (DItype, UDItype, TItype, UTItype): Add typedefs. (__divdi3, __moddi3, __udivdi3, __umoddi3): Add prototypes. * config/gcn/t-amdgcn (LIB2ADD): Add lib2-divmod-di.c and lib2-bswapti2.c.
2021-06-29amdgcn: Use unsigned types for udivsi3/umodsi3 libgcc helper args/returnJulian Brown2-6/+6
This patch changes the argument and return types for the libgcc __udivsi3 and __umodsi3 helper functions for GCN to USItype instead of SItype. This is probably just cosmetic in practice. 2021-06-18 Julian Brown <julian@codesourcery.com> libgcc/ * config/gcn/lib2-divmod.c (__udivsi3, __umodsi3): Change argument and return types to USItype. * config/gcn/lib2-gcn.h (__udivsi3, __umodsi3): Update prototypes.
2021-06-22rs6000: Fix typos in float128 ISA3.1 supportKewen Lin3-19/+10
The recent float128 ISA3.1 support (r12-1340) has some typos, it makes the libgcc build fail if it's with one binutils (assembler) which doesn't support Power10 insns. The error looks like: Error: invalid switch -mpower10 Error: unrecognized option -mpower10 ... [...libgcc/shared-object.mk:14: float128-p10.o] Error 1 What this patch does are: - fix test target typo libgcc_cv_powerpc_3_1_float128_hw (written wrongly as libgcc_cv_powerpc_float128_hw, so it's going to build ISA3.1 stuffs just when detecting ISA3.0). - fix test used for libgcc_cv_powerpc_3_1_float128_hw check. - fix test option used for libgcc_cv_powerpc_3_1_float128_hw check. - remove the ISA3.1 related contents from t-float128-hw. - add new macro FLOAT128_HW_INSNS_ISA3_1 to differentiate ISA3.1 content from ISA3.0 part in ifunc support. Bootstrapped/regtested on: - powerpc64le-linux-gnu P10 - powerpc64le-linux-gnu P9 (w/i and w/o p10 supported as) - powerpc64-linux-gnu P8 (w/i and w/o p10 supported as) libgcc/ChangeLog: * configure: Regenerate. * configure.ac (test for libgcc_cv_powerpc_3_1_float128_hw): Fix typos among the name, CFLAGS and the test. * config/rs6000/t-float128-hw (fp128_3_1_hw_funcs, fp128_3_1_hw_src, fp128_3_1_hw_static_obj, fp128_3_1_hw_shared_obj, fp128_3_1_hw_obj): Remove. * config/rs6000/t-float128-p10-hw (FLOAT128_HW_INSNS): Append macro FLOAT128_HW_INSNS_ISA3_1. (FP128_3_1_CFLAGS_HW): Fix option typo. * config/rs6000/float128-ifunc.c (SW_OR_HW_ISA3_1): Guard this with FLOAT128_HW_INSNS_ISA3_1. (__floattikf_resolve): Likewise. (__floatuntikf_resolve): Likewise. (__fixkfti_resolve): Likewise. (__fixunskfti_resolve): Likewise. (__floattikf): Likewise. (__floatuntikf): Likewise. (__fixkfti): Likewise. (__fixunskfti): Likewise.
2021-06-11arm: Fix the mve multilib for the broken cmse support (pr99939).Srinath Parvathaneni2-5/+4
The current CMSE support in the multilib build for "-march=armv8.1-m.main+mve -mfloat-abi=hard -mfpu=auto" is broken as specified in PR99939 and this patch fixes the issue. gcc/testsuite/ChangeLog: 2021-06-11 Srinath Parvathaneni <srinath.parvathaneni@arm.com> PR target/99939 * gcc.target/arm/cmse/cmse-18.c: Add separate scan-assembler directives check for target is v8.1-m.main+mve or not before comparing the assembly output. * gcc.target/arm/cmse/cmse-20.c: New test. libgcc/ChangeLog: 2021-06-11 Srinath Parvathaneni <srinath.parvathaneni@arm.com> PR target/99939 * config/arm/cmse_nonsecure_call.S: Add __ARM_FEATURE_MVE macro. * config/arm/t-arm: To link cmse.o and cmse_nonsecure_call.o on passing -mcmse option.
2021-06-10rs6000: Fix *TItype_ppcSegher Boessenkool1-0/+12
The *TItype_ppc definitions are guarded by _ARCH_PPC64, so all declarations using it should do so as well. 2021-06-10 Segher Boessenkool <segher@kernel.crashing.org> libgcc/ * config/rs6000/quad-float128.h: Guard all uses of [U]TItype_ppc by _ARCH_PPC64 .
2021-06-09Conversions between 128-bit integer and floating point values.Carl Love12-23/+185
The files fixkfti-sw.c and fixunskfti-sw.c are renamed versions of fixkfti.c and fixunskfti.c respectively to do the conversions in software. The function names in the files were updated with the rename as well as some white spaces fixes. The file float128-p10.c contains the functions for using the ISA 3.1 hardware instructions to perform the conversions. 2021-06-08 Carl Love <cel@us.ibm.com> gcc/ChangeLog * config/rs6000/rs6000.c (__fixkfti, __fixunskfti, __floattikf, __floatuntikf): Names changed to __fixkfti_sw, __fixunskfti_sw, __floattikf_sw, __floatuntikf_sw respectively. * config/rs6000/rs6000.md (floatti<mode>2, floatunsti<mode>2, fix_trunc<mode>ti2, fixuns_trunc<mode>ti2): Add define_insn for mode IEEE 128. gcc/testsuite/ChangeLog * gcc.target/powerpc/fp128_conversions.c: New file. * gcc.target/powerpc/int_128bit-runnable.c(vextsd2q, vcmpuq, vcmpsq, vcmpequq, vcmpequq., vcmpgtsq, vcmpgtsq. vcmpgtuq, vcmpgtuq.): Update scan-assembler-times. (ppc_native_128bit): Remove dg-require-effective-target. libgcc/ChangeLog * config.host: Add if test and set for libgcc_cv_powerpc_3_1_float128_hw. * config/rs6000/fixkfti.c: Renamed to fixkfti-sw.c. Change calls of __fixkfti to __fixkfti_sw. * config/rs6000/fixunskfti.c: Renamed to fixunskfti-sw.c. Change calls of __fixunskfti to __fixunskfti_sw. * config/rs6000/float128-p10.c (__floattikf_hw, __floatuntikf_hw, __fixkfti_hw, __fixunskfti_hw): New file. * config/rs6000/float128-ifunc.c (SW_OR_HW_ISA3_1): New macro. (__floattikf_resolve, __floatuntikf_resolve, __fixkfti_resolve, __fixunskfti_resolve): Add resolve functions. (__floattikf, __floatuntikf, __fixkfti, __fixunskfti): New functions. * config/rs6000/float128-sed (floattitf, __floatuntitf, __fixtfti, __fixunstfti): Add editor commands to change names. * config/rs6000/float128-sed-hw (__floattitf, __floatuntitf, __fixtfti, __fixunstfti): Add editor commands to change names. * config/rs6000/floattikf.c: Renamed to floattikf-sw.c. * config/rs6000/floatuntikf.c: Renamed to floatuntikf-sw.c. * config/rs6000/quad-float128.h (__floattikf_sw, __floatuntikf_sw, __fixkfti_sw, __fixunskfti_sw, __floattikf_hw, __floatuntikf_hw, __fixkfti_hw, __fixunskfti_hw, __floattikf, __floatuntikf, __fixkfti, __fixunskfti): New extern declarations. * config/rs6000/t-float128 (floattikf, floatuntikf, fixkfti, fixunskfti): Remove file names from fp128_ppc_funcs. (floattikf-sw, floatuntikf-sw, fixkfti-sw, fixunskfti-sw): Add file names to fp128_ppc_funcs. * config/rs6000/t-float128-hw(fp128_3_1_hw_funcs, fp128_3_1_hw_src, fp128_3_1_hw_static_obj, fp128_3_1_hw_shared_obj, fp128_3_1_hw_obj): Add variables for ISA 3.1 support. * config/rs6000/t-float128-p10-hw: New file. * configure: Update script for isa 3.1 128-bit float support. * configure.ac: Add check for 128-bit float hardware support.
2021-05-13libgcc: pru: Place mpyll into its own sectionDimitar Dimitrov1-0/+2
This should help LD's --gc-sections feature to reduce final ELF size. libgcc/ChangeLog: * config/pru/mpyll.S (__pruabi_mpyll): Place into own section. Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
2021-04-28Practical improvement to libgcc complex dividePatrick McGehearty1-8/+101
Correctness and performance test programs used during development of this project may be found in the attachment to: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg254210.html Summary of Purpose This patch to libgcc/libgcc2.c __divdc3 provides an opportunity to gain important improvements to the quality of answers for the default complex divide routine (half, float, double, extended, long double precisions) when dealing with very large or very small exponents. The current code correctly implements Smith's method (1962) [2] further modified by c99's requirements for dealing with NaN (not a number) results. When working with input values where the exponents are greater than *_MAX_EXP/2 or less than -(*_MAX_EXP)/2, results are substantially different from the answers provided by quad precision more than 1% of the time. This error rate may be unacceptable for many applications that cannot a priori restrict their computations to the safe range. The proposed method reduces the frequency of "substantially different" answers by more than 99% for double precision at a modest cost of performance. Differences between current gcc methods and the new method will be described. Then accuracy and performance differences will be discussed. Background This project started with an investigation related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714. Study of Beebe[1] provided an overview of past and recent practice for computing complex divide. The current glibc implementation is based on Robert Smith's algorithm [2] from 1962. A google search found the paper by Baudin and Smith [3] (same Robert Smith) published in 2012. Elen Kalda's proposed patch [4] is based on that paper. I developed two sets of test data by randomly distributing values over a restricted range and the full range of input values. The current complex divide handled the restricted range well enough, but failed on the full range more than 1% of the time. Baudin and Smith's primary test for "ratio" equals zero reduced the cases with 16 or more error bits by a factor of 5, but still left too many flawed answers. Adding debug print out to cases with substantial errors allowed me to see the intermediate calculations for test values that failed. I noted that for many of the failures, "ratio" was a subnormal. Changing the "ratio" test from check for zero to check for subnormal reduced the 16 bit error rate by another factor of 12. This single modified test provides the greatest benefit for the least cost, but the percentage of cases with greater than 16 bit errors (double precision data) is still greater than 0.027% (2.7 in 10,000). Continued examination of remaining errors and their intermediate computations led to the various tests of input value tests and scaling to avoid under/overflow. The current patch does not handle some of the rare and most extreme combinations of input values, but the random test data is only showing 1 case in 10 million that has an error of greater than 12 bits. That case has 18 bits of error and is due to subtraction cancellation. These results are significantly better than the results reported by Baudin and Smith. Support for half, float, double, extended, and long double precision is included as all are handled with suitable preprocessor symbols in a single source routine. Since half precision is computed with float precision as per current libgcc practice, the enhanced algorithm provides no benefit for half precision and would cost performance. Further investigation showed changing the half precision algorithm to use the simple formula (real=a*c+b*d imag=b*c-a*d) caused no loss of precision and modest improvement in performance. The existing constants for each precision: float: FLT_MAX, FLT_MIN; double: DBL_MAX, DBL_MIN; extended and/or long double: LDBL_MAX, LDBL_MIN are used for avoiding the more common overflow/underflow cases. This use is made generic by defining appropriate __LIBGCC2_* macros in c-cppbuiltin.c. Tests are added for when both parts of the denominator have exponents small enough to allow shifting any subnormal values to normal values all input values could be scaled up without risking overflow. That gained a clear improvement in accuracy. Similarly, when either numerator was subnormal and the other numerator and both denominator values were not too large, scaling could be used to reduce risk of computing with subnormals. The test and scaling values used all fit within the allowed exponent range for each precision required by the C standard. Float precision has more difficulty with getting correct answers than double precision. When hardware for double precision floating point operations is available, float precision is now handled in double precision intermediate calculations with the simple algorithm the same as the half-precision method of using float precision for intermediate calculations. Using the higher precision yields exact results for all tested input values (64-bit double, 32-bit float) with the only performance cost being the requirement to convert the four input values from float to double. If double precision hardware is not available, then float complex divide will use the same improved algorithm as the other precisions with similar change in performance. Further Improvement The most common remaining substantial errors are due to accuracy loss when subtracting nearly equal values. This patch makes no attempt to improve that situation. NOTATION For all of the following, the notation is: Input complex values: a+bi (a= real part, b= imaginary part) c+di Output complex value: e+fi = (a+bi)/(c+di) For the result tables: current = current method (SMITH) b1div = method proposed by Elen Kalda b2div = alternate method considered by Elen Kalda new = new method proposed by this patch DESCRIPTIONS of different complex divide methods: NAIVE COMPUTATION (-fcx-limited-range): e = (a*c + b*d)/(c*c + d*d) f = (b*c - a*d)/(c*c + d*d) Note that c*c and d*d will overflow or underflow if either c or d is outside the range 2^-538 to 2^512. This method is available in gcc when the switch -fcx-limited-range is used. That switch is also enabled by -ffast-math. Only one who has a clear understanding of the maximum range of all intermediate values generated by an application should consider using this switch. SMITH's METHOD (current libgcc): if(fabs(c)<fabs(d) { r = c/d; denom = (c*r) + d; e = (a*r + b) / denom; f = (b*r - a) / denom; } else { r = d/c; denom = c + (d*r); e = (a + b*r) / denom; f = (b - a*r) / denom; } Smith's method is the current default method available with __divdc3. Elen Kalda's METHOD Elen Kalda proposed a patch about a year ago, also based on Baudin and Smith, but not including tests for subnormals: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-08/msg01629.html [4] It is compared here for accuracy with this patch. This method applies the most significant part of the algorithm proposed by Baudin&Smith (2012) in the paper "A Robust Complex Division in Scilab" [3]. Elen's method also replaces two divides by one divide and two multiplies due to the high cost of divide on aarch64. In the comparison sections, this method will be labeled b1div. A variation discussed in that patch which does not replace the two divides will be labeled b2div. inline void improved_internal (MTYPE a, MTYPE b, MTYPE c, MTYPE d) { r = d/c; t = 1.0 / (c + (d * r)); if (r != 0) { x = (a + (b * r)) * t; y = (b - (a * r)) * t; } else { /* Changing the order of operations avoids the underflow of r impacting the result. */ x = (a + (d * (b / c))) * t; y = (b - (d * (a / c))) * t; } } if (FABS (d) < FABS (c)) { improved_internal (a, b, c, d); } else { improved_internal (b, a, d, c); y = -y; } NEW METHOD (proposed by patch) to replace the current default method: The proposed method starts with an algorithm proposed by Baudin&Smith (2012) in the paper "A Robust Complex Division in Scilab" [3]. The patch makes additional modifications to that method for further reductions in the error rate. The following code shows the #define values for double precision. See the patch for #define values used for other precisions. #define RBIG ((DBL_MAX)/2.0) #define RMIN (DBL_MIN) #define RMIN2 (0x1.0p-53) #define RMINSCAL (0x1.0p+51) #define RMAX2 ((RBIG)*(RMIN2)) if (FABS(c) < FABS(d)) { /* prevent overflow when arguments are near max representable */ if ((FABS (d) > RBIG) || (FABS (a) > RBIG) || (FABS (b) > RBIG) ) { a = a * 0.5; b = b * 0.5; c = c * 0.5; d = d * 0.5; } /* minimize overflow/underflow issues when c and d are small */ else if (FABS (d) < RMIN2) { a = a * RMINSCAL; b = b * RMINSCAL; c = c * RMINSCAL; d = d * RMINSCAL; } else { if(((FABS (a) < RMIN) && (FABS (b) < RMAX2) && (FABS (d) < RMAX2)) || ((FABS (b) < RMIN) && (FABS (a) < RMAX2) && (FABS (d) < RMAX2))) { a = a * RMINSCAL; b = b * RMINSCAL; c = c * RMINSCAL; d = d * RMINSCAL; } } r = c/d; denom = (c*r) + d; if( r > RMIN ) { e = (a*r + b) / denom ; f = (b*r - a) / denom } else { e = (c * (a/d) + b) / denom; f = (c * (b/d) - a) / denom; } } [ only presenting the fabs(c) < fabs(d) case here, full code in patch. ] Before any computation of the answer, the code checks for any input values near maximum to allow down scaling to avoid overflow. These scalings almost never harm the accuracy since they are by 2. Values that are over RBIG are relatively rare but it is easy to test for them and allow aviodance of overflows. Testing for RMIN2 reveals when both c and d are less than [FLT|DBL]_EPSILON. By scaling all values by 1/EPSILON, the code converts subnormals to normals, avoids loss of accuracy and underflows in intermediate computations that otherwise might occur. If scaling a and b by 1/EPSILON causes either to overflow, then the computation will overflow whatever method is used. Finally, we test for either a or b being subnormal (RMIN) and if so, for the other three values being small enough to allow scaling. We only need to test a single denominator value since we have already determined which of c and d is larger. Next, r (the ratio of c to d) is checked for being near zero. Baudin and Smith checked r for zero. This code improves that approach by checking for values less than DBL_MIN (subnormal) covers roughly 12 times as many cases and substantially improves overall accuracy. If r is too small, then when it is used in a multiplication, there is a high chance that the result will underflow to zero, losing significant accuracy. That underflow is avoided by reordering the computation. When r is subnormal, the code replaces a*r (= a*(c/d)) with ((a/d)*c) which is mathematically the same but avoids the unnecessary underflow. TEST Data Two sets of data are presented to test these methods. Both sets contain 10 million pairs of complex values. The exponents and mantissas are generated using multiple calls to random() and then combining the results. Only values which give results to complex divide that are representable in the appropriate precision after being computed in quad precision are used. The first data set is labeled "moderate exponents". The exponent range is limited to -DBL_MAX_EXP/2 to DBL_MAX_EXP/2 for Double Precision (use FLT_MAX_EXP or LDBL_MAX_EXP for the appropriate precisions. The second data set is labeled "full exponents". The exponent range for these cases is the full exponent range including subnormals for a given precision. ACCURACY Test results: Note: The following accuracy tests are based on IEEE-754 arithmetic. Note: All results reporteed are based on use of fused multiply-add. If fused multiply-add is not used, the error rate increases, giving more 1 and 2 bit errors for both current and new complex divide. Differences between using fused multiply and not using it that are greater than 2 bits are less than 1 in a million. The complex divide methods are evaluated by determining the percentage of values that exceed differences in low order bits. If a "2 bit" test results show 1%, that would mean that 1% of 10,000,000 values (100,000) have either a real or imaginary part that differs from the quad precision result by more than the last 2 bits. Results are reported for differences greater than or equal to 1 bit, 2 bits, 8 bits, 16 bits, 24 bits, and 52 bits for double precision. Even when the patch avoids overflows and underflows, some input values are expected to have errors due to the potential for catastrophic roundoff from floating point subtraction. For example, when b*c and a*d are nearly equal, the result of subtraction may lose several places of accuracy. This patch does not attempt to detect or minimize this type of error, but neither does it increase them. I only show the results for Elen Kalda's method (with both 1 and 2 divides) and the new method for only 1 divide in the double precision table. In the following charts, lower values are better. current - current complex divide in libgcc b1div - Elen Kalda's method from Baudin & Smith with one divide b2div - Elen Kalda's method from Baudin & Smith with two divides new - This patch which uses 2 divides =================================================== Errors Moderate Dataset gtr eq current b1div b2div new ====== ======== ======== ======== ======== 1 bit 0.24707% 0.92986% 0.24707% 0.24707% 2 bits 0.01762% 0.01770% 0.01762% 0.01762% 8 bits 0.00026% 0.00026% 0.00026% 0.00026% 16 bits 0.00000% 0.00000% 0.00000% 0.00000% 24 bits 0% 0% 0% 0% 52 bits 0% 0% 0% 0% =================================================== Table 1: Errors with Moderate Dataset (Double Precision) Note in Table 1 that both the old and new methods give identical error rates for data with moderate exponents. Errors exceeding 16 bits are exceedingly rare. There are substantial increases in the 1 bit error rates for b1div (the 1 divide/2 multiplys method) as compared to b2div (the 2 divides method). These differences are minimal for 2 bits and larger error measurements. =================================================== Errors Full Dataset gtr eq current b1div b2div new ====== ======== ======== ======== ======== 1 bit 2.05% 1.23842% 0.67130% 0.16664% 2 bits 1.88% 0.51615% 0.50354% 0.00900% 8 bits 1.77% 0.42856% 0.42168% 0.00011% 16 bits 1.63% 0.33840% 0.32879% 0.00001% 24 bits 1.51% 0.25583% 0.24405% 0.00000% 52 bits 1.13% 0.01886% 0.00350% 0.00000% =================================================== Table 2: Errors with Full Dataset (Double Precision) Table 2 shows significant differences in error rates. First, the difference between b1div and b2div show a significantly higher error rate for the b1div method both for single bit errros and well beyond. Even for 52 bits, we see the b1div method gets completely wrong answers more than 5 times as often as b2div. To retain comparable accuracy with current complex divide results for small exponents and due to the increase in errors for large exponents, I choose to use the more accurate method of two divides. The current method has more 1.6% of cases where it is getting results where the low 24 bits of the mantissa differ from the correct answer. More than 1.1% of cases where the answer is completely wrong. The new method shows less than one case in 10,000 with greater than two bits of error and only one case in 10 million with greater than 16 bits of errors. The new patch reduces 8 bit errors by a factor of 16,000 and virtually eliminates completely wrong answers. As noted above, for architectures with double precision hardware, the new method uses that hardware for the intermediate calculations before returning the result in float precision. Testing of the new patch has shown zero errors found as seen in Tables 3 and 4. Correctness for float ============================= Errors Moderate Dataset gtr eq current new ====== ======== ======== 1 bit 28.68070% 0% 2 bits 0.64386% 0% 8 bits 0.00401% 0% 16 bits 0.00001% 0% 24 bits 0% 0% ============================= Table 3: Errors with Moderate Dataset (float) ============================= Errors Full Dataset gtr eq current new ====== ======== ======== 1 bit 19.98% 0% 2 bits 3.20% 0% 8 bits 1.97% 0% 16 bits 1.08% 0% 24 bits 0.55% 0% ============================= Table 4: Errors with Full Dataset (float) As before, the current method shows an troubling rate of extreme errors. There very minor changes in accuracy for half-precision since the code changes from Smith's method to the simple method. 5 out of 1 million test cases show correct answers instead of 1 or 2 bit errors. libgcc computes half-precision functions in float precision allowing the existing methods to avoid overflow/underflow issues for the allowed range of exponents for half-precision. Extended precision (using x87 80-bit format on x86) and Long double (using IEEE-754 128-bit on x86 and aarch64) both have 15-bit exponents as compared to 11-bit exponents in double precision. We note that the C standard also allows Long Double to be implemented in the equivalent range of Double. The RMIN2 and RMINSCAL constants are selected to work within the Double range as well as with extended and 128-bit ranges. We will limit our performance and accurancy discussions to the 80-bit and 128-bit formats as seen on x86 here. The extended and long double precision investigations were more limited. Aarch64 does not support extended precision but does support the software implementation of 128-bit long double precision. For x86, long double defaults to the 80-bit precision but using the -mlong-double-128 flag switches to using the software implementation of 128-bit precision. Both 80-bit and 128-bit precisions have the same exponent range, with the 128-bit precision has extended mantissas. Since this change is only aimed at avoiding underflow/overflow for extreme exponents, I studied the extended precision results on x86 for 100,000 values. The limited exponent dataset showed no differences. For the dataset with full exponent range, the current and new values showed major differences (greater than 32 bits) in 567 cases out of 100,000 (0.56%). In every one of these cases, the ratio of c/d or d/c (as appropriate) was zero or subnormal, indicating the advantage of the new method and its continued correctness where needed. PERFORMANCE Test results In order for a library change to be practical, it is necessary to show the slowdown is tolerable. The slowdowns observed are much less than would be seen by (for example) switching from hardware double precison to a software quad precision, which on the tested machines causes a slowdown of around 100x). The actual slowdown depends on the machine architecture. It also depends on the nature of the input data. If underflow/overflow is rare, then implementations that have strong branch prediction will only slowdown by a few cycles. If underflow/overflow is common, then the branch predictors will be less accurate and the cost will be higher. Results from two machines are presented as examples of the overhead for the new method. The one labeled x86 is a 5 year old Intel x86 processor and the one labeled aarch64 is a 3 year old arm64 processor. In the following chart, the times are averaged over a one million value data set. All values are scaled to set the time of the current method to be 1.0. Lower values are better. A value of less than 1.0 would be faster than the current method and a value greater than 1.0 would be slower than the current method. ================================================ Moderate set full set x86 aarch64 x86 aarch64 ======== =============== =============== float 0.59 0.79 0.45 0.81 double 1.04 1.24 1.38 1.56 long double 1.13 1.24 1.29 1.25 ================================================ Table 5: Performance Comparisons (ratio new/current) The above tables omit the timing for the 1 divide and 2 multiply comparison with the 2 divide approach. The float results show clear performance improvement due to using the simple method with double precision for intermediate calculations. The double results with the newer method show less overhead for the moderate dataset than for the full dataset. That's because the moderate dataset does not ever take the new branches which protect from under/overflow. The better the branch predictor, the lower the cost for these untaken branches. Both platforms are somewhat dated, with the x86 having a better branch predictor which reduces the cost of the additional branches in the new code. Of course, the relative slowdown may be greater for some architectures, especially those with limited branch prediction combined with a high cost of misprediction. The long double results are fairly consistent in showing the moderate additional cost of the extra branches and calculations for all cases. The observed cost for all precisions is claimed to be tolerable on the grounds that: (a) the cost is worthwhile considering the accuracy improvement shown. (b) most applications will only spend a small fraction of their time calculating complex divide. (c) it is much less than the cost of extended precision (d) users are not forced to use it (as described below) Those users who find this degree of slowdown unsatisfactory may use the gcc switch -fcx-fortran-rules which does not use the library routine, instead inlining Smith's method without the C99 requirement for dealing with NaN results. The proposed patch for libgcc complex divide does not affect the code generated by -fcx-fortran-rules. SUMMARY When input data to complex divide has exponents whose absolute value is less than half of *_MAX_EXP, this patch makes no changes in accuracy and has only a modest effect on performance. When input data contains values outside those ranges, the patch eliminates more than 99.9% of major errors with a tolerable cost in performance. In comparison to Elen Kalda's method, this patch introduces more performance overhead but reduces major errors by a factor of greater than 4000. REFERENCES [1] Nelson H.F. Beebe, "The Mathematical-Function Computation Handbook. Springer International Publishing AG, 2017. [2] Robert L. Smith. Algorithm 116: Complex division. Commun. ACM, 5(8):435, 1962. [3] Michael Baudin and Robert L. Smith. "A robust complex division in Scilab," October 2012, available at http://arxiv.org/abs/1210.4539. [4] Elen Kalda: Complex division improvements in libgcc https://gcc.gnu.org/legacy-ml/gcc-patches/2019-08/msg01629.html 2020-12-08 Patrick McGehearty <patrick.mcgehearty@oracle.com> gcc/c-family/ * c-cppbuiltin.c (c_cpp_builtins): Add supporting macros for new complex divide libgcc/ * libgcc2.c (XMTYPE, XCTYPE, RBIG, RMIN, RMIN2, RMINSCAL, RMAX2): Define. (__divsc3, __divdc3, __divxc3, __divtc3): Improve complex divide. * config/rs6000/_divkc3.c (RBIG, RMIN, RMIN2, RMINSCAL, RMAX2): Define. (__divkc3): Improve complex divide. gcc/testsuite/ * gcc.c-torture/execute/ieee/cdivchkd.c: New test. * gcc.c-torture/execute/ieee/cdivchkf.c: Likewise. * gcc.c-torture/execute/ieee/cdivchkld.c: Likewise.
2021-04-23Fix logic error in 32-bit trampolines.Michael Meissner1-4/+2
The test in the PowerPC 32-bit trampoline support is backwards. It aborts if the trampoline size is greater than the expected size. It should abort when the trampoline size is less than the expected size. I fixed the test so the operands are reversed. I then folded the load immediate into the compare instruction. I verified this by creating a 32-bit trampoline program and manually changing the size of the trampoline to be 48 instead of 40. The program aborted with the larger size. I updated this code and ran the test again and it passed. I added a test case that runs on PowerPC 32-bit Linux systems and it calls the __trampoline_setup function with a larger buffer size than the compiler uses. The test is not run on 64-bit systems, since the function __trampoline_setup is not called. I also limited the test to just Linux systems, in case trampolines are handled differently in other systems. libgcc/ 2021-04-23 Michael Meissner <meissner@linux.ibm.com> PR target/98952 * config/rs6000/tramp.S (__trampoline_setup, elfv1 #ifdef): Fix trampoline size comparison in 32-bit by reversing test and combining load immediate with compare. (__trampoline_setup, elfv2 #ifdef): Fix trampoline size comparison in 32-bit by reversing test and combining load immediate with compare. gcc/testsuite/ 2021-04-23 Michael Meissner <meissner@linux.ibm.com> PR target/98952 * gcc.target/powerpc/pr98952.c: New test.
2021-04-05Honor --disable-decimal-float on PowerPC Decimal/Float128 conversionsMichael Meissner1-2/+5
This patch fixes the problem that the Decimal <-> Float128 conversions were built even if the user configured GCC with --disable-decimal-float. libgcc/ 2021-04-05 Florian Weimer <fweimer@redhat.com> * config/rs6000/t-float128 (fp128_ppc_funcs): Add decimal floating point functions for $(decimal_float) only. Co-Authored-By: Michael Meissner <meissner@linux.ibm.com>
2021-04-03rs6000: Fix up libgcc ABI when built with --with-long-double-format=ieee ↵Jakub Jelinek1-4/+6
[PR97653] __floatunditf and __fixtfdi and a couple of other libgcc{.a,_s.so} entrypoints for backwards compatibility should mean IBM double double handling (i.e. IFmode), gcc emits such calls for that format and form IEEE long double emits *kf* instead. When gcc is configured without --with-long-double-format=ieee , everything is fine, but when it is not, we need to compile those libgcc sources with -mno-gnu-attribute -mabi=ibmlongdouble. The following snippet in libgcc/config/rs6000/t-linux was attempting to ensure that, and for some routines it works fine (e.g. for _powitf2). But, due to 4 different types of bugs it doesn't work for most of those functions, which means that in --with-long-double-format=ieee configured gcc those *tf* entrypoints instead handle the long double arguments as if they were KFmode. The bugs are: 1) the first few objs properly use $(objext) as suffix, but several other contain a typo and use $(object) instead, which is a variable that isn't set to anything, so we don't add .o etc. extensions 2) while unsigned fix are properly called _fixuns*, unsigned float are called _floatun* (without s), but the var was using there the extra s and so didn't match 3) the variable didn't cover any of the TF <-> TI conversions, only TF <-> DI conversions 4) nothing in libgcc_s.so was handled, as those object files are called *_s.o rather than *.o and IBM128_SHARED_OBJS used wrong syntax of the GNU make substitution reference, which should be $(var:a=b) standing for $(patsubst a,b,$(var)) but it used $(var:a:b) instead 2021-04-03 Jakub Jelinek <jakub@redhat.com> PR target/97653 * config/rs6000/t-linux (IBM128_STATIC_OBJS): Fix spelling, use $(objext) instead of $(object). Use _floatunditf instead of _floatunsditf. Add tf <-> ti conversion objects. (IBM128_SHARED_OBJS): Use proper substitution reference syntax.
2021-03-29Require GLIBC 2.32 for Decimal/_Float128 conversions.Michael Meissner5-177/+1
In the patch that I applied on March 2nd, I had code to provide support for Decimal/_Float128 conversions if the user did not use at least GLIBC 2.32. It did this by using __ibm128 as an intermediate type. The trouble is __ibm128 cannot represent all of the numbers that _Float128 can, and you lose if you do this conversion. This patch removes this support. The dfp-bit.c functions now call the the __sprintfieee128 and __strtoieee128 functions to do the conversion. If the user does not have GLIBC, they will get a linker error that these functions do not exist. The float128 support functions are only built into the static libgcc, so there isn't an issue with having references to __strtoieee128 and __sprintfieee128 with older GLIBC libraries. As an added bonus, this patch eliminates the __sprintfkf function which included stdio.h to get a definition for the sprintf library function. This allows for building cross compilers without having to have a target stdio.h available. libgcc/ 2021-03-29 Michael Meissner <meissner@linux.ibm.com> * config/rs6000/t-float128 (fp128_decstr_funcs): Delete. (fp128_ppc_funcs): Do not add $(fp128_decstr_funcs). (fp128_decstr_objs): Delete. * dfp-bit.h: Call __sprintfieee128 to do conversions from _Float128 to a Decimal type. Call __strtoieee128 to do conversions from a Decimal type to _Float128. * config/rs6000/_sprintfkf.c: Delete file. * config/rs6000/_sprintfkf.h: Delete file. * config/rs6000/_strtokf.c: Delete file. * config/rs6000/_strtokf.h: Delete file.
2021-03-23RISC-V: Update soft-fp config for big-endianMarcus Comstedt1-0/+4
libgcc/ * config/riscv/sfp-machine.h (__BYTE_ORDER): Set according to __BYTE_ORDER__.
2021-03-01Fix __sprintfkf prototype in libgcc.Michael Meissner2-2/+2
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.
2021-02-24arm: Fix CMSE support detection in libgcc (PR target/99157)Christophe Lyon1-1/+1
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.
2021-02-22Add conversions between _Float128 and Decimal.Michael Meissner12-1/+431
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.
2021-01-27libgcc, i386: Add .note.GNU-stack sections to the ms sse/avx sav/resJakub Jelinek6-0/+30
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.
2021-01-14or1k: Support for softfloat to emulate hw exceptionsStafford Horne1-1/+40
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.
2021-01-13hurd: libgcc unwinding over signal trampolines with SIGINFOSamuel Thibault1-13/+47
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.
2021-01-04Update copyright years.Jakub Jelinek999-1000/+1000
2021-01-04Update Copyright in ChangeLog filesJakub Jelinek1-1/+1
Do this separately from all other Copyright updates, as ChangeLog files can be modified only separately.
2020-12-20gcc: xtensa: implement bswapsi2, bswapdi2 and helpersMax Filippov2-0/+40
2020-12-20 Max Filippov <jcmvbkbc@gmail.com> gcc/ * config/xtensa/xtensa.md (bswapsi2, bswapdi2): New patterns. gcc/testsuite/ * gcc.target/xtensa/bswap.c: New test. libgcc/ * config/xtensa/lib1funcs.S (__bswapsi2, __bswapdi2): New functions. * config/xtensa/t-xtensa (LIB1ASMFUNCS): Add _bswapsi2 and _bswapdi2.
2020-12-03PowerPC: PR libgcc/97543 and libgcc/97643, fix long double issuesMichael Meissner1-0/+22
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.
2020-12-02introduce overridable clear_cache emitterAlexandre Oliva3-37/+0
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.
2020-11-18MSP430: Add 64-bit hardware multiply supportJozef Lawrynowicz3-4/+130
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.
2020-11-17[RS6000] Use LIB2_SIDITI_CONV_FUNCS in place of ppc64-fp.cAlan Modra2-239/+1
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.
2020-11-15MSP430: Fix inconsistent naming of hwmult libfuncsJozef Lawrynowicz1-6/+6
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.
2020-10-29Fix the logic conditioning VX_ENTER/LEAVE_TLS_DTOROlivier Hainque1-1/+1
Fix a basic #if/#ifdef confusion which leads to improper choices in some configurations. 2020-10-28 Olivier Hainque <hainque@adacore.com> libgcc/ * config/gthr-vxworks-tls.c: Fix preprocessor logic controlling the definition of VX_ENTER_TLS_DTOR and VX_LEAVE_TLS_DTOR based on a version major check.
2020-10-29Fix conditional inclusion guard in gthr-vxworks-thread.cOlivier Hainque1-1/+1
This fixes the name of the macro used to condition the inclusion of an actual implementation of some of the gthread support services for VxWorks, to agree with the side defining that macro based on tests against the targetted VxWorks version major. 2020-10-28 Olivier Hainque <hainque@adacore.com> libgcc/ * config/gthr-vxworks-thread.c: Fix name of macro used to condition the inclusion of an actual implementation.
2020-10-24Daily bump.GCC Administrator1-0/+5
2020-10-23Fix overzealous gthread support inhibition for vxworksRasmus Villemoes2-2/+4
The tests for macros possibly defined in gthr.h needs to be performed after the corresponding #include. This was tested together with the previous updates to gthr-vxworks-thread.c and gthr-vxworks-cond.c and was meant to be squashed with them. 2010-10-23 Rasmus Villemoes <rv@rasmusvillemoes.dk> libgcc/ * config/gthr-vxworks-thread.c: #include gthr.h before testing the guard defined there. * config/gthr-vxworks-cond.c: Likewise.
2020-10-23stor-layout: Reject forming arrays with elt sizes not divisible by elt ↵Jakub Jelinek1-1/+1
alignment [PR97164] As mentioned in the PR, since 2005 we reject if array elements are smaller than their alignment (i.e. overaligned elements), because such arrays don't make much sense, only their first element is guaranteed to be aligned as user requested, but the next element can't be. The following testcases show something we've been silent about but is equally bad, the 2005 case is just the most common special case of that the array element size is not divisible by the alignment. In those arrays too only the first element is guaranteed to be properly aligned and the second one can't be. This patch rejects those cases too, but keeps the existing wording for the old common case. Unfortunately, the patch breaks bootstrap, because libbid uses this mess (forms arrays with 24 byte long elements with 16 byte element alignment). I don't really see justification for that, so I've decreased the alignment to 8 bytes instead. 2020-10-23 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/97164 gcc/ * stor-layout.c (layout_type): Also reject arrays where element size is constant, but not a multiple of element alignment. gcc/testsuite/ * c-c++-common/pr97164.c: New test. * gcc.c-torture/execute/pr36093.c: Move ... * gcc.dg/pr36093.c: ... here. Add dg-do compile and dg-error directives. * gcc.c-torture/execute/pr43783.c: Move ... * gcc.dg/pr43783.c: ... here. Add dg-do compile, dg-options and dg-error directives. libgcc/config/libbid/ * bid_functions.h (UINT192): Decrease alignment to 8 bytes.
2020-10-16Inhibit support for C++0x threads on VxWorks < 6Rasmus Villemoes2-2/+6
As for condition variables, the C++0x threads support relies on VxWorks entry points not available in VxWorks versions prior to 6. We just expose absence of support for C++0x threads on such systems. 2020-10-15 Rasmus Villemoes <rv@rasmusvillemoes.dk> libgcc/ * config/gthr-vxworks.h: Condition the ___GTHREADS_CXX0X section on VxWorks >= 6. * config/gthr-vxworks-thread.c: Condition the entire implementation on __GTHREAD_CXX0X.
2020-10-16Inhibit support for gthread condvars on VxWorks < 6Rasmus Villemoes2-0/+12
The condition variables support relies on kernel entry points to enforce critical aspects of it's expected behavior. Some of these entry points are not available prior to VxWorks 6, so we just expose absence of support for condition variables on such systems. 2020-10-15 Rasmus Villemoes <rv@rasmusvillemoes.dk> libgcc/ * config/gthr-vxworks.h: Condition the __GTHREAD_HAS_COND section on VxWorks >= 6. * config/gthr-vxworks-cond.c: Condition the entire implementation on __GTHREAD_HAS_COND.
2020-10-16Add missing #include <taskLib.h> in gthr-vxworks.cRasmus Villemoes1-0/+1
This fixes an oversight and addresses a few build time warnings. 2020-10-15 Rasmus Villemoes <rv@rasmusvillemoes.dk> libgcc/ * config/gthr-vxworks.c: #include <taskLib.h>.
2020-10-16Fix leftover _VXW_PRE_69 in gthr-vxworks.hRasmus Villemoes1-1/+1
2020-10-15 Rasmus Villemoes <rv@rasmusvillemoes.dk> libgcc/ * config/gthr-vxworks.h: Rewrite remaining occurrence of _VXW_PRE_69 as _VXWORKS_PRE(6,9).
2020-10-16Stub out VX_ENTER_TLS_DTOR for VxWorks != 6Rasmus Villemoes1-7/+15
As of today, the __gthread_enter/leave entry points are only meaningful on VxWorks 6. Refactor the VX_ENTER_TLS_DTOR macros accordingly. 2020-10-15 Rasmus Villemoes <rv@rasmusvillemoes.dk> libgcc/ * config/gthr-vxworks-tls.c (VX_ENTER_TLS_DTOR): Nil except on VxWorks 6. Co-authored-by: Olivier Hainque <hainque@adacore.com>
2020-10-16Fix the vxworks crtstuff handling of kernel/rtp variationsOlivier Hainque1-6/+6
The ports that support RTPs achieve the kernel/rtp compilation and link distinction through the multilib mechanism. This patch just removes the bogus explicit extraneous materialization of this distinction in the common VxWorks configuration files and leaves the rtp specialization all to the multilib machinery. 2020-10-15 Olivier Hainque <hainque@adacore.com> libgcc/ * config/t-vxcrtstuff: Remove the -kernel/-rtp specialization. gcc/ * config/vxworks.h (VX_CRTBEGIN_SPEC): Likewise.
2020-10-14Rework the condition variables support for VxWorksAlexandre Oliva2-12/+47
This change reworks the condition variables support for VxWorks to address the very legit points raised by Rasmus in https://gcc.gnu.org/pipermail/gcc/2020-May/232524.html While some of the issues were taken care of by the use of semFlush, a few others were indeed calling for adjustments. We first considered resorting to the condvarLib library available in VxWorks7. Unfortunately, it is vx7 only and we wanted something working for at least vx 6.9 as well. It also turned out requiring the use of recursive mutexes for condVarWait, which seemed unnecessarily constraining. Instead, this change corrects the sequencing logic in a few places and leverages the semExchange API to ensure the key atomicity requirement on cond_wait operations. 2020-10-14 Alexandre Oliva <oliva@adacore.com> libgcc/ * config/gthr-vxworks-thread.c: Include stdlib.h. (tls_delete_hook): Prototype it. (__gthread_cond_signal): Return early if no waiters. Consume signal in case the semaphore got full. Use semInfoGet instead of kernel-mode-only semInfo. (__gthread_cond_timedwait): Use semExchange. Always take the mutex again before returning. * config/gthr-vxworks-cond.c (__ghtread_cond_wait): Likewise.
2020-10-14Honor $(MULTISUBDIR) in -I directives for libgcc on VxWorksOlivier Hainque2-2/+2
This is useful to handle ports where we might arrange to use different sets of fixed headers for different multilibs, typically for kernel vs rtp modes. 2020-10-14 Olivier Hainque <hainque@adacore.com> libgcc/ * config/t-vxworks (LIBGCC2_INCLUDES): Append $(MULTISUBDIR) to the -I path for fixed headers, as we arrange to have different sets of such headers for different multilibs when they are activated. * config/t-vxworks7: Likewise.
generated by cgit v1.1 at 2025-09-18 11:51:48 +0000