I came across a couple of clang workarounds for old libstdc++ issues. One of them seems good for removal, by documenting the oldest supported libstdc++ as 4.9, which is what https://reviews.llvm.org/D100465 does.
The other is more recent, and proposing to keep that (see https://reviews.llvm.org/D100469)
any objections on the oldest libstdc++ version?
nathan
Was there any oldest supported libstdc++ version previously documented?
How's this compare (is there any insight to be gained by such
comparison?) with the oldest supported gcc?
Was there any oldest supported libstdc++ version previously documented?
I think this might be the only place we talk about it: https://clang.llvm.org/docs/Toolchain.html#libstdc-gnu
“Clang supports a wide range of versions of libstdc++, from around version 4.2 onwards, and will implicitly work around some bugs in older versions of libstdc++.”
How’s this compare (is there any insight to be gained by such
comparison?) with the oldest supported gcc?
Do you mean the oldest GCC that we support as a host compiler? That’s GCC 5.1 (https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library), so bumping our minimum libstdc++ to 4.9 brings these closer together.
I came across a couple of clang workarounds for old libstdc++ issues.
One of them seems good for removal, by documenting the oldest supported
libstdc++ as 4.9, which is what https://reviews.llvm.org/D100465 does.The other is more recent, and proposing to keep that (see
https://reviews.llvm.org/D100469)
Here are a few more that we may be able to remove:
https://github.com/llvm/llvm-project/blob/main/clang/lib/Parse/ParseDecl.cpp#L6568
https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp#L859
https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaTemplateInstantiateDecl.cpp#L1524
Was there any oldest supported libstdc++ version previously documented?
I think this might be the only place we talk about it: https://clang.llvm.org/docs/Toolchain.html#libstdc-gnu
"Clang supports a wide range of versions of libstdc++, from around version 4.2 onwards, and will implicitly work around some bugs in older versions of libstdc++."
How's this compare (is there any insight to be gained by such
comparison?) with the oldest supported gcc?Do you mean the oldest GCC that we support as a host compiler? That's GCC 5.1 (https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library), so bumping our minimum libstdc++ to 4.9 brings these closer together.
yeah, though fair point that it's a pretty significant distinction
between what you need to compile LLVM versus what you need to run/link
to LLVM, so it's not a huge indicator of much. But good to know.
Agreed re: Google. Not sure about the issue Erich mentions re: Redhat.
it's a long time to keep these workarounds around... though not sure
how much they cost us to keep either. Doesn't seem likely to be hugely
costly?
We enforce libstdc++ >= 5.1 when building LLVM (in order for C++14 support), and I would imagine that same minimum applies to being able to run the built binaries. See https://github.com/llvm/llvm-project/blob/main/llvm/cmake/modules/CheckCompilerVersion.cmake (the libstdc++ version is specifically checked towards the end of that file).
>
>>
>> Was there any oldest supported libstdc++ version previously documented?
>
>
> I think this might be the only place we talk about it: https://clang.llvm.org/docs/Toolchain.html#libstdc-gnu
>
> "Clang supports a wide range of versions of libstdc++, from around version 4.2 onwards, and will implicitly work around some bugs in older versions of libstdc++."
>
>> How's this compare (is there any insight to be gained by such
>> comparison?) with the oldest supported gcc?
>
>
> Do you mean the oldest GCC that we support as a host compiler? That's GCC 5.1 (https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library ), so bumping our minimum libstdc++ to 4.9 brings these closer together.
yeah, though fair point that it's a pretty significant distinction
between what you need to compile LLVM versus what you need to run/link
to LLVM, so it's not a huge indicator of much. But good to know.
Agreed re: Google. Not sure about the issue Erich mentions re: Redhat.
it's a long time to keep these workarounds around... though not sure
how much they cost us to keep either. Doesn't seem likely to be hugely
costly?
2 of those are now nuked, the remaining one has additional information so the EOL criteria is clearer.
nathan
Fantastic, thank you 