mailing list of musl libc
 help / color / Atom feed
* [musl] PCC unable to build musl 1.2.0 (and likely earlier)
@ 2020-05-12 20:59 John Arnold
  2020-05-12 21:21 ` Rich Felker
  0 siblings, 1 reply; 16+ messages in thread
From: John Arnold @ 2020-05-12 20:59 UTC (permalink / raw)
  To: musl

With an i386 PCC 1.2.0.DEVEL built from source from
http://pcc.ludd.ltu.se/ftp/pub/pcc/pcc-20200510.tgz, I was unable to
build an i386 musl 1.2.0. The compiler first hits this error:

./include/limits.h:10: error: bad charcon

This line was the only change made in commit cdbbcfb8f5d, but it has a
lengthy commit message about the proper way of determining CHAR_MIN
and CHAR_MAX.

Reverting that change fixes the issue with limits.h, but PCC then runs
into another problem:

src/complex/catan.c, line 105: operands of = have incompatible types
src/complex/catan.c, line 105: cannot recover from earlier errors: goodbye!

catan.c only has one change that could possibly be relevant:
10e4bd3780050e75b72, which fixed a hack labeled FIXME.

Undoing this change results in hitting yet more errors:
/tmp/ctm.AkDmnc: Assembler messages:
/tmp/ctm.AkDmnc:50: Error: bad register name `%%ax'

Which are beyond my ability to debug on my own. Happy to help with the
hunt though. I'm not on the musl mailing list, but please CC me on the
replies to this.
-- John

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [musl] PCC unable to build musl 1.2.0 (and likely earlier)
  2020-05-12 20:59 [musl] PCC unable to build musl 1.2.0 (and likely earlier) John Arnold
@ 2020-05-12 21:21 ` Rich Felker
  2020-05-13  7:10   ` [musl] Re: [Pcc] " Anders Magnusson
  0 siblings, 1 reply; 16+ messages in thread
From: Rich Felker @ 2020-05-12 21:21 UTC (permalink / raw)
  To: John Arnold; +Cc: musl, pcc

Thanks. Adding pcc list to cc.

On Tue, May 12, 2020 at 03:59:36PM -0500, John Arnold wrote:
> With an i386 PCC 1.2.0.DEVEL built from source from
> http://pcc.ludd.ltu.se/ftp/pub/pcc/pcc-20200510.tgz, I was unable to
> build an i386 musl 1.2.0. The compiler first hits this error:
> 
> ../include/limits.h:10: error: bad charcon
> 
> This line was the only change made in commit cdbbcfb8f5d, but it has a
> lengthy commit message about the proper way of determining CHAR_MIN
> and CHAR_MAX.

I think this is clearly a PCC bug, one they can hopefully fix. The
commit message cites the example from 6.4.4.4:

     EXAMPLE 2 Consider implementations that use two's complement
     representation for integers and eight bits for objects that have
     type char. In an implementation in which type char has the same
     range of values as signed char, the integer character constant
     '\xFF' has the value -1; if type char has the same range of
     values as unsigned char, the character constant '\xFF' has the
     value +255. 

> Reverting that change fixes the issue with limits.h, but PCC then runs
> into another problem:
> 
> src/complex/catan.c, line 105: operands of = have incompatible types
> src/complex/catan.c, line 105: cannot recover from earlier errors: goodbye!

Are there any warnings before this? Perhaps pcc is not aware of
__builtin_complex and treating it as an implicit declaration of a
function returning int? But then int should still convert to complex
double just fine, so I think the problem is just a weird bug in PCC
with complex types.

> catan.c only has one change that could possibly be relevant:
> 10e4bd3780050e75b72, which fixed a hack labeled FIXME.

