try_io on x86-64

[Michael Day]

Hi,

Trying Mercury on x86-64, and everything seems to work, it's great.

However, when I recompile the compiler so that it uses unboxed floats
and 3 tag bits instead of 2, there is a problem: I get a link error
concerning try_io from the exception module.

I also get this link error on MacOS X, which is 32-bit. Only workaround
so far is to not catch exceptions.

Anyone ran into this before?

Cheers,

Michael

--
Print XML with Prince!
http://www.princexml.com
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Ian MacLarty-4]

On Thu, Oct 8, 2009 at 8:59 PM, Michael Day <mikeday@...> wrote:

> Hi,
>
> Trying Mercury on x86-64, and everything seems to work, it's great.
>
> However, when I recompile the compiler so that it uses unboxed floats and 3
> tag bits instead of 2, there is a problem: I get a link error concerning
> try_io from the exception module.
>
> I also get this link error on MacOS X, which is 32-bit. Only workaround so
> far is to not catch exceptions.
>

Which version of MacOS X?  I have successfully compiled and run
programs that use try_io on 10.5 (Intel).  I've also tried a small
program with try_io on 10.6 (with the 10.6 patch I posted to
mercury-reviews which is not yet committed) and it seems to work fine.

Ian.
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Michael Day]

Hi Ian,

> Which version of MacOS X?  I have successfully compiled and run
> programs that use try_io on 10.5 (Intel).  I've also tried a small
> program with try_io on 10.6 (with the 10.6 patch I posted to
> mercury-reviews which is not yet committed) and it seems to work fine.

Definitely on MacOS X 10.4 PowerPC, not sure about Intel, need to check
again. Do you have an x86-64 system for testing?

Cheers,

Michael

--
Print XML with Prince!
http://www.princexml.com
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Julien Fischer-2]

On Thu, 8 Oct 2009, Michael Day wrote:

>> Which version of MacOS X?  I have successfully compiled and run
>> programs that use try_io on 10.5 (Intel).  I've also tried a small
>> program with try_io on 10.6 (with the 10.6 patch I posted to
>> mercury-reviews which is not yet committed) and it seems to work fine.
>
> Definitely on MacOS X 10.4 PowerPC, not sure about Intel, need to check
> again. Do you have an x86-64 system for testing?

Mercury is primarily developed on Linux x86-64 systems these days; we
haven't noticed any problems with try_io.

Cheers,
Julien.
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Ian MacLarty-4]

On Thu, Oct 8, 2009 at 10:11 PM, Michael Day <mikeday@...> wrote:

> Hi Ian,
>
>> Which version of MacOS X?  I have successfully compiled and run
>> programs that use try_io on 10.5 (Intel).  I've also tried a small
>> program with try_io on 10.6 (with the 10.6 patch I posted to
>> mercury-reviews which is not yet committed) and it seems to work fine.
>
> Definitely on MacOS X 10.4 PowerPC, not sure about Intel, need to check
> again. Do you have an x86-64 system for testing?
>

With Linux yes, and that works fine.  The version of boehm that
Mercury currently uses doesn't work on 64 bit Mac OS, so for Mac OS
you've got to go 32 bit.  I've never tried Mercury on 10.4.

Ian.

--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Michael Day]

Hi Julien,

> Mercury is primarily developed on Linux x86-64 systems these days; we
> haven't noticed any problems with try_io.

I can reproduce the bug with the program below and rotd-2008-01-30, but
only when building with some optimisations enabled:

