I'm working with Jacob to try to resolve an issue where D programs compiled on his Ubuntu box (in 32-bit/32-bit) error out on my Ubuntu box with "Illegal instruction". At first we thought it was because my OS was an older version than his. But he tried compiling on an older OS than mine and it still didn't work. So now I'm wondering if it may really be just like the message seems to imply: an illegal CPU instruction.

So my main question: Does DMD do anything like, say, detecting the CPU at compile time and then enabling instructions only available on that CPU and up? Or does it do anything like always assuming the target CPU has SSE2? Anything like that that could cause differences between our CPUs to result in object code that will work on one of the CPUs, but not the other? FWIW, the CPU on my linux box is i686, so it's not like I'm on some super-ultra-old i586, or anything like that.

On 2011-06-04 11:36, Nick Sabalausky wrote:
> I'm working with Jacob to try to resolve an issue where D programs compiled
> on his Ubuntu box (in 32-bit/32-bit) error out on my Ubuntu box with
> "Illegal instruction". At first we thought it was because my OS was an older
> version than his. But he tried compiling on an older OS than mine and it
> still didn't work. So now I'm wondering if it may really be just like the
> message seems to imply: an illegal CPU instruction.

Actually, the Ubuntu 6.06 box is 64bit. Don't remember if I compiled with a 32bit or 64bit DMD. But anyway, it works on my Ubuntu 11.04 box that is 32bit.

> So my main question: Does DMD do anything like, say, detecting the CPU at
> compile time and then enabling instructions only available on that CPU and
> up? Or does it do anything like always assuming the target CPU has SSE2?
> Anything like that that could cause differences between our CPUs to result
> in object code that will work on one of the CPUs, but not the other? FWIW,
> the CPU on my linux box is i686, so it's not like I'm on some
> super-ultra-old i586, or anything like that.

I'm having an Intel Core 2 Duo. Don't know if it helps but when I run the pre-compiled DMD on the 6.06 box I get an errors message similar to: "Floating point exception".

-- 
/Jacob Carlborg

If you run the program in GDB, can you disassemble when the error is given? That may give you the instruction the kernel is assasinating your process for.

Jacob Carlborg <doob@me.com> writes:
>
> I'm having an Intel Core 2 Duo. Don't know if it helps but when I run the pre-compiled DMD on the 6.06 box I get an errors message similar to: "Floating point exception".

A long shot, but this sounds like a problem I hit trying to run some C code binaries on an older system. Try googling for FPE and gnuhash. When binaries are built with a newer ld option --hash-style=gnu, running on systems with an older loader with fail wth an FPE. For backwards compatability you have to use --hash-style=both or sysv.

I don't use D on linux and don't know how it passes options to ld. You can use objdump to show if a .gnu.hash section is being used. And on older systems, the man page for ld won't list --hash-style.

-- 
Dan

Nick Sabalausky wrote:
> So my main question: Does DMD do anything like, say, detecting the CPU at compile time and then enabling instructions only available on that CPU and up? Or does it do anything like always assuming the target CPU has SSE2? Anything like that that could cause differences between our CPUs to result in object code that will work on one of the CPUs, but not the other? FWIW, the CPU on my linux box is i686, so it's not like I'm on some super-ultra-old i586, or anything like that. 

DMD itself doesn't, but the array operations do. The DMD backend is ancient, and generates code for original Pentiums (+ 64 bit equivalents of the same instructions).

"Don" <nospam@nospam.com> wrote in message news:isoh6c$15jb$1@digitalmars.com...
> Nick Sabalausky wrote:
>> So my main question: Does DMD do anything like, say, detecting the CPU at compile time and then enabling instructions only available on that CPU and up? Or does it do anything like always assuming the target CPU has SSE2? Anything like that that could cause differences between our CPUs to result in object code that will work on one of the CPUs, but not the other? FWIW, the CPU on my linux box is i686, so it's not like I'm on some super-ultra-old i586, or anything like that.
>
> DMD itself doesn't, but the array operations do. The DMD backend is ancient, and generates code for original Pentiums (+ 64 bit equivalents of the same instructions).

