* Re: bug#34817: coreutils 8.31 compile failure on rhel5 [not found] <201903111716.x2BHGEjY016306@refuge.colorado.edu> @ 2019-03-11 23:42 ` Paul Eggert 2019-03-13 18:35 ` Bruno Haible 0 siblings, 1 reply; 5+ messages in thread From: Paul Eggert @ 2019-03-11 23:42 UTC (permalink / raw) To: Jesse; +Cc: Gnulib bugs, 34817 [-- Attachment #1: Type: text/plain, Size: 290 bytes --] On 3/11/19 10:16 AM, Jesse wrote: > The latest coreutils no longer compiles cleanly on rhel5 x32 and x64 > (I know rhel5 is EOL). Thanks for the bug report. I installed the attached patch into Gnulib. Would you please give it a try and report back? I can't easily test on RHEL 5. Thanks. [-- Attachment #2: 0001-strtod-fix-clash-with-strtold.patch --] [-- Type: text/x-patch, Size: 2268 bytes --] From 0562b040fa17f1722ba2b3096067b45d0582ca53 Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Mon, 11 Mar 2019 16:40:29 -0700 Subject: [PATCH] strtod: fix clash with strtold Problem reported for RHEL 5 by Jesse Caldwell (Bug#34817). * lib/strtod.c (compute_minus_zero, minus_zero): Simplify by remving the macro / external variable, and having just a function. User changed. This avoids the need for an external variable that might clash. --- ChangeLog | 9 +++++++++ lib/strtod.c | 11 +++++------ 2 files changed, 14 insertions(+), 6 deletions(-) diff --git a/ChangeLog b/ChangeLog index b633380b5..e5ba0caa4 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2019-03-11 Paul Eggert <eggert@cs.ucla.edu> + + strtod: fix clash with strtold + Problem reported for RHEL 5 by Jesse Caldwell (Bug#34817). + * lib/strtod.c (compute_minus_zero, minus_zero): + Simplify by remving the macro / external variable, + and having just a function. User changed. This avoids + the need for an external variable that might clash. + 2019-03-10 Bruno Haible <bruno@clisp.org> alloca-opt: Fix conflict mingw's new <alloca.h> file. diff --git a/lib/strtod.c b/lib/strtod.c index b9eaa51b4..69b1564e1 100644 --- a/lib/strtod.c +++ b/lib/strtod.c @@ -294,16 +294,15 @@ parse_number (const char *nptr, ICC 10.0 has a bug when optimizing the expression -zero. The expression -MIN * MIN does not work when cross-compiling to PowerPC on Mac OS X 10.5. */ -#if defined __hpux || defined __sgi || defined __ICC static DOUBLE -compute_minus_zero (void) +minus_zero (void) { +#if defined __hpux || defined __sgi || defined __ICC return -MIN * MIN; -} -# define minus_zero compute_minus_zero () #else -DOUBLE minus_zero = -0.0; + return -0.0; #endif +} /* Convert NPTR to a DOUBLE. If ENDPTR is not NULL, a pointer to the character after the last one used in the number is put in *ENDPTR. */ @@ -479,6 +478,6 @@ STRTOD (const char *nptr, char **endptr) /* Special case -0.0, since at least ICC miscompiles negation. We can't use copysign(), as that drags in -lm on some platforms. */ if (!num && negative) - return minus_zero; + return minus_zero (); return negative ? -num : num; } -- 2.20.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: bug#34817: coreutils 8.31 compile failure on rhel5 2019-03-11 23:42 ` bug#34817: coreutils 8.31 compile failure on rhel5 Paul Eggert @ 2019-03-13 18:35 ` Bruno Haible 2019-03-13 21:49 ` Paul Eggert 0 siblings, 1 reply; 5+ messages in thread From: Bruno Haible @ 2019-03-13 18:35 UTC (permalink / raw) To: bug-gnulib; +Cc: 34817, Paul Eggert, Jesse Paul Eggert wrote: > Thanks for the bug report. I installed the attached patch into Gnulib. A simpler fix would have been to mark the 'minus_zero' variable as 'static': --- a/lib/strtod.c +++ b/lib/strtod.c @@ -302,7 +302,7 @@ compute_minus_zero (void) } # define minus_zero compute_minus_zero () #else -DOUBLE minus_zero = -0.0; +static DOUBLE minus_zero = -0.0; #endif /* Convert NPTR to a DOUBLE. If ENDPTR is not NULL, a pointer to the When this variable was introduced, it ought to have been 'static' from the beginning (2010-11-05); but this was harmless until 2019-01-30. I did not notice the problem when doing the 2019-01-30 changes; sorry. Bruno ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bug#34817: coreutils 8.31 compile failure on rhel5 2019-03-13 18:35 ` Bruno Haible @ 2019-03-13 21:49 ` Paul Eggert 2019-03-13 22:36 ` Bruno Haible 0 siblings, 1 reply; 5+ messages in thread From: Paul Eggert @ 2019-03-13 21:49 UTC (permalink / raw) To: Bruno Haible, bug-gnulib; +Cc: 34817, Jesse On 3/13/19 11:35 AM, Bruno Haible wrote: > A simpler fix would have been to mark the 'minus_zero' variable as 'static': Yes, that would have been a smaller change. Although I originally did that, there's a reason I went for the larger change. Making the variable 'static' might cause some compilers to notice that the variable never changes, so it's a constant, so it can be folded, and then they (mistakenly) convert -0.0 to 0.0. Originally the variable was extern and the extern hack prevents most compilers from doing this incorrect optimization (unless they're doing whole-program optimization, which typically they aren't). Since making the variable static removed the hack, I decided it was clearer to use the larger change, which makes it more obvious that we aren't trying to work around this potential problem any more. I hope the issue I mentioned is not a real problem. If it is, we can go back to the old code except rename the variable so that it's called "lminus_zero" for the long double case. I considered doing that too, but that's even more confusing and I hope we don't have to be that confusing. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bug#34817: coreutils 8.31 compile failure on rhel5 2019-03-13 21:49 ` Paul Eggert @ 2019-03-13 22:36 ` Bruno Haible 0 siblings, 0 replies; 5+ messages in thread From: Bruno Haible @ 2019-03-13 22:36 UTC (permalink / raw) To: Paul Eggert; +Cc: Jesse, 34817, bug-gnulib Hi Paul, > Making the variable 'static' might cause some compilers to notice that > the variable never changes, so it's a constant, so it can be folded, and > then they (mistakenly) convert -0.0 to 0.0. Originally the variable was > extern and the extern hack prevents most compilers from doing this > incorrect optimization (unless they're doing whole-program optimization, > which typically they aren't). Since making the variable static removed > the hack, I decided it was clearer to use the larger change, which makes > it more obvious that we aren't trying to work around this potential > problem any more. Yes, I perfectly agree. When I said "a simpler fix", I did not mean "a better fix". Your fix is the more reliable one! Bruno ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: bug#34817: coreutils 8.31 compile failure on rhel5
@ 2019-03-11 23:54 Jesse
0 siblings, 0 replies; 5+ messages in thread
From: Jesse @ 2019-03-11 23:54 UTC (permalink / raw)
To: Paul Eggert; +Cc: Gnulib bugs, 34817
>
> On 3/11/19 10:16 AM, Jesse wrote:
> > The latest coreutils no longer compiles cleanly on rhel5 x32 and x64
> > (I know rhel5 is EOL).
>
> Thanks for the bug report. I installed the attached patch into Gnulib.
> Would you please give it a try and report back? I can't easily test on
> RHEL 5. Thanks.
Hello,
coreutils 8.31 compiles cleanly (warnings, but no errors) on rhel5 x32
and x64 with the provided patch applied. That you for the prompt response!
Jesse
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-03-13 22:36 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <201903111716.x2BHGEjY016306@refuge.colorado.edu> 2019-03-11 23:42 ` bug#34817: coreutils 8.31 compile failure on rhel5 Paul Eggert 2019-03-13 18:35 ` Bruno Haible 2019-03-13 21:49 ` Paul Eggert 2019-03-13 22:36 ` Bruno Haible 2019-03-11 23:54 Jesse
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).