[llvm-bugs] [Bug 27189] New: __func__ incompatibilities with gcc

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=27189

            Bug ID: 27189
           Summary: __func__ incompatibilities with gcc
           Product: new-bugs
           Version: 3.6
          Hardware: PC
                OS: NetBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: bruce.lilly at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Tested version:
4.2.1 Compatible Clang 3.6.2 (tags/RELEASE_362/final)

Gcc in pre-C99 modes does not define C99 __func__ but has a documented
work-around:
https://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/Function-Names.html
viz.:

#if __STDC_VERSION__ < 199901L
# if __GNUC__ >= 2
#  define __func__ __FUNCTION__
/* ... */
#endif

which only needs to be done once per file, and can be incorporated into a
common header file.  For that matter, when a pre-C99 mode is used, one can
supply gcc with -D__func__=__FUNCTION__ w/o having to do anything to source
files.

Clang in pre-C99 modes defines __func__, but in a manner different from the way
it is defined in C99 and later modes, and which is incompatible with:
A. ANSI/ISO C99, which specifies the unadorned function name shall be used
and
B. the documented gcc work-arounds (clang redefines __func__ incompatibly, in
each called function, overriding preprocessor definitions as used for the gcc
work-arounds)
as well as
C. other compilers in pre-C99-compatible modes, which define __func__ as the
unadorned function name (i.e. compatible w/ C99), e.g.:
   SunPro C version 0x5100
   pcc 1.0.0.RELEASE 20110221 for x86_64--netbsd, pbulk at amd64-nb61

The excess adornment attached to __func__ by clang in pre-C99 modes leads to
excessive noise in log files, etc. as well as the difference in output between
code compiled by clang in pre-C99 modes and that produced by the same code
compiled by other compilers or by clang in C99 and later modes, leading to
regression failures.

There is no obvious practical work-around for this incompatibility[*].

The difference in behavior in various modes and the incompatibility are not
documented at
http://clang.llvm.org/docs/UsersManual.html#differences-between-various-standard-modes
or
http://clang.llvm.org/comparison.html

* Impractical work-around: in *every* function:
#ifdef __clang__
# undef __func__
# define __func__ __FUNCTION__
#endif

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160403/85774da5/attachment-0001.html>