Asp Forum - OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc

David Mathog

6/2/2011 8:53:00 PM

Since this is OT I will keep it very brief. C code that compiles
cleanly on linux with

gcc -std=c99 -Wall -pedantic -lm -o test test.c

has problems on Solaris 8 (Sparc) with gcc 4.3.3, where it cannot find
the definitions of NAN, FP_NAN, FP_INFINITE, or the prototypes (and
most likely the functions, if some of this wasn't an error that kept
it from getting that far) for fmax, fmin, isinf, isnormal, and round.

Anybody know why this happens, or better yet, how to work around it?

Thanks,

David Mathog

28 Answers

John Doe

6/2/2011 9:17:00 PM

On Thu, 02 Jun 2011 13:52:35 -0700, David Mathog wrote:

> Since this is OT I will keep it very brief. C code that compiles
> cleanly on linux with
>
> gcc -std=c99 -Wall -pedantic -lm -o test test.c
>
> has problems on Solaris 8 (Sparc) with gcc 4.3.3, where it cannot find
> the definitions of NAN, FP_NAN, FP_INFINITE, or the prototypes (and
> most likely the functions, if some of this wasn't an error that kept
> it from getting that far) for fmax, fmin, isinf, isnormal, and round.
>
> Anybody know why this happens, or better yet, how to work around it?

These definitions/declarations belong in <math.h>, which is part of the
standard library (libc) rather than gcc. Linux uses GNU libc, Solaris has
its own version (which may or may not support C99; from your report, it
appears not to).

David Mathog

6/2/2011 9:18:00 PM

On Jun 2, 1:52 pm, David Mathog <dmat...@gmail.com> wrote:

This may have something to do with it:

**************test.c***************
#include <stdlib.h>
#include <stdio.h>
#include <math.h>

int main(void){
double dv;

dv=0.0;
fprintf(stdout,"DEBUG zero %llX\n",dv);
dv=log(-1);
fprintf(stdout,"DEBUG nan %llX\n",dv);
dv=log(0);
fprintf(stdout,"DEBUG -inf %llX\n",dv);
dv=-log(0);
fprintf(stdout,"DEBUG inf %llX\n",dv);

exit(EXIT_SUCCESS);
}
******************************************

Compile with: gcc -std=c99 -lm -o test test.c

On linux (Opteron machine):

../test
DEBUG zero 0
DEBUG nan 7FF8000000000000
DEBUG -inf FFF0000000000000
DEBUG inf 7FF0000000000000

and on Solaris (Sparc):

../test
DEBUG zero 0
DEBUG nan FFF0000000000000
DEBUG -inf FFF0000000000000
DEBUG inf 7FF0000000000000

So even though they are both IEEE math, there is a difference in the
bits that are set, so that
on the Opteron one can distinguish nan,-inf,and inf from the bit
pattern, but that isn't the case
on the Sparc. At least with the compiler options I used - for all I
know there may be some switch
that makes NAN on the Sparc (v9 architecture, I think) like it is on
the Opteron.

Regards,

David Mathog

David Mathog

6/2/2011 9:37:00 PM

On Jun 2, 2:18 pm, David Mathog <dmat...@gmail.com> wrote:

> and on Solaris (Sparc):
>
> ./test
> DEBUG zero 0
> DEBUG nan FFF0000000000000
> DEBUG -inf FFF0000000000000
> DEBUG inf 7FF0000000000000
>

Using Forte 7 compiler (5.4) there is such a flag:

cc -xlibmieee -lm -o test test.c
../test
DEBUG zero 0
DEBUG nan FFFFFFFFFFFFFFFF
DEBUG -inf FFF0000000000000
DEBUG inf 7FF0000000000000

Anybody know what the gcc equivalent is? If I can get the compiler to
generate
code with the right bits, writing isinf etc. becomes a lot easier..

Thanks,

David Mathog

Ian Collins

6/2/2011 9:59:00 PM

On 06/ 3/11 09:37 AM, David Mathog wrote:
> On Jun 2, 2:18 pm, David Mathog<dmat...@gmail.com> wrote:
>
>> and on Solaris (Sparc):
>>
>> ./test
>> DEBUG zero 0
>> DEBUG nan FFF0000000000000
>> DEBUG -inf FFF0000000000000
>> DEBUG inf 7FF0000000000000
>>
>
> Using Forte 7 compiler (5.4) there is such a flag:

Is there a good reason why you are using an OS and tools that are over a
decade old?

Both where EOL'd long ago.

With this century's tools, your code compiles fine and gives the same
result as Linux on amd64.

--
Ian Collins

David Mathog

6/2/2011 10:18:00 PM

On Jun 2, 2:59 pm, Ian Collins <ian-n...@hotmail.com> wrote:

> Is there a good reason why you are using an OS and tools that are over a
> decade old?

There is a reason. While the OS is that old, gcc 4.3.3 is pretty
recent. That's why I'm surprised gcc doesn't work here. Digging
around in the Forte documentation all of these bits and pieces seem to
be there, but in sunmath.h and libsunmath, rather than math.h and
libm, and gcc doesn't seem to work around these missing pieces. Not
even for fmax (and fmin) which only need

#define fmax(A,B) ( A>=B ? A : B)

