[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200513180451.GX21576@brightrain.aerifal.cx>
Date: Wed, 13 May 2020 14:04:52 -0400
From: Rich Felker <dalias@...ifal.cx>
To: John Arnold <iohannes.eduardus.arnold@...il.com>
Cc: Anders Magnusson <ragge@...d.ltu.se>, musl@...ts.openwall.com,
pcc@...ts.ludd.ltu.se
Subject: Re: Re: [Pcc] PCC unable to build musl 1.2.0 (and
likely earlier)
On Wed, May 13, 2020 at 12:53:55PM -0500, John Arnold wrote:
> On Wed, May 13, 2020 at 12:27 PM Rich Felker <dalias@...ifal.cx> 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.
Ohh, different definitions from src/internal/complex_impl.h are still
used internally because the public complex.h definitions are dependent
on a compiler with extensions to do C11-conforming macros.
So it looks like this is probably just a bug in something to do with
PCC's compound literal handling.
> > > 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.
That doesn't sound related. %%ax appearing in the input to the
assembler would always indicate a bug in either the compiler or the
inline asm text in the program being compiled.
Rich
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.
