Re: [PATCH] Additional features for -fms-extensions

[Nathan Sidwell <nathan at codesourcery dot com>]

Giovanni Bajo wrote:
> Schönbeck, Andreas wrote:
>
>
> > + An ellipsis does not take variables of non-POD type as arguments:
>
>
> I believe the patch is not safe. It might work for some limited case of
> semi-POD classes (for instance, classes without destructors, or classes
> without virtual members), but I would like to know if this does not
> introduce cases where we abort later. Maybe an ABI expert can comment on
> this.
>
> If we can isolate some kind of classes for which it is always correct, we
> could isolate the extension to those cases only.

I think these will work ok.  non-pods[1] are passed by 'invisible' pointer,
and the caller is responsible for running dtors.

[1] The ABI separates out classes with trivial dtors and trivial copy-ctors
and treats them pretty much pod-like for passing.


> > + When passing a lvalue to a function which wants to take a reference
>
> there
>
> > is an error thrown:
>
>
> I have bad gut feelings about this as well. This is a very delicate area of
> the standard, so I do not know if this works well in complex overload &
> template contexts. Nathan knows something about this for sure. Of course, it
> could be argued that you get what you ask for, so if the compiler then hangs
> or segfaults on complex testcases you should not use -fms-extensions :)

this is about binding a temporary to a non-constant reference. It affects
overload resolution and template deduction.  It will allow changing of the
constant 3[2], for instance.

[2] compiler passes address of a '3' constant, and that value is changed by
the caller.  Compiler later relies on that slot not having been changed, and
things go wrong.

> > + When declaring something extern and later static an error is thrown

> I do not know about this. Maybe other declaration experts can comment on
> side effects of this.

I believe there are architectures that generate different call sequences
for local and non-local calls.  Such an architecture would fail if there was
a call to the function between the declaration and definition.

> > + When declaring a not-anonymous union within an anonymous union an error
>
> is
>
> > thrown
> > + When declaring something extern and later static an error is thrown

> These are feasable AFAICT.
I'm not sure.  What is the linkage of the not-anonymous union?  Can it
be used as part of a function parameter type? What is the mangled name of
that type? (I.e. I'd need to think harder about this one)

> > + The address of a member of a packed struct can't be retrieved

> I believe this could be a problem for platforms which do not support
> unaligned memory accesses. In this case, it would make sense to restrict the
> extensions to the platform where it works (like x86).

The problem is that the address of the packed field is not aligned correctly.
On i86 that doesn't matter, but on other architectures it can cause a bus-fault.
The problem is the address of that field is 'int *' but really should be
'int packed *' or something, to propagate the non-alignment (much like CV qualifiers
are dealt with).  Allowing this extension leads to unportable code -- but
hey -ms-extensions is unportable anyway.

I personally don't like such extensions, but if we're going to implement
ms-extensions, we should implement them all ... Maybe we should only allow
them on i86 targets :)

It will be easier to consider these if
a) they were posted separately
b) each had a testcase and changelog in the appropriate format
c) each had a description/rationale (you've got this already)
d) doc/extend.texi was patched appropriately.

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk