Importable STL Header Units?
Currently, when importing the standard library, one has to separately compile each unit they want to use, which is a hindrance to the build process and a gap in the implementation. Is there any particular reason why gcc doesn't provide importable header units for the standard library? Is there a timeline for this? Given that the standard library can already be compiled into header units, is there any particular reason why those aren't shipped with gcc?
Re: Importable STL Header Units?
On Mon, Jul 25, 2022 at 19:48:28 +1000, Zopolis0 via Gcc wrote: > Currently, when importing the standard library, one has to > separately compile each unit they want to use, which is a hindrance to the > build process and a gap in the implementation. > > Is there any particular reason why gcc doesn't provide importable header > units for the standard library? Is there a timeline for this? Given that > the standard library can already be compiled into header units, is there > any particular reason why those aren't shipped with gcc? Some questions that come to mind if GCC were to provide this: - What flags should be used for these pre-compiled units? - How do you expect build systems to be able to find them? Will there be some kind of naming convention? It'd certainly be nice if other implementations would cooperate… (FD: CMake developer working on module support myself) It is my belief that any module-supporting build system has to consider the possibility of compiling any given external module because there's no guarantee that the flag set is compatible (say, `-ffast-math` or other "fun" flags with ABI implications) and you'll need your own compilation of the module anyways. Having pre-compiled units is nice, but merely an optimization for any robust build system; you certainly can't just use any available pre-compiled module blindly (unless you're relying on the linker to detect mismatches or something). The C++ committee's SG15 (Tooling) is looking into the problem. These papers are likely of interest to you (still under discussion): https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2577r2.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2581r0.pdf More papers will certainly appear: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/ --Ben
Re: Importable STL Header Units?
On Mon, 25 Jul 2022 at 10:49, Zopolis0 via Gcc wrote: > > Currently, when importing the standard library, one has to > separately compile each unit they want to use, which is a hindrance to the > build process and a gap in the implementation. > > Is there any particular reason why gcc doesn't provide importable header > units for the standard library? Is there a timeline for this? Given that > the standard library can already be compiled into header units, is there > any particular reason why those aren't shipped with gcc? Are you asking why GCC doesn't install compiled module interface files for the std::lib headers? Those would have to be built with a specific set of compiler options, and then would only work if you compile with those same options. Should they enable C++20 features, or C++23 as well? Should they be built with assertions enabled? etc. etc. Those seem like things that should be decided by the user consuming those header units, not by the GCC project. More generally, GCC's support for modules (and all of C++20) is still experimental, so I don't think we're ready to be installing CMI files yet. If you disagree, feel free to propose patches to install header units. Changes like that happen because somebody works on it, not by magic. Later today the C++ committee is likely to approve https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2465r3.pdf for C++23, and I think implementing that would be a far better use of our limited resources than providing importable header units.
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: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.
>> 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).
Well - with a number of elements specified, it might have needed to
be a function processing a single argument only. For the new ABI -
yes, that's the function I would have expected to be called.
Jan
Re: [RFC] Function Multi Versioning on Arm
On 7/22/22 10:40, Daniel Kiss wrote: > IMHO it would make sense if the “default" attribute becomes optional for > “target”. I'm not against it, but it can be done incrementally. Cheers, Martin
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.
Re: libiberty D tuple demangling
On 25.07.2022 17:45, ibuc...@gdcproject.org wrote:
>> 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;
> ---
Oh. Then two of the testcases are actually wrong as well:
_D8demangle4testFB2OaaZv
_D8demangle4testFB3aDFZaaZv
I would have assumed they had been taken from observable output of a
compiler, ...
> 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).
... but one way of reading this would make me infer that can't have
been the case.
Jan
How to best reference ltdl.m4?
As part of my gcj work, I need to call a couple of variables and functions from ltdl.m4 (installed in usr/share/aclocal, as part of libltdl). Should I reference the system installed copy? How would I do that? Or should I copy it into the gcc root directory, like what was done with libtool.m4? If I end up doing that, what version should I use? (2.2.6 to match the other files, or the latest version, or update all the files)
