[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gcc ICE

On Fri, Nov 04, 2011 at 11:20:57PM +0000, Jurij Smakov wrote:
> On Fri, Nov 04, 2011 at 10:49:03PM +0100, Mathieu Malaterre wrote:
> > On Fri, Nov 4, 2011 at 9:49 PM, Julien Cristau <jcristau@debian.org> wrote:
> > > On Fri, Nov  4, 2011 at 10:05:49 +0100, Mathieu Malaterre wrote:
> > >
> > >> Hi all,
> > >>
> > >>   I am reporting an ICE for one of my project. Because I am not a DD,
> > >> I cannot fill a proper bug report upstream (gcc).
> > >>
> > > This makes no sense, what does being a DD have to do with upstream
> > > gcc...
> > 
> > Ok. I'll rephrase it into, i need someone with proper write level
> > access to buidd machine to execute the command described at:
> > 
> > http://lists.debian.org/debian-sparc/2011/11/msg00008.html
> A few relevant facts:
> 1. The internal compiler error you are encountering is only affecting 
> the experimental sparc64 port. The same package version built fine on 
> "regular" sparc:
> https://buildd.debian.org/status/package.php?p=vxl&suite=sid

As said in another mail it doesn't really affect sparc64, it's just a
build daemon issue, which is the source of most of the current ICE
appearing when building packages.

> 2. The buildd machine you refer to is not a part of official buildd 
> network, as it has been set up specifically to build packages for 
> sparc64 port. Thus, it's unlikely that regular buildd admins would be 
> able to do anything about it.

The contact point for architectures hosted on debian-ports.org can be
found on http://www.debian-ports.org/contacts , so for sparc64 it is

> 3. As far as I know, there is no DD-accessible sparc64 porterbox, so 
> even DDs would not be able to help.

Confirmed. That said if someone can provide a machine (including the
hosting), its probably something that can be setup.

> To be honest, I have no idea on how to handle bugs like this. To the 
> best of my knowledge, a decision regarding inclusion of sparc64 in 
> wheezy has not been made, and it has a long way to go to get to a 
> point of achieving feature parity with the existing sparc port. I 
> believe that Aurelien Jarno (CC'd) is the only person currently 
> working on it, so perhaps he can shed some light on how to approach 
> it. 
> For the record, I'm not in any way opposed to the sparc64 port
> effort, but I don't think it's realistic to get it into acceptable 
> shape before wheezy release, so I tend to spend most of my available 
> time fixing the "regular" sparc port problems.

I fully agree that the sparc64 port won't be ready in time to get into
wheezy release, at least not with a lot more manpower. The s390x port
(also 64-bit and big endian) helps to get some packages fixed, but the
sparc64 port also forbids 64-bit unaligned access, which requires fixes
in numerous packages (32-bit unaligned access issues are almost all 
already fixed in ther archive). In addition to that the toolchain is not
yet to the level of the sparc32 port.

Right now my goal with the sparc64 port is to maintain it to a level
where a big part of the packages are buildable and built, so that we
don't loose the efforts of the initial bootstrap and so that we can
restart the porting efforts at some point.

Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Reply to: