Alexandre Oliva wrote:
On Aug 15, 2020, Iain Sandoe wrote:
Alexandre Oliva wrote:
I'm pretty sure setting multiple labels at the same address is used
and relied on quite often.
That’s what’s currently disallowed (the assemblers all support .set).
I understand you mean it's disallowe
On Aug 15, 2020, Iain Sandoe wrote:
> Alexandre Oliva wrote:
>> I'm pretty sure setting multiple labels at the same address is used
>> and relied on quite often.
> That’s what’s currently disallowed (the assemblers all support .set).
I understand you mean it's disallowed for global labels. I
On Aug 15, 2020, Nathan Sidwell wrote:
> 'alias' is also now a confusing term, because of the concept of
> object-aliasing.
True, but it's also an established attribute name. It seems thus
desirable to bring the conceptual framework of the alias attribute to
mind through the name of the attrib
On 8/14/20 10:43 PM, Alexandre Oliva wrote:
On Aug 14, 2020, Nathan Sidwell wrote:
Since you don't seem to have liked 'aka' either, how about 'nickname',
or 'nicknamed'? A more convenient name to refer to an entity is exactly
what this is about, eh?
I'm sorry, I think those are awful name
HI Alexandre
I don’t want to derail the discussion - but FIO mostly….
Alexandre Oliva wrote:
On Aug 15, 2020, Iain Sandoe wrote:
* if the target ABI does not support symbol aliases, then this facility
cannot
be used.
True. I'm surprised there are modern platforms that don’t.
diffe
On Aug 15, 2020, Iain Sandoe wrote:
> what about annotating the import pragma in some way such that the platform
> mangling is applied by the compiler?
Oh, one more thing about this.
Requiring all names to be given in canonical form might alleviate some
of the problems I raised, since it would
On Aug 15, 2020, Iain Sandoe wrote:
> * if the target ABI does not support symbol aliases, then this facility
> cannot
>be used.
True. I'm surprised there are modern platforms that don't.
What is it that stands in the way? Lack of support for .set in the
assembler? If that's the case,
Hi Alexandre,
I built the patch on x86_64-linux and darwin*** (fwiw).
* It’s firmly agreed that there are times when referring to C++ mangled names
is less than ideal.
* IIUC, the objective is to have a short-hand way of annotating an export
from
C++ so that it’s (a) more human-readable a
On Aug 14, 2020, Nathan Sidwell wrote:
> 'exalias' sounds either like a used-to-be alias
*nod*
> or it sounds like exa-lias, making me wonder what a 'lia' is, and why
> I want 10^18 of them
heh
>>> I'm sure we can bikeshed the name 'exalias' doesn't seem very mnemonic
>>> to me. 'symbol_alia
On 8/14/20 3:24 PM, Alexandre Oliva wrote:
On Aug 14, 2020, Nathan Sidwell wrote:
This seems a useful feature. I don;t think it needs language
lawyering -- it's an extension, right?
Well, yeah, but I think it's usually good for even extensions to be
sound language-wise.
By 'same-linkage',
On Aug 14, 2020, Nathan Sidwell wrote:
> This seems a useful feature. I don;t think it needs language
> lawyering -- it's an extension, right?
Well, yeah, but I think it's usually good for even extensions to be
sound language-wise.
> By 'same-linkage', do you mean same linkage as the *symbol*
On 8/14/20 11:39 AM, Alexandre Oliva wrote:
Ping?
In case there isn't immediate approval for the patch proper (I suppose
different parts will require review by different subsystem maintainers),
I'd appreciate at least community and language lawyers buy-in (or
turn-down) for the new feature hereb
Ping?
In case there isn't immediate approval for the patch proper (I suppose
different parts will require review by different subsystem maintainers),
I'd appreciate at least community and language lawyers buy-in (or
turn-down) for the new feature hereby proposed for C-family languages,
namely, att
Since last week's patchlet, I've delayed the creation of the exalias
decls, improved the merging of attributes, minimizing
interface/visibility updates, found a better way to assign exaliases to
nested explicit instantiations, even after enabling aliases to
already-defined types, so now I'm reasona
14 matches
Mail list logo