$ mmc --make try -O3 --intermodule-optimisation
Mercury/os/try.o:(.rodata+0x310): undefined reference to `<predicate
'exception.wrap_success_or_failure'/2 mode 0>'
collect2: ld returned 1 exit status

--------------------------------
:- module try.

:- interface.

:- import_module io.

:- pred main(io, io).
:- mode main(di, uo) is cc_multi.

:- implementation.

:- import_module int, exception.

main(!IO) :-
     try_io(test, Res, !IO),
     write(Res, !IO), nl(!IO).

:- pred test(int, io, io).
:- mode test(out, di, uo) is det.

test(17, !IO).
--------------------------------

Can you see if this error still manifests in the latest version?

Cheers,

Michael

--
Print XML with Prince!
http://www.princexml.com
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Ian MacLarty-4]

On Fri, Oct 9, 2009 at 8:55 AM, Ian MacLarty
<maclarty@...> wrote:

> On Thu, Oct 8, 2009 at 10:11 PM, Michael Day <mikeday@...> wrote:
>> Hi Ian,
>>
>>> Which version of MacOS X?  I have successfully compiled and run
>>> programs that use try_io on 10.5 (Intel).  I've also tried a small
>>> program with try_io on 10.6 (with the 10.6 patch I posted to
>>> mercury-reviews which is not yet committed) and it seems to work fine.
>>
>> Definitely on MacOS X 10.4 PowerPC, not sure about Intel, need to check
>> again. Do you have an x86-64 system for testing?
>>
>
> With Linux yes, and that works fine.  The version of boehm that
> Mercury currently uses doesn't work on 64 bit Mac OS, so for Mac OS
> you've got to go 32 bit.  I've never tried Mercury on 10.4.
>

By the way, have you tried building prince with the improved Java
backend?  We've been using it for some non-trivial  web applications
and have found it very good.  Performance is quite reasonable. A pure
Java version of prince might be quite useful

Ian.

--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Michael Day]

Hi Ian,

> By the way, have you tried building prince with the improved Java
> backend?  We've been using it for some non-trivial  web applications
> and have found it very good.  Performance is quite reasonable. A pure
> Java version of prince might be quite useful

Yes, but it would require us to provide Java alternatives for all the C
stuff that we depend on:

  - libxml2
  - image libraries
  - zlib compression
  - font access (this is a big one)
  - flex-based scanner

This could certainly be done, but it requires more than just a rebuild
in a different grade.

Cheers,

Michael

--
Print XML with Prince!
http://www.princexml.com
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Julien Fischer-2]

On Fri, 9 Oct 2009, Ian MacLarty wrote:

> On Thu, Oct 8, 2009 at 10:11 PM, Michael Day <mikeday@...> wrote:
>> Hi Ian,
>>
>>> Which version of MacOS X?  I have successfully compiled and run
>>> programs that use try_io on 10.5 (Intel).  I've also tried a small
>>> program with try_io on 10.6 (with the 10.6 patch I posted to
>>> mercury-reviews which is not yet committed) and it seems to work fine.
>>
>> Definitely on MacOS X 10.4 PowerPC, not sure about Intel, need to check
>> again. Do you have an x86-64 system for testing?
>>
>
> With Linux yes, and that works fine.  The version of boehm that
> Mercury currently uses doesn't work on 64 bit Mac OS, so for Mac OS
> you've got to go 32 bit.  I've never tried Mercury on 10.4.

Mercury was working on 10.4/PPC -- for Mercury's purposes 10.4 wasn't
signficantly different from 10.3.

Julien.
>

[Michael Day]

Hi Julien,

> Mercury was working on 10.4/PPC -- for Mercury's purposes 10.4 wasn't
> signficantly different from 10.3.

So no one has seen the link error affecting wrap_success_or_failure?

The test program I sent earlier demonstrates it on x86-64, but only if
the compiler has been bootstrapped, not with first build of the source
distribution.

Cheers,

Michael

--
Print XML with Prince!
http://www.princexml.com
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Julien Fischer-2]

Hi Michael,

On Fri, 9 Oct 2009, Michael Day wrote:

>> Mercury is primarily developed on Linux x86-64 systems these days; we
>> haven't noticed any problems with try_io.
>
> I can reproduce the bug with the program below and rotd-2008-01-30, but only
> when building with some optimisations enabled:
>
> $ mmc --make try -O3 --intermodule-optimisation
> Mercury/os/try.o:(.rodata+0x310): undefined reference to `<predicate
> 'exception.wrap_success_or_failure'/2 mode 0>'
> collect2: ld returned 1 exit status
>
> --------------------------------
> :- module try.
>
> :- interface.
>
> :- import_module io.
>
> :- pred main(io, io).
> :- mode main(di, uo) is cc_multi.
>
> :- implementation.
>
> :- import_module int, exception.
>
> main(!IO) :-
>    try_io(test, Res, !IO),
>    write(Res, !IO), nl(!IO).
>
> :- pred test(int, io, io).
> :- mode test(out, di, uo) is det.
>
> test(17, !IO).
> --------------------------------
>
> Can you see if this error still manifests in the latest version?

