Re: libstdc++/4563: [cygwin] `::acosf' undeclared (first use here)

Re: libstdc++/4563: [cygwin] `::acosf' undeclared (first use here)

[bkoz]

Synopsis: [cygwin]  `::acosf' undeclared (first use here)

State-Changed-From-To: open->analyzed
State-Changed-By: bkoz
State-Changed-When: Fri Oct 26 10:05:29 2001
State-Changed-Why:
    Is this still an issue?

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=4563&database=gcc

Re: libstdc++/4563: [cygwin] `::acosf' undeclared (first use here)

[billingd]

The following reply was made to PR libstdc++/4563; it has been noted by GNATS.

From: billingd@gcc.gnu.org
To: David.Billinghurst@riotinto.com, gcc-bugs@gcc.gnu.org,
  gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/4563: [cygwin]  `::acosf' undeclared (first use here)
Date: 10 Dec 2001 02:37:36 -0000

 Synopsis: [cygwin]  `::acosf' undeclared (first use here)
 
 State-Changed-From-To: analyzed->closed
 State-Changed-By: billingd
 State-Changed-When: Sun Dec  9 18:37:36 2001
 State-Changed-Why:
     Passes with cvs from 2001-12-09.  Not sure when it was fixed
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=4563&database=gcc

Re: libstdc++/4563: [cygwin] `::acosf' undeclared (first use here)

[billingd]

Synopsis: [cygwin]  `::acosf' undeclared (first use here)

State-Changed-From-To: analyzed->closed
State-Changed-By: billingd
State-Changed-When: Sun Dec  9 18:37:36 2001
State-Changed-Why:
    Passes with cvs from 2001-12-09.  Not sure when it was fixed

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=4563&database=gcc

libstdc++/4563: [cygwin] `::acosf' undeclared (first use here)

[David.Billinghurst]

>Number:         4563
>Category:       libstdc++
>Synopsis:       [cygwin]  `::acosf' undeclared (first use here)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Oct 13 17:16:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     David Billinghurst
>Release:        gcc 3.1
>Organization:
>Environment:
i686-pc-cygwin
>Description:
http://gcc.gnu.org/ml/gcc-bugs/2001-07/msg00995.html

Around 10 of my g++ testsuite failures on cygwin due to the use of the compiler option "-ansi" in the g++ testsuite.

The failures are of the form: 

In file included 
	from <...>/include/bits/std_complex.h:43,                  
	from <...>/libstdc++-v3/include/complex:31,
	from <...>/g++.brendan/crash20.C:3:
<...>/std_cmath.h: In function `float std::acos(float)':
<...>/std_cmath.h:95: `::acosf' undeclared (first use here) 
<...>/std_cmath.h: In function `float std::asin(float)':  
.... /std_cmath.h:113: `::asinf' undeclared (first use here)
.... /std_cmath.h: In function `float std::atan(float)':
.... /std_cmath.h:131: `::atanf' undeclared (first use here)

and so on.

In /usr/include/math.h the declaration of the these functions is guarded by 
#ifndef __STRICT_ANSI__
#endif
which seems reasonable

but the command line used to run the test has the flag "-ansi" 

/usr/local/obj/gcc-ec/gcc/testsuite/../g++ --verbose -save-temps
-B/usr/local/obj/gcc-ec/gcc/testsuite/../  -nostdinc++
-I/usr/local/obj/gcc-ec/i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin
-I/usr/local/obj/gcc-ec/i686-pc-cygwin/libstdc++-v3/include
-I/usr/local/src/gcc/libstdc++-v3/libsupc++
-I/usr/local/src/gcc/libstdc++-v3/libio
-I/usr/local/src/gcc/libstdc++-v3/testsuite -fmessage-length=0
-pedantic-errors -Wno-long-long  -c  -o
/usr/local/obj/gcc-ec/gcc/testsuite/crash20.o
/usr/local/src/gcc/gcc/testsuite/g++.old-deja/g++.brendan/crash20.C

Gabriel Dos Reis <gdr@codesourcery.com> wrote:

A reliable fix is to adopt the __builtin_xxx road, but we don't have built-in support for the incriminated functions :-(

This reopens the question of whether we should test for features (at configure time) with -ansi on.  

Currently here is what happens: we test  support for features without turning on -ansi and then we build the library on top of them. Latter, users specify -ansi and boom we get confused...

On the other hand, detecting features with -ansi on may lead us miss some nonetheless supported features in non-strict mode.

I don't have any definitive answer.

I'll work on a patch for your problem.  Thanks.

Alexandre Oliva <aoliva at redhat dot com> wrote:

It seems to me that the best course of action would be to test for the feature both with and without -ansi, and behave accordingly.  But then, how about _POSIX_SOURCE and other _*_SOURCE macros? :-(




>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: