Mac Intel

Mikael Pettersson mikpe@REDACTED
Sat Aug 12 12:16:58 CEST 2006

On Sat, 12 Aug 2006 02:50:41 +0100, Joel Reymont wrote:
>HiPE is sort of done but I'm using the open source mach_override code  
>and I still need to take care of the precise floating-point exception  
>code. Then again, FPE has nothing to do with HiPE.

Oh yes it does. Unless you disable floating-point code generation
by passing no_inline_fp to the HiPE compiler, HiPE will generate
code that relies on the floating-point exception mechanisms in the
runtime system. This is the case on x86, amd64, ppc32, and sparc32;
on arm floating-point is usually emulated by software so I enforce
no_inline_fp on arm.

>Test results below, both general and compiler. How do I interpret  
>these results? Which ones have to do with FPE?
>On Aug 10, 2006, at 12:35 PM, Mikael Pettersson wrote:
>> I assume you're working on the R11B-0 code base? If so, download
>> <>,
>> unpack the tarball, cd into it, and run ./ <path to  
>> your OTP directory>.
>1> <HiPE (v 3.5.5)> EXITED with reason {function_clause, 
>{hipe_main,rtl_ssa,2}]} @hipe:806
>*** In trivial_tests: trivial_13_new@REDACTED and trivial_13_old  

All of the failures appear to be similar to this one. The compiler
breaks in RTL before the code gets to the backend. This is not
expected and indicates that something is very broken. This test
case (trivial_13) does perform floating-point operations (a / and
a round) so the compiler must generate code for that, but no
floating-point exceptions should occur while it's doing this.

Is this message from the /tmp/hipe_test_log.${USER} file?

Sometimes you can get a better stack trace when compiling
interactively. 'cd' into tests/trivial_tests/ and start Erlang.
Then type 'c(trivial_13,[native]).' or 'hipe:c(trivial_13).'.

Do things work better with 'no_inline_fp'?

More information about the erlang-questions mailing list