Clang need to implement '#pragma redefine_extname' to support C++ on Solaris.

[Quuxplusone]

Bugzilla Link	PR5172
Status	RESOLVED FIXED
Importance	P normal
Reported by	Edward O'Callaghan (eocallaghan@alterapraxis.com)
Reported on	2009-10-12 19:27:04 -0700
Last modified on	2018-11-07 00:22:18 -0800
Version	trunk
Hardware	Sun Solaris
CC	andreybokhanko@gmail.com, csdavec@swan.ac.uk, dgregor@apple.com, llvm-bugs@lists.llvm.org, llvm@sishbi.me.uk, sbn@tbricks.com
Fixed by commit(s)
Attachments	wchar_iso.h (14669 bytes, text/x-chdr) PR5172.patch (6179 bytes, text/plain) PR5172.patch (8673 bytes, text/plain)
Blocks	PR4696
Blocked by	PR5326
See also

G'Day,

On Solaris: /usr/include/iso/wchar_iso.h uses #pragma redefine_extname to
redefine fgetwc as __fgetwc_xpg5 as well as a number of other functions.

Thus, our simple Hello World fails to build as follows:

-bash-3.2$ cat hello.cpp
#include <iostream>

//using namespace std;

int main() {
  std::cout << "Hello World!" << std::endl;
  return 0;
}

In file included from /opt/gcc4/include/c++/4.2.4/iostream:44:
In file included from /opt/gcc4/include/c++/4.2.4/ostream:44:
In file included from /opt/gcc4/include/c++/4.2.4/ios:42:
In file included from /opt/gcc4/include/c++/4.2.4/iosfwd:48:
In file included from /opt/gcc4/include/c++/4.2.4/bits/postypes.h:45:
/opt/gcc4/include/c++/4.2.4/cwchar:148:11: error: no member named 'fgetwc' in
the global namespace
  using ::fgetwc;
        ~~^
/opt/gcc4/include/c++/4.2.4/cwchar:149:11: error: no member named 'fgetws' in
the global namespace
  using ::fgetws;
        ~~^
/opt/gcc4/include/c++/4.2.4/cwchar:150:11: error: no member named 'fputwc' in
the global namespace
  using ::fputwc;
        ~~^
/opt/gcc4/include/c++/4.2.4/cwchar:151:11: error: no member named 'fputws' in
the global namespace
  using ::fputws;
        ~~^
/opt/gcc4/include/c++/4.2.4/cwchar:155:11: error: no member named 'getwc' in
the global namespace
  using ::getwc;
        ~~^
/opt/gcc4/include/c++/4.2.4/cwchar:156:11: error: no member named 'getwchar' in
the global namespace
  using ::getwchar;
        ~~^
/opt/gcc4/include/c++/4.2.4/cwchar:161:11: error: no member named 'putwc' in
the global namespace
  using ::putwc;
        ~~^
/opt/gcc4/include/c++/4.2.4/cwchar:162:11: error: no member named 'putwchar' in
the global namespace
  using ::putwchar;
        ~~^
/opt/gcc4/include/c++/4.2.4/cwchar:165:11: error: no member named 'ungetwc' in
the global namespace
  using ::ungetwc;
        ~~^
/opt/gcc4/include/c++/4.2.4/cwchar:184:11: error: no member named 'wcsftime' in
the global namespace
  using ::wcsftime;
        ~~^
/opt/gcc4/include/c++/4.2.4/cwchar:195:11: error: no member named 'wcstok' in
the global namespace
  using ::wcstok;

Background:
http://developer.apple.com/mac/library/documentation/DeveloperTools/gcc-4.0.1/gcc/Symbol_002dRenaming-Pragmas.html
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00685.html

Cheers,
Edward.

[Quuxplusone]

Attached wchar_iso.h (14669 bytes, text/x-chdr): iso/wchar_iso.h

[Quuxplusone]