The FIXME was just a completely wrong code path and unrelated to the
code that appears right after it in the diff using the CMPLX macro. I
think it would be possible to use w+0.25*log(a)*I here instead of
CMPLX, but it may (I'm not sure about this) generates significantly
worse code because the compiler can't know log(a) isn't NAN or INF.

> Undoing this change results in hitting yet more errors:
> /tmp/ctm.AkDmnc: Assembler messages:
> /tmp/ctm.AkDmnc:50: Error: bad register name `%%ax'

Which file is this in? I think it's inline asm expanded from
somewhere, maybe the new x86 math functions, and it might be something
we're doing not quite right or a PCC bug. We could suppress the asm
with pcc (or with a configure test for the bug) if it's not something
they can fix.

> Which are beyond my ability to debug on my own. Happy to help with the
> hunt though. I'm not on the musl mailing list, but please CC me on the
> replies to this.

Thanks again. Others replying, please keep the John (the OP) Cc'd.

Rich

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier)
  2020-05-12 21:21 ` Rich Felker
@ 2020-05-13  7:10   ` Anders Magnusson
  2020-05-13 14:30     ` Rich Felker
  2020-05-13 17:00     ` John Arnold
  0 siblings, 2 replies; 16+ messages in thread
From: Anders Magnusson @ 2020-05-13  7:10 UTC (permalink / raw)
  To: Rich Felker, John Arnold; +Cc: musl, pcc

Den 2020-05-12 kl. 23:21, skrev Rich Felker:
> Thanks. Adding pcc list to cc.
>
> On Tue, May 12, 2020 at 03:59:36PM -0500, John Arnold wrote:
>> With an i386 PCC 1.2.0.DEVEL built from source from
>> http://pcc.ludd.ltu.se/ftp/pub/pcc/pcc-20200510.tgz, I was unable to
>> build an i386 musl 1.2.0. The compiler first hits this error:
>>
>> ../include/limits.h:10: error: bad charcon
>>
>> This line was the only change made in commit cdbbcfb8f5d, but it has a
>> lengthy commit message about the proper way of determining CHAR_MIN
>> and CHAR_MAX.
> I think this is clearly a PCC bug, one they can hopefully fix. The
> commit message cites the example from 6.4.4.4:
Can you please sen med the offending line?

>> Reverting that change fixes the issue with limits.h, but PCC then runs
>> into another problem:
>>
>> src/complex/catan.c, line 105: operands of = have incompatible types
>> src/complex/catan.c, line 105: cannot recover from earlier errors: goodbye!
> Are there any warnings before this? Perhaps pcc is not aware of
> __builtin_complex and treating it as an implicit declaration of a
> function returning int? But then int should still convert to complex
> double just fine, so I think the problem is just a weird bug in PCC
> with complex types.
Same here, can you send me the line that causes the bug?
And true, __builtin_complex is not recognized in pcc.

>> Undoing this change results in hitting yet more errors:
>> /tmp/ctm.AkDmnc: Assembler messages:
>> /tmp/ctm.AkDmnc:50: Error: bad register name `%%ax'
> Which file is this in? I think it's inline asm expanded from
> somewhere, maybe the new x86 math functions, and it might be something
> we're doing not quite right or a PCC bug. We could suppress the asm
> with pcc (or with a configure test for the bug) if it's not something
> they can fix.
Pcc recognizes gcc extended assembler, but it is more strict than gcc so 
it sometimes
reveals bugs that gcc don't catch.

...and same here, please send me what fails so that I can fix the bugs :-)

-- R

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier)
  2020-05-13  7:10   ` [musl] Re: [Pcc] " Anders Magnusson
@ 2020-05-13 14:30     ` Rich Felker
  2020-05-13 19:09       ` Anders Magnusson
  2020-05-13 17:00     ` John Arnold
  1 sibling, 1 reply; 16+ messages in thread
From: Rich Felker @ 2020-05-13 14:30 UTC (permalink / raw)
  To: Anders Magnusson; +Cc: John Arnold, musl, pcc

On Wed, May 13, 2020 at 09:10:40AM +0200, Anders Magnusson wrote:
> Den 2020-05-12 kl. 23:21, skrev Rich Felker:
> >Thanks. Adding pcc list to cc.
> >
> >On Tue, May 12, 2020 at 03:59:36PM -0500, John Arnold wrote:
> >>With an i386 PCC 1.2.0.DEVEL built from source from
> >>http://pcc.ludd.ltu.se/ftp/pub/pcc/pcc-20200510.tgz, I was unable to
> >>build an i386 musl 1.2.0. The compiler first hits this error:
> >>
> >>../include/limits.h:10: error: bad charcon
> >>
> >>This line was the only change made in commit cdbbcfb8f5d, but it has a
> >>lengthy commit message about the proper way of determining CHAR_MIN
> >>and CHAR_MAX.
> >I think this is clearly a PCC bug, one they can hopefully fix. The
> >commit message cites the example from 6.4.4.4:
> Can you please sen med the offending line?

