The following changes since commit 281f327487c9c9b1599f93c589a408bbf4a651b8:

  Merge remote-tracking branch 'remotes/vivier/tags/m68k-for-2.12-pull-request' into staging (2017-12-22 00:11:36 +0000)

are available in the Git repository at:

  git://github.com/dgibson/qemu.git tags/ppc-for-2.12-20180108

for you to fetch changes up to 9f173585d3f35345b2facce50620ce2cdda05f2f:

  spapr: Correct compatibility mode setting for hotplugged CPUs (2018-01-08 13:33:17 +1100)

----------------------------------------------------------------
ppc patch queue 2018-01-08

This pull requests supersedes both ppc-for-2.12-20180103 and
ppc-for-2.12-20171219.  We've discovered that some substantial
extensions to the proposed capabilities infrastructure will be
valuable, amongst other things for managing/advertising workarounds
for the dreaded Meltdown/Spectre bugs.

Although that could be done as follow on changes, since the caps
infrastructure hasn't been merged yet, we might as well pull it out
while we rework, and just merge the unrelated bugfixes.

The last two pull requests apparently had problems on some arm32
systems.  I haven't been able to reproduce those, so I have no idea
which patch is causing them.  If we get lucky and it was one of the
patches I've removed from this series, this may also serve to unjam
the other fixes.

Higlights from this series:
  * SLOF update
  * Significant TCG speedup from Paolo
  * Several new devices for embedded platforms
  * Fix to correctly set compatiblity mode for hotplugged CPUs
  * dtc compile fix for older MacOS versions

----------------------------------------------------------------
Alexey Kardashevskiy (1):
      pseries: Update SLOF firmware image to qemu-slof-20171214

BALATON Zoltan (4):
      sm501: Add panel hardware cursor registers also to read function
      sm501: Add some more unimplemented registers
      ppc4xx_i2c: Implement basic I2C functions
      hw/ide: Emulate SiI3112 SATA controller

Cédric Le Goater (2):
      ppc/pnv: change powernv_ prefix to pnv_ for overall naming consistency
      target/ppc: more use of the PPC_*() macros

David Gibson (1):
      spapr: Correct compatibility mode setting for hotplugged CPUs

Greg Kurz (1):
      spapr_pci: use warn_report()

John Arbuckle (1):
      Update dtc to fix compilation problem on Mac OS 10.6

Thomas Huth (1):
      hw/ppc: Remove the deprecated spapr-pci-vfio-host-bridge device

pbonzini@redhat.com (1):
      target-ppc: optimize cmp translation

 MAINTAINERS                        |   6 +
 default-configs/ppcemb-softmmu.mak |   1 +
 dtc                                |   2 +-
 hw/display/sm501.c                 |  30 +++
 hw/i2c/ppc4xx_i2c.c                | 198 +++++++++++++++++---
 hw/ide/Makefile.objs               |   1 +
 hw/ide/sii3112.c                   | 368 +++++++++++++++++++++++++++++++++++++
 hw/ide/trace-events                |   5 +
 hw/ppc/pnv.c                       |  94 +++++-----
 hw/ppc/pnv_bmc.c                   |   2 +-
 hw/ppc/pnv_core.c                  |   8 +-
 hw/ppc/pnv_lpc.c                   |  16 +-
 hw/ppc/pnv_psi.c                   |   4 +-
 hw/ppc/pnv_xscom.c                 |  10 +-
 hw/ppc/spapr.c                     |   2 +-
 hw/ppc/spapr_pci.c                 |   6 +-
 hw/ppc/spapr_pci_vfio.c            |  47 -----
 hw/ppc/spapr_rtas.c                |   9 +
 include/hw/i2c/ppc4xx_i2c.h        |   3 +
 include/hw/ppc/pnv.h               |  10 +-
 include/hw/ppc/pnv_xscom.h         |   4 +-
 pc-bios/README                     |   2 +-
 pc-bios/slof.bin                   | Bin 905200 -> 913880 bytes
 qemu-doc.texi                      |   5 -
 roms/SLOF                          |   2 +-
 scripts/device-crash-test          |   1 -
 target/ppc/cpu.h                   |  56 +++---
 target/ppc/int_helper.c            |   2 +-
 target/ppc/translate.c             |  29 ++-
 29 files changed, 717 insertions(+), 206 deletions(-)
 create mode 100644 hw/ide/sii3112.c

On 8 January 2018 at 05:53, David Gibson <david@gibson.dropbear.id.au> wrote:
> The following changes since commit 281f327487c9c9b1599f93c589a408bbf4a651b8:
>
>   Merge remote-tracking branch 'remotes/vivier/tags/m68k-for-2.12-pull-request' into staging (2017-12-22 00:11:36 +0000)
>
> are available in the Git repository at:
>
>   git://github.com/dgibson/qemu.git tags/ppc-for-2.12-20180108
>
> for you to fetch changes up to 9f173585d3f35345b2facce50620ce2cdda05f2f:
>
>   spapr: Correct compatibility mode setting for hotplugged CPUs (2018-01-08 13:33:17 +1100)
>
> ----------------------------------------------------------------
> ppc patch queue 2018-01-08
>
> This pull requests supersedes both ppc-for-2.12-20180103 and
> ppc-for-2.12-20171219.  We've discovered that some substantial
> extensions to the proposed capabilities infrastructure will be
> valuable, amongst other things for managing/advertising workarounds
> for the dreaded Meltdown/Spectre bugs.
>
> Although that could be done as follow on changes, since the caps
> infrastructure hasn't been merged yet, we might as well pull it out
> while we rework, and just merge the unrelated bugfixes.
>
> The last two pull requests apparently had problems on some arm32
> systems.  I haven't been able to reproduce those, so I have no idea
> which patch is causing them.  If we get lucky and it was one of the
> patches I've removed from this series, this may also serve to unjam
> the other fixes.

This still hangs on my arm32 setup in the migration test. I'll see
if I can identify what is going wrong.

thanks
-- PMM

On Tue, Jan 09, 2018 at 11:46:41AM +0000, Peter Maydell wrote:
> On 8 January 2018 at 05:53, David Gibson <david@gibson.dropbear.id.au> wrote:
> > The following changes since commit 281f327487c9c9b1599f93c589a408bbf4a651b8:
> >
> >   Merge remote-tracking branch 'remotes/vivier/tags/m68k-for-2.12-pull-request' into staging (2017-12-22 00:11:36 +0000)
> >
> > are available in the Git repository at:
> >
> >   git://github.com/dgibson/qemu.git tags/ppc-for-2.12-20180108
> >
> > for you to fetch changes up to 9f173585d3f35345b2facce50620ce2cdda05f2f:
> >
> >   spapr: Correct compatibility mode setting for hotplugged CPUs (2018-01-08 13:33:17 +1100)
> >
> > ----------------------------------------------------------------
> > ppc patch queue 2018-01-08
> >
> > This pull requests supersedes both ppc-for-2.12-20180103 and
> > ppc-for-2.12-20171219.  We've discovered that some substantial
> > extensions to the proposed capabilities infrastructure will be
> > valuable, amongst other things for managing/advertising workarounds
> > for the dreaded Meltdown/Spectre bugs.
> >
> > Although that could be done as follow on changes, since the caps
> > infrastructure hasn't been merged yet, we might as well pull it out
> > while we rework, and just merge the unrelated bugfixes.
> >
> > The last two pull requests apparently had problems on some arm32
> > systems.  I haven't been able to reproduce those, so I have no idea
> > which patch is causing them.  If we get lucky and it was one of the
> > patches I've removed from this series, this may also serve to unjam
> > the other fixes.
> 
> This still hangs on my arm32 setup in the migration test. I'll see
> if I can identify what is going wrong.

Thanks.  Even if you can identify which patch it is and we can
postpone that one would be a bug help.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

On 9 January 2018 at 12:16, David Gibson <david@gibson.dropbear.id.au> wrote:
> Thanks.  Even if you can identify which patch it is and we can
> postpone that one would be a bug help.

Bisection blames this one:

pbonzini@redhat.com (1):
      target-ppc: optimize cmp translation

A plain boot doesn't work either:
./build/ppc/ppc64-softmmu/qemu-system-ppc64 -display none -serial stdio


SLOF **********************************************************************
QEMU Starting
 Build Date = Jul 24 2017 15:15:46
 FW Version = git-89f519f09bf85091
 Press "s" to enter Open Firmware.

Populating /vdevice methods
Populating /vdevice/vty@71000000
Populating /vdevice/nvram@71000001
Populating /vdevice/l-lan@71000002
Populating /vdevice/v-scsi@71000003
       SCSI: Looking for devices
          00000000 CD-ROM   : "QEMU     QEMU CD-ROM      2.5+"

Populating /pci@0000000
                     00 0000 (D) : 1234 1111    qemu vga
                     00 0800 (D) : 1033 0194    serial bus [ usb-xhci ]
No NVRAM common partition, re-initializing...
E

and then keeps printing out spaces for ever as far as I can see.

A working build does


SLOF **********************************************************************
QEMU Starting
 Build Date = Jul 24 2017 15:15:46
 FW Version = git-89f519f09bf85091
 Press "s" to enter Open Firmware.

Populating /vdevice methods
Populating /vdevice/vty@71000000
Populating /vdevice/nvram@71000001
Populating /vdevice/l-lan@71000002
Populating /vdevice/v-scsi@71000003
       SCSI: Looking for devices
          8200000000000000 CD-ROM   : "QEMU     QEMU CD-ROM      2.5+"
Populating /pci@800000020000000
                     00 0000 (D) : 1234 1111    qemu vga
                     00 0800 (D) : 1033 0194    serial bus [ usb-xhci ]
No NVRAM common partition, re-initializing...
Installing QEMU fb



Scanning USB
  XHCI: Initializing
    USB Keyboard
    USB mouse
No console specified using screen & keyboard

[etc etc]

so you can see it's already diverged because it prints out
a different value for the name of the pci node and the
SCSI line has 8200000000000000 vs 00000000.

(This is a build for arm32, running in a chroot on an aarch64
box, non-debug build.)

thanks
-- PMM

Quoting Peter Maydell (2018-01-09 09:15:25)
> On 9 January 2018 at 12:16, David Gibson <david@gibson.dropbear.id.au> wrote:
> > Thanks.  Even if you can identify which patch it is and we can
> > postpone that one would be a bug help.
> 
> Bisection blames this one:
> 
> pbonzini@redhat.com (1):
>       target-ppc: optimize cmp translation
> 
> A plain boot doesn't work either:
> ./build/ppc/ppc64-softmmu/qemu-system-ppc64 -display none -serial stdio
> 
> 
> SLOF **********************************************************************
> QEMU Starting
>  Build Date = Jul 24 2017 15:15:46
>  FW Version = git-89f519f09bf85091
>  Press "s" to enter Open Firmware.
> 
> Populating /vdevice methods
> Populating /vdevice/vty@71000000
> Populating /vdevice/nvram@71000001
> Populating /vdevice/l-lan@71000002
> Populating /vdevice/v-scsi@71000003
>        SCSI: Looking for devices
>           00000000 CD-ROM   : "QEMU     QEMU CD-ROM      2.5+"
> 
> Populating /pci@0000000
>                      00 0000 (D) : 1234 1111    qemu vga
>                      00 0800 (D) : 1033 0194    serial bus [ usb-xhci ]
> No NVRAM common partition, re-initializing...
> E
> 
> and then keeps printing out spaces for ever as far as I can see.
> 
> A working build does
> 
> 
> SLOF **********************************************************************
> QEMU Starting
>  Build Date = Jul 24 2017 15:15:46
>  FW Version = git-89f519f09bf85091
>  Press "s" to enter Open Firmware.
> 
> Populating /vdevice methods
> Populating /vdevice/vty@71000000
> Populating /vdevice/nvram@71000001
> Populating /vdevice/l-lan@71000002
> Populating /vdevice/v-scsi@71000003
>        SCSI: Looking for devices
>           8200000000000000 CD-ROM   : "QEMU     QEMU CD-ROM      2.5+"
> Populating /pci@800000020000000
>                      00 0000 (D) : 1234 1111    qemu vga
>                      00 0800 (D) : 1033 0194    serial bus [ usb-xhci ]
> No NVRAM common partition, re-initializing...
> Installing QEMU fb
> 
> 
> 
> Scanning USB
>   XHCI: Initializing
>     USB Keyboard
>     USB mouse
> No console specified using screen & keyboard
> 
> [etc etc]
> 
> so you can see it's already diverged because it prints out
> a different value for the name of the pci node and the
> SCSI line has 8200000000000000 vs 00000000.

FYI I actually see this with a raspberry pi 3 too, with repeating spaces
as well. I didn't notice it before since in my case the
ufd_version_check() in test-migration.c was failing so the migration tests
were reporting success but were actually just getting skipped.

> 
> (This is a build for arm32, running in a chroot on an aarch64
> box, non-debug build.)
> 
> thanks
> -- PMM
> 

On 09/01/2018 17:02, Michael Roth wrote:
>> so you can see it's already diverged because it prints out
>> a different value for the name of the pci node and the
>> SCSI line has 8200000000000000 vs 00000000.
> FYI I actually see this with a raspberry pi 3 too

Is this an arm32 or aarch64 install?  From Peter's report, I am tempted
to blame the ARM backend (I tested 32-bit x86 and it works).  But a bug
in both 32-bit ARM and aarch64 would be less likely.

Paolo

> , with repeating spaces
> as well. I didn't notice it before since in my case the
> ufd_version_check() in test-migration.c was failing so the migration tests
> were reporting success but were actually just getting skipped.
> 

Quoting Paolo Bonzini (2018-01-09 11:34:48)
> On 09/01/2018 17:02, Michael Roth wrote:
> >> so you can see it's already diverged because it prints out
> >> a different value for the name of the pci node and the
> >> SCSI line has 8200000000000000 vs 00000000.
> > FYI I actually see this with a raspberry pi 3 too
> 
> Is this an arm32 or aarch64 install?  From Peter's report, I am tempted
> to blame the ARM backend (I tested 32-bit x86 and it works).  But a bug
> in both 32-bit ARM and aarch64 would be less likely.

In my case it's a 32-bit kernel/userspace:

pi@rpi-office:~/dev/qemu-build $ uname -a
Linux rpi-office 4.4.38-v7+ #938 SMP Thu Dec 15 15:22:21 GMT 2016 armv7l
GNU/Linux
pi@rpi-office:~/dev/qemu-build $ file ppc64-softmmu/qemu-system-ppc64 
ppc64-softmmu/qemu-system-ppc64: ELF 32-bit LSB executable, ARM, EABI5
version 1 (GNU/Linux), dynamically linked, interpreter
/lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32,
BuildID[sha1]=4e3e0c8ddbab91a672e4c29b5bfcee9d22459cf7, not stripped

> 
> Paolo
> 
> > , with repeating spaces
> > as well. I didn't notice it before since in my case the
> > ufd_version_check() in test-migration.c was failing so the migration tests
> > were reporting success but were actually just getting skipped.
> > 
> 

On 01/09/2018 07:15 AM, Peter Maydell wrote:
> (This is a build for arm32, running in a chroot on an aarch64
> box, non-debug build.)

It's an arm backend problem.

For 64-bit setcond2, we do

0x6e5c3fa4:  e1570008  cmp      r7, r8
0x6e5c3fa8:  01550004  cmpeq    r5, r4
0x6e5c3fac:  b3a09001  movlt    sb, #1
0x6e5c3fb0:  a3a09000  movge    sb, #0

which looks good, but only works for LTU not LT.

I'll work on a fix.


r~

On Tue, Jan 09, 2018 at 03:15:25PM +0000, Peter Maydell wrote:
> On 9 January 2018 at 12:16, David Gibson <david@gibson.dropbear.id.au> wrote:
> > Thanks.  Even if you can identify which patch it is and we can
> > postpone that one would be a bug help.
> 
> Bisection blames this one:
> 
> pbonzini@redhat.com (1):
>       target-ppc: optimize cmp translation

Aha!  Ok, I'll pull that one out until we find a fix.

[snip]
> (This is a build for arm32, running in a chroot on an aarch64
> box, non-debug build.)

