[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] Adding support for multiple non-virtual inheritance for -cxx-abi microsoft
From: Richard Smith <richard () metafoo ! co ! uk>
Date: 2013-04-09 0:24:36
Message-ID: CAOfiQqkCo-WFWFpgD-XH8yNGqQ1HqCTXO3J5P9NGc=QTaty9dg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Apr 8, 2013 at 11:33 AM, John McCall <rjmccall@apple.com> wrote:
> On Apr 8, 2013, at 11:08 AM, Reid Kleckner <rnk@google.com> wrote:
> > On Mon, Apr 8, 2013 at 2:02 PM, Timur Iskhodzhanov <timurrrr@google.com=
>
> wrote:
> >> 2013/4/8 John McCall <rjmccall@apple.com>:
> >>> I also find it curious that MSVC uses a thunk for member pointers,
> since
> >>> the required this-adjustment is already plainly expressible in the
> member
> >>> pointer value.
> >> Me too actually.
> >> Reid, wdyt?
> >
> > I think it allows them to avoid the union between non-virtual methods
> > and virtual methods. Seems a bit cleaner and more obvious to me, but
> > it has tradeoffs in terms of code size at the call site and the number
> > of conditional vs. indirect branches that you have to do:
> > indirect to thunk and indirect through vtable, vs conditional between
> > two indirect calls
>
> Oh, does MSVC not do the union thing? They always make a thunk to do
> the virtual call?
>
> If so, this "thunk" is potentially quite a bit more than just a thunk =97=
it
> may
> actually have ABI pointer-equality requirements on it for e.g. member
> pointer equality tests.
>
I don't believe there's any need for that -- comparisons on pointers to
virtual member functions produce unspecified results (see [expr.eq]p2,
second-last sentence).
[Attachment #5 (text/html)]
<div dir="ltr">On Mon, Apr 8, 2013 at 11:33 AM, John McCall <span dir="ltr"><<a \
href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> \
wrote:<br><div class="gmail_extra"><div class="gmail_quote"> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div class="im">On Apr 8, 2013, at 11:08 AM, Reid Kleckner \
<<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br>
> On Mon, Apr 8, 2013 at 2:02 PM, Timur Iskhodzhanov <<a \
href="mailto:timurrrr@google.com">timurrrr@google.com</a>> wrote:<br> >> \
2013/4/8 John McCall <<a \
href="mailto:rjmccall@apple.com">rjmccall@apple.com</a>>:<br> >>> I also \
find it curious that MSVC uses a thunk for member pointers, since<br> >>> \
the required this-adjustment is already plainly expressible in the member<br> \
>>> pointer value.<br> >> Me too actually.<br>
>> Reid, wdyt?<br>
><br>
> I think it allows them to avoid the union between non-virtual methods<br>
> and virtual methods. Seems a bit cleaner and more obvious to me, but<br>
> it has tradeoffs in terms of code size at the call site and the number<br>
> of conditional vs. indirect branches that you have to do:<br>
> indirect to thunk and indirect through vtable, vs conditional between<br>
> two indirect calls<br>
<br>
</div>Oh, does MSVC not do the union thing? They always make a thunk to do<br>
the virtual call?<br>
<br>
If so, this "thunk" is potentially quite a bit more than just a thunk — it \
may<br> actually have ABI pointer-equality requirements on it for e.g. member<br>
pointer equality tests.<br></blockquote><div> </div><div style>I don't believe \
there's any need for that -- comparisons on pointers to virtual member functions \
produce unspecified results (see [expr.eq]p2, second-last sentence).</div> \
</div></div></div>
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic