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 2808 invoked from network); 12 May 2020 21:21:42 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 12 May 2020 21:21:42 -0000 Received: (qmail 18057 invoked by uid 550); 12 May 2020 21:21:40 -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 18038 invoked from network); 12 May 2020 21:21:40 -0000 Date: Tue, 12 May 2020 17:21:28 -0400 From: Rich Felker To: John Arnold Cc: musl@lists.openwall.com, pcc@lists.ludd.ltu.se Message-ID: <20200512212127.GQ21576@brightrain.aerifal.cx> References: 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] 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