Ah.. but since it's a chroot, still an aarch64 cpu behind it all.  I
think the machines I managed to borrow were all much older slower
really truly arm32 machines, which I guess didn't show the problem.

Oh.. and probably a debug (default) build as well.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

On 10/01/2018 02:55, David Gibson wrote:
> On Tue, Jan 09, 2018 at 03:15:25PM +0000, Peter Maydell wrote:
>> On 9 January 2018 at 12:16, David Gibson <david@gibson.dropbear.id.au> wrote:
>>> Thanks.  Even if you can identify which patch it is and we can
>>> postpone that one would be a bug help.
>>
>> Bisection blames this one:
>>
>> pbonzini@redhat.com (1):
>>       target-ppc: optimize cmp translation
> 
> Aha!  Ok, I'll pull that one out until we find a fix.

Richard posted one, it's an ARM32 backend bug.

> [snip]
>> (This is a build for arm32, running in a chroot on an aarch64
>> box, non-debug build.)
> 
> Ah.. but since it's a chroot, still an aarch64 cpu behind it all.

No, it's running 32-bit ARM code.

Paolo

  I
> think the machines I managed to borrow were all much older slower
> really truly arm32 machines, which I guess didn't show the problem.
> 
> Oh.. and probably a debug (default) build as well.
> 

On Wed, Jan 10, 2018 at 02:33:41PM +0100, Paolo Bonzini wrote:
> On 10/01/2018 02:55, David Gibson wrote:
> > On Tue, Jan 09, 2018 at 03:15:25PM +0000, Peter Maydell wrote:
> >> On 9 January 2018 at 12:16, David Gibson <david@gibson.dropbear.id.au> wrote:
> >>> Thanks.  Even if you can identify which patch it is and we can
> >>> postpone that one would be a bug help.
> >>
> >> Bisection blames this one:
> >>
> >> pbonzini@redhat.com (1):
> >>       target-ppc: optimize cmp translation
> > 
> > Aha!  Ok, I'll pull that one out until we find a fix.
> 
> Richard posted one, it's an ARM32 backend bug.
> 
> > [snip]
> >> (This is a build for arm32, running in a chroot on an aarch64
> >> box, non-debug build.)
> > 
> > Ah.. but since it's a chroot, still an aarch64 cpu behind it all.
> 
> No, it's running 32-bit ARM code.

Ah.  But maybe a different version to older ARM32s?

I'm trying to figure out why I entirely failed to reproduce this on a
Raspberry Pi 1 (and a couple of other arm32 machines, but I forget the
details of them).

>   I
> > think the machines I managed to borrow were all much older slower
> > really truly arm32 machines, which I guess didn't show the problem.
> > 
> > Oh.. and probably a debug (default) build as well.
> > 
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

On 01/10/2018 06:47 PM, David Gibson wrote:
> Ah.  But maybe a different version to older ARM32s?

No, the bug affected all arm32 back to the beginning of time.

> I'm trying to figure out why I entirely failed to reproduce this on a
> Raspberry Pi 1 (and a couple of other arm32 machines, but I forget the
> details of them).

I can't imagine, really.  You should have been able to see it there.


r~

Hi devs sorry if i enter in the discussion about.

gcc gave errors in building this queue.

here i paste my build log.

https://pastebin.com/fXw2Whrq



This is my machine infos and so and so


Architecture:        ppc64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Big Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):           4
NUMA node(s):        1
Model:               1.1 (pvr 0044 0101)
Model name:          PPC970MP, altivec supported
CPU max MHz:         2500.0000
CPU min MHz:         1250.0000
L1d cache:           32K
L1i cache:           64K
L2 cache:            1024K
NUMA node0 CPU(s):   0-3


uname -a
Linux debian 4.9.67 #1 SMP Sat Dec 9 12:20:20 CET 2017 ppc64 GNU/Linux

gcc --version
gcc (Debian 7.2.0-19) 7.2.0



Regards
Luigi

