This code:

http://pastebin.com/U5XdFfDq

Will result in a bus error when compiled as 32bit. Three ways the bus error won't happen:

* If I compile as 64bit everything works fine
* If the function "foo" is moved inline in the "main" function everything works fine
* If store the return value of "fp" in "foo" in a temporary variable and then return it

DMD 2.062
Mac OS X 10.8.2

-- 
/Jacob Carlborg

On Sunday, 14 April 2013 at 14:48:40 UTC, Jacob Carlborg wrote:
> This code:
>
> http://pastebin.com/U5XdFfDq
>
> Will result in a bus error when compiled as 32bit. Three ways the bus error won't happen:
>
> * If I compile as 64bit everything works fine
> * If the function "foo" is moved inline in the "main" function everything works fine
> * If store the return value of "fp" in "foo" in a temporary variable and then return it
>
> DMD 2.062
> Mac OS X 10.8.2

http://d.puremagic.com/issues/enter_bug.cgi

On 2013-04-14 17:13, Peter Alexander wrote:

> http://d.puremagic.com/issues/enter_bug.cgi

I was hoping someone would have an idea what's wrong so I can create a proper bugzilla entry. Filed an issue anyway:

http://d.puremagic.com/issues/show_bug.cgi?id=9931

-- 
/Jacob Carlborg

On Sunday, 14 April 2013 at 14:48:40 UTC, Jacob Carlborg wrote:
> This code:
>
> http://pastebin.com/U5XdFfDq
>
> Will result in a bus error when compiled as 32bit. Three ways the bus error won't happen:
>
> * If I compile as 64bit everything works fine
> * If the function "foo" is moved inline in the "main" function everything works fine
> * If store the return value of "fp" in "foo" in a temporary variable and then return it
>
> DMD 2.062
> Mac OS X 10.8.2

Have you tried any debugging? Disassembly? It's quite hard for me (or anyone else for that matter) to diagnose when it's not a separately compilable example and there's no extra info.

On 2013-04-14 19:12, John Colvin wrote:

> Have you tried any debugging? Disassembly? It's quite hard for me (or
> anyone else for that matter) to diagnose when it's not a separately
> compilable example and there's no extra info.

This is the dissassembly for the 64bit version:

http://pastebin.com/L30u3tMu

32bit version:

http://pastebin.com/tKVCTeZV

This is what Clang produces for basically the same code:

http://pastebin.com/JBcNupfs

The C code looks like:

http://pastebin.com/KS9QwB3A

-- 
/Jacob Carlborg

On Sunday, 14 April 2013 at 18:50:52 UTC, Jacob Carlborg wrote:
> On 2013-04-14 19:12, John Colvin wrote:
>
>> Have you tried any debugging? Disassembly? It's quite hard for me (or
>> anyone else for that matter) to diagnose when it's not a separately
>> compilable example and there's no extra info.
>
> This is the dissassembly for the 64bit version:
>
> http://pastebin.com/L30u3tMu
>
> 32bit version:
>
> http://pastebin.com/tKVCTeZV
>
> This is what Clang produces for basically the same code:
>
> http://pastebin.com/JBcNupfs
>
> The C code looks like:
>
> http://pastebin.com/KS9QwB3A

That's a start. The relative offsets are missing from the calls though (I think), which makes it rather hard to decipher. What are you using to disassemble? "objdump -M intel -dr file.o" will give you more info. It's the standard linux tool for the job, available from macports.

Also, it would be good if you ran it with gdb, when it bus errors type 'disas' and post that. Then we'd be able to see what instruction it's occurring at (hopefully).

On 2013-04-14 23:55, John Colvin wrote:

> That's a start. The relative offsets are missing from the calls though
> (I think), which makes it rather hard to decipher. What are you using to
> disassemble? "objdump -M intel -dr file.o" will give you more info. It's
> the standard linux tool for the job, available from macports.

Ok, I used obj2asm.

> Also, it would be good if you ran it with gdb, when it bus errors type
> 'disas' and post that. Then we'd be able to see what instruction it's
> occurring at (hopefully).

Ok, I'll do that.

I just tried the same example on Mac OS X 10.6.3 and it runs fine. The assembly is basically the same.

I wasn't able to install objdump, I'll try again tonight. This what otool gives:

http://pastebin.com/N8hMiKDe

This is the man page for otool, if there any particular flags you want me to use:

http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/otool.1.html

-- 
/Jacob Carlborg

On Monday, 15 April 2013 at 07:22:08 UTC, Jacob Carlborg wrote:
> On 2013-04-14 23:55, John Colvin wrote:
>
>> That's a start. The relative offsets are missing from the calls though
>> (I think), which makes it rather hard to decipher. What are you using to
>> disassemble? "objdump -M intel -dr file.o" will give you more info. It's
>> the standard linux tool for the job, available from macports.
>
> Ok, I used obj2asm.
>
>> Also, it would be good if you ran it with gdb, when it bus errors type
>> 'disas' and post that. Then we'd be able to see what instruction it's
>> occurring at (hopefully).
>
> Ok, I'll do that.
>
> I just tried the same example on Mac OS X 10.6.3 and it runs fine. The assembly is basically the same.
>
> I wasn't able to install objdump, I'll try again tonight. This what otool gives:
>
> http://pastebin.com/N8hMiKDe
>
> This is the man page for otool, if there any particular flags you want me to use:
>
> http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/otool.1.html

That otool output is missing foo. Other than that the flags you're using are fine.

On Sunday, 14 April 2013 at 14:48:40 UTC, Jacob Carlborg wrote:
> This code:
>
> http://pastebin.com/U5XdFfDq
>
> Will result in a bus error when compiled as 32bit. Three ways the bus error won't happen:
>
> * If I compile as 64bit everything works fine
> * If the function "foo" is moved inline in the "main" function everything works fine
> * If store the return value of "fp" in "foo" in a temporary variable and then return it
>
> DMD 2.062
> Mac OS X 10.8.2

Casting a function that returns void to a function that returns something seems bound to cause trouble. While it may be allowed in C It seems a bit of a leap to assume that it would work properly in D.

On 2013-04-15 16:34, John Colvin wrote:

> That otool output is missing foo. Other than that the flags you're using
> are fine.

Hmm, I don't know why it didn't output "foo". This is the output from the executable:

http://pastebin.com/yJEpHaDH

The previous ones were from the object file.

-- 
/Jacob Carlborg