Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 13 May 2020 12:53:55 -0500
From: John Arnold <>
To: Rich Felker <>
Cc: Anders Magnusson <>,,
Subject: Re: Re: [Pcc] PCC unable to build musl 1.2.0 (and
 likely earlier)

On Wed, May 13, 2020 at 12:27 PM Rich Felker <> wrote:
> On Wed, May 13, 2020 at 12:00:24PM -0500, John Arnold wrote:
> > > Can you please sen med the offending line?
> >
> > include/limits.h:10:
> > #if '\xff' > 0
> >
> > > Same here, can you send me the line that causes the bug?
> > > And true, __builtin_complex is not recognized in pcc.
> >
> > catan.c:105 is:
> > w = CMPLX(w, 0.25 * log(a));
> >
> > which pcc -E expands to:
> > w = ((union { _Complex double __z; double __xy[2]; }){.__xy =
> > {(w),(0.25 * log(a))}}.__z);
> Where are you getting this from? There has not been any union compound
> literal like that since 2014 because it was found not to be valid in
> constant expressions and CMPLX is required to produce a constant
> expression. Commit 5ff2a118c64224789b7286830912425e58831b2b is
> informative, and the message notes that CMPLX is a C11 feature, so
> since the musl source is supposed to build with just C99 (+ minimal
> extensions) perhaps we should drop internal use of CMPLX anyway...

The full command I ran was:
pcc -D_XOPEN_SOURCE=700 -I./arch/i386 -I./arch/generic
-Iobj/src/internal -I./src/include -I./src/internal -Iobj/include
-I./include -DBROKEN_EBX_ASM -E src/complex/catan.c

And that's what pcc spit out (with a similar expansion of cimag() in
line 92). I don't understand pcc's inner workings enough to say why.

> > Rich is right, changing line 105 to:
> > w = w+0.25*log(a)*I
> >
> > solves the problem, but then we get the bad register name `%%ax' error
> > when trying to assemble catan.o.
> Are you sure? There's no asm in catan.c. If %%ax appears in what gets
> passed to the assembled for this file, it's emitted by PCC itself.
> > Running make -j also reveals that this assembly error pops up in more
> > places, at least also catanl.o, catanf.o, and csqrt.o.
> In that case it sounds like it very well might be a bug in PCC's
> codegen rather than anything in our inline asm (elsewhere) which I
> originally suspected it was.

I'm beginning to think the assembly problems might have to do with my
particular setup rather than be a bug in the source. This morning I
forgot to put an i386 GNU toolchain in my path before running make,
and was getting assembler errors about push and pop, which went away
once I added the i386 GNU toolchain to PATH.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.