http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53539
Bug #: 53539
Summary: Different __WCHAR_TYPE__/wchar_t for gcc -m32 on
Linux/i386 and Linux/x86-64
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com
From
http://gcc.gnu.org/ml/gcc/2012-05/msg00397.html
On Linux/i386:
[hjl@gnu-29 ~]$ echo __WCHAR_TYPE__ | gcc -E -
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "<stdin>"
long int
[hjl@gnu-29 ~]$
On Linux/x86-64:
[hjl@gnu-6 include]$ echo __WCHAR_TYPE__ | gcc -m32 -E -
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "<stdin>"
int
[hjl@gnu-6 include]$ echo __WCHAR_TYPE__ | gcc -mx32 -E -
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "<stdin>"
int
[hjl@gnu-6 include]$ echo __WCHAR_TYPE__ | gcc -m64 -E -
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "<stdin>"
int
[hjl@gnu-6 include]$
http://gcc.gnu.org/ml/gcc/2012-05/msg00398.html
That's a bug. Not a very serious one - it doesn't affect C++ name
mangling because wchar_t is a built-in type in C++, with its own mangling
- but still a bug. The choice of underlying type for wchar_t should not
depend on what the compiler defaults to like that. (Actually, it looks
like a 32-bit-default compiler built --enable-targets=all also uses "int"
here.)
