[Bug fortran/39570] New: cabs and cabsf are named differently on NetBSD 5

[Bug fortran/39570] New: cabs and cabsf are named differently on NetBSD 5

[aran at 100acres dot us]

On NetBSD 5.0, cabs and cabsf, defined in complex.h, are renames of __c99_cabs
and __c99_cabsf.  The build-in definitions in f95-lang.c specifically name
"cabs" and "cabsf".  On NetBSD 5.0, these are provided for compatibility and
emit a linker warning when linking.  This causes 7000 or so tests to fail.


-- 
           Summary: cabs and cabsf are named differently on NetBSD 5
           Product: gcc
           Version: 4.3.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: aran at 100acres dot us
 GCC build triplet: i386-unknown-netbsdelf5.99.7
  GCC host triplet: i386-unknown-netbsdelf5.99.7
GCC target triplet: i386-unknown-netbsdelf5.99.7


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

[Bug fortran/39570] cabs and cabsf are named differently on NetBSD 5

[aran at 100acres dot us]

------- Comment #1 from aran at 100acres dot us  2009-03-28 00:22 -------
Created an attachment (id=17552)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17552&action=view)
Grungy little patch.

This is a dirty hack for NetBSD 5.x only.  It is not intended to be applied to
the main source.  However, if you are running NetBSD 5.x and just want it
fixed, here is the patch for you.


-- 


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

[Bug fortran/39570] cabs and cabsf are named differently on NetBSD 5

[aran at 100acres dot us]

------- Comment #2 from aran at 100acres dot us  2009-03-28 00:23 -------
I really tried looking at Darwin's fix to the built-in problem, but that is
completely beyond me.  Any suggestions would be very nice.


-- 


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

[Bug fortran/39570] cabs and cabsf are named differently on NetBSD 5

[steven at gcc dot gnu dot org]

------- Comment #3 from steven at gcc dot gnu dot org  2009-03-28 01:02 -------
Completely beyond you, how?

What gcc does for darwin (and this is a hack, mind you), is basically replace
the standard C99 builtins with darwin-specific ones.  You have to do the same
for NetBSD.

See the following files in gcc/config/:
* darwin.c
* darwin-ppc-ldouble-patch.def

The code in darwin_patch_builtin() changes the assembler name of the builtin
function to a custom, darwin-specific version.  E.g. cabsl has a PATCH_BUILTIN
defines, so its DECL_NAME is the normal cabls name but its assembler name
becomes _cabsl_$LDBL128.

You need to do something similar (but probably less ugly) for NetBSD to make
this work.


-- 


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

[Bug fortran/39570] cabs and cabsf are named differently on NetBSD 5

[aran at 100acres dot us]

------- Comment #4 from aran at 100acres dot us  2009-03-28 01:34 -------
Subject: Re:  cabs and cabsf are named differently on NetBSD 5

What is beyond me is how darwin_patch_builtings gets called.  
It looks like it is called from rs6000.c in 
rs6000_init_builtins via the macro SUBTARGET_INIT_BUILTINS.  
i386.c doesn't appear to have this infrastructure.  I am 
not familiar enough with gcc internals to know what the 
impacts might be on other platforms if I start making 
changes here.  

Also, these renames are only for NetBSD 5.  How do I detect 
the os version.  The darwin example uses 
darwin_macosx_version_min.  Is there a NetBSD analog?

Aran

On Friday 27 March 2009 18:02:48 steven at gcc dot gnu dot 
org wrote:
> ------- Comment #3 from steven at gcc dot gnu dot org 
> 2009-03-28 01:02 ------- Completely beyond you, how?
>
> What gcc does for darwin (and this is a hack, mind you),
> is basically replace the standard C99 builtins with
> darwin-specific ones.  You have to do the same for
> NetBSD.
>
> See the following files in gcc/config/:
> * darwin.c
> * darwin-ppc-ldouble-patch.def
>
> The code in darwin_patch_builtin() changes the assembler
> name of the builtin function to a custom, darwin-specific
> version.  E.g. cabsl has a PATCH_BUILTIN defines, so its
> DECL_NAME is the normal cabls name but its assembler name
> becomes _cabsl_$LDBL128.
>
> You need to do something similar (but probably less ugly)
> for NetBSD to make this work.


-- 


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

[Bug fortran/39570] cabs and cabsf are named differently on NetBSD 5

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2009-03-28 09:54 -------
Another fix is to #undef TARGET_C99_FUNCTIONS as obviously netbsd is another
OS without a clue ...


