Re: D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
> On 21/04/2021 00:02 Peter Bergner wrote:
>
>
> On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote:
> > On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
> >> /tmp/cc8zG8DV.s: Assembler messages:
> >> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
> >> /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
> [snip]
> > So do we need to change
> > +else version (PPC)
> >
> >
> > +{
> >
> >
> > +void*[19] regs = void;
> >
> >
> > +asm pure nothrow @nogc
> >
> >
> > +{
> >
> >
> > +"stw r13, %0" : "=m" (regs[ 0]);
> >
> >
> > +"stw r14, %0" : "=m" (regs[ 1]);
> >
> >
> > ...
> > +else version (PPC64)
> >
> >
> > +{
> >
> >
> > +void*[19] regs = void;
> >
> >
> > +asm pure nothrow @nogc
> >
> >
> > +{
> >
> >
> > +"std r13, %0" : "=m" (regs[ 0]);
> >
> >
> > +"std r14, %0" : "=m" (regs[ 1]);
> >
> >
> > ...
> > to "stw 13, %0" and "std 13, %0" etc. unconditionally, or
> > to "stw %%r13, %0" etc. under some conditions?
>
> Yes, I think so. The "r13", etc. names are not accepted by gas unless you
> use the -mregnames option. It's easier to just remove the 'r'.
>
OK, unless told otherwise, I'll keep them in for darwin though.
--- a/libphobos/libdruntime/core/thread/osthread.d
+++ b/libphobos/libdruntime/core/thread/osthread.d
@@ -1444,55 +1444,35 @@ in (fn)
else version (PPC)
{
void*[19] regs = void;
-asm pure nothrow @nogc
-{
-"stw r13, %0" : "=m" (regs[ 0]);
-"stw r14, %0" : "=m" (regs[ 1]);
-"stw r15, %0" : "=m" (regs[ 2]);
-"stw r16, %0" : "=m" (regs[ 3]);
-"stw r17, %0" : "=m" (regs[ 4]);
-"stw r18, %0" : "=m" (regs[ 5]);
-"stw r19, %0" : "=m" (regs[ 6]);
-"stw r20, %0" : "=m" (regs[ 7]);
-"stw r21, %0" : "=m" (regs[ 9]);
-"stw r22, %0" : "=m" (regs[ 9]);
-"stw r23, %0" : "=m" (regs[10]);
-"stw r24, %0" : "=m" (regs[11]);
-"stw r25, %0" : "=m" (regs[12]);
-"stw r26, %0" : "=m" (regs[13]);
-"stw r27, %0" : "=m" (regs[14]);
-"stw r28, %0" : "=m" (regs[15]);
-"stw r29, %0" : "=m" (regs[16]);
-"stw r30, %0" : "=m" (regs[17]);
-"stw r31, %0" : "=m" (regs[18]);
-}
+version (Darwin)
+enum regname = "r";
+else
+enum regname = "";
+static foreach (i; 0 .. regs.length)
+{{
+enum int j = 13 + i; // source register
+asm pure nothrow
Re: libiberty D tuple demangling
> On 25/07/2022 08:45 CEST Jan Beulich wrote:
>
>
> Hello,
>
> while commit 3f30a274913b ("libiberty: Update D symbol demangling
> for latest ABI spec") mentions in its description that tuple encoding
> has changed, there's no real adjustment to dlang_parse_tuple() there,
> nor are there any new (or replaced) test cases for that. Was this
> simply overlooked?
>
Hi Jan,
Is there any specific example that fails to demangle, or are you just skimming?
>From what I recall, there is a couple places in the dlang_demangle parser that
>handle ambiguities in a mangled symbol. The ABI change only added a
>terminating 'Z', which makes said code that handles ambiguity redundant - but
>of course kept around so we handle both old and new symbols.
> Furthermore the current ABI specifies "B Parameters Z". As I don't
> know what the old ABI said, I can only wonder whether the present
> code decoding (in a loop) merely a Type (and not a Parameter) was
> actually correct.
>
Do you think we should instead be calling dlang_function_args instead?
(Having a quick look at both, that does seem to be the case).
Iain.
Re: libiberty D tuple demangling
> On 25/07/2022 14:13 CEST Jan Beulich wrote:
>
>
> On 25.07.2022 14:05, ibuc...@gdcproject.org wrote:
> >> On 25/07/2022 08:45 CEST Jan Beulich wrote:
> >> while commit 3f30a274913b ("libiberty: Update D symbol demangling
> >> for latest ABI spec") mentions in its description that tuple encoding
> >> has changed, there's no real adjustment to dlang_parse_tuple() there,
> >> nor are there any new (or replaced) test cases for that. Was this
> >> simply overlooked?
> >
> > Is there any specific example that fails to demangle, or are you just
> > skimming?
>
> I'm merely looking at the code alongside the ABI spec.
>
> > From what I recall, there is a couple places in the dlang_demangle parser
> > that handle ambiguities in a mangled symbol. The ABI change only added a
> > terminating 'Z', which makes said code that handles ambiguity redundant -
> > but of course kept around so we handle both old and new symbols.
>
> It's not just the addition of Z at the end but also the dropping of the
> number of elements at the beginning, aiui. It's actually that aspect
> which caught my attention, since the ABI doesn't talk about any number
> there, but the code fetches one.
>
Went to have a look at docarchives, but it appears to be down (that's on me, I
have been meaning to migrate the service to new servers).
Yes, your right, the number was indeed dropped too from the ABI.
https://web.archive.org/web/20170812061158/https://dlang.org/spec/abi.html#TypeTuple
TypeTuple:
B Number Parameters
https://dlang.org/spec/abi.html#TypeTuple
TypeTuple:
B Parameters Z
However, it gets worse the more I stare at it. Looks like it was not understood
what 'Number' meant in the old ABI. I assumed it was the encoded number of
tuple elements - same as static arrays - however what I see in the front-end is
instead an encoded buffer length.
https://github.com/gcc-mirror/gcc/blob/releases/gcc-10/gcc/d/dmd/dmangle.c#L312-L313
So the loop should instead be more like:
---
unsigned long len;
mangled = dlang_number (mangled, &len);
if (mangled == NULL)
return NULL;
string_append (decl, "Tuple!(");
const char *endp = mangled + len;
int elements = 0;
while (mangled != endp)
{
if (elements++)
string_append (decl, ", ");
mangled = dlang_type (decl, mangled, info);
if (mangled == NULL || mangled > endp)
return NULL;
}
string_append (decl, ")");
return mangled;
---
On top of that, TypeTuple is a compile-time-only type - it never leaks to the
code generator - so the grammar entry in the ABI is frivolous (although
internally, that it gets a mangle at all would save some memory as duplicated
types are merged).
Iain.
