[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 12 May 2020 17:21:28 -0400
From: Rich Felker <dalias@...c.org>
To: John Arnold <iohannes.eduardus.arnold@...il.com>
Cc: musl@...ts.openwall.com, pcc@...ts.ludd.ltu.se
Subject: Re: PCC unable to build musl 1.2.0 (and likely earlier)
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
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.
