[Top][All Lists]

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

Re: [Gm2] Fedora Core 14 compatibility

From: Gaius Mulley
Subject: Re: [Gm2] Fedora Core 14 compatibility
Date: Sat, 29 Oct 2011 12:02:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

SiTex Graphics <address@hidden> writes:

> Hi Gaius,
> Thanks for looking into this.  I sent the user a build linked with
> FIO.o -O0, and he reports getting the same error.
> Here's the call stack from gdb:
> #0  0x00007ffff6ca32d5 in raise () from /lib64/
> #1  0x00007ffff6ca4beb in abort () from /lib64/
> #2  0x000000000063cfb2 in M2RTS_HALT (exitcode=-1) at
> ../../gcc-4.1.2+gm2-cvs-latest
> /gcc/gm2/gm2-libs-iso/M2RTS.mod:145
> #3  0x00000000006509cc in RTExceptions_DefaultErrorCatch ()
>    at ../../gcc-4.1.2+gm2-cvs-latest/gcc/gm2/gm2-libs/RTExceptions.mod:153
> #4  0x0000000000403c09 in init(int, char**) ()
> #5  0x0000000000403f79 in main ()
> Am I right that init() calls the initialization code for each module?
> If so, is there a build option to have the executable print a message
> as each module is initialized?  Any other suggestions for how to track
> down the offending module (which may well be one of ours)?
> Thanks,
> Scott
> On Wed, Oct 19, 2011 at 5:32 AM, Gaius Mulley <address@hidden> wrote:
>> SiTex Graphics <address@hidden> writes:
>>> On Tue, Oct 11, 2011 at 2:50 AM, Gaius Mulley <address@hidden> wrote:
>>>> is this a 32 bit or 64 bit version of FC 14?  I've not run either - but
>>>> I'll download/install and try and reproduce the bug,
>>> 64-bit
>>> Thanks for taking a look.
>> Hi Scott,
>> I've reproduced the bug and indeed it crashes before the main
>> application starts - if you link against the -O2 libraries.  There is a
>> bug in the compilation of FIO.mod when -O2 is used.  As a work around it
>> should be possibly to copy
>>  build-4.1.2/gcc/gm2/gm2-libs/FIO.o
>> into your user area where the link is performed.  Thus linking against
>> the -O0 FIO.mod and -O2 other libraries.  I'm still looking into the
>> actual bug (for the correct fix),
>> regards,
>> Gaius

Hi Scott,

all fixed now in the latest cvs:

    * gm2/gccgm2.c:  gccgm2_BuildAddr call gm2_mark_addressable.
    * gm2/gccgm2.c:  gccgm2_BuildComponentRef, convertToSizeT
      (New functions).
    * gm2/gm2builtins.c:  gm2builtins_BuiltInAlloca call
    * convertToSizeT.
    * gm2/gm2-compiler/M2GenGCC.mod:  use gccgm2_BuildComponentRef
      to access high and address fields within unbounded records.
      This fixes a bug reported by Scott Iverson which has been
      expressed as testsuite/gm2/pim/run/pass/passparam.mod and
      testsuite/gm2/pim/run/pass/passparam2.mod.  Manifested
      itself when attempting to take the address of a parameter.
      This does not work with -O2 as parameters are passed in
      registers on some architectures (x86_64).  These changes
      introduce no new regression test failures.

thanks for the bug report.  The problem manifested itself because gm2
was attempting to take the address of a structure passed as a parameter
which when -O2 (or higher) is used will pass parameters in registers.
The fix also has a nice side effect of producing more efficient code.

I'll release a new binary of gm2 shortly


reply via email to

[Prev in Thread] Current Thread [Next in Thread]