[m-rev.] Re: for review: don't make asm label functions static

[Julien Fischer]

On Thu, 8 Jul 2010, Ian MacLarty wrote:

> On Thu, Jul 8, 2010 at 9:43 AM, Ian MacLarty
> <maclarty at csse.unimelb.edu.au> wrote:
>> On Thursday, July 8, 2010, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>>>
>>> On Wed, 7 Jul 2010, Ian MacLarty wrote:
>>>
>>>
>>> On Tue, Jul 6, 2010 at 3:31 PM, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
>>>
>>> On Tue, Jul 06, 2010 at 12:17:33PM +1000, Ian MacLarty wrote:
>>>
>>> For review by anyone.
>>>
>>>
>>>
>>> Thanks Ian,
>>>
>>> Julien and I are happy with this.  Could you also bootcheck it using GCC 3.4?
>>> We have gcc-3.4 installed on taura.
>>>
>>>
>>>
>>> Bootcheck with gcc-3.4 passes, so I've committed this.
>>>
>>>
>>> rotd-2010-07-07 is very broken on x86-64 in the asm_fast.gc grades, (the
>>> generated executables seg fault when initialising the standard library.)
>>> This is presumably what PeterW mentioned yesterday afternoon.
>>>
>>> What optimization options did you bootcheck with?  It appears that
>>> everything is fine at -O2, but the nightly builds are broken on the
>>> following machines:
>>>
>>>         taura           gcc 4.4         -O5 --intermod-opt
>>>         goliath         gcc 4.1         -O5 --intermod-opt
>>>         neptune         gcc 4.1         -O4
>>>         saturn          gcc 4.3         -O5 --intermod-opt
>>>
>>> The only one of the x86-64 machines on which it is working is goofy,
>>> which builds at -O2 (it's also gcc 4.1).
>>>
>>
>> I checked at the default (-O2 I believe) using gcc-4.3 and gcc-3.4 on
>> a 32 bit machine.
>>
>
> I did a bootcheck on an x86_64 machine with gcc-4.3 and -O4 and it
> passed.  However when I installed it and used the installed version to
> build hello world, the executable segfaults.  I reverted my change and
> reinstalled and still got a segfault.  Then I did a clean check out,
> reverted my change and installed, and that worked.
>
> I have reverted my change for now until we can figure out what's going on.
>
> Is it the case that everything is statically linked when doing a
> bootcheck?

By default yes, although the nightly builds do use dynamic linking
on most of our Linux hosts for the test suite.

> If so then the problem seems to occur only when the
> executable is dynamically linked with the Mercury libraries.

Did you observe any difference in the .pic_o files when originally made
your change?

Julien.