Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 14 May 2020 19:24:53 -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 1:04 PM Rich Felker <dalias@...ifal.cx> wrote:
>
> 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.

Just want to confirm that as of pcc 1.2.0.DEVEL 20200514, for i386 I
can build musl 1.1.19. Musl versions 1.1.20 to 1.2.0 still have this
issue with the CMPLX macro.

Powered by blists - more mailing lists

Your e-mail address:

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