On 6/19/26 5:30 PM, Jeffrey Law wrote: > Either works for me. If we go with the backport, then I'd suggest > letting it simmer on the trunk for a week or so. While I don't expect > problems, the soak time never hurts. Duplication is safer, but > obviously would require more maintenance if we find something needs to > change in the ascalon bits. > > Ultimately, your call. I'll support either approach.
The duplicated entries both use the same tt_ascalon_d8 and tt_ascalon_d8_tune_info data, which is where the bulk of the Ascalon code lives, so the only extra maintenance would be if we needed to change the extensions in the RISCV_CORE() entries and I think those are fairly solid. Therefore, I think I'm leaning towards just using the duplicated entry patch to be super safe. I'm currently testing that now. I didn't change any of the tt_ascalon_d8 usage in the tt-ascalin-d8.md file, since that would be a huge mechanical patch for little gain. That said, I think we are missing some of the Ascalon changes that went into GCC 16 in the GCC 15 release branch, so I have some homework to see what else we may want/need to backport to GCC 15. Peter
