HUGE_VAL on Solaris (was: Re: On dropping -D_REENTRANT -D_THREAD_SAFE)

[Albert Chin]

On Wed, Jun 25, 2008 at 12:44:31PM +0200, Simon Josefsson wrote:
> Albert Chin <gnutls-dev at mlists.thewrittenword.com> writes:
> 
> > On Mon, Jan 07, 2008 at 10:12:13PM +0100, Simon Josefsson wrote:
> >> Florian Weimer <fweimer at bfk.de> writes:
> >> 
> >> > * Simon Josefsson:
> >> >
> >> >> gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I..  -I../includes -I../includes -I../lgl -I../lgl -I../gl -I../gl -I./cfg  -pipe -I/tmp/jas//include -g -O2 -MT shared.o -MD -MP -MF .deps/shared.Tpo -c -o shared.o `test -f 'cfg/shared.c' || echo './'`cfg/shared.c
> >> >> cfg/shared.c: In function `store_single_arg':
> >> >> cfg/shared.c:727: error: wrong type argument to unary plus
> >> >> cfg/shared.c:727: error: wrong type argument to unary minus
> >> >>
> >> >> The line reads:
> >> >>
> >> >> 			if (double_val == +HUGE_VAL || double_val == -HUGE_VAL)
> >> >
> >> > Looks like a GCC bug to me.  I can't reproduce this with:
> >> >
> >> > gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
> >> > gcc (GCC) 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
> >> 
> >> This was gcc 3.4.x and 4.0.3 on solaris 5.10, but on a machine that I
> >> suspect doesn't have enough administrative TLC to have properly
> >> installed tools.  So unless someone else reports the same issue, let's
> >> ignore it.
> >
> > We see it with gcc-3.4.4 on Solaris 10/SPARC.
> 
> Indeed the problem seems real, however it seems to be a gcc bug:
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
> 
> A patch for gcc back-ported to 3.4.x is:
> 
> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02123.html
> 
> I can't test the patch, but it seems to address the problem.

We have the patch.

> Does any of the suggested work-arounds work for you?  I.e., add the
> following before the line containing "cfg+.h" in src/cfg/shared.c:
> 
> #define HUGE_VAL (__builtin_huge_val())
> 
> This work-around appears to work on the solaris 5.10 I have access to.
> 
> I'm not sure if we can detect this brokenness in a clean way, but
> patches are welcome.  Otherwise, perhaps this message can serve as
> sufficient documentation to work around this gcc problem.

It's only a problem with --std=gnu99. We just build without that
(ac_cv_prog_cc_c99=no) and things are ok.

-- 
albert chin (china at thewrittenword.com)