[parisc-linux] Weird compile problems

[parisc-linux] Weird compile problems

[Paul J.Y. Lahaie]

[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]

Hello everyone,

I'm in the process of trying to get a working apt (still) and I'm getting
the following with the latest kernel (updated this morning) and the
toolchain from nfsroot-20010118.  The system is a C360 with 256MB of RAM.

Compiling deb/debindexfile.cc to /home/pjlahaie/src/apt/build/obj/apt-pkg/debindexfile.opic
deb/debindexfile.cc: In member function `string debSourcesIndex::SourceInfo 
   (const pkgSrcRecords::Parser &, const pkgSrcRecords::File &) const':
deb/debindexfile.cc:62: Basic block 57 pred edge is corrupted
Predecessor:  14
Successor:  1075043236
deb/debindexfile.cc:62: Basic block 57 edge lists are corrupted
deb/debindexfile.cc:62: Basic block 55 edge lists are corrupted
deb/debindexfile.cc:62: Basic block 53 edge lists are corrupted
deb/debindexfile.cc:62: Basic block 47 edge lists are corrupted
deb/debindexfile.cc:62: Basic block 44 edge lists are corrupted
deb/debindexfile.cc:62: Basic block 41 edge lists are corrupted
deb/debindexfile.cc:62: Basic block 39 edge lists are corrupted
deb/debindexfile.cc:62: Basic block 31 edge lists are corrupted
deb/debindexfile.cc:62: Basic block 28 edge lists are corrupted
deb/debindexfile.cc:62: Basic block 26 edge lists are corrupted
deb/debindexfile.cc:62: Basic block 21 edge lists are corrupted
deb/debindexfile.cc:62: Basic block 19 edge lists are corrupted
deb/debindexfile.cc:62: Basic block 14 edge lists are corrupted
deb/debindexfile.cc:62: Basic block 10 edge lists are corrupted
deb/debindexfile.cc:62: Basic block 7 edge lists are corrupted
deb/debindexfile.cc:62: Basic block 1 edge lists are corrupted
deb/debindexfile.cc:62: Internal compiler error in , at flow.c:6834
   Please submit a full bug report.
   See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.


Now if I do another make, it will compile fine.  The file is compiled with
the following options:  -g -O -fno-rtti

Is this a kernel problem or a compiler problem?  I can move the build
environment over to an A180 instead.

						- Paul


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [parisc-linux] Weird compile problems

[Randolph Chung]

[-- Attachment #1: Type: text/plain, Size: 739 bytes --]

> I'm in the process of trying to get a working apt (still) and I'm getting
> the following with the latest kernel (updated this morning) and the
> toolchain from nfsroot-20010118.  The system is a C360 with 256MB of RAM.

FWIW I didn't run into this problem when I tried to compile apt using
the same nfsroot and a kernel that is a few days old (Jan20). I get
almost all the way through the end of the build. one of the files take a
lot of memory to build and fails on my gecko, but i've gotten it to work
before so i'm pretty sure it'll work if i increase my swap. i'll try to
give this a try this weekend.

randolph
-- 
   @..@                                         http://www.TauSq.org/
  (----)
 ( >__< )
 ^^ ~~ ^^

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [parisc-linux] Weird compile problems

[Alan Modra]

On Tue, 30 Jan 2001, Paul J.Y. Lahaie wrote:

[about pehc CVS devel branch gcc]
> And fixincl (the progrma that does the subst) is taking 0% CPU (from top)
> 10727 pjlahaie   9   0   712  712   520 S      20  0.0  0.5   0:00 fixincl

Yeah, fixincl dies for me too.  I'd been putting it down to some sort of
kernel problem, and just disabled fixinc (gcc/Makefile:STMP_FIXINC).
Other than that, I get a successful bootstrap, and both kernel & glibc
compile natively - except that `make' died randomly in the glibc build,
and I currently have a ld.so.1 that segfaults.

Hmm, looking at what I just wrote, you can hardly call it a "successful
bootstrap".  I'm investigating the ld.so.1 problem - at least that one is
reproducable.

Alan
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] Weird compile problems

[Matt Taggart]

Alan Modra writes...

