Hi All,
I see a build failure on AIX.
g++ -std=c++14 -c -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-error=narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H
-DGENERATOR_FILE -I. -Ibuild -I/opt/freeware/src/packages/BUILD/gcc/gcc
-I/opt/freeware/src/packages/BUILD/gcc/gcc/build
-I/opt/freeware/src/packages/BUILD/gcc/gcc/../include
-I/opt/freeware/src/packages/BUILD/gcc/gcc/../libcpp/include
-I/home/sangam/install/include \
-o build/gencondmd.o build/gencondmd.cc
In file included from ./tm_p.h:5,
from build/gencondmd.cc:29:
./tm-preds.h: In function 'size_t insn_constraint_len(char, const char*)':
./tm-preds.h:350:30: error: 'rawmemchr' was not declared in this scope; did
you mean 'wmemchr'?
350 | return ((const char *) rawmemchr (str + 1, '}') - str) + 1;
| ^~~~~~~~~
| wmemchr
g++ -std=c++14 -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-error=narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H
-DGENERATOR_FILE -static-libstdc++ -static-libgcc -Wl,-bbigtoc
-Wl,-bmaxdata:0x40000000 -o build/genmatch \
build/genmatch.o ../build-powerpc-ibm-aix7.3.1.0/libcpp/libcpp.a
build/errors.o build/vec.o build/hash-table.o build/sort.o
../build-powerpc-ibm-aix7.3.1.0/libiberty/libiberty.a
make[3]: *** [Makefile:3200: build/gencondmd.o] Error 1
Thanks,
Sangamesh
On Mon, Jul 21, 2025 at 4:46 PM 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
>
--
Thanks & Regards,
Sangamesh
