Bug 41169 - [4.5 regression] libgfortran fails to build on Solaris 10+: '_Imaginary_I' undeclared
Summary: [4.5 regression] libgfortran fails to build on Solaris 10+: '_Imaginary_I' un...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libfortran (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: 4.5.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-25 20:08 UTC by Rainer Orth
Modified: 2009-09-02 15:01 UTC (History)
4 users (show)

See Also:
Host: *-*-solaris2.1[01]
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-08-25 21:32:24


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Orth 2009-08-25 20:08:27 UTC
Probably since the introduction of those two patches

2009-07-27  Tobias Burnus  <burnus@net-b.de>

	PR fortran/40863
	* c99_functions.c: Define complex I, if not defined.
	Create prototypes for C99 functions to silence warnings.
	* gfortran.map: Add missing functions to GFORTRAN_C99_1.0
	and new GFORTRAN_C99_1.1.

2009-07-25  Tobias Burnus  <burnus@net-b.de>

	PR fortran/33197
	* intrinsics/c99_functions.c (cacosf,cacos,cacosl,casinf,
	casin,casind,catanf,catan,catanl,cacoshf,cacosh,cacoshl,
	casinhf,casinh,casinhf,catanhf,catanh,catanhl): New functions.
	* c99_protos.h: Add prototypes for those.

libgfortran fails to build on Solaris 10 and 11:

/vol/gcc/src/gcc-dist/libgfortran/intrinsics/c99_functions.c: In function 'casinf':
/vol/gcc/src/gcc-dist/libgfortran/intrinsics/c99_functions.c:1585:11: error: '_Imaginary_I' undeclared (first use in this function)
/vol/gcc/src/gcc-dist/libgfortran/intrinsics/c99_functions.c:1585:11: error: (Each undeclared identifier is reported only once
/vol/gcc/src/gcc-dist/libgfortran/intrinsics/c99_functions.c:1585:11: error: for each function it appears in.)

and many more such errors.

The problem fails to be twofold: <complex.h> states:

/*
 * Compilation environments for Solaris must provide the _Imaginary datatype
 * and the compiler intrinsics _Complex_I and _Imaginary_I
 */
#define _Complex_I      _Complex_I
#define complex         _Complex
#define _Imaginary_I    _Imaginary_I
#define imaginary       _Imaginary
#undef  I
#define I               _Imaginary_I

but gcc obviously fails to do that.  Maybe this can be worked around with
fixincludes, but until this is fixed somehow, libgfortran needs to work around
the problem.

IRIX 6.5 is very likely affected as well: there, <complex.h> has

#define complex _Complex
#define _Complex_I ((float _Complex) (__I__))
#define imaginary _Imaginary
// #define _Imaginary_I ((float _Imaginary) 1)
#define _Imaginary_I __I__
#define I _Imaginary_I

and __I__ seems to be a compiler builtin.
Comment 1 Tobias Burnus 2009-08-25 20:47:15 UTC
That problem is very similar to the one on AIX, namely, <complex.h> is broken. I think the proper fix is to use fixinclude. For AIX the following patch worked
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00844.html

I think one needs do do something similar.

David, as you seemingly know the syntax of fixinclude: Could you have a look?
Comment 2 David Edelsohn 2009-08-25 21:32:24 UTC
Just follow the style that Steve Ellcey and I used for HPUX and AIX.  You basically should be able to take either of our stanzas in inclhack.def and substitute the regex in the "select" line that matches Solaris (and another for Irix).  Choose an appropriate "hackname", set "mach" line for Solaris, and use the original text from the header file in test_text.
Comment 3 Rainer Orth 2009-08-26 17:44:03 UTC
Josef, there are a couple of issues with complex support on Solaris 2/IRIX 6 where
you might be able to help.
Comment 4 Rainer Orth 2009-08-26 17:51:25 UTC
Subject: Re:  [4.5 regression] libgfortran fails to build on Solaris 10+: '_Imaginary_I' undeclared

> ------- Comment #2 from dje at gcc dot gnu dot org  2009-08-25 21:32 -------
> Just follow the style that Steve Ellcey and I used for HPUX and AIX.  You
> basically should be able to take either of our stanzas in inclhack.def and
> substitute the regex in the "select" line that matches Solaris (and another for
> Irix).  Choose an appropriate "hackname", set "mach" line for Solaris, and use
> the original text from the header file in test_text.

I don't have access to either an HP-UX or AIX system, but there may be an
additional complication on Solaris 2 and IRIX 6: unlike e.g. glibc and
maybe HP-UX and/or AIX, both systems define both _Complex_I and
_Imaginary_I and I in terms of the latter.  I'm not certain if we can just
throw the _Imaginary_I/imaginary definitions away and use

#define _Complex_I	(__extension__ 1.0iF)

instead or we must/should maintain the imaginary related definitions.
There seems to be some discussion around having removed
imaginary/_Imaginary_I in C99 TC2, but I'm not sure what the resolution
was.

I've manually done the former by dropping a hacked complex.h into
gcc/include-fixed and as expected the bootstrap finished.  If this is the
proper way to go, I can implement this via fixincludes.

	Rainer
Comment 5 joseph@codesourcery.com 2009-08-26 18:59:09 UTC
Subject: Re:  [4.5 regression] libgfortran fails to
 build on Solaris 10+: '_Imaginary_I' undeclared

On Wed, 26 Aug 2009, ro at techfak dot uni-bielefeld dot de wrote:

> I don't have access to either an HP-UX or AIX system, but there may be an
> additional complication on Solaris 2 and IRIX 6: unlike e.g. glibc and
> maybe HP-UX and/or AIX, both systems define both _Complex_I and
> _Imaginary_I and I in terms of the latter.  I'm not certain if we can just
> throw the _Imaginary_I/imaginary definitions away and use
> 
> #define _Complex_I      (__extension__ 1.0iF)
> 
> instead or we must/should maintain the imaginary related definitions.
> There seems to be some discussion around having removed
> imaginary/_Imaginary_I in C99 TC2, but I'm not sure what the resolution
> was.

There is no use in keeping definitions relating to imaginary types when 
GCC doesn't implement them, and the uses of imaginary types are extremely 
limited (as far as I can tell, they are only useful for building up 
complex values with exact control of infinities, NaNs and signed zeros in 
each component).

Comment 6 Rainer Orth 2009-08-27 16:25:45 UTC
Subject: Re:  [4.5 regression] libgfortran fails to build on Solaris 10+: '_Imaginary_I' undeclared

joseph at codesourcery dot com writes:

> There is no use in keeping definitions relating to imaginary types when 
> GCC doesn't implement them, and the uses of imaginary types are extremely 
> limited (as far as I can tell, they are only useful for building up 
> complex values with exact control of infinities, NaNs and signed zeros in 
> each component).

Ok, thanks.  So I'll implement my manual hack in fixincludes and submit
that patch once I'm ready.

I'll probably try to get a fix into OpenSolaris for CR 6549313

	http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6549313

so the fix will become unnecessary in the future.

What I don't fully understand yet is whether imaginary support in GCC
isn't/won't be there simply because it's been removed from C99 or nobody
thinks the work to implement it is worthwile.

	Rainer
Comment 7 joseph@codesourcery.com 2009-08-27 16:38:48 UTC
Subject: Re:  [4.5 regression] libgfortran fails to
 build on Solaris 10+: '_Imaginary_I' undeclared

On Thu, 27 Aug 2009, ro at techfak dot uni-bielefeld dot de wrote:

> What I don't fully understand yet is whether imaginary support in GCC
> isn't/won't be there simply because it's been removed from C99 or nobody
> thinks the work to implement it is worthwile.

It is:

* Only in a non-normative Annex (C99 TC3 makes further changes to make it 
possible for an implementation of this Annex also to conform to base C99).

* Not generally useful.

* Something involving ABI issues for every target (you need to define how 
_Imaginary parameters are handled, in particular, and you can't just say 
"like corresponding real types" since float _Imaginary is not promoted to 
double _Imaginary when passed in variable arguments to a variadic 
function, whereas float is promoted to double).  So you might want to 
disable this by default and only enable it for targets with a target hook 
to say the ABI has been agreed.

Comment 8 Rainer Orth 2009-09-02 14:59:05 UTC
Subject: Bug 41169

Author: ro
Date: Wed Sep  2 14:58:50 2009
New Revision: 151331

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151331
Log:
	PR libfortran/41169
	* inclhack.def (irix_complex): New fix.
	(solaris_complex): Likewise.
	* fixincl.x: Regenerate.
	* tests/base/complex.h [IRIX_COMPLEX_CHECK, SOLARIS_COMPLEX_CHECK]:
	New tests.

Modified:
    trunk/fixincludes/ChangeLog
    trunk/fixincludes/fixincl.x
    trunk/fixincludes/inclhack.def
    trunk/fixincludes/tests/base/complex.h

Comment 9 Rainer Orth 2009-09-02 15:01:42 UTC
Fixed for 4.5.0.
Comment 10 Rainer Orth 2010-06-02 16:50:13 UTC
Subject: Bug 41169

Author: ro
Date: Wed Jun  2 16:49:39 2010
New Revision: 160166

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160166
Log:
	Backport from mainline:
	2009-09-02  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	PR libfortran/41169
	* inclhack.def (irix_complex): New fix.
	(solaris_complex): Likewise.
	* fixincl.x: Regenerate.
	* tests/base/complex.h [IRIX_COMPLEX_CHECK, SOLARIS_COMPLEX_CHECK]:
	New tests.

	2009-09-08  Ralf Wildenhues  <Ralf.Wildenhues@gmx.de>

	* inclhack.def (solaris_complex): Remove superfluous backslashes from
	replacement string.  Replace \+ operator with \{1,\}.

Added:
    branches/gcc-4_4-branch/fixincludes/tests/base/complex.h
Modified:
    branches/gcc-4_4-branch/fixincludes/ChangeLog
    branches/gcc-4_4-branch/fixincludes/fixincl.x
    branches/gcc-4_4-branch/fixincludes/inclhack.def