From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2031 invoked from network); 13 May 2020 18:05:08 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 May 2020 18:05:08 -0000 Received: (qmail 22517 invoked by uid 550); 13 May 2020 18:05:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 22498 invoked from network); 13 May 2020 18:05:04 -0000 Date: Wed, 13 May 2020 14:04:52 -0400 From: Rich Felker To: John Arnold Cc: Anders Magnusson , musl@lists.openwall.com, pcc@lists.ludd.ltu.se Message-ID: <20200513180451.GX21576@brightrain.aerifal.cx> References: <20200512212127.GQ21576@brightrain.aerifal.cx> <5ae8c7fa-aed9-d957-fe53-68eb2fa622a6@ludd.ltu.se> <20200513172718.GW21576@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: [Pcc] [musl] 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 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