#if '\xff' > 0

> >>Reverting that change fixes the issue with limits.h, but PCC then runs
> >>into another problem:
> >>
> >>src/complex/catan.c, line 105: operands of = have incompatible types
> >>src/complex/catan.c, line 105: cannot recover from earlier errors: goodbye!
> >Are there any warnings before this? Perhaps pcc is not aware of
> >__builtin_complex and treating it as an implicit declaration of a
> >function returning int? But then int should still convert to complex
> >double just fine, so I think the problem is just a weird bug in PCC
> >with complex types.
> Same here, can you send me the line that causes the bug?
> And true, __builtin_complex is not recognized in pcc.

w = CMPLX(w, 0.25 * log(a));

where:

#define __CMPLX(x, y, t) (__builtin_complex((t)(x), (t)(y)))
#define CMPLX(x, y) __CMPLX(x, y, double)

Is there another way PCC can provide a mechanism to implement CMPLX?
Or can __builtin_complex be added?

> >>Undoing this change results in hitting yet more errors:
> >>/tmp/ctm.AkDmnc: Assembler messages:
> >>/tmp/ctm.AkDmnc:50: Error: bad register name `%%ax'
> >Which file is this in? I think it's inline asm expanded from
> >somewhere, maybe the new x86 math functions, and it might be something
> >we're doing not quite right or a PCC bug. We could suppress the asm
> >with pcc (or with a configure test for the bug) if it's not something
> >they can fix.
> Pcc recognizes gcc extended assembler, but it is more strict than
> gcc so it sometimes
> reveals bugs that gcc don't catch.
> 
> ....and same here, please send me what fails so that I can fix the bugs :-)

OK, still waiting on report of what this is.

Thanks!

Rich

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier)
  2020-05-13  7:10   ` [musl] Re: [Pcc] " Anders Magnusson
  2020-05-13 14:30     ` Rich Felker
@ 2020-05-13 17:00     ` John Arnold
  2020-05-13 17:27       ` Rich Felker
  2020-05-13 19:36       ` Anders Magnusson
  1 sibling, 2 replies; 16+ messages in thread
From: John Arnold @ 2020-05-13 17:00 UTC (permalink / raw)
  To: Anders Magnusson; +Cc: Rich Felker, musl, pcc

> 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);

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.
Running make -j also reveals that this assembly error pops up in more
places, at least also catanl.o, catanf.o, and csqrt.o.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier)
  2020-05-13 17:00     ` John Arnold
@ 2020-05-13 17:27       ` Rich Felker
  2020-05-13 17:53         ` John Arnold
  2020-05-13 19:36       ` Anders Magnusson
  1 sibling, 1 reply; 16+ messages in thread
From: Rich Felker @ 2020-05-13 17:27 UTC (permalink / raw)
  To: John Arnold; +Cc: Anders Magnusson, musl, pcc

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...

> 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.

Rich

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier)
  2020-05-13 17:27       ` Rich Felker
@ 2020-05-13 17:53         ` John Arnold
  2020-05-13 18:04           ` Rich Felker
  0 siblings, 1 reply; 16+ messages in thread
From: John Arnold @ 2020-05-13 17:53 UTC (permalink / raw)
  To: Rich Felker; +Cc: Anders Magnusson, musl, pcc

On Wed, May 13, 2020 at 12:27 PM Rich Felker <dalias@aerifal.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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier)
  2020-05-13 17:53         ` John Arnold
@ 2020-05-13 18:04           ` Rich Felker
  2020-05-13 18:49             ` John Arnold
  2020-05-15  0:24             ` John Arnold
  0 siblings, 2 replies; 16+ messages in thread
From: Rich Felker @ 2020-05-13 18:04 UTC (permalink / raw)
  To: John Arnold; +Cc: Anders Magnusson, musl, pcc

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@aerifal.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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier)
  2020-05-13 18:04           ` Rich Felker