-- 


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

[Bug target/39570] cabs and cabsf are named differently on NetBSD 5

[fxcoudert at gcc dot gnu dot org]

------- Comment #6 from fxcoudert at gcc dot gnu dot org  2009-03-28 13:09 -------
Switch component to "target", as this is target-specific behaviour not specific
to fortran (you'd have the same thing with C if you use __builtin_cabs() and
__builtin_cabsf().


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|fortran                     |target


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

[Bug target/39570] cabs and cabsf are named differently on NetBSD 5

[aran at 100acres dot us]

------- Comment #7 from aran at 100acres dot us  2009-03-28 18:13 -------
(In reply to comment #5)
> Another fix is to #undef TARGET_C99_FUNCTIONS as obviously netbsd is another
> OS without a clue ...
> 

Please explain how an OS with a clue would handle this problem.  Older binaries
that use the pre-c99 complex structure links to the existing linker symbols,
cabs and cabsf.  Changing the meaning of these symbols to the c99 meaning would
break these legacy programs.  It seems cluefull to decorate these symbols with
__c99_ and provide a rename in the header.  What would be a better solution?


-- 


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

[Bug target/39570] cabs and cabsf are named differently on NetBSD 5

[jakub at gcc dot gnu dot org]

------- Comment #8 from jakub at gcc dot gnu dot org  2009-03-28 18:30 -------
Symbol versioning, obviously.


-- 


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

[Bug target/39570] cabs and cabsf are named differently on NetBSD 5

[aran at 100acres dot us]

------- Comment #9 from aran at 100acres dot us  2009-03-28 19:38 -------
(In reply to comment #8)
> Symbol versioning, obviously.
> 
Yep, that would have worked.  Thanks for the clue.


-- 


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

[Bug target/39570] cabs and cabsf are named differently on NetBSD 5

[kuehro at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39570

Kai-Uwe Eckhardt <kuehro at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kuehro at gmx dot de

--- Comment #12 from Kai-Uwe Eckhardt <kuehro at gmx dot de> ---
Created attachment 34296
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34296&action=edit
a set of four patches for snapshot 20141214

I have used the darwin files as templates and made the necessary changes. It
reduces test failures from over 15000 (all run tests) to 27 in 3 files (patch
for PR 48244 applied as well).

[Bug target/39570] cabs and cabsf are named differently on NetBSD 5

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-11-07
                 CC|                            |fxcoudert at gcc dot
                   |                            |gnu.org
     Ever Confirmed|0                           |1

[Bug target/39570] cabs and cabsf are named differently on NetBSD 5

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cato at df dot lth.se

--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-22 13:25:53 UTC ---
I just checked
CC the one of the two NetBSD maintainers who has been last active...

 * * *

  CVS_RSH="ssh"  cvs -d "anoncvs@anoncvs.NetBSD.org:/cvsroot" co src/lib/libm/

and libm/compat contains only compat_cabsf and compat_cabs.c, which use a
struct instead of complex. That those are the only math-related changes, one
sees if on greps for __RENAME in
  CVS_RSH="ssh"  cvs -d "anoncvs@anoncvs.NetBSD.org:/cvsroot" co src/include/
i.e. complex.h contains:

#ifndef __LIBM0_SOURCE__
/* avoid conflict with historical cabs(struct complex) */
double cabs(double complex) __RENAME(__c99_cabs);
float cabsf(float complex) __RENAME(__c99_cabsf);
#endif

 * * *

Regarding the patch (cf. comment 3): Darwin has the files darwin.c in
./gcc/config/, which is included via ./gcc/config.gcc's
  tm_p_file="${tm_p_file} darwin-protos.h"
  target_gtfiles="\$(srcdir)/config/darwin.c"
  extra_objs="darwin.o"
One probably needs to do likewise for "*-*-netbsd*)".

In darwin.c, see darwin_patch_builtins and darwin_patch_builtin.

Those are used via SUBTARGET_INIT_BUILTINS in some ./gcc/config/* files.

[Bug target/39570] cabs and cabsf are named differently on NetBSD 5

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-21 09:48:08 UTC ---
(In reply to comment #9)
> Yep, that would have worked.  Thanks for the clue.

Is there any update on this issue?

(Cf. also bug 47716 comment 6
 and http://www.mailinglistarchive.com/fortran@gcc.gnu.org/msg17593.html )