hi folks,
i was interesting in tackling some problems gcc netbsd/vax has.
it has some ICEs which are in reload phase. searching around, the answer
to that is "switch to LRA first". Now, I don't quite know what that is
yet, but I know I need to try to do it.
As an initial step, I need to sync the
On Sun, Mar 31, 2019 at 01:25:50PM -0400, Paul Koning wrote:
>
>
> > On Mar 30, 2019, at 5:03 AM, co...@sdf.org wrote:
> >
> > hi folks,
> >
> > i was interesting in tackling some problems gcc netbsd/vax has.
> > it has some ICEs which are in reload phase. searching around, the answer
> > to th
Just chiming in.
My buddy wrote a traditional C pre-processor for use with Imake (and,
presumably, other old things).
https://www.netbsd.org/~dholland/tradcpp/
(It's standalone).
Sorry for the delay...
Updated diff: http://coypu.sdf.org/vax-gcc10.diff
On Mon, Apr 29, 2019 at 02:08:32PM -0600, Jeff Law wrote:
> On 3/30/19 3:03 AM, co...@sdf.org wrote:
> > hi folks,
> >
> > i was interesting in tackling some problems gcc netbsd/vax has.
> > it has some ICEs which are in rel
On Fri, Sep 20, 2019 at 11:15:32AM +, co...@sdf.org wrote:
> Removed from the diff. Unfortunately this introduces an ICE during the
> build of GCC...
I took another look at the VAX atomic pattern issue.
(http://gnats.netbsd.org/53039)
It is a compiler crash to do with the added atomic builtins
On Fri, Sep 20, 2019 at 03:45:46PM -0600, Jeff Law wrote:
> Conditional branching patterns must support the label_ref and pc
> operands in either position. Everything else I've seen on this thread
> is just working around that broken aspect of the builtins.md file.
>
>
> (define_insn "jbbssiqi"
On Fri, Sep 20, 2019 at 10:07:59PM +, co...@sdf.org wrote:
> Introducing the reversed jbb* patterns doesn't seem to help with the
> original issue. It crashes building libatomic.
My loose understanding of what is going on:
- GCC emits this atomic in expand.
- When cleaning up, it looks for opt
Hi, GCC!
I believe netbsd is the primary user of the vax target. its status is:
good: netbsd uses gcc 5.4.0, and cross compiles its userland+kernel with
this. it runs and is also able to natively build useful programs like perl.
bad: -O0 in places, text relocations. obvious signs of more bugs no
Hi folks,
netbsd's copy of GCC differs enough that it fails elsewhere with
gcc-trunk, but the problematic code is upstream.
updating netbsd to gcc 6.4.0, I get an internal compiler error building
libstdc++. (Long version: http://gnats.netbsd.org/53039)
Short version:
test.cc: In function 'bool
(updating)
krister found a better hack patch which explains what the problem is,
adding a useless move at the end of the instruction, so the label is
not the last instruction.
(And, in the problem code, the last instruction in the function.)
--- a/external/gpl3/gcc/dist/gcc/config/vax/builtins.md
It turns out (all from krister, I am still totally lost) that it is not
failing for this specific reason in this case.
Rather, the attached patch from krister fixes it, saying that gcc
wants to change the label and then doesn't recognise the new insn
thinking the memory_operand predicate is not sa
11 matches
Mail list logo
