RE: [clang] 4bafe65 - Add support for floating-point option `ffp-eval-method` and for

[Ammarguellat, Zahira via cfe-commits]

https://reviews.llvm.org/D109239

-Original Message-
From: Roman Lebedev  
Sent: Tuesday, February 15, 2022 5:26 PM
To: Ammarguellat, Zahira ; Zahira Ammarguellat 

Cc: cfe-commits@lists.llvm.org
Subject: Re: [clang] 4bafe65 - Add support for floating-point option 
`ffp-eval-method` and for

Where was this reviewed?

On Wed, Feb 16, 2022 at 12:59 AM Zahira Ammarguellat via cfe-commits
 wrote:
>
>
> Author: Zahira Ammarguellat
> Date: 2022-02-15T13:59:27-08:00
> New Revision: 4bafe65c2b2f1ce745894a509a6d80c87fb1c335
>
> URL: 
> https://github.com/llvm/llvm-project/commit/4bafe65c2b2f1ce745894a509a6d80c87fb1c335
> DIFF: 
> https://github.com/llvm/llvm-project/commit/4bafe65c2b2f1ce745894a509a6d80c87fb1c335.diff
>
> LOG: Add support for floating-point option `ffp-eval-method` and for
> `pragma clang fp eval_method`.
>
> Added:
> clang/test/CodeGen/X86/32bit-behavior-no-eval.c
> clang/test/CodeGen/X86/32bit-behavior.c
> clang/test/CodeGen/X86/fp-eval-method.c
> clang/test/CodeGen/flt_eval_macro.cpp
> clang/test/Preprocessor/flt_eval_macro.cpp
> clang/test/Sema/fp-eval-pragma.cpp
> clang/test/Sema/x86-eval-method.c
> clang/test/Sema/x86_64-eval-method.c
>
> Modified:
> clang/docs/LanguageExtensions.rst
> clang/docs/UsersManual.rst
> clang/include/clang/Basic/DiagnosticCommonKinds.td
> clang/include/clang/Basic/DiagnosticLexKinds.td
> clang/include/clang/Basic/FPOptions.def
> clang/include/clang/Basic/LangOptions.def
> clang/include/clang/Basic/LangOptions.h
> clang/include/clang/Basic/TargetInfo.h
> clang/include/clang/Driver/Options.td
> clang/include/clang/Lex/Preprocessor.h
> clang/include/clang/Parse/Parser.h
> clang/include/clang/Sema/Sema.h
> clang/lib/Basic/Targets/OSTargets.h
> clang/lib/Basic/Targets/X86.h
> clang/lib/Driver/ToolChains/Clang.cpp
> clang/lib/Frontend/InitPreprocessor.cpp
> clang/lib/Lex/PPMacroExpansion.cpp
> clang/lib/Parse/ParsePragma.cpp
> clang/lib/Parse/ParseStmt.cpp
> clang/lib/Sema/Sema.cpp
> clang/lib/Sema/SemaAttr.cpp
> clang/lib/Sema/SemaExpr.cpp
> clang/test/CodeGen/fp-floatcontrol-pragma.cpp
> clang/test/Preprocessor/init-aarch64.c
> clang/test/Preprocessor/init-arm.c
> clang/test/Preprocessor/init-mips.c
> clang/test/Preprocessor/init-ppc.c
> clang/test/Preprocessor/init-ppc64.c
> clang/test/Preprocessor/init-s390x.c
> clang/test/Preprocessor/init-v7k-compat.c
> clang/test/Preprocessor/init-x86.c
> clang/test/Preprocessor/init.c
>
> Removed:
>
>
>
> 
> diff  --git a/clang/docs/LanguageExtensions.rst 
> b/clang/docs/LanguageExtensions.rst
> index f45d88092eb4a..5249d3f3f7930 100644
> --- a/clang/docs/LanguageExtensions.rst
> +++ b/clang/docs/LanguageExtensions.rst
> @@ -3907,6 +3907,38 @@ A ``#pragma clang fp`` pragma may contain any number 
> of options:
>  ...
>}
>
> +``#pragma clang fp eval_method`` allows floating-point behavior to be 
> specified
> +for a section of the source code. This pragma can appear at file or namespace
> +scope, or at the start of a compound statement (excluding comments).
> +The pragma is active within the scope of the compound statement.
> +
> +When ``pragma clang fp eval_method(source)`` is enabled, the section of code
> +governed by the pragma behaves as though the command-line option
> +``-ffp-eval-method=source`` is enabled. Rounds intermediate results to
> +source-defined precision.
> +
> +When ``pragma clang fp eval_method(double)`` is enabled, the section of code
> +governed by the pragma behaves as though the command-line option
> +``-ffp-eval-method=double`` is enabled. Rounds intermediate results to
> +``double`` precision.
> +
> +When ``pragma clang fp eval_method(extended)`` is enabled, the section of 
> code
> +governed by the pragma behaves as though the command-line option
> +``-ffp-eval-method=extended`` is enabled. Rounds intermediate results to
> +target-dependent ``long double`` precision. In Win32 programming, for 
> instance,
> +the long double data type maps to the double, 64-bit precision data type.
> +
> +The full syntax this pragma supports is
> +``#pragma clang fp eval_method(source|double|extended)``.
> +
> +.. code-block:: c++
> +
> +  for(...) {
> +// The compiler will use long double as the floating-point evaluation
> +// method.
> +#pragma clang fp eval_method(extended)
> +a = b[i] * c[i] + e;
> +  }
>
>  The ``#pragma float_control`` pragma allows precise floating-point
>  semantics and floating-point exception behavior to be specified
>
> diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
> index 1df96296cb8ac..70fee29ab2a84 100644
> --- a/clang/docs/UsersManual.rst
> +++ b/clang/docs/UsersManual.rst
> @@ -1566,6 +1566,22 @@ Note that floating-point operations performed as part 
> of constant initialization
> * 

