* [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
* 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
* 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
* [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 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
* [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
end of thread, other threads:[~2020-05-15 0:22 UTC | newest] 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
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).