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. > > 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.