________________________________
Da: Qemu-ppc <qemu-ppc-bounces+intermediadc=hotmail.com@nongnu.org> per conto di David Gibson <david@gibson.dropbear.id.au>
Inviato: martedì 9 gennaio 2018 13:16
A: Peter Maydell
Cc: Michael Roth; QEMU Developers; qemu-ppc@nongnu.org; Greg Kurz; surajjs@au1.ibm.com
Oggetto: Re: [Qemu-ppc] [PULL 00/12] ppc-for-2.12 queue 20180108

On Tue, Jan 09, 2018 at 11:46:41AM +0000, Peter Maydell wrote:
> On 8 January 2018 at 05:53, David Gibson <david@gibson.dropbear.id.au> wrote:
> > The following changes since commit 281f327487c9c9b1599f93c589a408bbf4a651b8:
> >
> >   Merge remote-tracking branch 'remotes/vivier/tags/m68k-for-2.12-pull-request' into staging (2017-12-22 00:11:36 +0000)
> >
> > are available in the Git repository at:
> >
> >   git://github.com/dgibson/qemu.git tags/ppc-for-2.12-20180108
> >
> > for you to fetch changes up to 9f173585d3f35345b2facce50620ce2cdda05f2f:
> >
> >   spapr: Correct compatibility mode setting for hotplugged CPUs (2018-01-08 13:33:17 +1100)
> >
> > ----------------------------------------------------------------
> > ppc patch queue 2018-01-08
> >
> > This pull requests supersedes both ppc-for-2.12-20180103 and
> > ppc-for-2.12-20171219.  We've discovered that some substantial
> > extensions to the proposed capabilities infrastructure will be
> > valuable, amongst other things for managing/advertising workarounds
> > for the dreaded Meltdown/Spectre bugs.
> >
> > Although that could be done as follow on changes, since the caps
> > infrastructure hasn't been merged yet, we might as well pull it out
> > while we rework, and just merge the unrelated bugfixes.
> >
> > The last two pull requests apparently had problems on some arm32
> > systems.  I haven't been able to reproduce those, so I have no idea
> > which patch is causing them.  If we get lucky and it was one of the
> > patches I've removed from this series, this may also serve to unjam
> > the other fixes.
>
> This still hangs on my arm32 setup in the migration test. I'll see
> if I can identify what is going wrong.

Thanks.  Even if you can identify which patch it is and we can
postpone that one would be a bug help.

--
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson
[http://www.ozlabs.org/~dgibson/dgibson-small.jpg]<http://www.ozlabs.org/~dgibson>

David Gibson's Home Page - OzLabs<http://www.ozlabs.org/~dgibson>
www.ozlabs.org
Home; Papers; Junk code; PGP Key; Ozlabs. David Gibson's Home Page. I'm a Linux kernel hacker, mostly, though I've also worked on other projects including, recently ...

On 10 January 2018 at 10:37, luigi burdo <intermediadc@hotmail.com> wrote:
> Hi devs sorry if i enter in the discussion about.
>
> gcc gave errors in building this queue.
>
> here i paste my build log.
>
> https://pastebin.com/fXw2Whrq

Thanks. This is the relevant bit of the log:

/home/amigaone/src/new/tags/ppc-for-2.12-20180108/target/s390x/mem_helper.c:2567:1:
internal compiler error: Segmentation fault
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.

This means that gcc crashed. This is either:
 (a) a hardware problem with your machine (eg bad memory)
or
 (b) a bug in gcc (which you can report to the gcc team
as they suggest in the error message)

You should check whether gcc reliably crashes in the
same way every time you try to build that source file.
If it does, that suggests a gcc bug is more likely. If
it sometimes works and sometimes doesn't, I would suspect
hardware problems.

thanks
-- PMM

Hi Peter,

thanks for reply.

I will check the ram banks and will try again to build it .

but i have more fear about gcc now because the issue come exactly in the same point every time i try to rebuild everyting.


Thankyou

Luigi


________________________________________

This means that gcc crashed. This is either:
 (a) a hardware problem with your machine (eg bad memory)
or
 (b) a bug in gcc (which you can report to the gcc team
as they suggest in the error message)

You should check whether gcc reliably crashes in the
same way every time you try to build that source file.
If it does, that suggests a gcc bug is more likely. If
it sometimes works and sometimes doesn't, I would suspect
hardware problems.

thanks
-- PMM