llvm dev - Jul 2013 - [LLVMdev] Proposing a new 'alloca' parameter attribute to implement the Microsoft C++ ABI

Oh, well, I don't actually have any objection to the patch (I'm not
sure if Oscar does) or work in this direction. (So apologies for
hijacking, it's just I wanted to back up the sentiment that Oscar
expressed initially.)

I'm honestly just trying to understand why the engineering focus is
where it is, and wonders if anyone has put any thought into supporting
our own (or possibly someone else's, if it's documented) C++ ABI on
Windows, as a either a subgoal or parallel goal of full MSVC C++ ABI
implementation. As I said before, something like that wouldn't just be
a stop gap, it would provide real benefits on its own.

I'll stop hijacking this thread for that, though, sorry.

Stephen

On Wed, Jul 31, 2013 at 9:54 AM, Chris Lattner <clattner at apple.com>
wrote:
> This thread is odd to me. It seems that the gist of your guys' argument
is that you don't know if we will ever get full support, therefore we
don't welcome progress towards that (very useful) goal/feature.
>
> If the specific proposal doesn't make make sense from a design
standpoint, that's one thing, but saying we shouldn't take it because of
licensing issues with MFC or because it is harmful to be partially (but not
fully) compatible with MSVC seems just weird to me.
>
> -Chris
>
> On Jul 31, 2013, at 9:04 AM, Stephen Lin <swlin at post.harvard.edu>
wrote:
>
>>> Quite the contrary, knowing that Clang's C++ ABI is completely
>>> incompatible with MS is a maintenance *simplification*.
>>
>> Yes, for example, as explained by Bjarne once, incompatible name
>> mangling schemes for ABIs that are not guaranteed to be 100% binary
>> compatible is a _feature_, not a bug, since it prevents anyone from
>> even beginning to develop a workflow that relies upon linking possibly
>> incompatible binaries.
>>
>>>
>>> Saying that supporting the MS C++ ABI is an uphill battle is an
>>> understatement (and better say MS C++ ABI*S*, because it evolved
over
>>> time and it is known that it will change on future releases.) As
far as
>>> I'm concerned, I'll never base my decisions on compiler
usage on the
>>> advertisement of MS compatibility by Clang++, becase I *know* that
for a
>>> very long time (maybe forever) whatever MS C++ libraries that work
with
>>> Clang++ is by luck. That's what happens when you try to
implement
>>> compatibility with an undocumented, propietary, complex feature.
>>
>> This is my point as well; it just seems odd to spend so much effort to
>> implement and undocumented ABI with no guarantee of support or
>> stability (outside of MSVC major version releases). Furthermore, I
>> feel that, by reinforcing the notion that use of the MSVC++ ABI is
>> required for development on Windows (when no system-provided libraries
>> or ABIs require it), Clang developers are hindering the adoption of
>> Clang on Windows rather than promoting it, since it is unlikely that
>> any party that is not personally invested in Clang development would
>> be willing to depend on a backward engineered implementation of a
>> "required" but undocumented ABI for production use.
Furthermore, it
>> means that Clang will always be behind the curve on Windows, since,
>> even if MSVC++ ABI support is fully usable one day, no one will be
>> willing to link it with object files from a new major version of MSVC
>> without some critical mass of users being guinea pigs first and
>> ensuring that there are no major bugaboos.
>>
>> I agree that there is value in supporting implementing full MSVC++
>> ABI, if it can be done, but it seems like that support can never be
>> 100% complete (or, more to the point, known to be 100% complete)
>> unless Microsoft itself decides to officially support the
>> implementation or completely stabilize and document their C++ ABIs.
>> However, I personally think that it is not only easier, there is more
>> value in implementing a C++ ABI which is compatible with officially
>> supported C and COM MSVC++ ABI subsets and consciously _not_
>> compatible in others way (in particular, which does not even attempt
>> to link C++ symbols with MSVC++, since that is not required for COM).
>> This is something that can be made to work and guaranteed (barring
>> some seriously misguided behavior from Microsoft) to continue to work
>> stably.
>>
>> Furthermore, by providing and controlling its own Windows C++ ABI:
>> Clang can possibly offer something that MSVC *cannot* (and does not
>> even try to do): a development platform and ecosystem which provides a
>> stable-over-time C++ ABI and consistent cross-module usage of RTTI,
>> STL, C++ memory management, etc. (which is dicey even within MSVC
>> major versions unless the exact same build settings are used, last
>> time I checked.) This would give someone an active reason to switch to
>> Clang more than anything else Clang currently offers on Windows.
>>
>> Stephen
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Jul 31, 2013 10:16 AM, "Stephen Lin" <swlin at
post.harvard.edu> wrote:
>
> Oh, well, I don't actually have any objection to the patch (I'm not
> sure if Oscar does) or work in this direction. (So apologies for
> hijacking, it's just I wanted to back up the sentiment that Oscar
> expressed initially.)
>
> I'm honestly just trying to understand why the engineering focus is
> where it is, and wonders if anyone has put any thought into supporting
> our own (or possibly someone else's, if it's documented) C++ ABI on
> Windows, as a either a subgoal or parallel goal of full MSVC C++ ABI
> implementation. As I said before, something like that wouldn't just be
> a stop gap, it would provide real benefits on its own.
Thia patch and the others currently under development seem clearly aimed at
compatibility
If you or others are interested in something else then mail the patches. I
don't think any of this precludes the other.
>
> I'll stop hijacking this thread for that, though, sorry.
If you're around I think several of us will be at the social tomorrow.
Always a good place to have such discussions.
>
> Stephen
>
> On Wed, Jul 31, 2013 at 9:54 AM, Chris Lattner <clattner at
apple.com> wrote:
> > This thread is odd to me. It seems that the gist of your guys'
argument
is that you don't know if we will ever get full support, therefore we
don't
welcome progress towards that (very useful)
goal/feature.
> >
> > If the specific proposal doesn't make make sense from a design
standpoint, that's one thing, but saying we shouldn't take it because of
licensing issues with MFC or because it is harmful to be partially (but not
fully) compatible with MSVC seems just weird to me.
> >
> > -Chris
> >
> > On Jul 31, 2013, at 9:04 AM, Stephen Lin <swlin at
post.harvard.edu> wrote:
> >
> >>> Quite the contrary, knowing that Clang's C++ ABI is
completely
> >>> incompatible with MS is a maintenance *simplification*.
> >>
> >> Yes, for example, as explained by Bjarne once, incompatible name
> >> mangling schemes for ABIs that are not guaranteed to be 100%
binary
> >> compatible is a _feature_, not a bug, since it prevents anyone
from
> >> even beginning to develop a workflow that relies upon linking
possibly
> >> incompatible binaries.
> >>
> >>>
> >>> Saying that supporting the MS C++ ABI is an uphill battle is
an
> >>> understatement (and better say MS C++ ABI*S*, because it
evolved over
> >>> time and it is known that it will change on future releases.)
As far
as
> >>> I'm concerned, I'll never base my decisions on
compiler usage on the
> >>> advertisement of MS compatibility by Clang++, becase I *know*
that
for a
> >>> very long time (maybe forever) whatever MS C++ libraries that
work
with
> >>> Clang++ is by luck. That's what happens when you try to
implement
> >>> compatibility with an undocumented, propietary, complex
feature.
> >>
> >> This is my point as well; it just seems odd to spend so much
effort to
> >> implement and undocumented ABI with no guarantee of support or
> >> stability (outside of MSVC major version releases). Furthermore, I
> >> feel that, by reinforcing the notion that use of the MSVC++ ABI is
> >> required for development on Windows (when no system-provided
libraries
> >> or ABIs require it), Clang developers are hindering the adoption
of
> >> Clang on Windows rather than promoting it, since it is unlikely
that
> >> any party that is not personally invested in Clang development
would
> >> be willing to depend on a backward engineered implementation of a
> >> "required" but undocumented ABI for production use.
Furthermore, it
> >> means that Clang will always be behind the curve on Windows,
since,
> >> even if MSVC++ ABI support is fully usable one day, no one will be
> >> willing to link it with object files from a new major version of
MSVC
> >> without some critical mass of users being guinea pigs first and
> >> ensuring that there are no major bugaboos.
> >>
> >> I agree that there is value in supporting implementing full MSVC++
> >> ABI, if it can be done, but it seems like that support can never
be
> >> 100% complete (or, more to the point, known to be 100% complete)
> >> unless Microsoft itself decides to officially support the
> >> implementation or completely stabilize and document their C++
ABIs.
> >> However, I personally think that it is not only easier, there is
more
> >> value in implementing a C++ ABI which is compatible with
officially
> >> supported C and COM MSVC++ ABI subsets and consciously _not_
> >> compatible in others way (in particular, which does not even
attempt
> >> to link C++ symbols with MSVC++, since that is not required for
COM).
> >> This is something that can be made to work and guaranteed (barring
> >> some seriously misguided behavior from Microsoft) to continue to
work
> >> stably.
> >>
> >> Furthermore, by providing and controlling its own Windows C++ ABI:
> >> Clang can possibly offer something that MSVC *cannot* (and does
not
> >> even try to do): a development platform and ecosystem which
provides a
> >> stable-over-time C++ ABI and consistent cross-module usage of
RTTI,
> >> STL, C++ memory management, etc. (which is dicey even within MSVC
> >> major versions unless the exact same build settings are used, last
> >> time I checked.) This would give someone an active reason to
switch to
> >> Clang more than anything else Clang currently offers on Windows.
> >>
> >> Stephen
> >> _______________________________________________
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/ec55cdc5/attachment.html>

