On 07.01.26 21:40, Jonathan Wakely wrote:
> On Wed, 7 Jan 2026 at 20:36, Frank Scheiner <[email protected]> wrote:
>>
>> On 07.01.26 21:28, Jonathan Wakely wrote:
>>> On Wed, 7 Jan 2026 at 19:56, Frank Scheiner <[email protected]> wrote:
>>>>
>>>> As per latest testsuite results for ia64 based on gcc-16-20251214 ([1])
>>>> "libstdc++-abi/abi_check" is failing. This is due to outdated baseline
>>>> symbols for ia64-linux. These were now regenerated based on the above
>>>> mentioned GCC version, fixing the previously failing test:
>>>>
>>>> ```
>>>> ==== libstdc++-v3 check-abi Summary ====
>>>>
>>>> # of added symbols: 0
>>>> # of missing symbols: 0
>>>> # of undesignated symbols: 0
>>>> # of incompatible symbols: 0
>>>>
>>>> using: baseline_symbols.txt
>>>> PASS: libstdc++-abi/abi_check
>>>> testcase
>>>> /dev/shm/gcc-16-20251214/libstdc++-v3/testsuite/libstdc++-abi/abi.exp
>>>> completed in 127 seconds
>>>> ```
>>>>
>>>> [1]:
>>>> https://gcc.gnu.org/pipermail/gcc-testresults/2025-December/865397.html
>>>>
>>>> Also update on trunk with attached patch.
>>>
>>> The GLIBCXX_3.4.35 and CXXABI_1.3.17 symbols should not be added yet,
>>> not until GCC 16.1.0 is close to release.
>>
>> I see.
>>
>>> The symbols for the older symbol versions GLIBCXX_3.4.{30,31,33,34}
>>> are the ones that need to be added.
>>
>> Should I (1) make a V2 and add just these now and update again close to
>> GCC 16.1.0 release or (2) carry this locally until then and make a
>> single patch instead when it's time?
>
> Please send a v2 patch for the missing symbols now, so that the ia64
> baseline is fixed (and that patch would also be appropriate for the
> gcc-15 branch). Then when the GCC 16 symbols are added it will just be
> a smaller incremental change, which will only add symbols for the new
> symbol versions in GCC 16, and will match the updates for other
> similar targets.
Ok, should be done. I'll test the changed patch tomorrow and then send in
a V2.
>>> Also the TLS symbols for __once_call and __once_callable should not be
>>> added (by convention, because those are not present for all
>>> configurations).
>>
>> Ah ok, is their a documentation available about this convention
>> somewhere?
>
> I don't think so, but those symbols have been around for many years
> and are not in any of the baselines for *-*-linux-gnu targets so you
> can compare and contrast with the others.
Thanks for the pointers.
Cheers,
Frank