> On Tue, 30 Jan 2001, Paul J.Y. Lahaie wrote:
> 
> [about pehc CVS devel branch gcc]
> > And fixincl (the progrma that does the subst) is taking 0% CPU (from top)
> > 10727 pjlahaie   9   0   712  712   520 S      20  0.0  0.5   0:00 fixincl
> 
> Yeah, fixincl dies for me too.  I'd been putting it down to some sort of
> kernel problem, and just disabled fixinc (gcc/Makefile:STMP_FIXINC).
> Other than that, I get a successful bootstrap, and both kernel & glibc
> compile natively - except that `make' died randomly in the glibc build,
> and I currently have a ld.so.1 that segfaults.

I suspect that your make actually died during the make install right? This is 
the problem that John Marvin and I are working on. The pthread changes that he 
made broke things that use librt and libpthread. In our current nfsroot that 
is tar, make, and sleep. For now we're using a static make to complete the 
install. Once I have a new glibc package built I will do new new 
make,tar,sleep stuff too.

> Hmm, looking at what I just wrote, you can hardly call it a "successful
> bootstrap".  I'm investigating the ld.so.1 problem - at least that one is
> reproducable.

I was seeing that here too but John wasn't. We're currently trying to 
determine the differences in our build environments. What system are you 
building on and what nfsroot/kernel are you using?

Thanks,

-- 
Matt Taggart        Linux Development Lab
taggart@fc.hp.com   HP Linux Systems Operation

Re: [parisc-linux] Weird compile problems

[Alan Modra]

On Tue, 30 Jan 2001, Matt Taggart wrote:

> I suspect that your make actually died during the make install right? This is 

No, during the build.

> the problem that John Marvin and I are working on. The pthread changes that he 
> made broke things that use librt and libpthread. In our current nfsroot that 
> is tar, make, and sleep. For now we're using a static make to complete the 
> install. Once I have a new glibc package built I will do new new 
> make,tar,sleep stuff too.
> 
> > Hmm, looking at what I just wrote, you can hardly call it a "successful
> > bootstrap".  I'm investigating the ld.so.1 problem - at least that one is
> > reproducable.
> 
> I was seeing that here too but John wasn't. We're currently trying to 
> determine the differences in our build environments. What system are you 
> building on and what nfsroot/kernel are you using?

Machine is a 712/80, nfsroot started life as nfsroot-20001009 but has been
tweaked quit a bit - compiler, binutils, glibc.  Kernel is one I built
from CVS checked out 24th. Jan.

Alan
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] Weird compile problems

[Alan Modra]

On Wed, 31 Jan 2001, Alan Modra wrote:

> and I currently have a ld.so.1 that segfaults.

r19 is being trashed.  It's a compiler bug.  One I added too. :-(

At least, it's to do with the new scheme of allowing gcc to allocate a
register to save r19 rather than trying to use a fixed register.  From a
quick glance over disassembled code, it seems that inline functions try
to restore r19 from a register that has never been initialised.

Alan
-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] Weird compile problems

[Alan Modra]

On Wed, 31 Jan 2001, Alan Modra wrote:

[about pehc devel branch gcc]
> r19 is being trashed.  It's a compiler bug.  One I added too. :-(

Now fixed.

-- 
Linuxcare.  Support for the Revolution.

Re: [parisc-linux] Weird compile problems

[Alan Modra]

On Wed, 31 Jan 2001, Alan Modra wrote:

> On Wed, 31 Jan 2001, Alan Modra wrote:
> 
> [about pehc devel branch gcc]
> > r19 is being trashed.  It's a compiler bug.  One I added too. :-(
> 
> Now fixed.

It anyone has tried to compile glibc with the devel branch compiler,
you've probably discovered by now that ld.so is still crashing, but for a
different reason.  The global register allocation pass does the following
naughty thing:

[from elf/dl-load.c]
(insn 612 608 1626 (set (reg:SI 1 %r1)
        (plus:SI (reg:SI 19 %r19)
            (high:SI (symbol_ref/v/f:SI ("*.LC27"))))) 80 {*pa.md:2326}
(nil)
    (nil))

(insn 1626 612 621 (set (reg:SI 23 %r23 [242])
        (reg:SI 1 %r1)) 69 {*pa.md:2099} (nil)
    (nil))

[snip around 1480 lines, including calls]

(insn 1638 1527 988 (set (reg:SI 21 %r21)
        (mem/u:SI (lo_sum:SI (reg:SI 23 %r23 [242])
                (unspec:SI[ 
                        (symbol_ref/v/f:SI ("*.LC27"))
                    ]  0)) 0)) 82 {*pa.md:2352} (nil)
    (nil))

With the problem being that r23 is not a callee saved register, so it's
well and truly trashed by the time insn 1638 tries to use it.

-- 
Linuxcare.  Support for the Revolution.