The redefine_extname pragma has about the same semantics as the GNU asm
extension, which is already implemented in Clang via the AsmLabelAttr
attribute. The GNU extension uses the asm keyword on a function declarator, as
described here:

  http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Asm-Labels.html#Asm-Labels

The redefine_extname pragma could be implemented by looking at the logic for
#pragma weak, which shows how to associate names in pragmas with actual
declarations, then using that information to attach an AsmLabelAttr to the
function declaration referenced by redefine_extname. It might be worth adding a
bit to AsmLabelAttr to state whether it came from redefine_extname vs. coming
from __asm__("blah").

[Quuxplusone]

It seems we need to define:

__PRAGMA_REDEFINE_EXTNAME

In lib/Frontend/InitPreprocessor.cpp
when we have '#pragma redefine_extname' support, so we are blocked by the patch
in PR5326.

So something like;

Index: lib/Frontend/InitPreprocessor.cpp
===================================================================
--- lib/Frontend/InitPreprocessor.cpp   (revision 89660)
+++ lib/Frontend/InitPreprocessor.cpp   (working copy)
@@ -369,6 +369,10 @@
     }
   }

+  if (LangOpts.Sun) {
+    DefineBuiltinMacro(Buf, "__PRAGMA_REDEFINE_EXTNAME");
+  }
+
   if (LangOpts.Optimize)
     DefineBuiltinMacro(Buf, "__OPTIMIZE__=1");
   if (LangOpts.OptimizeSize)

Making a blocker to this PR.
Regards,

[Quuxplusone]

Attached PR5172.patch (6179 bytes, text/plain): PR5172.patch outliner, non-workable.

[Quuxplusone]

Attached PR5172.patch (8673 bytes, text/plain): PR5172.patch (2)

[Quuxplusone]

I am seeing this on Solaris as well.
A simple program emits many errors caused the stdc++ header file:
wchar

I am on gcc 4.5.0 - Solaris 10 x86

This is blocking the use of clang on my platform :(

[Quuxplusone]

This doesn't seem to be Solaris only. I have the same problem on Windows 7 with mingw gcc 4.5.0.

[Quuxplusone]

Same problem with MinGW reported @ http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-August/010475.html

[Quuxplusone]

On MinGW there is no redefine_extname in the headers, the problem might be somewhere else.

[Quuxplusone]

This is implemented in r150882.

It is now possible to compile C++ programs that use standard Solaris headers with clang.

[Quuxplusone]

clang behavior wrt this pragma still differs from GCC and Sun Studio C++ on
Solaris:

$ cat -n a.cpp
     1  extern "C" {
     2
     3  struct statvfs64 {
     4  };
     5
     6  #pragma redefine_extname statvfs64 statvfs
     7
     8  int statvfs64(struct statvfs64 *);
     9
    10  }
    11
    12  int main()
    13  {
    14      struct statvfs64 st;
    15      statvfs64(&st);
    16      return 0;
    17  }
$ /opt/clang/bin/clang++ -c a.cpp && nm a.o | grep statvfs
[8]     |         0|         0|NOTY |GLOB |0    |UNDEF  |statvfs64
$ /opt/csw/gcc4/bin/g++ -c a.cpp && nm a.o | grep statvfs
[8]     |         0|         0|NOTY |GLOB |0    |UNDEF  |statvfs
 $ CC -c a.cpp && nm a.o | grep statvfs
[22]    |         0|         0|FUNC |GLOB |0    |UNDEF  |statvfs
$ /opt/clang/bin/clang++ -v
clang version 3.1 (branches/release_31 155814)
Target: i386-pc-solaris2.10
Thread model: posix

[Quuxplusone]

I submitted a patch for the problem described in comment 11:
http://reviews.llvm.org/D10187

Yours,
Andrey
======
Software Engineer
Intel Compiler Team
Intel

[Quuxplusone]

Fix committed; r239466.

Andrey