@ 2020-05-13 18:49             ` John Arnold
  2020-05-13 18:50               ` Rich Felker
  2020-05-15  0:24             ` John Arnold
  1 sibling, 1 reply; 16+ messages in thread
From: John Arnold @ 2020-05-13 18:49 UTC (permalink / raw)
  To: Rich Felker; +Cc: Anders Magnusson, musl, pcc

On Wed, May 13, 2020 at 1:04 PM Rich Felker <dalias@aerifal.cx> wrote:
> 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.

I did some poking around with pcc -S and it looked like %%ax was only
appearing in the context of the fnstsw instruction, which in pcc's
source only occurs once, in line 329 of arch/i386/local2.c:

expand(p, 0, "\tfnstsw %%ax\n");

My assembly is *really* basic, so I don't know what that means, but
hopefully it's relevant?

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier)
  2020-05-13 18:49             ` John Arnold
@ 2020-05-13 18:50               ` Rich Felker
  0 siblings, 0 replies; 16+ messages in thread
From: Rich Felker @ 2020-05-13 18:50 UTC (permalink / raw)
  To: John Arnold; +Cc: Anders Magnusson, musl, pcc

On Wed, May 13, 2020 at 01:49:22PM -0500, John Arnold wrote:
> On Wed, May 13, 2020 at 1:04 PM Rich Felker <dalias@aerifal.cx> wrote:
> > 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.
> 
> I did some poking around with pcc -S and it looked like %%ax was only
> appearing in the context of the fnstsw instruction, which in pcc's
> source only occurs once, in line 329 of arch/i386/local2.c:
> 
> expand(p, 0, "\tfnstsw %%ax\n");
> 
> My assembly is *really* basic, so I don't know what that means, but
> hopefully it's relevant?

It just means someone inadvertently wrote %% thinking the expected
form was inline-asm text that would be %-expanded rather than whatever
form PCC uses at this point where all %'s are literal. Changing it to
a single % should fix it.

Rich

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier)
  2020-05-13 14:30     ` Rich Felker
@ 2020-05-13 19:09       ` Anders Magnusson
  2020-05-13 19:33         ` Rich Felker
  0 siblings, 1 reply; 16+ messages in thread
From: Anders Magnusson @ 2020-05-13 19:09 UTC (permalink / raw)
  To: Rich Felker; +Cc: John Arnold, musl, pcc

Den 2020-05-13 kl. 16:30, skrev Rich Felker:
> On Wed, May 13, 2020 at 09:10:40AM +0200, Anders Magnusson wrote:
>> Den 2020-05-12 kl. 23:21, skrev Rich Felker:
>>> Thanks. Adding pcc list to cc.
>>>
>>> On Tue, May 12, 2020 at 03:59:36PM -0500, John Arnold wrote:
>>>> With an i386 PCC 1.2.0.DEVEL built from source from
>>>> http://pcc.ludd.ltu.se/ftp/pub/pcc/pcc-20200510.tgz, I was unable to
>>>> build an i386 musl 1.2.0. The compiler first hits this error:
>>>>
>>>> ../include/limits.h:10: error: bad charcon
>>>>
>>>> This line was the only change made in commit cdbbcfb8f5d, but it has a
>>>> lengthy commit message about the proper way of determining CHAR_MIN
>>>> and CHAR_MAX.
>>> I think this is clearly a PCC bug, one they can hopefully fix. The
>>> commit message cites the example from 6.4.4.4:
>> Can you please sen med the offending line?
> #if '\xff' > 0
>
Thanks, fixed now, it was a missing pushback of ' that was the problem.

Note that this check cannot be used to see whether a target uses signed 
or unsigned char.
In pcc the above is always true, no matter what char is.  See C11 clause 
6.10.1 clause 4.

-- Ragge


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier)
  2020-05-13 19:09       ` Anders Magnusson
@ 2020-05-13 19:33         ` Rich Felker
  2020-05-13 20:31           ` Anders Magnusson
  0 siblings, 1 reply; 16+ messages in thread
From: Rich Felker @ 2020-05-13 19:33 UTC (permalink / raw)
  To: Anders Magnusson; +Cc: John Arnold, musl, pcc

On Wed, May 13, 2020 at 09:09:13PM +0200, Anders Magnusson wrote:
> Den 2020-05-13 kl. 16:30, skrev Rich Felker:
> >On Wed, May 13, 2020 at 09:10:40AM +0200, Anders Magnusson wrote:
> >>Den 2020-05-12 kl. 23:21, skrev Rich Felker:
> >>>Thanks. Adding pcc list to cc.
> >>>
> >>>On Tue, May 12, 2020 at 03:59:36PM -0500, John Arnold wrote:
> >>>>With an i386 PCC 1.2.0.DEVEL built from source from
> >>>>http://pcc.ludd.ltu.se/ftp/pub/pcc/pcc-20200510.tgz, I was unable to
> >>>>build an i386 musl 1.2.0. The compiler first hits this error:
> >>>>
> >>>>../include/limits.h:10: error: bad charcon
> >>>>
> >>>>This line was the only change made in commit cdbbcfb8f5d, but it has a
> >>>>lengthy commit message about the proper way of determining CHAR_MIN
> >>>>and CHAR_MAX.
> >>>I think this is clearly a PCC bug, one they can hopefully fix. The
> >>>commit message cites the example from 6.4.4.4:
> >>Can you please sen med the offending line?
> >#if '\xff' > 0
> >
> Thanks, fixed now, it was a missing pushback of ' that was the problem.
> 
> Note that this check cannot be used to see whether a target uses
> signed or unsigned char.
> In pcc the above is always true, no matter what char is.  See C11
> clause 6.10.1 clause 4.

See the commit message for:

https://git.musl-libc.org/cgit/musl/commit/include/limits.h?id=cdbbcfb8f5d748f17694a5cc404af4b9381ff95f

There is good reason we changed this.

I believe you're referring to the text:

    "This includes interpreting character constants, which may involve
    converting escape sequences into execution character set members.
    Whether the numeric value for these character constants matches
    the value obtained when an identical character constant occurs in
    an expression (other than within a #if or #elif directive) is
    implementation-defined.168) Also, whether a single-character
    character constant may have a negative value is
    implementation-defined."

and the footnote is:

    "168) Thus, the constant expression in the following #if directive
    and if statement is not guaranteed to evaluate to the same value
    in these two contexts.

    #if 'z' - 'a' == 25
    if ('z' - 'a' == 25)"

The point here seems to be allowing compilers where the preprocessor
character set does not match, an awful possibility the standard didn't
want to rule out (mixed ASCII/EBCDIC environments, etc.). A compile
using the allowance given in the example in the footnote would
definitely not be one I'd want to try to support. While this isn't
really a _binary_ issue, I'd consider it non-conforming to the
platform ABI, which should uniquely determine how character constants
evaluate.

The signedness issue seems to be technically a different allowance,
and one that's not inherently awful like the EBCDIC one above. I'm
somewhat amenable to finding an alternate solution here that's
compatible with PCC, but I think it would be preferable just for PCC
to make the definition of the value consistent here just like GCC and
clang and other compilers do.


^ permalink raw reply	[flat|nested] 16+ messages in thread

* [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier)
  2020-05-13 17:00     ` John Arnold
  2020-05-13 17:27       ` Rich Felker
@ 2020-05-13 19:36       ` Anders Magnusson
  1 sibling, 0 replies; 16+ messages in thread
From: Anders Magnusson @ 2020-05-13 19:36 UTC (permalink / raw)
  To: John Arnold; +Cc: Rich Felker, musl, pcc

Den 2020-05-13 kl. 19:00, skrev John Arnold:
> 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.
>
The %%ax bug fixed.  It only appeared for float comparisons where a CPU 
less than i686 was given.
Some of the code was changed from using printf to internal routines and 
the extra % was left by mistake.