RE: [clang] 6278682 - In spir functions, llvm.dbg.declare intrinsics created

[Ammarguellat, Zahira via cfe-commits]

https://reviews.llvm.org/D112963

-Original Message-
From: Aaron Ballman  
Sent: Monday, November 8, 2021 6:51 AM
To: Ammarguellat, Zahira ; Zahira Ammarguellat 

Cc: cfe-commits 
Subject: Re: [clang] 6278682 - In spir functions, llvm.dbg.declare intrinsics 
created

Hello! Was this code reviewed anywhere? I can't seem to spot a review for it, 
so wondering if I missed something.

Thanks!

~Aaron

On Fri, Nov 5, 2021 at 6:08 PM Zahira Ammarguellat via cfe-commits 
 wrote:
>
>
> Author: Zahira Ammarguellat
> Date: 2021-11-05T15:08:09-07:00
> New Revision: 627868263cd4d57c230b61904483a3dad9e1a1da
>
> URL: 
> https://github.com/llvm/llvm-project/commit/627868263cd4d57c230b619044
> 83a3dad9e1a1da
> DIFF: 
> https://github.com/llvm/llvm-project/commit/627868263cd4d57c230b619044
> 83a3dad9e1a1da.diff
>
> LOG: In spir functions, llvm.dbg.declare intrinsics created for 
> parameters and locals need to refer to the stack allocation in the 
> alloca address space.
>
> Added:
> clang/test/CodeGenSYCL/debug-info-kernel-variables.cpp
>
> Modified:
> clang/lib/CodeGen/CGDecl.cpp
>
> Removed:
>
>
>
> ##
> ## diff  --git a/clang/lib/CodeGen/CGDecl.cpp 
> b/clang/lib/CodeGen/CGDecl.cpp index dfb74a3fc6547..941671c614824 
> 100644
> --- a/clang/lib/CodeGen/CGDecl.cpp
> +++ b/clang/lib/CodeGen/CGDecl.cpp
> @@ -1447,6 +1447,7 @@ CodeGenFunction::EmitAutoVarAlloca(const VarDecl 
> ) {
>
>if (getLangOpts().OpenMP && OpenMPLocalAddr.isValid()) {
>  address = OpenMPLocalAddr;
> +AllocaAddr = OpenMPLocalAddr;
>} else if (Ty->isConstantSizeType()) {
>  // If this value is an array or struct with a statically determinable
>  // constant initializer, there are optimizations we can do.
> @@ -1492,6 +1493,7 @@ CodeGenFunction::EmitAutoVarAlloca(const VarDecl ) {
>// return slot, so that we can elide the copy when returning this
>// variable (C++0x [class.copy]p34).
>address = ReturnValue;
> +  AllocaAddr = ReturnValue;
>
>if (const RecordType *RecordTy = Ty->getAs()) {
>  const auto *RD = RecordTy->getDecl(); @@ -1503,7 +1505,8 @@ 
> CodeGenFunction::EmitAutoVarAlloca(const VarDecl ) {
>// applied.
>llvm::Value *Zero = Builder.getFalse();
>Address NRVOFlag =
> -CreateTempAlloca(Zero->getType(), CharUnits::One(), "nrvo");
> +  CreateTempAlloca(Zero->getType(), CharUnits::One(), "nrvo",
> +   /*ArraySize=*/nullptr, );
>EnsureInsertPoint();
>Builder.CreateStore(Zero, NRVOFlag);
>
> @@ -1605,10 +1608,11 @@ CodeGenFunction::EmitAutoVarAlloca(const VarDecl ) {
>  DI->setLocation(D.getLocation());
>
>  // If NRVO, use a pointer to the return address.
> -if (UsePointerValue)
> +if (UsePointerValue) {
>DebugAddr = ReturnValuePointer;
> -
> -(void)DI->EmitDeclareOfAutoVariable(, DebugAddr.getPointer(), Builder,
> +  AllocaAddr = ReturnValuePointer;
> +}
> +(void)DI->EmitDeclareOfAutoVariable(, AllocaAddr.getPointer(), 
> + Builder,
>  UsePointerValue);
>}
>
> @@ -2450,6 +2454,7 @@ void CodeGenFunction::EmitParmDecl(const VarDecl , 
> ParamValue Arg,
>}
>
>Address DeclPtr = Address::invalid();
> +  Address AllocaPtr = Address::invalid();
>bool DoStore = false;
>bool IsScalar = hasScalarEvaluationKind(Ty);
>// If we already have a pointer to the argument, reuse the input pointer.
> @@ -2464,6 +2469,7 @@ void CodeGenFunction::EmitParmDecl(const VarDecl , 
> ParamValue Arg,
>  // from the default address space.
>  auto AllocaAS = CGM.getASTAllocaAddressSpace();
>  auto *V = DeclPtr.getPointer();
> +AllocaPtr = DeclPtr;
>  auto SrcLangAS = getLangOpts().OpenCL ? LangAS::opencl_private : 
> AllocaAS;
>  auto DestLangAS =
>  getLangOpts().OpenCL ? LangAS::opencl_private : 
> LangAS::Default; @@ -2500,10 +2506,11 @@ void 
> CodeGenFunction::EmitParmDecl(const VarDecl , ParamValue Arg,
>  : Address::invalid();
>  if (getLangOpts().OpenMP && OpenMPLocalAddr.isValid()) {
>DeclPtr = OpenMPLocalAddr;
> +  AllocaPtr = DeclPtr;
>  } else {
>// Otherwise, create a temporary to hold the value.
>DeclPtr = CreateMemTemp(Ty, getContext().getDeclAlign(),
> -  D.getName() + ".addr");
> +  D.getName() + ".addr", );
>  }
>  DoStore = true;
>}
> @@ -2579,7 +2586,7 @@ void CodeGenFunction::EmitParmDecl(const VarDecl , 
> ParamValue Arg,
>if (CGDebugInfo *DI = getDebugInfo()) {
>  if (CGM.getCodeGenOpts().hasReducedDebugInfo() && !CurFuncIsThunk) {
>llvm::DILocalVariable *DILocalVar = DI->EmitDeclareOfArgVariable(
> -  , DeclPtr.getPointer(), ArgNo, Builder);
> +  , AllocaPtr.getPointer(), ArgNo, Builder);
>if (const 

RE: r324991 - Fix for PR32992. Static const classes not exported.

[Ammarguellat, Zahira via cfe-commits]

Hello,

Please see https://reviews.llvm.org/D42968
For the fix of the assertion belwo.
Thanks.

-Original Message-
From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of Hans 
Wennborg
Sent: Tuesday, February 20, 2018 4:04 AM
To: Ammarguellat, Zahira 
Cc: cfe-commits 
Subject: Re: r324991 - Fix for PR32992. Static const classes not exported.

The problem is that your patch caused the reproducer to trigger an assert, 
which it didn't do before, causing our builds to break.

Your patch seems like it does fix the PR, but it can't break currently working 
builds.

$ build.release/bin/clang -cc1 -triple i386-pc-windows-msvc19.11.0 -emit-pch 
-fms-extensions -fms-compatibility
-fms-compatibility-version=19.11 -std=c++14 -fdelayed-template-parsing -x 
c++-header /tmp/a.cc -o /dev/null
clang: 
/work/llvm.combined/llvm/tools/clang/lib/Serialization/ASTWriter.cpp:4723:
clang::ASTFileSignature clang::ASTWriter::WriteASTCore(clang::Sema&,
llvm::StringRef, const string&, clang::Module*): Assertion
`SemaRef.PendingLocalImplicitInstantiations.empty() && "There are local ones at 
end of translation unit!"' failed.
build.release/bin/clang(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x1a)[0x55c535576aaa]
build.release/bin/clang(_ZN4llvm3sys17RunSignalHandlersEv+0x3e)[0x55c53557492e]
build.release/bin/clang(+0x2424a7c)[0x55c535574a7c]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7f4aeeb9d0c0]
/lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7f4aed732fcf]
/lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f4aed7343fa]
/lib/x86_64-linux-gnu/libc.so.6(+0x2be37)[0x7f4aed72be37]
/lib/x86_64-linux-gnu/libc.so.6(+0x2bee2)[0x7f4aed72bee2]
build.release/bin/clang(_ZN5clang9ASTWriter12WriteASTCoreERNS_4SemaEN4llvm9StringRefERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPNS_6ModuleE+0x29fa)[0x55c536444cea]
build.release/bin/clang(_ZN5clang9ASTWriter8WriteASTERNS_4SemaERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPNS_6ModuleEN4llvm9StringRefEb+0xad)[0x55c536444dfd]
build.release/bin/clang(_ZN5clang12PCHGenerator21HandleTranslationUnitERNS_10ASTContextE+0x80)[0x55c536465fe0]
build.release/bin/clang(_ZN5clang17MultiplexConsumer21HandleTranslationUnitERNS_10ASTContextE+0x28)[0x55c535b53488]
build.release/bin/clang(_ZN5clang8ParseASTERNS_4SemaEbb+0x350)[0x55c5362c5d30]
build.release/bin/clang(_ZN5clang14FrontendAction7ExecuteEv+0x11e)[0x55c535b2958e]
build.release/bin/clang(_ZN5clang16CompilerInstance13ExecuteActionERNS_14FrontendActionE+0x176)[0x55c535af54d6]
build.release/bin/clang(_ZN5clang25ExecuteCompilerInvocationEPNS_16CompilerInstanceE+0x981)[0x55c535bc2561]
build.release/bin/clang(_Z8cc1_mainN4llvm8ArrayRefIPKcEES2_Pv+0xc50)[0x55c533e1a890]
build.release/bin/clang(main+0x1295)[0x55c533d9b585]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f4aed7202b1]
build.release/bin/clang(_start+0x2a)[0x55c533e1684a]
Stack dump:
0.  Program arguments: build.release/bin/clang -cc1 -triple
i386-pc-windows-msvc19.11.0 -emit-pch -fms-extensions -fms-compatibility 
-fms-compatibility-version=19.11 -std=c++14 -fdelayed-template-parsing -x 
c++-header /tmp/a.cc -o /dev/null
1.   parser at end of file
Aborted

On Mon, Feb 19, 2018 at 10:18 PM, Ammarguellat, Zahira 
 wrote:
> Hans,
>
>
>
> The reproducer below generates wrong export symbols compared to MSVC 
> but I am not sure it is related to my change.
>
> Compiling this with MSVC generates these symbols:
>
>
>
> ksh-3.2$ dumpbin /directives t3.obj | grep EXPORT
>
>/EXPORT:??4?$d@H@@QEAAAEAV0@AEBV0@@Z
>
>/EXPORT:??4?$d@H@@QEAAAEAV0@$$QEAV0@@Z
>
>/EXPORT:??4?$h@H@f@@QEAAAEAV01@AEBV01@@Z
>
>/EXPORT:??4?$h@H@f@@QEAAAEAV01@$$QEAV01@@Z
>
>/EXPORT:??4i@@QEAAAEAV0@AEBV0@@Z
>
>/EXPORT:??4i@@QEAAAEAV0@$$QEAV0@@Z
>
>
>
>
>
> Compiling with clang (my patches no included) generate these symbols:
>
> ksh-3.2$ dumpbin /directives t3.o | grep EXPORT
>
>/EXPORT:??4?$d@H@@QEAAAEAV0@AEBV0@@Z
>
>/EXPORT:??4?$d@H@@QEAAAEAV0@$$QEAV0@@Z
>
>/EXPORT:??4?$h@H@f@@QEAAAEAV01@AEBV01@@Z
>
>/EXPORT:??4?$h@H@f@@QEAAAEAV01@$$QEAV01@@Z
>
>/EXPORT:??4i@@QEAAAEAV0@AEBV0@@Z
>
>/EXPORT:??4i@@QEAAAEAV0@$$QEAV0@@Z
>
>/EXPORT:?e@?$d@H@@0W4b@a@@B,DATA   ç This is not generated in MSVC.
>
>
>
> Although this is a bug that needs to be fixes, it is in my opinion 
> un-related to the patches I have proposed.
>
>
>
> Your thoughts?
>
>
>
> Thanks.
>
> -Zahira
>
>
>
>
>
> -Original Message-
> From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of 
> Hans Wennborg
> Sent: Monday, February 19, 2018 5:11 AM
> To: cfe-commits ; Ammarguellat, Zahira 
> 
> Subject: Re: r324991 - Fix for PR32992. Static const classes not exported.
>
>
>
> Reduced repro:
>
>
>
> $ clang -cc1 -triple i386-pc-windows-msvc19.11.0 -emit-pch 
> -fms-extensions -fms-compatibility 

RE: r324991 - Fix for PR32992. Static const classes not exported.

[Ammarguellat, Zahira via cfe-commits]

Hans,



The reproducer below generates wrong export symbols compared to MSVC but I am 
not sure it is related to my change.

Compiling this with MSVC generates these symbols:



ksh-3.2$ dumpbin /directives t3.obj | grep EXPORT

   /EXPORT:??4?$d@H@@QEAAAEAV0@AEBV0@@Z

   /EXPORT:??4?$d@H@@QEAAAEAV0@$$QEAV0@@Z

   /EXPORT:??4?$h@H@f@@QEAAAEAV01@AEBV01@@Z

   /EXPORT:??4?$h@H@f@@QEAAAEAV01@$$QEAV01@@Z

   /EXPORT:??4i@@QEAAAEAV0@AEBV0@@Z

   /EXPORT:??4i@@QEAAAEAV0@$$QEAV0@@Z





Compiling with clang (my patches no included) generate these symbols:

ksh-3.2$ dumpbin /directives t3.o | grep EXPORT

   /EXPORT:??4?$d@H@@QEAAAEAV0@AEBV0@@Z

   /EXPORT:??4?$d@H@@QEAAAEAV0@$$QEAV0@@Z

   /EXPORT:??4?$h@H@f@@QEAAAEAV01@AEBV01@@Z

   /EXPORT:??4?$h@H@f@@QEAAAEAV01@$$QEAV01@@Z

   /EXPORT:??4i@@QEAAAEAV0@AEBV0@@Z

   /EXPORT:??4i@@QEAAAEAV0@$$QEAV0@@Z

   /EXPORT:?e@?$d@H@@0W4b@a@@B,DATA   <== This is not generated in MSVC.



Although this is a bug that needs to be fixes, it is in my opinion un-related 
to the patches I have proposed.



Your thoughts?



Thanks.

-Zahira





-Original Message-
From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of Hans 
Wennborg
Sent: Monday, February 19, 2018 5:11 AM
To: cfe-commits ; Ammarguellat, Zahira 

Subject: Re: r324991 - Fix for PR32992. Static const classes not exported.



Reduced repro:



$ clang -cc1 -triple i386-pc-windows-msvc19.11.0 -emit-pch -fms-extensions 
-fms-compatibility -fms-compatibility-version=19.11

-std=c++14 -fdelayed-template-parsing -x c++-header a.ii -o /dev/null



a.ii:



namespace a {

enum b { c };

}

template  class d { static constexpr a::b e = a::c; }; namespace f { 
template  class h : d {}; } using f::h; class 
__declspec(dllexport) i : h<> {};



On Wed, Feb 14, 2018 at 4:22 PM, Hans Wennborg 
> wrote:

> I ended up having to revert this in r325133 as it broke the Chromium

> build. Please see

> https://bugs.chromium.org/p/chromium/issues/detail?id=812231#c1 for a

> reproducer.

>

> On Tue, Feb 13, 2018 at 10:19 AM, Hans Wennborg via cfe-commits

> > wrote:

>> Author: hans

>> Date: Tue Feb 13 01:19:43 2018

>> New Revision: 324991

>>

>> URL: http://llvm.org/viewvc/llvm-project?rev=324991=rev

>> Log:

>> Fix for PR32992. Static const classes not exported.

>>

>> Patch by zahiraam!

>>

>> Differential Revision: https://reviews.llvm.org/D42968

>>

>> Modified:

>> cfe/trunk/lib/Sema/SemaDeclCXX.cpp

>> cfe/trunk/test/CodeGenCXX/dllexport.cpp

>>

>> Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp

>> URL:

>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cp

>> p?rev=324991=324990=324991=diff

>> =

>> =

>> --- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)

>> +++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Tue Feb 13 01:19:43 2018

>> @@ -5476,7 +5476,7 @@ static void CheckAbstractClassUsage(Abst

>>}

>>  }

>>

>> -static void ReferenceDllExportedMethods(Sema , CXXRecordDecl

>> *Class) {

>> +static void ReferenceDllExportedMembers(Sema , CXXRecordDecl

>> +*Class) {

>>Attr *ClassAttr = getDLLAttr(Class);

>>if (!ClassAttr)

>>  return;

>> @@ -5491,6 +5491,16 @@ static void ReferenceDllExportedMethods(

>>  return;

>>

>>for (Decl *Member : Class->decls()) {

>> +// Defined static variables that are members of an exported base

>> +// class must be marked export too. Push them to implicit instantiation

>> +// queue.

>> +auto *VD = dyn_cast(Member);

>> +if (VD && Member->getAttr() &&

>> +VD->getStorageClass() == SC_Static &&

>> +TSK == TSK_ImplicitInstantiation)

>> +  S.PendingLocalImplicitInstantiations.push_back(

>> +  std::make_pair(VD, VD->getLocation()));

>> +

>>  auto *MD = dyn_cast(Member);

>>  if (!MD)

>>continue;

>> @@ -10902,12 +10912,12 @@ void Sema::ActOnFinishCXXNonNestedClass(

>>

>>  void Sema::referenceDLLExportedClassMethods() {

>>if (!DelayedDllExportClasses.empty()) {

>> -// Calling ReferenceDllExportedMethods might cause the current function 
>> to

>> +// Calling ReferenceDllExportedMembers might cause the current

>> + function to

>>  // be called again, so use a local copy of DelayedDllExportClasses.

>>  SmallVector WorkList;

>>  std::swap(DelayedDllExportClasses, WorkList);

>>  for (CXXRecordDecl *Class : WorkList)

>> -  ReferenceDllExportedMethods(*this, Class);

>> +  ReferenceDllExportedMembers(*this, Class);

>>}

>>  }

>>

>>

>> Modified: cfe/trunk/test/CodeGenCXX/dllexport.cpp

>> URL:

>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/dllexpo

>> rt.cpp?rev=324991=324990=324991=diff

>> 

Disable fms-extensions?

[Ammarguellat, Zahira via cfe-commits]

Hello,

Clang implements MS extensions when using -fms-extension. On windows this 
option is enabled by default.
Is there any way of disabling it to mirror the behavior of the /Za 
(-permissive-) option of CL?
Thanks,
-Zahira

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Multiple versions of VS

[Ammarguellat, Zahira via cfe-commits]

Hello,

Is there any plan from the community to have clang support multiple versions of 
VS?
Thanks.
-Zahira

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits