On Mon, Jul 21, 2025 at 01:54:55PM -0700, H.J. Lu wrote: > 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
Right, I only tested for i?86 and x86_64 && lp64 but forgot about -m32. I will look into those and come up with a patch. Cheers, Stefan > > > -- > H.J.
