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

D

David Mathog

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
 
N

Nobody

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).
 
D

David Mathog

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
 
D

David Mathog

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
 
I

Ian Collins

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.
 
D

David Mathog

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
 
I

Ian Collins

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!
 
D

David Mathog

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
 
K

Keith Thompson

Ian Collins said:
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.
 
I

ImpalerCore

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.
 
D

David Mathog

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
 
J

jacob navia

Le 03/06/11 21:13, David Mathog a écrit :
Which raises the question - why do we do that? Is there some reason
why the compilers never seem to supply the equivalent of libc?

Not all compilers do this.

The lcc-win compiler has its own basic library in 32 and 64 bits since
one of the goals was to support C99. It is the only compiler under
windows to support C99.

And this was done by a single individual working for years like a fool.

gcc never did it for windows and, apparently, for Solaris either.
 
I

Ian Collins

Which raises the question - why do we do that? Is there some reason
why the compilers never seem to supply the equivalent of libc?

Probably to avoid chaos when the OS and application are linked to
different version 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.

Quite. That's why you run old code with old compilers on old OSs. If
you want newer language features, use a newer OS. Whinging that an OS
and compiler that are sufficiently old to be no longer supported don't
do what you want is pointless.
 
N

Nobody

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.

It typically works out better than trying to use a compiler-specific libc,
which tends to fall down the moment you need to use the OS and thus use
the OS' DLLs which are linked against the OS' libc.

A compiler-specific libc would work better on Windows than on most Unices
due to the different dynamic linking models. On Windows, imported symbols
are tied to a specific DLL, so you can have multiple versions of MSVCRT
co-exist within a single process. On most Unices, you end up with symbol
conflicts. OTOH, with Windows' model you can run into problems if a
library function expects the caller to provide a FILE*, a pointer obtained
from malloc(), etc.
 
J

jacob navia

Le 04/06/11 07:32, Gordon Burditt a écrit :
The interfaces between libc and the rest of the OS (not the interface
between libc and the user program) may not be documented and changes
may not be announced. (I'm thinking especially of the syscall
interface to the kernel). This isn't too bad if the OS version of
libc is open-source, but the compiler vendor needs to track OS
changes. Someone who tries to duplicate that may be operating in
constant catch-up mode to keep up with the changes. The OS developers
figure that THEY are in charge of libc and if they make a change
that stays compatible (e.g. a matching libc/kernel change that won't
affect dynamic-linked programs, which works great unless you try
to use an OLD libc on a NEW kernel or vice-versa) they aren't going
to worry about that other libc some compiler vendor added.

This is less of an issue with math functions, *printf, and the
string library and such since they usually don't have much of an
interface with the kernel in areas where changes occur.

Exactly, and those functions should be provided by the compiler,
not the OS.
However, it's a problem trying to replace *PART* of libc.
Things also tend to go very badly if you try to link to multiple
versions of the same library.

This is absolutely no problem if the linker links to a compiler
version of the libc that THEN calls the OS libc if necessary.
I can see problems where the OS (and its version of libc) is young
enough to be under active development.

Bogus, since the libc interfaces didn't change since C89 in most
cases.
 
I

Ian Collins

Le 04/06/11 07:32, Gordon Burditt a écrit :

Exactly, and those functions should be provided by the compiler,
not the OS.

If so, how do you cope with the other dependencies? Not just technical,
but documentation. Do you provide replacement man pages? How about
linking to libraries built with the system libc?

I can see this getting very messy, very fast.
 
J

jacob navia

Le 05/06/11 05:47, Ian Collins a écrit :
If so, how do you cope with the other dependencies? Not just technical,
but documentation. Do you provide replacement man pages?

Yes, and lcc-win provides its own documentation since
there are sizable differences between the C99 printf
that I provide, and the system printf that is C89.
How about
linking to libraries built with the system libc?

lcc-win doesn't accept static library linking with
other compiler's libraries. I would have to
replicate Microsoft object code format (that is not
documented) and I would have to replicate the Microsoft
linker behavior, that is not documented either.

That is why lcc-win provides its own linker.
I can see this getting very messy, very fast.

Of course much less messy is to fail to provide
a C99 library when the system is not C99 like
mingw under windows (gcc doesn't run under windows).

I have demonstrated that if you want to do it you can
do it. But I am always wrong in this group, even if I
provide a full C99 implementation under windows.
 
I

Ian Collins

Le 05/06/11 05:47, Ian Collins a écrit :

Yes, and lcc-win provides its own documentation since
there are sizable differences between the C99 printf
that I provide, and the system printf that is C89.
OK.


lcc-win doesn't accept static library linking with
other compiler's libraries. I would have to
replicate Microsoft object code format (that is not
documented) and I would have to replicate the Microsoft
linker behavior, that is not documented either.

That is why lcc-win provides its own linker.

Ah, I see. I'm not used to the windows way of doing things. Do you
have problems with system libraries? I'm used to the Unix way where all
C compilers coexist by using the system ABI and libraries.
Of course much less messy is to fail to provide
a C99 library when the system is not C99 like
mingw under windows (gcc doesn't run under windows).

Now I'm really glad I don't have to use windows!
I have demonstrated that if you want to do it you can
do it. But I am always wrong in this group, even if I
provide a full C99 implementation under windows.

Why oh why do you have to take every comment as a personal insult? I'd
have thought you've been around Usenet long enough to how it works.
 
J

jacob navia

Le 05/06/11 10:22, Ian Collins a écrit :
Why oh why do you have to take every comment as a personal insult? I'd
have thought you've been around Usenet long enough to how it works.

Sorry I am getting paranoiac...

:)
 
J

Joel C. Salomon

Of course much less messy is to fail to provide
a C99 library when the system is not C99 like
mingw under windows (gcc doesn't run under windows).

Not sure what you mean; the MinGW project supplies GCC running under
windows, without requiring a Cygwin/MSys UNIX-emulation layer.

(Of course, as you pointed out, since the MS C runtime it links to is
not C99-compliant, the best the compiler can do is present a
free-standing environment -- but with a library *resembling* that of a
hosted implementation. See also <http://mingw.org/wiki/C99>.)

--Joel
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top