I tried the above program on three of our machines using all
combinations of the grades installed on the machines,
--intermodule-optimisation/--no-intermodule-optimization, -O[0-6],
--linkage static** / shared.

(** Except on Mac OS X, where --linkage static doesn't work due to the
static versions of the system libs not be installed by default; I tried
--mercury-linkage static here though.)

This was with rotd-2009-10-0{8,9}.

The machines and GCC versions were:

    i686-pc-linux-gnu, gcc 3.4
    i686-apple-darwin9.8.0, gcc 4.0
    x86_64-unknown-linux-gnu, gcc 3.4

The only problem I can report is that you can no longer use "try" as a
module name; otherwise everything worked.

Cheers,
Julien.
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Michael Day]

Hi Julien,

> I tried the above program on three of our machines using all
> combinations of the grades installed on the machines,
> --intermodule-optimisation/--no-intermodule-optimization, -O[0-6],
> --linkage static** / shared.

Sounds pretty thorough! I'll grab a newer release of the day and see how
it goes.

Cheers,

Michael

--
Print XML with Prince!
http://www.princexml.com
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Michael Day]

Hi Julien,

> This was with rotd-2009-10-0{8,9}.

I'm afraid I've reproduced the problem:

  - rotd-2009-10-08
  - x86_64-unknown-linux-gnu, gcc 3.4
  - --use-subdirs --make -O3 --intermodule-optimisation

> The only problem I can report is that you can no longer use "try" as a
> module name; otherwise everything worked.

Yes, I had to rename the module. But I still get the bug:

$ mmc --use-subdirs --make try2 --intermodule-optimisation -O3
Making Mercury/int3s/try2.int3
Making Mercury/ints/try2.int
Making Mercury/opts/try2.opt
Making Mercury/cs/try2.c
Making Mercury/os/try2.o
Making try2
** Error making `try2'.
Mercury/os/try2.o:(.rodata+0x310): undefined reference to `<predicate
'exception.wrap_success_or_failure'/2 mode 0>'
collect2: ld returned 1 exit status

IMPORTANT NOTE: I only get this bug after fully bootstrapping the
compiler. The first install of the compiler builds it fine, only the
second rebuild of the compiler with unboxed floats and 3 tag bits has
problems with try_io.

Cheers,

Michael

--
Print XML with Prince!
http://www.princexml.com
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Julien Fischer-2]

Hi,

On Sat, 10 Oct 2009, Michael Day wrote:

>> This was with rotd-2009-10-0{8,9}.
>
> I'm afraid I've reproduced the problem:
>
> - rotd-2009-10-08
> - x86_64-unknown-linux-gnu, gcc 3.4
> - --use-subdirs --make -O3 --intermodule-optimisation
>
>> The only problem I can report is that you can no longer use "try" as a
>> module name; otherwise everything worked.
>
> Yes, I had to rename the module. But I still get the bug:
>
> $ mmc --use-subdirs --make try2 --intermodule-optimisation -O3
> Making Mercury/int3s/try2.int3
> Making Mercury/ints/try2.int
> Making Mercury/opts/try2.opt
> Making Mercury/cs/try2.c
> Making Mercury/os/try2.o
> Making try2
> ** Error making `try2'.
> Mercury/os/try2.o:(.rodata+0x310): undefined reference to `<predicate
> 'exception.wrap_success_or_failure'/2 mode 0>'
> collect2: ld returned 1 exit status
>
> IMPORTANT NOTE: I only get this bug after fully bootstrapping the compiler.
> The first install of the compiler builds it fine, only the second rebuild of
> the compiler with unboxed floats and 3 tag bits has problems with try_io.