in the math.h header file.

Thanks,

David Mathog

Ian Collins

6/2/2011 10:35:00 PM

On 06/ 3/11 10:18 AM, David Mathog wrote:
> On Jun 2, 2:59 pm, Ian Collins<ian-n...@hotmail.com> wrote:
>
>> Is there a good reason why you are using an OS and tools that are over a
>> decade old?
>
> There is a reason. While the OS is that old, gcc 4.3.3 is pretty
> recent. That's why I'm surprised gcc doesn't work here.

Don't forget the OS pre-dates C99!

--
Ian Collins

David Mathog

6/2/2011 11:02:00 PM

On Jun 2, 3:35 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 06/ 3/11 10:18 AM, David Mathog wrote:
>
> > On Jun 2, 2:59 pm, Ian Collins<ian-n...@hotmail.com> wrote:
>
> >> Is there a good reason why you are using an OS and tools that are over a
> >> decade old?
>
> > There is a reason. While the OS is that old, gcc 4.3.3 is pretty
> > recent. That's why I'm surprised gcc doesn't work here.
>
> Don't forget the OS pre-dates C99!

Right, but the present issues all revolve around IEEE-754 double
support, which dates back to 1985 or so.
I think "nobody" hit it on the head a few posts forward, regarding
libm and math.h. If the compiler
distribution included Gnu libc then the age of the underlying OS
wouldn't matter. Unfortunately in this case
the compiler uses libm from the OS, and so no matter how new the
compiler, some parts of it are stuck in the past with the OS.

Regards,

David Mathog

Keith Thompson

6/2/2011 11:05:00 PM

Ian Collins <ian-news@hotmail.com> writes:
> On 06/ 3/11 10:18 AM, David Mathog wrote:
>> On Jun 2, 2:59 pm, Ian Collins<ian-n...@hotmail.com> wrote:
>>
>>> Is there a good reason why you are using an OS and tools that are over a
>>> decade old?
>>
>> There is a reason. While the OS is that old, gcc 4.3.3 is pretty
>> recent. That's why I'm surprised gcc doesn't work here.
>
> Don't forget the OS pre-dates C99!

And the math library (that's both libmath.whatever and <math.h> are
provided by the OS, not by gcc.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.ne...
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

ImpalerCore

6/3/2011 1:45:00 PM

On Jun 2, 7:01 pm, David Mathog <dmat...@gmail.com> wrote:
> On Jun 2, 3:35 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>
> > On 06/ 3/11 10:18 AM, David Mathog wrote:
>
> > > On Jun 2, 2:59 pm, Ian Collins<ian-n...@hotmail.com> wrote:
>
> > >> Is there a good reason why you are using an OS and tools that are over a
> > >> decade old?
>
> > > There is a reason. While the OS is that old, gcc 4.3.3 is pretty
> > > recent. That's why I'm surprised gcc doesn't work here.
>
> > Don't forget the OS pre-dates C99!
>
> Right, but the present issues all revolve around IEEE-754 double
> support, which dates back to 1985 or so.
> I think "nobody" hit it on the head a few posts forward, regarding
> libm and math.h. If the compiler
> distribution included Gnu libc then the age of the underlying OS
> wouldn't matter. Unfortunately in this case
> the compiler uses libm from the OS, and so no matter how new the
> compiler, some parts of it are stuck in the past with the OS.

The same issue occurs with the Microsoft C Runtime and C99 printf
support. You can compile 'printf( "%lu %zu\n", sizeof (int), sizeof
(int) );' with gcc -std=c99 in the MinGW environment, but because it
links in the Microsoft Runtime, the printf statement just generates "4
zu". Similar problems occur for modifiers 't' and 'll'.

Best regards,
John D.

David Mathog

6/3/2011 7:13:00 PM

On Jun 3, 6:45 am, ImpalerCore <jadil...@gmail.com> wrote:

> The same issue occurs with the Microsoft C Runtime and C99 printf
> support. You can compile 'printf( "%lu %zu\n", sizeof (int), sizeof
> (int) );' with gcc -std=c99 in the MinGW environment, but because it
> links in the Microsoft Runtime, the printf statement just generates "4
> zu". Similar problems occur for modifiers 't' and 'll'.

Which raises the question - why do we do that? Is there some reason
why the compilers never seem to supply the equivalent of libc? Sure,
there are going to be instances where one can get away with using the
native OS libc, but clearly there are lots of other cases where it
doesn't work out so well. And I would wager it works out less and
less well as the target OS ages.

Here is another test which failed indicating a Solaris vs. Linux
difference:

36 Fail 0000000.053 22c22
< NaN,Inf,Inf,-Inf,NaN
---
> nan,inf,inf,-inf,nan

Do any of the C standards say what fprintf("%lf\n",dval) is supposed
to emit in each of these cases? Is it really free to use alternate
capitalization? I can see the upside in ignoring the punctuation when
reading in these values, but not so much in emitting them.

Regards,

David

comp.lang.c

OT: missing C99 math pieces in gcc 4.x on Solaris 8 (sparc

David Mathog

John Doe

David Mathog

David Mathog

Ian Collins

David Mathog

Ian Collins

David Mathog

Keith Thompson

ImpalerCore

David Mathog

x Login to ForumsZone