[cfe-dev] math.h on Windows

[Douglas Gregor]

On Oct 14, 2009, at 8:40 PM, John Thompson wrote:

> Doug,
>
> _Complex is currently a keyword in every mode. We could make it only  
> be a keyword in C99 or GNU mode, then make sure that neither of  
> these modes is turned on by default when Clang is built with VC++.  
> That probably makes sense, since VC++ doesn't support C99 or many  
> GNU extensions anyway.
>
> We can always force tests into specific modes (turning off Microsoft  
> extensions, turning on GNU extensions or C99, whatever), rather than  
> trying to work around problems that are unlikely to show up in code  
> that compiles with VC++.
>
> How would you collectively force the tests?

I don't think we can collectively force the tests; we could explicitly  
add -fno-extensions to the ones that matter.

> I'm kinda feeling that since we're down to just 21 failing tests,  
> and _Complex isn't a problem with VC 9.0, we could probably punt on  
> it for now, and see how it goes with the rest of the tests.  But let  
> me know if you want me to persue this.

Let's punt on it for now, then.

>
> What is the actual issue with the redefinition of wchar_t? Are they  
> creating a typedef of wchar_t in their headers? Does the VC++  
> compiler implicitly define _WCHAR_T_DEFINED?
>
> This occurs in a few headers:
>
> #ifndef _WCHAR_T_DEFINED
> typedef unsigned short wchar_t;
> #define _WCHAR_T_DEFINED
> #endif
>
> The enclosed wchar_t_fix2.patch seems to fix both the wchar_t issue,  
> and another one I ran into with VC++ headers.  I was side-tracked a  
> bit with errors on wchar_t I didn't understand, until I realized  
> that wchar_t was only a C++ keyword.

The wchar_t bits look good. Please go ahead and commit!

> I also ran into some new errors with the VC 9.0 headers on some  
> #pragma's.  Defining _CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES avoids  
> them, though it's a bit of a hack.

At the very least, please put a FIXME near that define, since we don't  
want to keep it for long.

>   This symbol prevents the definition of some macros, some of which  
> have errors, for example on __pragma statements like this:
>
> __pragma(warning(push))
>
> This is a Microsoft extension not currently supported, right?  It  
> seems kind of useful for macros.

Right. There are two issues here, I guess. The first is that we don't  
handle __pragma, although it looks like it's similar "enough" to C99's  
_Pragma that it wouldn't be hard to implement this Microsoft  
extension. Second, we have the ability to push/pop diagnostic contexts  
(see the PragmaDiagnosticHandler in lib/Lex/Pragma.cpp) but, IIRC, not  
with that syntax. Again, it's probably simple to implement, or we  
could live with the hack for a bit longer.

> You mentioned that the Targets.cpp was probably not the right place  
> for the defines, so I moved them to InitPreprocessor.cpp.  Is this  
> the right place?

Yep!

> Also, could someone look at the enclosed patch for stdint.h?  This  
> also fixes some failing tests, since VC++ doesn't have stdint.h.   
> Who is point on this?

I'm not thrilled about using _M_IX86 and _M_X64 to detect what is  
really a library issue. I guess in the worst case we could have a  
configure-time check that determines whether we can #include_next  
<stdint.h>, but that's.... horrible.

Unless someone has a better idea... ?

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20091015/646ac523/attachment.html>