Re: Native gcc on netbsd-7

[Björn Johannesson <rherdware%yahoo.com@localhost>]

Hi!

--------------------------------------------
On Mon, 1/5/15, Martin Husemann <martin%duskware.de@localhost> wrote:

Subject: Re: Native gcc on netbsd-7
To: "Bj}rn Johannesson" <rherdware%yahoo.com@localhost>
Cc: port-vax%netbsd.org@localhost
Date: Monday, January 5, 2015, 11:09 PM

On Mon, Jan 05, 2015 at
10:08:22AM -0800, Bj}rn Johannesson wrote:
>> I know Mattias saw the same(?) crash on his /90A. (Also netbsd-7)
>> This is with netbsd-7 snapshots from nyftp.
>> This did not happen with the old userland that was on it when Mattias sent it to me (5.x).
>> I don't even know where to begin debugging this.
>> Hopefully someone with a vax faster than my vlc could take a look.

> I see this a lot, gcc is miscompiled (I think it happens in dse.c) and
> a bitfield operation with index out of bounds happens, which causes the SIGILL.
Is there a difference when building dse.c with -O0?

> This is one of the reasons default optimization flags are -O1 currently, when
> building gcc with -O2 it dies a lot more due to this issue.
Or perhaps the entire compiler?
But I'm guessing the code generation is buggy with any or no optimization.

> I can reliably trigger it by trying to build tcsh from pkgsrc.
Right now I can't even get to the start of building packages.
Btw, is it known if gcc >4.9 exhibits the same behaviour?
Right now it's either HAVE_GCC=45 or investigate pcc.

Those that follow port-sh3 saw that I was chasing an ICE with that
yesterday. The post includes a test case. (Should this have gone to tech-toolchain too?)
http://mail-index.netbsd.org/port-sh3/2015/01/05/msg000123.html
Not the same fault of course.
ISTR gcc on super-h has never been reliable with -O2 or higher. -O1 and
-Os was fine though.

/B