The x86-64 machine I tested on was using those settings.

Cheers,
Julien.
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Michael Day]

Hi Julien,

> The x86-64 machine I tested on was using those settings.

Using the asm_fast.gc grade?

What other points of difference could there be?

Cheers,

Michael

--
Print XML with Prince!
http://www.princexml.com
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Julien Fischer-2]

Hi,

On Sat, 10 Oct 2009, Michael Day wrote:

> Hi Julien,
>
>> The x86-64 machine I tested on was using those settings.
>
> Using the asm_fast.gc grade?

Yes, among others.

> What other points of difference could there be?

Good question - I've just tried it on another machine, this one with
Ubutnu 9.04 - same results as before; the last lot of tests I ran were on
a machine running Debian 4.  We've got another machine running Debian 5,
which I'll try shortly.

One possible difference is that the installed compiler on our machines
is not built from the source distribution, but based directly on a CVS
checkout -- I'll try building an installation with the source
distribution and see if I can reproduce the problem with that.

Cheers,
Julien.
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Julien Fischer-2]

On Sat, 10 Oct 2009, Michael Day wrote:

>> The x86-64 machine I tested on was using those settings.
>
> Using the asm_fast.gc grade?

Does this problem affect other grades, e.g. hlc.gc, on your
system?

Julien.
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Julien Fischer-2]

On Sat, 10 Oct 2009, Julien Fischer wrote:

> One possible difference is that the installed compiler on our machines
> is not built from the source distribution, but based directly on a CVS
> checkout -- I'll try building an installation with the source
> distribution and see if I can reproduce the problem with that.

And indeed that does cause the problem to show up.

Julien.
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Julien Fischer-2]

On Sat, 10 Oct 2009, Michael Day wrote:

> Yes, I had to rename the module. But I still get the bug:
>
> $ mmc --use-subdirs --make try2 --intermodule-optimisation -O3
> Making Mercury/int3s/try2.int3
> Making Mercury/ints/try2.int
> Making Mercury/opts/try2.opt
> Making Mercury/cs/try2.c
> Making Mercury/os/try2.o
> Making try2
> ** Error making `try2'.
> Mercury/os/try2.o:(.rodata+0x310): undefined reference to `<predicate
> 'exception.wrap_success_or_failure'/2 mode 0>'
> collect2: ld returned 1 exit status
>
> IMPORTANT NOTE: I only get this bug after fully bootstrapping the compiler.
> The first install of the compiler builds it fine, only the second rebuild of
> the compiler with unboxed floats and 3 tag bits has problems with try_io.

It works if you use first install of the source distribution (i.e. the
one with  2 tag bits and unboxed floats) to build and install using
the sources from CVS.

I suspect it may also work with just the source distribution if
you do an mmake realclean between doing the initial install and the
rebuild.

Julien.
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

[Michael Day]

Hi Julien,

> And indeed that does cause the problem to show up.

Thank goodness for that, I'm not going mad :)

> It works if you use first install of the source distribution (i.e. the
> one with  2 tag bits and unboxed floats) to build and install using
> the sources from CVS.

Okay, so what is the difference between the sources in CVS and the
latest source distribution?

> I suspect it may also work with just the source distribution if
> you do an mmake realclean between doing the initial install and the
> rebuild.

I suspect not, as I actually deleted the entire directory and started
from scratch when doing the rebuild.

Cheers,

Michael

--
Print XML with Prince!
http://www.princexml.com
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------