Hi Jeff, > This ought to work. Plan is to do a first pass through for things that > are clearly safe and simple then work towards the more complex or > controversial stuff. Hopefully I don't goof dependencies again.
Thanks a lot for merging the patches and for the detailed feedback. > > [PATCH v2 08/10] Testsuite: Skip tests making calls to variables: > > https://sourceware.org/pipermail/gcc-patches/2025-March/677845.html > This is mostly OK. When new selectors are added to target-supports.exp, > we need to also update doc/sourcebuild.texi. So resubmit with that > documentation added, and this will be ready to move forward. Regarding this patch, we’ll hold off on upstreaming it until support for microMIPS R6 is added in binutils. Also, thanks to Maciej for the helpful comment about -minterlink-compressed. > > [PATCH v2 02/12] Fix unsafe comparison against stack_pointer_rtx: > > https://sourceware.org/pipermail/gcc-patches/2025-March/677829.html > Is this still an issue? I thought this was fixed a while back in the > renamer. I don't necessarily thing the patch would ever do anything > wrong, but if it's still needed, then that's likely pointing at a bug > elsewhere. There is supposed to be one and only one stack pointer. For this patch, the issue currently cannot be reproduced with the test gcc/testsuite/gcc.target/mips/pr68400.c, as described in this message: https://gcc.gnu.org/pipermail/gcc-patches/2016-January/441362.html. If the problem resurfaces in the future; we’ll follow up accordingly. > > [PATCH v2 05/12] Testsuite: Disable the time-profiler-2.c test: > > https://sourceware.org/pipermail/gcc-patches/2025-March/677835.html > I think we have a dejagnu selector to disable tests under simulation. > That would be better than putting some mips specific check in a generic > test. As for this patch, we’ll skip it for now. Regarding the time-profiler-2.c test, you're absolutely right that modifying a generic test isn't ideal. I looked into your suggestion and found that the `--ignore` option in DejaGNU works well for this purpose, but it seems to apply to .exp files. This seems like a good solution for avoiding instability in simulation environments without touching the test source. If that’s the option you were referring to, or if there’s another mechanism available, could you please confirm? Thanks again for your guidance and support! Best regards, Aleksandar