-- R

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier)
  2020-05-13 19:33         ` Rich Felker
@ 2020-05-13 20:31           ` Anders Magnusson
  2020-05-13 21:49             ` Rich Felker
  0 siblings, 1 reply; 16+ messages in thread
From: Anders Magnusson @ 2020-05-13 20:31 UTC (permalink / raw)
  To: Rich Felker; +Cc: John Arnold, musl, pcc



Den 2020-05-13 kl. 21:33, skrev Rich Felker:
> On Wed, May 13, 2020 at 09:09:13PM +0200, Anders Magnusson wrote:
>> Den 2020-05-13 kl. 16:30, skrev Rich Felker:
>>> On Wed, May 13, 2020 at 09:10:40AM +0200, Anders Magnusson wrote:
>>>> Den 2020-05-12 kl. 23:21, skrev Rich Felker:
>>>>> Thanks. Adding pcc list to cc.
>>>>>
>>>>> On Tue, May 12, 2020 at 03:59:36PM -0500, John Arnold wrote:
>>>>>> With an i386 PCC 1.2.0.DEVEL built from source from
>>>>>> http://pcc.ludd.ltu.se/ftp/pub/pcc/pcc-20200510.tgz, I was unable to
>>>>>> build an i386 musl 1.2.0. The compiler first hits this error:
>>>>>>
>>>>>> ../include/limits.h:10: error: bad charcon
>>>>>>
>>>>>> This line was the only change made in commit cdbbcfb8f5d, but it has a
>>>>>> lengthy commit message about the proper way of determining CHAR_MIN
>>>>>> and CHAR_MAX.
>>>>> I think this is clearly a PCC bug, one they can hopefully fix. The
>>>>> commit message cites the example from 6.4.4.4:
>>>> Can you please sen med the offending line?
>>> #if '\xff' > 0
>>>
>> Thanks, fixed now, it was a missing pushback of ' that was the problem.
>>
>> Note that this check cannot be used to see whether a target uses
>> signed or unsigned char.
>> In pcc the above is always true, no matter what char is.  See C11
>> clause 6.10.1 clause 4.
> See the commit message for:
>
> https://git.musl-libc.org/cgit/musl/commit/include/limits.h?id=cdbbcfb8f5d748f17694a5cc404af4b9381ff95f
>
> There is good reason we changed this.
>
> I believe you're referring to the text:
>
>      "This includes interpreting character constants, which may involve
>      converting escape sequences into execution character set members.
>      Whether the numeric value for these character constants matches
>      the value obtained when an identical character constant occurs in
>      an expression (other than within a #if or #elif directive) is
>      implementation-defined.168) Also, whether a single-character
>      character constant may have a negative value is
>      implementation-defined."
>
Actually, the ambiguous handling of negative values in #if is historical 
behaviour, and has nothing to do with EBCDIC.
It do not sound very good to rely on explicitly documented undefined 
behaviour IMHO, and this is actually the first time in the last 20 years 
that someone has complained about it :-)

It might be possible to change it (due to the "law of least surprise") 
but since cpp do not have any relation to the target architecture it 
needs some thinking. (cpp is the same even if multiple target backends 
are generated).

-- Ragge

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier)
  2020-05-13 20:31           ` Anders Magnusson
