|
Message-ID: <CACq8dh0YvtV+kuyt4efpM_VjYufhDLbJLqVYvub2CQTZi8kytw@mail.gmail.com> Date: Wed, 13 May 2020 12:53:55 -0500 From: John Arnold <iohannes.eduardus.arnold@...il.com> To: Rich Felker <dalias@...ifal.cx> 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: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. > > 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.