On Wed, Jul 31, 2013 at 10:33 AM, Chandler Carruth <chandlerc at
google.com>wrote:
>
> On Jul 31, 2013 10:16 AM, "Stephen Lin" <swlin at
post.harvard.edu> wrote:
> >
> > Oh, well, I don't actually have any objection to the patch
(I'm not
> > sure if Oscar does) or work in this direction. (So apologies for
> > hijacking, it's just I wanted to back up the sentiment that Oscar
> > expressed initially.)
> >
> > I'm honestly just trying to understand why the engineering focus
is
> > where it is, and wonders if anyone has put any thought into supporting
> > our own (or possibly someone else's, if it's documented) C++
ABI on
> > Windows, as a either a subgoal or parallel goal of full MSVC C++ ABI
> > implementation. As I said before, something like that wouldn't
just be
> > a stop gap, it would provide real benefits on its own.
>
> Thia patch and the others currently under development seem clearly aimed
> at compatibility
> If you or others are interested in something else then mail the patches. I
> don't think any of this precludes the other.
>
Just to clarify, there's no patch for this particular issue yet.  This is
an RFC so I don't waste time on patches that will be rejected due to high
level concerns.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/941c619b/attachment.html>

> Thia patch and the others currently under development seem clearly aimed at
> compatibility
> If you or others are interested in something else then mail the patches. I
> don't think any of this precludes the other.
Thanks. Unfortunately, it's not something I can prioritize to work, so
all I can do at this point is express my opinion and hope someone
agrees with me :)

And yes, of course, it's not mutually exclusive at all; in fact, it
seems like from a technical perspective a lot of the work for a C and
COM-complaint ABI (but Itanium-like otherwise, perhaps) would be a
subset of the work of doing full compatibility--things would just need
to be repackaged and exposed in a different. So it would be great if
someone actively working in this area can keep such an idea in mind,
since I think it would be valuable for reasons other than as a stop
gap. (A stable and sane Windows C++ ABI with quality compiler support
would have been a godsend to me in a former life, personally.)

Stephen