llvm dev - Aug 2015 - [LLVMdev] Ideas for making llvm-config --cxxflags more useful

> On Aug 3, 2015, at 10:24 AM, Chris Bieneman <beanz at apple.com>
wrote:
> 
> Hey Tom,
> 
> I’m not a regular user of llvm-config, but this sounds completely right to
me, and it would be a significant improvement over what we have now.
> 
> The only question I want to raise is, what about NDEBUG? There are headers
that conditionalize on NDEBUG, which could lead to ABI incompatibility in the
C++ API.
Is it something that can be fixed or would it be too complicated to handle? 
It would be nice in general to be able to link a “Non assert” build of Clang
with an “Assert" version of  LLVM (and vice-versa).

And on the original topic: +1 for Tom proposal/goal, it makes sense to me.

—
Mehdi


> 
> Thanks for doing this,
> -Chris
> 
>> On Jul 30, 2015, at 1:04 PM, tom at stellard.net wrote:
>> 
>> Hi,
>> 
>> My understanding of llvm-config --cxxflags is that it is supposed to
report
>> which flags are necessary to compile a program that will include
LLVM's
>> headers and link against its libraries.  What it currently reports is
>> all of the flags which were used to compile LLVM.  This is not very
useful,
>> because users are required in most cases to filter out flags they
don't
>> want.
>> 
>> I would like to try to fix this so that it reports only the bare
minimum
>> of required flags.  As an example here all the flags that it reports in
>> my autoconf build of llvm:
>> 
>> -I/usr/local/llvm/3.8/include
>> -D_DEBUG
>> -D_GNU_SOURCE
>> -D__STDC_CONSTANT_MACROS
>> -D__STDC_FORMAT_MACROS
>> -D__STDC_LIMIT_MACROS
>> -O3
>> -fomit-frame-pointer
>> -std=c++11
>> -fvisibility-inlines-hidden
>> -fno-exceptions
>> -fno-rtti
>> -fPIC
>> -ffunction-sections
>> -fdata-sections
>> -Wcast-qual
>> 
>> Of these flags the only ones that are really required are (c++ experts
>> please correct me if I'm wrong here):
>> 
>> -I/usr/local/llvm/3.8/include
>> -D__STDC_CONSTANT_MACROS
>> -D__STDC_FORMAT_MACROS
>> -D__STDC_LIMIT_MACROS
>> -std=c++11
>> 
>> Technically the -D__STDC* macros are only required if you include
>> Support/DataTypes.h, but I think that is hard to avoid.
>> 
>> As I understand, The rest of the flags are not required in 100% of the
>> use cases.
>> 
>> My proposal for fixing this is to remove everything but the 5 options
listed
>> above.
>> 
>> For flags like -fno-rtti (are there others?) that are required in some
cases
>> (I think -fno-rtti is required only if you sub-class LLVM objects), I
would propose
>> adding a separate flag like --uses-rtti.  This would give users more
fine-grained
>> control over which flags they use, and also would let them choose the
correct
>> flag since, for example, -fno-rtti is not understood by MSVC.
>> 
>> How do people feel about this proposal?
>> 
>> Thanks,
>> Tom
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

The only question I want to raise is, what about NDEBUG? There are headers that
conditionalize on NDEBUG, which could lead to ABI incompatibility in the C++
API.

Is it something that can be fixed or would it be too complicated to handle?
It would be nice in general to be able to link a “Non assert” build of Clang
with an “Assert" version of  LLVM (and vice-versa).

From my user perspective, it would be desirable to set as few flags as possible.
NDEBUG is used outside of clang/llvm as well (including our software), so if it
were returned by llvm-config, it would effectively preclude us from using
llvm-config (as it would effectively turn off all checks even when desired).

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150803/01cf596a/attachment.html>

The problem with not including it is that if your LLVM build is not ABI
compatible with different values of NDEBUG.

-Chris
> On Aug 3, 2015, at 10:40 AM, Schlottke-Lakemper, Michael
<m.schlottke-lakemper at aia.rwth-aachen.de> wrote:
> 
>>> The only question I want to raise is, what about NDEBUG? There are
headers that conditionalize on NDEBUG, which could lead to ABI incompatibility
in the C++ API.
>> 
>> Is it something that can be fixed or would it be too complicated to
handle?
>> It would be nice in general to be able to link a “Non assert” build of
Clang with an “Assert" version of  LLVM (and vice-versa).
> 
> From my user perspective, it would be desirable to set as few flags as
possible. NDEBUG is used outside of clang/llvm as well (including our software),
so if it were returned by llvm-config, it would effectively preclude us from
using llvm-config (as it would effectively turn off all checks even when
desired).
> 
> Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150803/791c6ce7/attachment.html>

> On Aug 3, 2015, at 10:40 AM, Schlottke-Lakemper, Michael
<m.schlottke-lakemper at aia.rwth-aachen.de> wrote:
> 
>>> The only question I want to raise is, what about NDEBUG? There are
headers that conditionalize on NDEBUG, which could lead to ABI incompatibility
in the C++ API.
>> 
>> Is it something that can be fixed or would it be too complicated to
handle?
>> It would be nice in general to be able to link a “Non assert” build of
Clang with an “Assert" version of  LLVM (and vice-versa).
> 
> From my user perspective, it would be desirable to set as few flags as
possible. NDEBUG is used outside of clang/llvm as well (including our software),
so if it were returned by llvm-config, it would effectively preclude us from
using llvm-config (as it would effectively turn off all checks even when
desired).
If as Chris said it is *required* for ABI compatibility, my understanding is
that you don’t really have any choice: if you want to compile/link at the C++
level with LLVM you’ll have to include this flag or you’ll run into strange
runtime issue.

— 
Mehdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150803/11297083/attachment.html>

> On Aug 3, 2015, at 10:30 AM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
> 
>> 
>> On Aug 3, 2015, at 10:24 AM, Chris Bieneman <beanz at apple.com
<mailto:beanz at apple.com>> wrote:
>> 
>> Hey Tom,
>> 
>> I’m not a regular user of llvm-config, but this sounds completely right
to me, and it would be a significant improvement over what we have now.
>> 
>> The only question I want to raise is, what about NDEBUG? There are
headers that conditionalize on NDEBUG, which could lead to ABI incompatibility
in the C++ API.
> 
> Is it something that can be fixed or would it be too complicated to handle?
I think this would need a case-by-case determination that I haven’t done. There
are quite a few occurrences of NDEBUG in headers:
> grep -r NDEBUG ./include/ | wc -l
      77

I imagine many of these aren’t actually ABI issues, but I know that ABI issues
have existed in the past.

-Chris
> It would be nice in general to be able to link a “Non assert” build of
Clang with an “Assert" version of  LLVM (and vice-versa).
> 
> And on the original topic: +1 for Tom proposal/goal, it makes sense to me.
> 
> —
> Mehdi
> 
> 
> 
>> 
>> Thanks for doing this,
>> -Chris
>> 
>>> On Jul 30, 2015, at 1:04 PM, tom at stellard.net wrote:
>>> 
>>> Hi,
>>> 
>>> My understanding of llvm-config --cxxflags is that it is supposed
to report
>>> which flags are necessary to compile a program that will include
LLVM's
>>> headers and link against its libraries.  What it currently reports
is
>>> all of the flags which were used to compile LLVM.  This is not very
useful,
>>> because users are required in most cases to filter out flags they
don't
>>> want.
>>> 
>>> I would like to try to fix this so that it reports only the bare
minimum
>>> of required flags.  As an example here all the flags that it
reports in
>>> my autoconf build of llvm:
>>> 
>>> -I/usr/local/llvm/3.8/include
>>> -D_DEBUG
>>> -D_GNU_SOURCE
>>> -D__STDC_CONSTANT_MACROS
>>> -D__STDC_FORMAT_MACROS
>>> -D__STDC_LIMIT_MACROS
>>> -O3
>>> -fomit-frame-pointer
>>> -std=c++11
>>> -fvisibility-inlines-hidden
>>> -fno-exceptions
>>> -fno-rtti
>>> -fPIC
>>> -ffunction-sections
>>> -fdata-sections
>>> -Wcast-qual
>>> 
>>> Of these flags the only ones that are really required are (c++
experts
>>> please correct me if I'm wrong here):
>>> 
>>> -I/usr/local/llvm/3.8/include
>>> -D__STDC_CONSTANT_MACROS
>>> -D__STDC_FORMAT_MACROS
>>> -D__STDC_LIMIT_MACROS
>>> -std=c++11
>>> 
>>> Technically the -D__STDC* macros are only required if you include
>>> Support/DataTypes.h, but I think that is hard to avoid.
>>> 
>>> As I understand, The rest of the flags are not required in 100% of
the
>>> use cases.
>>> 
>>> My proposal for fixing this is to remove everything but the 5
options listed
>>> above.
>>> 
>>> For flags like -fno-rtti (are there others?) that are required in
some cases
>>> (I think -fno-rtti is required only if you sub-class LLVM objects),
I would propose
>>> adding a separate flag like --uses-rtti.  This would give users
more fine-grained
>>> control over which flags they use, and also would let them choose
the correct
>>> flag since, for example, -fno-rtti is not understood by MSVC.
>>> 
>>> How do people feel about this proposal?
>>> 
>>> Thanks,
>>> Tom
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150803/8426a52d/attachment.html>

Mehdi Amini <mehdi.amini at apple.com> writes:
>> On Aug 3, 2015, at 10:24 AM, Chris Bieneman <beanz at apple.com>
wrote:
>> 
>> Hey Tom,
>> 
>> I’m not a regular user of llvm-config, but this sounds completely
>> right to me, and it would be a significant improvement over what we
>> have now.
>> 
>> The only question I want to raise is, what about NDEBUG? There are
>> headers that conditionalize on NDEBUG, which could lead to ABI
>> incompatibility in the C++ API.
>
> Is it something that can be fixed or would it be too complicated to handle?
> It would be nice in general to be able to link a “Non assert” build of
> Clang with an “Assert" version of LLVM (and vice-versa).
>
> And on the original topic: +1 for Tom proposal/goal, it makes sense to me.
It's probably possible, but I think it's quite a bit of work from where
we are now. A lot of our headers are not ABI compatible between NDEBUG
and !NDEBUG.

llvm-config does already provide --assertion-mode to check NDEBUG in
particular. I'm not sure if that's sufficient though, since it's
easy to
do the wrong thing when you need to use two different calls to get the
right set of flags to be able to grok llvm headers.

To add a few data points. I did a quick scan of the headers and here are the ABI
incompatibilities I came up with:

/Users/cbieneman/dev/open-source/llvm/include/llvm/Analysis/ScalarEvolutionExpander.h:86-88
/Users/cbieneman/dev/open-source/llvm/include/llvm/CodeGen/FunctionLoweringInfo.h:114-117
/Users/cbieneman/dev/open-source/llvm/include/llvm/CodeGen/MachineScheduler.h:244-248,623-627
/Users/cbieneman/dev/open-source/llvm/include/llvm/CodeGen/RegAllocPBQP.h:323-325
/Users/cbieneman/dev/open-source/llvm/include/llvm/CodeGen/ScheduleDAGInstrs.h:260-262
/Users/cbieneman/dev/open-source/llvm/include/llvm/CodeGen/SelectionDAG.h:295-297
/Users/cbieneman/dev/open-source/llvm/include/llvm/IR/ValueHandle.h:188-190,194-201
/Users/cbieneman/dev/open-source/llvm/include/llvm/MC/MCSchedule.h:27-29,105-107

-Chris
> On Aug 3, 2015, at 11:02 AM, Justin Bogner <mail at justinbogner.com>
wrote:
> 
> Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at
apple.com>> writes:
>>> On Aug 3, 2015, at 10:24 AM, Chris Bieneman <beanz at
apple.com> wrote:
>>> 
>>> Hey Tom,
>>> 
>>> I’m not a regular user of llvm-config, but this sounds completely
>>> right to me, and it would be a significant improvement over what we
>>> have now.
>>> 
>>> The only question I want to raise is, what about NDEBUG? There are
>>> headers that conditionalize on NDEBUG, which could lead to ABI
>>> incompatibility in the C++ API.
>> 
>> Is it something that can be fixed or would it be too complicated to
handle?
>> It would be nice in general to be able to link a “Non assert” build of
>> Clang with an “Assert" version of LLVM (and vice-versa).
>> 
>> And on the original topic: +1 for Tom proposal/goal, it makes sense to
me.
> 
> It's probably possible, but I think it's quite a bit of work from
where
> we are now. A lot of our headers are not ABI compatible between NDEBUG
> and !NDEBUG.
> 
> llvm-config does already provide --assertion-mode to check NDEBUG in
> particular. I'm not sure if that's sufficient though, since
it's easy to
> do the wrong thing when you need to use two different calls to get the
> right set of flags to be able to grok llvm headers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150803/4764828a/attachment.html>

> On Aug 3, 2015, at 10:51 AM, Chris Bieneman <beanz at apple.com>
wrote:
> 
> 
>> On Aug 3, 2015, at 10:30 AM, Mehdi Amini <mehdi.amini at apple.com
<mailto:mehdi.amini at apple.com>> wrote:
>> 
>>> 
>>> On Aug 3, 2015, at 10:24 AM, Chris Bieneman <beanz at apple.com
<mailto:beanz at apple.com>> wrote:
>>> 
>>> Hey Tom,
>>> 
>>> I’m not a regular user of llvm-config, but this sounds completely
right to me, and it would be a significant improvement over what we have now.
>>> 
>>> The only question I want to raise is, what about NDEBUG? There are
headers that conditionalize on NDEBUG, which could lead to ABI incompatibility
in the C++ API.
>> 
>> Is it something that can be fixed or would it be too complicated to
handle?
> 
> I think this would need a case-by-case determination that I haven’t done.
There are quite a few occurrences of NDEBUG in headers:
> 
> > grep -r NDEBUG ./include/ | wc -l
>       77
> 
> I imagine many of these aren’t actually ABI issues, but I know that ABI
issues have existed in the past.
I quickly looked at them and found these that I believe won’t trigger a linked
error:

- class SCEVExpander: has a field dependent on NDEBUG: "const char
*DebugType;"
- class FunctionLoweringInfo: two fields dependent on NDEBUG:
SmallPtrSet<const Instruction *, 8> CatchInfoLost and CatchInfoFound
- class ScheduleDAGMI:  has a field dependent on NDEBUG: unsigned
NumInstrsScheduled;
- class SchedBoundary: has a field dependent on NDEBUG: unsigned
MaxObservedStall;
- class NodeMetadata: has a field dependent on NDEBUG: bool
everConservativelyAllocatable;
- class ScheduleDAG: has a field dependent on NDEBUG: bool StressSched;
- class SelectionDAG: has a field dependent on NDEBUG: std::map<const SDNode
*, std::string> NodeGraphAttrs;
- class AssertingVH conditionally inherit from ValueHandleBase and has a
dependent field:   Value *ThePtr;
- class MCProcResourceDesc and MCSchedClassDesc have a field dependent on
NDEBUG: const char *Name;


— 
Mehdi


> 
> -Chris
> 
>> It would be nice in general to be able to link a “Non assert” build of
Clang with an “Assert" version of  LLVM (and vice-versa).
>> 
>> And on the original topic: +1 for Tom proposal/goal, it makes sense to
me.
>> 
>> —
>> Mehdi
>> 
>> 
>> 
>>> 
>>> Thanks for doing this,
>>> -Chris
>>> 
>>>> On Jul 30, 2015, at 1:04 PM, tom at stellard.net <mailto:tom
at stellard.net> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> My understanding of llvm-config --cxxflags is that it is
supposed to report
>>>> which flags are necessary to compile a program that will
include LLVM's
>>>> headers and link against its libraries.  What it currently
reports is
>>>> all of the flags which were used to compile LLVM.  This is not
very useful,
>>>> because users are required in most cases to filter out flags
they don't
>>>> want.
>>>> 
>>>> I would like to try to fix this so that it reports only the
bare minimum
>>>> of required flags.  As an example here all the flags that it
reports in
>>>> my autoconf build of llvm:
>>>> 
>>>> -I/usr/local/llvm/3.8/include
>>>> -D_DEBUG
>>>> -D_GNU_SOURCE
>>>> -D__STDC_CONSTANT_MACROS
>>>> -D__STDC_FORMAT_MACROS
>>>> -D__STDC_LIMIT_MACROS
>>>> -O3
>>>> -fomit-frame-pointer
>>>> -std=c++11
>>>> -fvisibility-inlines-hidden
>>>> -fno-exceptions
>>>> -fno-rtti
>>>> -fPIC
>>>> -ffunction-sections
>>>> -fdata-sections
>>>> -Wcast-qual
>>>> 
>>>> Of these flags the only ones that are really required are (c++
experts
>>>> please correct me if I'm wrong here):
>>>> 
>>>> -I/usr/local/llvm/3.8/include
>>>> -D__STDC_CONSTANT_MACROS
>>>> -D__STDC_FORMAT_MACROS
>>>> -D__STDC_LIMIT_MACROS
>>>> -std=c++11
>>>> 
>>>> Technically the -D__STDC* macros are only required if you
include
>>>> Support/DataTypes.h, but I think that is hard to avoid.
>>>> 
>>>> As I understand, The rest of the flags are not required in 100%
of the
>>>> use cases.
>>>> 
>>>> My proposal for fixing this is to remove everything but the 5
options listed
>>>> above.
>>>> 
>>>> For flags like -fno-rtti (are there others?) that are required
in some cases
>>>> (I think -fno-rtti is required only if you sub-class LLVM
objects), I would propose
>>>> adding a separate flag like --uses-rtti.  This would give users
more fine-grained
>>>> control over which flags they use, and also would let them
choose the correct
>>>> flag since, for example, -fno-rtti is not understood by MSVC.
>>>> 
>>>> How do people feel about this proposal?
>>>> 
>>>> Thanks,
>>>> Tom
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>   
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>>> 
>>> 
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>       
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150803/6fa6fe1e/attachment.html>

On Mon, Aug 03, 2015 at 10:51:15AM -0700, Chris Bieneman
wrote:
> 
> > On Aug 3, 2015, at 10:30 AM, Mehdi Amini <mehdi.amini at
apple.com> wrote:
> > 
> >> 
> >> On Aug 3, 2015, at 10:24 AM, Chris Bieneman <beanz at apple.com
<mailto:beanz at apple.com>> wrote:
> >> 
> >> Hey Tom,
> >> 
> >> I’m not a regular user of llvm-config, but this sounds completely
right to me, and it would be a significant improvement over what we have now.
> >> 
> >> The only question I want to raise is, what about NDEBUG? There are
headers that conditionalize on NDEBUG, which could lead to ABI incompatibility
in the C++ API.
> > 
> > Is it something that can be fixed or would it be too complicated to
handle?
> 
> I think this would need a case-by-case determination that I haven’t done.
There are quite a few occurrences of NDEBUG in headers:
> 
I think the issue with NDEBUG has been raised in the past, but I can't
find the email thread.  As I recall the suggestion was to replace NDEBUG
in headers with something like LLVM_NDEBUG.  I think this makes sense.
Is there any downside to making this change?

-Tom


> > grep -r NDEBUG ./include/ | wc -l
>       77
> 
> I imagine many of these aren’t actually ABI issues, but I know that ABI
issues have existed in the past.
> 
> -Chris
> 
> > It would be nice in general to be able to link a “Non assert” build of
Clang with an “Assert" version of  LLVM (and vice-versa).
> > 
> > And on the original topic: +1 for Tom proposal/goal, it makes sense to
me.
> > 
> > —
> > Mehdi
> > 
> > 
> > 
> >> 
> >> Thanks for doing this,
> >> -Chris
> >> 
> >>> On Jul 30, 2015, at 1:04 PM, tom at stellard.net wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> My understanding of llvm-config --cxxflags is that it is
supposed to report
> >>> which flags are necessary to compile a program that will
include LLVM's
> >>> headers and link against its libraries.  What it currently
reports is
> >>> all of the flags which were used to compile LLVM.  This is not
very useful,
> >>> because users are required in most cases to filter out flags
they don't
> >>> want.
> >>> 
> >>> I would like to try to fix this so that it reports only the
bare minimum
> >>> of required flags.  As an example here all the flags that it
reports in
> >>> my autoconf build of llvm:
> >>> 
> >>> -I/usr/local/llvm/3.8/include
> >>> -D_DEBUG
> >>> -D_GNU_SOURCE
> >>> -D__STDC_CONSTANT_MACROS
> >>> -D__STDC_FORMAT_MACROS
> >>> -D__STDC_LIMIT_MACROS
> >>> -O3
> >>> -fomit-frame-pointer
> >>> -std=c++11
> >>> -fvisibility-inlines-hidden
> >>> -fno-exceptions
> >>> -fno-rtti
> >>> -fPIC
> >>> -ffunction-sections
> >>> -fdata-sections
> >>> -Wcast-qual
> >>> 
> >>> Of these flags the only ones that are really required are (c++
experts
> >>> please correct me if I'm wrong here):
> >>> 
> >>> -I/usr/local/llvm/3.8/include
> >>> -D__STDC_CONSTANT_MACROS
> >>> -D__STDC_FORMAT_MACROS
> >>> -D__STDC_LIMIT_MACROS
> >>> -std=c++11
> >>> 
> >>> Technically the -D__STDC* macros are only required if you
include
> >>> Support/DataTypes.h, but I think that is hard to avoid.
> >>> 
> >>> As I understand, The rest of the flags are not required in
100% of the
> >>> use cases.
> >>> 
> >>> My proposal for fixing this is to remove everything but the 5
options listed
> >>> above.
> >>> 
> >>> For flags like -fno-rtti (are there others?) that are required
in some cases
> >>> (I think -fno-rtti is required only if you sub-class LLVM
objects), I would propose
> >>> adding a separate flag like --uses-rtti.  This would give
users more fine-grained
> >>> control over which flags they use, and also would let them
choose the correct
> >>> flag since, for example, -fno-rtti is not understood by MSVC.
> >>> 
> >>> How do people feel about this proposal?
> >>> 
> >>> Thanks,
> >>> Tom
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >> 
> >> 
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>      
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>