Port-vax archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Native builds?
To find the version, look in gcc/gcc/BASE_VER, that's a one line text file containing the version number.
The NetBSD cvs browser shows V6.4.0, imported into NetBSD 6 months ago. That's the current V6.x release but it is over a year old at this point, and it's probably worth upgrading to something more recent.
The sources at gcc.gnu.org show the bugfix in trunk and V8.2 but not in V7 or V6.
Much stranger is that the NetBSD copy of gcc shows V6.4.0, but the vax/builtin.md does not match at all. The real one does have ffssi_internal in it (without the fix); the one in NetBSD is dated four months ago but looks very different. I wonder if it was brought over from a much older GCC somehow.
It would be worth comparing builtins.md of 6.4.0 with the current one; it may well be there is nothing changed other than the bugfix. If so, dropping the fixed builtins.md into the NetBSD copy may be all yo uneed.
paul
> On Aug 29, 2018, at 10:16 AM, Johnny Billquist <bqt%softjar.se@localhost> wrote:
>
> Ah, sorry for my confusion about port maintaner. I don't remember seeing anything from Matt in a while. Not sure if he is still doing work on this.
>
> And looking at gcc in the NetBSD tree, that fix is not in there. In fact, there is not even a ffssi2_internal. Only an ffssi2... So I'm wondering how much behind we actually might be... :-/
> But thanks for finding that one. I guess the answer is that we should update gcc for vax, but how that is tracked, and done, I have no idea.
>
> Johnny
>
>
> On 2018-08-29 16:09, Paul Koning wrote:
>> I said "port maintainer", that was a wording mixup. I meant gcc target maintainer. The GCC source tree shows Matt Thomas as the (only) gcc vax target maintainer. I'm not sure how active he is at the moment. Others can submit fixes too, they just need approval from either the target maintainer or a global maintainer.
>> Which gcc version is the one doing the building? The current (in development) gcc is 9.0; latest released is 8.2. If NetBSD is running something older it might not have some target fixes.
>> Checking the logs... there is a bugfix in the operation that generates an "ffs" instruction, correcting the constraints. That rings a bell. It's dated 2017-06-29. I'm not sure how to tell whether that is in the 8.x release. You could check the sources in the NetBSD tree; the fixed code looks like this, in gcc/config/vax/builtins.md:
>> (define_insn "ffssi2_internal"
>> [(set (match_operand:SI 0 "nonimmediate_operand" "=rQ")
>> (ffs:SI (match_operand:SI 1 "general_operand" "nrQt")))
>> (set (cc0) (match_dup 0))]
>> ""
>> "ffs $0,$32,%1,%0")
>> The magic is the "nrQt" in the third line, which specifies what operand forms the machine will accept in that instruction (as the third argument of the ffs opcode in this case).
>> paul
>>> On Aug 29, 2018, at 9:51 AM, Johnny Billquist <bqt%softjar.se@localhost> wrote:
>>>
>>> The port mainainer is Ragge, and he is active enough, so there is no problem at that end. But gcc is a separate target. (And I tried getting commit rights to NetBSD years ago, but that went nowhere, and I lost interest. Still occasionally fixing things on the vax port, but normally passing those things on to Ragge for submitting whenever I have something.)
>>>
>>> I agree that this don't really have anything to do with cross-compilation or not. I just pointed as much out as I could think of so people wouldn't have to ask those questions. :-)
>>>
>>> I've peeked at gcc internals in the past, but got pretty tired of trying to understand that thing. INSV rings a bell, but I thought that had been fixed.
>>>
>>> Apart from that I can report that doing a cvs update to NetBSD-8.0 on an 8650 with RA73 disks took about three days. :-) It was slightly busy with some more things, but not too much.
>>>
>>> Johnny
>>>
>>>
>>> On 2018-08-29 15:27, Paul Koning wrote:
>>>> The VAX port has had some problems in its instruction generation at times. I remember some discussion about one, including possible fixes I think -- something to do with INSV instructions? I would assume the bug you ran into is simply one of those, a wrong code generation error that would show up in any run, native or cross. There's nothing about native vs. cross that affects how code generation works.
>>>> Some internal compiler errors are tricky, but illegal instruction ones tend to be not all that hard.
>>>> Are there active VAX port maintainers? While GCC is a large program with complex internals, the target part is fairly small and pretty well documented. Taking up maintenance of a simple port like VAX is quite doable.
>>>> Given that I don't think this has to do with native vs. cross, I would say that one should care. I have enough of a spare time sink being pdp11 target maintainer so I'm not going to volunteer for this one. For those who understand VAX well, I'd suggest picking up the GCC Internals manual and reading chapters 17 and 18, that's the basics of what you need to know to tackle this.
>>>> paul
>>>>> On Aug 29, 2018, at 8:17 AM, Johnny Billquist <bqt%softjar.se@localhost> wrote:
>>>>>
>>>>> Have anyone tried building natively lately?
>>>>>
>>>>> I just tried on an 8650 with 8.0 Stable. The results were depressing.
>>>>>
>>>>> ===> build.sh command: ./build.sh build
>>>>> ===> build.sh started: Wed Aug 29 14:00:03 CEST 2018
>>>>> ===> NetBSD version: 8.0_STABLE
>>>>> ===> MACHINE: vax
>>>>> ===> MACHINE_ARCH: vax
>>>>> ===> Build platform: NetBSD 8.0_STABLE vax
>>>>> ===> HOST_SH: /bin/sh
>>>>> ===> No $TOOLDIR/bin/nbmake, needs building.
>>>>> ===> Bootstrapping nbmake
>>>>> checking for sh... /bin/sh
>>>>> checking for gcc... cc
>>>>> checking for C compiler default output... a.out
>>>>> checking whether the C compiler works... yes
>>>>> checking whether we are cross compiling... no
>>>>> checking for executable suffix...
>>>>> checking for object suffix... o
>>>>> checking whether we are using the GNU C compiler... yes
>>>>> checking whether cc accepts -g... yes
>>>>> checking how to run the C preprocessor... cc -E
>>>>> checking for regex.h... yes
>>>>> checking for poll.h... yes
>>>>> checking for regfree in -lregex... no
>>>>> checking for library containing regfree... none required
>>>>> checking for setenv... yes
>>>>> checking for strdup... yes
>>>>> checking for strerror... yes
>>>>> checking for strftime... yes
>>>>> checking for vsnprintf... yes
>>>>> configure: creating ./config.status
>>>>> config.status: creating buildmake.sh
>>>>> cc -D_PATH_DEFSYSPATH="/usr/src/share/mk" -DDEFSHELL_CUSTOM="/bin/sh" -DHAVE_SETENV=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRFTIME=1 -DHAVE_VSNPRINTF=1 -O -c /usr/src/usr.bin/make/arch.c
>>>>> /usr/src/usr.bin/make/arch.c: In function 'ArchStatMember':
>>>>> /usr/src/usr.bin/make/arch.c:720:1: internal compiler error: Illegal instruction
>>>>> }
>>>>> ^
>>>>> no stack trace because unwind library not available
>>>>> Please submit a full bug report,
>>>>> with preprocessed source if appropriate.
>>>>> See <http://www.NetBSD.org/support/send-pr.html> for instructions.
>>>>>
>>>>> ERROR: Build of nbmake failed
>>>>> *** BUILD ABORTED ***
>>>>>
>>>>>
>>>>> The system I'm running was cross compiler from an amd64 system.
>>>>>
>>>>>
>>>>> Du we care? Anyone feel comfortable at looking at gcc internals? I generally don't.
>>>>>
>>>>> Johnny
>>>>>
>>>>> --
>>>>> Johnny Billquist || "I'm on a bus
>>>>> || on a psychedelic trip
>>>>> email: bqt%softjar.se@localhost || Reading murder books
>>>>> pdp is alive! || tryin' to stay hip" - B. Idol
>>>
>>> --
>>> Johnny Billquist || "I'm on a bus
>>> || on a psychedelic trip
>>> email: bqt%softjar.se@localhost || Reading murder books
>>> pdp is alive! || tryin' to stay hip" - B. Idol
>
> --
> Johnny Billquist || "I'm on a bus
> || on a psychedelic trip
> email: bqt%softjar.se@localhost || Reading murder books
> pdp is alive! || tryin' to stay hip" - B. Idol
Home |
Main Index |
Thread Index |
Old Index