Hi Martin, > On 09/22/2016 06:14 AM, Rainer Orth wrote: >> Hi Martin, >> >>> your patch broke bootstrap with MPFR 2.4.2, which is still the >>> recommended (or perhaps minimal) version according to install.texi: >> [...] >>> The following patch (together with your other one to fix ILP32 targets) >>> allows a sparc-sun-solaris2.12 bootstrap to continue. I'm going to >>> commit it as obvious. >> >> done now. Once the bootstrap had finished, I see quite a number of >> testsuite failures (i386-pc-solaris2.12 still running), both 32 and >> 64-bit: >> >> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line >> 1220) >> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line >> 1270) >> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line >> 1381) >> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line >> 356) >> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 99) >> +FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors) > > I have a patch for (hopefully) most of these failures that I will > commit along with the one for pr77676 as soon as it's approved.
as of r240389, a few of those failures occur also on x86_64-pc-linux-gnu with -m32: FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 1222) FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 1272) FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 1383) FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors) >> +FAIL: gcc.dg/tree-ssa/builtin-sprintf.c execution test >> >> FAIL: test_a_double:364: "%a" expected result for "0x0.0000000000000p+0" >> doesn't match function call return value: 20 != 6 >> FAIL: test_a_double:365: "%a" expected result for "0x1.0000000000000p+0" >> doesn't match function call return value: 20 != 6 >> FAIL: test_a_double:366: "%a" expected result for "0x1.0000000000000p+1" >> doesn't match function call return value: 20 != 6 >> >> FAIL: test_a_long_double:375: "%La" expected result for >> "0x0.0000000000000000000000000000p+0" doesn't match function call return >> value: 35 != 6 >> FAIL: test_a_long_double:376: "%La" expected result for >> "0x1.0000000000000000000000000000p+0" doesn't match function call return >> value: 35 != 6 >> FAIL: test_a_long_double:377: "%La" expected result for >> "0x1.0000000000000000000000000000p+1" doesn't match function call return >> value: 35 != 6 > > I don't know about these. It looks like the Solaris printf doesn't > handle the %a directive correctly and the tests (and the related > checks/optimization) might need to be disabled, which in turn might > involve extending the existing printf hook or adding a new one. I've found the following in Solaris 10 (and up) printf(3C): a, A A double argument representing a floating-point number is converted in the style "[-]0xh.hhhhp+d", where the single hexadecimal digit preceding the radix point is 0 if the value converted is zero and 1 otherwise and the number of hexadecimal digits after it is equal to the precision; if the precision is missing, the number of digits printed after the radix point is 13 for the conversion of a double value, 16 for the conversion of a long double value on x86, and 28 for the conversion of a long double value on SPARC; if the precision is zero and the '#' flag is not specified, no decimal-point character will appear. The letters "abcdef" are used for a conversion and the letters "ABCDEF" for A conver- sion. The A conversion specifier produces a number with 'X' and 'P' instead of 'x' and 'p'. The exponent will always contain at least one digit, and only as many more digits as necessary to represent the decimal exponent of 2. If the value is zero, the exponent is zero. The converted value is rounded to fit the specified output format according to the prevailing floating point rounding direction mode. If the conversion is not exact, an inexact exception is raised. A double argument representing an infinity or NaN is converted in the SUSv3 style of an e or E conversion specifier. I tried to check the relevant sections of the latest C99 and C11 drafts to check if this handling of missing precision is allowed by the standard, but I couldn't even fully parse the language there. > I don't have access to Solaris to fully debug and test this there. > Would you mind helping with it? Not at all: if it turns out that Solaris has bugs in this area, I can easily file them, too. Thanks. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University