On Mon, Jul 21, 2025 at 4:16 AM Stefan Schulze Frielinghaus <stefa...@linux.ibm.com> wrote: > > On Sat, Jul 19, 2025 at 08:26:22AM -0600, Jeff Law wrote: > > > > > > On 7/17/25 2:24 AM, Stefan Schulze Frielinghaus wrote: > > > On Wed, Jul 09, 2025 at 03:48:43PM +0200, Stefan Schulze Frielinghaus > > > wrote: > > > > This is a follow-up to > > > > https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684181.html > > > > > > > > I added the last missing pieces namely changelogs, and bootstrapped and > > > > regtested on > > > > > > > > aarch64-unknown-linux-gnu > > > > powerpc64le-unknown-linux-gnu > > > > s390x-ibm-linux-gnu > > > > x86_64-pc-linux-gnu > > > > > > > > Via cross compilers I verified the new tests for > > > > > > > > arm-linux-gnueabi > > > > i686-linux-gnueabi > > > > powerpc-linux-gnu > > > > riscv32-linux-gnu > > > > riscv64-linux-gnu > > > > > > > > Despite that I removed overloads for parse_{input,output}_constraint() > > > > by passing a null pointer explicitly. Furthermore, in case of register > > > > pairs, if two constraints of operands overlap, error out and report the > > > > overlapped register. For example, on aarch64 > > > > > > > > svuint32x2_t x, y; > > > > asm ("" : "={z5}" (x), "={z6}" (y)); > > > > > > > > previously I used the register as is of the first constraint in the > > > > error message which is imprecise/misleading. Now, I error out reporting > > > > multiple outputs to register z6/v6, i.e., the actual overlapped one, and > > > > not z5/v5 as previously. > > > > > > > > Although I found a lot of corner cases during development via > > > > -fdemote-register-asm I removed it from this patch series. I > > > > compiled and used the Linux kernel and glibc successfully with it for > > > > s390x. For x86_64, the Linux kernel compiles fine, too, except of one > > > > small manual change. For powerpc64le, I ran into an odd case compiling > > > > glibc which I would like to understand in more detail. Since register > > > > asm is not as strict as hard register constraints, for a full fledged > > > > implementation I need to consider more corner cases. Therefore, I would > > > > like to spend some more time on this before I push this new feature. > > > > > > > > In total no huge changes. Still ok for mainline? > > > > > > Although the v4 patches have been acked I'm not sure whether this falls > > > under the "is obvious" rule since I changed a little bit. If I get your > > > final Ok I will push these patches and will not bother you further ;-) > > > I already have an idea for the fourth patch (-fdemote-register-asm) > > > which I exclude for the moment and will come back to in the future. > > It's often left to the submitter to decide if minor adjustments require > > another review round. There's no firm policy. > > > > A fairly easy line to draw is are you just adjusting to ongoing trunk > > changes? If so, that's almost always not a problem and wouldn't suggest a > > re-review. > > > > If you made substantial changes to the implementation, then a re-review is > > probably advisable. > > > > For the stuff in the middle? Your best judgment as an engineer ;-) > > Certainly if you post for a re-review, give us some idea of what changed so > > we know where to focus. > > Thanks for clarification. Since the late time changes were rather a > nit/fixup, I committed the v5 patches as > > r16-2376-g9791950017c90c > r16-2375-gcbf17db978c663 > r16-2374-ga51c146ebce41b > > Cheers, > Stefan
These caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121205 -- H.J.
