[cfe-commits] [PATCH] -fshort-wchar

John Thompson john.thompson.jtsoftware at gmail.com
Thu Nov 5 08:30:04 PST 2009


Or maybe something that combines the two test scheme with my original
change:

// RUN: clang-cc %s -fsyntax-only -verify &&
// RUN: clang-cc %s -fsyntax-only -fshort-wchar -verify -DSHORT_WCHAR"

#include <wchar.h>

#if defined(_WIN32) || defined(_M_IX86) || defined(__CYGWIN__) \\
 || defined(_M_X64) || defined(SHORT_WCHAR)
  #define WCHAR_T_TYPE unsigned short
#else
  #define WCHAR_T_TYPE int
#endif

int check_wchar_size[sizeof(*L"") == sizeof(wchar_t) ? 1 : -1];

void foo() {
  WCHAR_T_TYPE t1[] = L"x";
  wchar_t tab[] = L"x";
  WCHAR_T_TYPE t2[] = "x";     // expected-error {{initialization}}
  char t3[] = L"x";   // expected-error {{initialization}}
}
You don't get the complete platform-independence, but it avoids the include
problems with specifying a triple, and still tests -fshort-wchar, but only
on non-windows platforms.
-John
On Wed, Nov 4, 2009 at 3:20 PM, John Thompson <
john.thompson.jtsoftware at gmail.com> wrote:

> Doug,
>
> >RUN: clang-cc %s -fsyntax-only -triple i686-pc-linux-gnu -verify
> -DWCHAR_T_TYPE="int" &&
> Sorry, I totally missed noticing that last comment.  There's a catch with
> this however.  By using "-triple i686-pc-linux-gnu", it causes the default
> include paths to be those for Linux.
>
> I can work around this by setting up a \usr\include directory on my PC and
> copying the Linux headers over, but would this be okay, since it would
> require any Windows-hosted developer running the test to do the same?
>
> This also would cause a couple of other minor problems in the tests, as 6
> tests then start failing on Windows.  I think the presence of another
> stdint.h in the system confuses Clang's stdint.h scheme, causing the Linux
> stdint to be included.  This can be worked around by putting
> -fms-extensions=0 in these tests, except that for one test this causes a
> problem because it also including limits.h, which includes crtdef.h which
> has at least one Window-isn __int64.
>
> I've included these work-arounds in the patch, in case you want to go this
> route.  Otherwise I'll need some help in knowing what to do.
>
> -John
>
>
>
> -John
>
>   On Wed, Nov 4, 2009 at 2:06 PM, Douglas Gregor <dgregor at apple.com>wrote:
>
>>
>>  On Nov 4, 2009, at 1:53 PM, John Thompson wrote:
>>
>>  Here's another go at it, adding stuff for PCH and the driver.  I put in
>> a partial test of the driver change in test/Driver/clang_f_opts.c, which I
>> hope is an appropriate place.
>>
>>
>> Looks good, but could you address this comment
>>
>>
>>>>
>>>> The change to the wchar.c test allows it to pass on Windows (and still
>>>> pass on Linux, which defaults to int for wchar_t).
>>>>
>>>
>>>  I'd like to retain the test that we use "int" for the other targets.
>>> Could you do something like
>>>
>>>  RUN: clang-cc %s -fsyntax-only -triple i686-pc-linux-gnu -verify
>>> -DWCHAR_T_TYPE="int" &&
>>>  RUN: clang-cc %s -fsyntax-only -fshort-wchar -verify
>>> -DWCHAR_T_TYPE="unsigned short"
>>>
>>> then use WCHAR_T_TYPE as the element type of the t1 and t2 arrays?
>>>
>>>        - Doug
>>>
>>
>> before committing?
>>
>> - Doug
>>
>
>
>
>  --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20091105/25337f15/attachment.html>


More information about the cfe-commits mailing list