@ 2020-05-13 21:49             ` Rich Felker
  0 siblings, 0 replies; 16+ messages in thread
From: Rich Felker @ 2020-05-13 21:49 UTC (permalink / raw)
  To: Anders Magnusson; +Cc: John Arnold, musl, pcc

On Wed, May 13, 2020 at 10:31:31PM +0200, Anders Magnusson wrote:
> 
> 
> Den 2020-05-13 kl. 21:33, skrev Rich Felker:
> >On Wed, May 13, 2020 at 09:09:13PM +0200, Anders Magnusson wrote:
> >>Den 2020-05-13 kl. 16:30, skrev Rich Felker:
> >>>On Wed, May 13, 2020 at 09:10:40AM +0200, Anders Magnusson wrote:
> >>>>Den 2020-05-12 kl. 23:21, skrev Rich Felker:
> >>>>>Thanks. Adding pcc list to cc.
> >>>>>
> >>>>>On Tue, May 12, 2020 at 03:59:36PM -0500, John Arnold wrote:
> >>>>>>With an i386 PCC 1.2.0.DEVEL built from source from
> >>>>>>http://pcc.ludd.ltu.se/ftp/pub/pcc/pcc-20200510.tgz, I was unable to
> >>>>>>build an i386 musl 1.2.0. The compiler first hits this error:
> >>>>>>
> >>>>>>../include/limits.h:10: error: bad charcon
> >>>>>>
> >>>>>>This line was the only change made in commit cdbbcfb8f5d, but it has a
> >>>>>>lengthy commit message about the proper way of determining CHAR_MIN
> >>>>>>and CHAR_MAX.
> >>>>>I think this is clearly a PCC bug, one they can hopefully fix. The
> >>>>>commit message cites the example from 6.4.4.4:
> >>>>Can you please sen med the offending line?
> >>>#if '\xff' > 0
> >>>
> >>Thanks, fixed now, it was a missing pushback of ' that was the problem.
> >>
> >>Note that this check cannot be used to see whether a target uses
> >>signed or unsigned char.
> >>In pcc the above is always true, no matter what char is.  See C11
> >>clause 6.10.1 clause 4.
> >See the commit message for:
> >
> >https://git.musl-libc.org/cgit/musl/commit/include/limits.h?id=cdbbcfb8f5d748f17694a5cc404af4b9381ff95f
> >
> >There is good reason we changed this.
> >
> >I believe you're referring to the text:
> >
> >     "This includes interpreting character constants, which may involve
> >     converting escape sequences into execution character set members.
> >     Whether the numeric value for these character constants matches
> >     the value obtained when an identical character constant occurs in
> >     an expression (other than within a #if or #elif directive) is
> >     implementation-defined.168) Also, whether a single-character
> >     character constant may have a negative value is
> >     implementation-defined."
> >
> Actually, the ambiguous handling of negative values in #if is
> historical behaviour, and has nothing to do with EBCDIC.

I mean the 'z'-'a' differing between #if and if() is an EBCDIC
artifact. Indeed the sign thing is more likely motivated by differing
historical behaviors in a subtle corner case than by mixed charset
environments.

> It do not sound very good to rely on explicitly documented undefined
> behaviour IMHO,

It's not undefined. It's implementation-defined, and generally
implementation-defined means roughly psABI-defined, or in other words
"should match for all interoperable implementations". One way of
thinking about this as an "ABI" issue is that 2 object files compiled
by different compilers, with foo.h containing:

#if 'z'-a'==25
#define func func1
#else
#define func func2
#endif

and one defining func and the other calling func, should successfully
link if the compilers are interoperable.

> and this is actually the first time in the last 20
> years that someone has complained about it :-)

:-)

> It might be possible to change it (due to the "law of least
> surprise") but since cpp do not have any relation to the target
> architecture it needs some thinking. (cpp is the same even if
> multiple target backends are generated).

I'm pretty sure this is subtly wrong then because the signedness of
wchar_t varies by target, and while the *values* may be allowed to
vary, whether L'\0' has preprocessor type uintmax_t or intmax_t has to
match whether wchar_t is unsigned or signed.

Rich

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [musl] Re: [Pcc] [musl] PCC unable to build musl 1.2.0 (and likely earlier)
  2020-05-13 18:04           ` Rich Felker
  2020-05-13 18:49             ` John Arnold
@ 2020-05-15  0:24             ` John Arnold
  1 sibling, 0 replies; 16+ messages in thread
From: John Arnold @ 2020-05-15  0:24 UTC (permalink / raw)
  To: Rich Felker; +Cc: Anders Magnusson, musl, pcc

On Wed, May 13, 2020 at 1:04 PM Rich Felker <dalias@aerifal.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@aerifal.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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, back to index

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-12 20:59 [musl] PCC unable to build musl 1.2.0 (and likely earlier) John Arnold
2020-05-12 21:21 ` Rich Felker
2020-05-13  7:10   ` [musl] Re: [Pcc] " Anders Magnusson
2020-05-13 14:30     ` Rich Felker
2020-05-13 19:09       ` Anders Magnusson
2020-05-13 19:33         ` Rich Felker
2020-05-13 20:31           ` Anders Magnusson
2020-05-13 21:49             ` Rich Felker
2020-05-13 17:00     ` John Arnold
2020-05-13 17:27       ` Rich Felker
2020-05-13 17:53         ` John Arnold
2020-05-13 18:04           ` Rich Felker
2020-05-13 18:49             ` John Arnold
2020-05-13 18:50               ` Rich Felker
2020-05-15  0:24             ` John Arnold
2020-05-13 19:36       ` Anders Magnusson

mailing list of musl libc

Archives are clonable: git clone --mirror http://inbox.vuxu.org/musl

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git