Is there any way to force the array operations down to a certain level? Or even better yet, have them detect the CPU at startup and then use the appropriate version?

On 6/4/2011 5:36 AM, Nick Sabalausky wrote:
> I'm working with Jacob to try to resolve an issue where D programs compiled
> on his Ubuntu box (in 32-bit/32-bit) error out on my Ubuntu box with
> "Illegal instruction". At first we thought it was because my OS was an older
> version than his. But he tried compiling on an older OS than mine and it
> still didn't work. So now I'm wondering if it may really be just like the
> message seems to imply: an illegal CPU instruction.
>
> So my main question: Does DMD do anything like, say, detecting the CPU at
> compile time and then enabling instructions only available on that CPU and
> up? Or does it do anything like always assuming the target CPU has SSE2?
> Anything like that that could cause differences between our CPUs to result
> in object code that will work on one of the CPUs, but not the other? FWIW,
> the CPU on my linux box is i686, so it's not like I'm on some
> super-ultra-old i586, or anything like that.
>
>

Couldn't you run it in GDB and find the instruction it doesn't like? I'm assuming it's a FPU instruction. Might help you discover where the missing check should be.

"Nick Sabalausky" <a@a.a> wrote in message news:isoltk$1ehd$1@digitalmars.com...
> "Don" <nospam@nospam.com> wrote in message news:isoh6c$15jb$1@digitalmars.com...
>> Nick Sabalausky wrote:
>>> So my main question: Does DMD do anything like, say, detecting the CPU at compile time and then enabling instructions only available on that CPU and up? Or does it do anything like always assuming the target CPU has SSE2? Anything like that that could cause differences between our CPUs to result in object code that will work on one of the CPUs, but not the other? FWIW, the CPU on my linux box is i686, so it's not like I'm on some super-ultra-old i586, or anything like that.
>>
>> DMD itself doesn't, but the array operations do. The DMD backend is ancient, and generates code for original Pentiums (+ 64 bit equivalents of the same instructions).
>
> Is there any way to force the array operations down to a certain level? Or even better yet, have them detect the CPU at startup and then use the appropriate version?
>

It would be a bad thing if we can't use an SSE2 CPU to compile a binary that'll work on a non-SSE2 machine.

"Bernard Helyer" <b.helyer@gmail.com> wrote in message news:isdgdc$m3a$1@digitalmars.com...
> If you run the program in GDB, can you disassemble when the error is given? That may give you the instruction the kernel is assasinating your process for.

I can try that if anyone can help walk me through it or at least point me to a good beginner's tutorial for gdb. I never use commandline debuggers, and I've never even touched gdb, so I don't have the slightest clue how to use it.

On Thu, Jun 9, 2011 at 5:58 PM, Nick Sabalausky <a@a.a> wrote:

> "Bernard Helyer" <b.helyer@gmail.com> wrote in message news:isdgdc$m3a$1@digitalmars.com...
> > If you run the program in GDB, can you disassemble when the error is given? That may give you the instruction the kernel is assasinating your process for.
>
> I can try that if anyone can help walk me through it or at least point me
> to
> a good beginner's tutorial for gdb. I never use commandline debuggers, and
> I've never even touched gdb, so I don't have the slightest clue how to use
> it.
>
>
> The short version is to run `gdb yourapp` which will get you into the GDB
shell. Then `run` to actually start the app. It will halt and return to the
shell when it hits the bad instruction, and you should type `disass` to view
the assembly code of the current function. There will be a pointer (->, I
think) pointing to the current instruction in the listing.
You can find GDB basics at http://www.cs.cmu.edu/~gilpin/tutorial/ although
that tutorial doesn't include `disass`. I mostly learned it by firing it up
and typing `help`  :D