On Mon, Jul 21, 2025 at 08:02:12PM +0530, swamy sangamesh wrote:
> 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
>
The generated file tm-preds.h contains now:
static inline size_t
insn_constraint_len (char fc, const char *str)
{
...
if (str[0] == '{')
return ((const char *) rawmemchr (str + 1, '}') - str) + 1;
return 1;
}
For some reason on all targets I tested, string.h is included. I will
have a look and see whether string.h may be included easily here, too.
If the dependency to string.h is not wanted, I could also come up with a
simple loop.
Sorry for the inconvenience.
Cheers,
Stefan
> 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
