public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ro at techfak dot uni-bielefeld dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/15266] [gfortran] libgfortran doesn't compile on IRIX 5.3
Date: Tue, 18 May 2004 23:18:00 -0000	[thread overview]
Message-ID: <20040518130647.25318.qmail@sourceware.org> (raw)
In-Reply-To: <20040503154240.15266.ro@techfak.uni-bielefeld.de>


------- Additional Comments From ro at techfak dot uni-bielefeld dot de  2004-05-18 13:06 -------
Subject: Re:  [gfortran] libgfortran doesn't compile on IRIX 5.3

pinskia at gcc dot gnu dot org writes:

> Yes and IIRC when IRIX (if ever) gets C99 most of everyone's code gets broken if they used csqrtf.

This is about cabs and friends on IRIX, but even so, not at all: IRIX
6.5.18 and up have C99 support, which is done like this:

<internal/math_core.h> (included from <math.h>) has

#if !defined(__c99)
struct __cabs_s { double a,b; };

extern double   cabs(struct __cabs_s);
[...]
#endif

and <complex.h> has

/* C99: 7.3.8.1 */

/* c89 also had functions cabs, cabsf and cabsl with the following
 * prototypes.
 *
 * double cabs (struct { double a,b; } z);
 * float cabsf (struct { float a,b; } z);
 * long double cabsl (struct { long double a,b; } z);
 *
 * As the passing of structs by value is different from passing
 * complex by value for the float and long double cases, the following
 * changes are being done to the C99 functions so as to maintain
 * backwards compatibility.
 * 
 * For the C99 functions we provide static definitions of these,
 * which in turn call the corresponding library functions with a __c99_
 * prefix.
 *
 * There are two drawbacks of this approach
 *
 *  1.  As each compilation will get its own copy of these functions,
 *      any program which relies on the address of these functions being
 *      unique will fail.
 *
 *  2.  If the user rolls his own version of these functions, they will
 *      never get invoked, and to get around this problem, the user
 *      should be able to disable the generation of these static functions.
 *      This is achieved by adding -D_C99_CABS_USER_DEFINED to the commandline.
 */


extern double      __c99_cabs  (double complex);
extern float       __c99_cabsf (float complex);
extern long double __c99_cabsl (long double complex);
#pragma optional   __c99_cabs
#pragma optional   __c99_cabsf
#pragma optional   __c99_cabsl

#ifdef _C99_CABS_USER_DEFINED

extern double       cabs  (double complex);
extern float        cabsf (float complex);
extern long double  cabsl (long double complex);

#else 

static inline double cabs       (double complex z)      {return __c99_cabs(z); }
static inline float  cabsf      (float complex z)       {return __c99_cabsf(z);}
static inline long double cabsl (long double complex z) {return __c99_cabsl(z);}

#endif /* _C99_CABS_USER_DEFINED */

These vendors usually know (and care) about backwards source and binary
compatibility.

	Rainer


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15266


  parent reply	other threads:[~2004-05-18 13:06 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-03 15:42 [Bug fortran/15266] New: [tree-ssa] " gcc-bugzilla at gcc dot gnu dot org
2004-05-03 15:50 ` [Bug libfortran/15266] " pinskia at gcc dot gnu dot org
2004-05-03 16:11 ` ro at techfak dot uni-bielefeld dot de
2004-05-18 11:45 ` [Bug libfortran/15266] [gfortran] " pinskia at gcc dot gnu dot org
2004-05-18 23:18 ` ro at techfak dot uni-bielefeld dot de [this message]
2004-08-11 21:56 ` [Bug libfortran/15266] " pinskia at gcc dot gnu dot org
2004-12-27 15:09 ` pinskia at gcc dot gnu dot org
2005-01-06 14:40 ` tobi at gcc dot gnu dot org
2005-01-07  0:16 ` coudert at clipper dot ens dot fr
2005-01-09 15:02 ` coudert at clipper dot ens dot fr
2005-01-09 15:07 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
2005-02-20 21:24 ` pinskia at gcc dot gnu dot org
2005-04-16 22:33 ` pinskia at gcc dot gnu dot org
2005-06-09 18:53 ` ro at techfak dot uni-bielefeld dot de
2005-06-13 16:10 ` fxcoudert at gcc dot gnu dot org
2005-06-15  0:00 ` cvs-commit at gcc dot gnu dot org
2005-06-15  0:01 ` ro at gcc dot gnu dot org
2005-06-15  0:02 ` ro at gcc dot gnu dot org
2005-06-15  8:22 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
2005-06-15  9:30 ` ro at techfak dot uni-bielefeld dot de
2005-06-15  9:37 ` Tobias dot Schlueter at physik dot uni-muenchen dot de
2005-07-08  1:37 ` mmitchel at gcc dot gnu dot org
2005-07-19 11:14 ` fxcoudert at gcc dot gnu dot org
2005-08-19 14:55 ` cvs-commit at gcc dot gnu dot org
2005-09-05 10:41 ` fxcoudert at gcc dot gnu dot org
2005-09-05 13:53 ` [Bug target/15266] " pinskia at gcc dot gnu dot org
2005-09-27 18:21 ` pinskia at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040518130647.25318.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).