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: unassignedb...@nondot.org
Reporter: bruce.li...@gmail.com
CC: llvm-bugs@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@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.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
