The alpha specific version of trunc and truncf always add and subtract 0x1.0p23 or 0x1.0p52 even for big values. This causes this kind of errors in the testsuite: Failure: Test: trunc_towardzero (0x1p107) Result: is: 1.6225927682921334e+32 0x1.fffffffffffffp+106 should be: 1.6225927682921336e+32 0x1.0000000000000p+107 difference: 1.8014398509481984e+16 0x1.0000000000000p+54 ulp : 0.5000 max.ulp : 0.0000 Change this by returning the input value when its absolute value is greater than 0x1.0p23 or 0x1.0p52. NaN have to go through the add and subtract operations to get possibly silenced. Finally remove the code to handle inexact exception, trunc should never generate such an exception. Changelog: * sysdeps/alpha/fpu/s_trunc.c (__trunc): Return the input value when its absolute value is greater than 0x1.0p52. [_IEEE_FP_INEXACT] Remove. * sysdeps/alpha/fpu/s_truncf.c (__truncf): Return the input value when its absolute value is greater than 0x1.0p23. [_IEEE_FP_INEXACT] Remove. (cherry picked from commit b74d259fe793499134eb743222cd8dd7c74a31ce) (cherry picked from commit 3a5aa2ee4ffc515c8e7e615ea38d6b3b20ed0a30)
The alpha version of rint wrongly return sNaN for sNaN input. Fix that by checking for NaN and by returning the input value added with itself in that case. Changelog: * sysdeps/alpha/fpu/s_rint.c (__rint): Add argument with itself when it is a NaN. * sysdeps/alpha/fpu/s_rintf.c (__rintf): Likewise. (cherry picked from commit cb7f9d63b921ea1a1cbb4ab377a8484fd5da9a2b) (cherry picked from commit 51a313c50445eded2cfbbb60da2bbb98f3e9b219)
The alpha version of floor wrongly return sNaN for sNaN input. Fix that by checking for NaN and by returning the input value added with itself in that case. Finally remove the code to handle inexact exception, floor should never generate such an exception. Changelog: * sysdeps/alpha/fpu/s_floor.c (__floor): Add argument with itself when it is a NaN. [_IEEE_FP_INEXACT] Remove. * sysdeps/alpha/fpu/s_floorf.c (__floorf): Likewise. (cherry picked from commit 65cc568cf57156e5230db9a061645e54ff028a41) (cherry picked from commit 12bf4f130d46a075c628a2c948b31973b2a12222)
The alpha version of ceil wrongly return sNaN for sNaN input. Fix that by checking for NaN and by returning the input value added with itself in that case. Finally remove the code to handle inexact exception, ceil should never generate such an exception. Changelog: * sysdeps/alpha/fpu/s_ceil.c (__ceil): Add argument with itself when it is a NaN. [_IEEE_FP_INEXACT] Remove. * sysdeps/alpha/fpu/s_ceilf.c (__ceilf): Likewise. (cherry picked from commit 062e53c195b4a87754632c7d51254867247698b4) (cherry picked from commit 85186de4f422170e4aff108200d96ffa60d61081)
Avoid a build error with microMIPS compilation and recent versions of
GAS which complain if a branch targets a label which is marked as data
rather than microMIPS code:
../sysdeps/mips/mips32/crti.S: Assembler messages:
../sysdeps/mips/mips32/crti.S:72: Error: branch to a symbol in another ISA mode
make[2]: *** [.../csu/crti.o] Error 1
as commit 9d862524f6ae ("MIPS: Verify the ISA mode and alignment of
branch and jump targets") closed a hole in branch processing, making
relocation calculation respect the ISA mode of the symbol referred.
This allowed diagnosing the situation where an attempt is made to pass
control from code assembled for one ISA mode to code assembled for a
different ISA mode and either relaxing the branch to a cross-mode jump
or if that is not possible, then reporting this as an error rather than
letting such code build and then fail unpredictably at the run time.
This however requires the correct annotation of branch targets as code,
because the ISA mode is not relevant for data symbols and is therefore
not recorded for them. The `.insn' pseudo-op is used for this purpose
and has been supported by GAS since:
Wed Feb 12 14:36:29 1997 Ian Lance Taylor <ian@cygnus.com>
* config/tc-mips.c (mips_pseudo_table): Add "insn".
(s_insn): New static function.
* doc/c-mips.texi: Document .insn.
so there has been no reason to avoid it where required. More recently
this pseudo-op has been documented, by the microMIPS architecture
specification[1][2], as required for the correct interpretation of any
code label which is not followed by an actual instruction in an assembly
source.
Use it in our crti.S files then, to mark that the trailing label there
with no instructions following is indeed not a code bug and the branch
is legitimate.
References:
[1] "MIPS Architecture for Programmers, Volume II-B: The microMIPS32
Instruction Set", MIPS Technologies, Inc., Document Number: MD00582,
Revision 5.04, January 15, 2014, Section 7.1 "Assembly-Level
Compatibility", p. 533
[2] "MIPS Architecture for Programmers, Volume II-B: The microMIPS64
Instruction Set", MIPS Technologies, Inc., Document Number: MD00594,
Revision 5.04, January 15, 2014, Section 8.1 "Assembly-Level
Compatibility", p. 623
2016-11-23 Matthew Fortune <Matthew.Fortune@imgtec.com>
Maciej W. Rozycki <macro@imgtec.com>
* sysdeps/mips/mips32/crti.S (_init): Add `.insn' pseudo-op at
`.Lno_weak_fn' label.
* sysdeps/mips/mips64/n32/crti.S (_init): Likewise.
* sysdeps/mips/mips64/n64/crti.S (_init): Likewise.
(cherry picked from commit cfaf1949ff1f8336b54c43796d0e2531bc8a40a2)
(cherry picked from commit 8ee1ecb99cd8928b767b9b50f31b5618d046f0f2)
When glibc is compiled with gcc 6.2 that has been configured with --enable-default-pie and --enable-default-ssp, the configure script fails to detect that the compiler has ssp turned on by default when being built for i686-linux-gnu. This is because gcc is emitting __stack_chk_fail_local but the script is only looking for __stack_chk_fail. Support both. Example output: checking whether x86_64-pc-linux-gnu-gcc -m32 -Wl,-O1 -Wl,--as-needed implicitly enables -fstack-protector... no (cherry picked from commit c7409aded44634411a19b0b7178b7faa237835e6) (cherry picked from commit a6a59e99d1249dc386d0a042c39e3860fbb7b6b6)
During the sincos consolidation I made two mistakes, one was a logical error due to which cos(0x1.8475e5afd4481p+0) returned sin(0x1.8475e5afd4481p+0) instead. The second issue was an error in negating inputs for the correct quadrants for sine. I could not find a suitable test case for this despite running a program to search for such an input for a couple of hours. Following patch fixes both issues. Tested on x86_64. Thanks to Matt Clay for identifying the issue. [BZ #20357] * sysdeps/ieee754/dbl-64/s_sin.c (sloww): Fix up condition to call __mpsin/__mpcos and to negate values. * math/auto-libm-test-in: Add test. * math/auto-libm-test-out: Regenerate. (cherry picked from commit cbf88869edced4b23d792d95a8626e35b831df35) (cherry picked from commit 422facff9f2c4972e2dc46090a704d11b840b0c0)
Don't compile do_test (in sincos ABI tests) with -mavx, -mavx2 nor -mavx512 since they won't run on non-AVX machines. (cherry-picked from commit fe0cf8614836e2b08b802eb1f55abca75d558545) (cherry picked from commit 6ab1e91474c0faab25a568436b846c2630624039)
Fixed wrong vector sincos/sincosf ABI to have it compatible with current vector function declaration "#pragma omp declare simd notinbranch", according to which vector sincos should have vector of pointers for second and third parameters. It is fixed with implementation as wrapper to version having second and third parameters as pointers. (cherry-picked from commit ee2196bb6766ca7e63a1ba22ebb7619a3266776a) (cherry picked from commit 0350824fabf12da92c3ed5e1f3938bc1453a5938)
Fix multiarch build for POWER9 by correcting the order of the directories listed at sysnames configure variable. (cherry picked from commit 1850ce5a2ea3b908b26165e7e951cd4334129f07) (cherry picked from commit 79312adef2645f9051b251c56b0e45f6c4d38058)