Hello,

as soon as I try to compile SW with float values using the -mhard-float option, I receive an internal compiler error. If I compile the code without the option it works fine, but I have no floating point instructions lf.* in my code.

The error is the following:

or32-elf-gcc -c -mboard=or1ksim -mnewlib -mhard-mul -mhard-div -mhard-float -O0 -g -I../utils_simdebug -I../bootcode -I/usr/local/research/projects/SystemDesign/tools/openrisc/gnu-toolchain2/or32-elf/include sw_main.c
sw_main.c: In function �manual_abs�:
sw_main.c:107:6: internal compiler error: in copy_to_mode_reg, at explow.c:635
Please submit a full bug report,
with preprocessed source if appropriate.
See " target="_blank">http://www.opencores.org/> for instructions.
make: *** [sw_main.o] Error 1

The function, which the error is reported on, is rather simple:


#include "defs.h"
#include "math.h"
...

float manual_abs(float x)
{
float y;

if(x else y= x;
return y;
}

...

If I comment out this function, the same error is reported on the next function that includes float values. Maybe someone has an idea what goes wrong, because I have some hard time figuring out why this does not work. I hope I just forgot to set some other flag correctly.
I am grateful for any ideas, where to start looking for a solution.

Regards,
Daniel

Hi Daniel,

Are you using the latest version of GCC 4.5.1 from OpenCores SVN?

That is the most robustly tested version of GCC (the newer 4.8 version is still under development). I don't know to what extent the hardware FP support was tested.

Would you post a bug report in Bugzilla, so we can make sure it is tracked. There is no one actively working on the stable GCC 4.5.1 release, so I can't promise an early fix.

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

Hi Jeremy, hi all,

we use: gcc version 4.5.1-or32-1.0rc4 (OpenRISC 32-bit toolchain for or32-elf (built 20111116))

We advanced a little by ourselves yesterday.
The problem is located in the comparison of two float values such as if (x ≥ 0) for which x is a float value.
It seems our used GCC version does not support the comparison float instructions.

Or1ksim implements single precision float comparison instructions such as lf.sfne.s.
I haven't looked at the RTL code yet, but I assume they might be supported there, too.

So basically, we just can't compile c code that uses conditions on float.
We can use arithmetic operations on float though and these are compiled just fine.

We will try a workaround and make our own comparison functions by either using assembler
(if the floating point comparison instructions are supported by the RTL code) or by implementing them in c and compiling the code without the -mhard-float option, which then makes the float comparison in software. We can link it with the rest of the code that uses the -mhard-float option such that we can do the arithmetic floating point operations still in hardware.

The code above would then look basically like this: if(custom_float_ge(x,0))
If somebody else has some other good idea or is interested in our code, please let me know.

Regards,
Daniel

Hi Daniel

That seems pretty up to date to me. SVN might have some tiny differences, but I doubt affecting your area of interest.

By this, I take it you mean the use of hardware float comparison. The compiler with software float passed regression, and I am sure that would ahve tested comparison instructions.

I'm not an expert on the RTL of the FPU. Perhaps someone else could answer that.

This looks like a reasonable approach, but you really need hardware floating point properly implemented. The alternative is to use software floating point and provide inline functions to use the hardware floating point instructions.

The problem is that working on GCC is very complex, so there are relatively few hobbyists who do it. My company (Embecosm, www.embecosm.com) provides such services on a commercial basis. When time permits we contribute pro bono to the OpenRISC project, but I can't give any commitment to providing this hardware floating point support at present.

Best wishes,

Jeremy

Thank you for the fast reply.

You are right, the software float comparison works just fine.
The problem is that when you compile for the hardware floating point unit with -mhard-float
the compiler does not mix soft float comparison with hard float arithmetic operations but reports the above error.
I am not sure if this is a real bug or just a missing feature to support hard float comparison. But I can report it in the bugzilla when desired.

Our workaround works for now. We keep the soft float comparisons in separate functions and link those with the program. the idea of using inline functions is also very good. I think we will explore it.
If we get new results I will report on it.

Thank you again and best regards,
Daniel

Of course this is a bug, even if some construct wouldn't be supported
by hardware, it should fall-back to a soft solution even if hard-float
switch is turned on.

Regardless of that, your example in your first message is mangled
by the brain-dead forum-software, and all my efforts to reconstruct
it to give an internal compiler error have failed.

Hello,

Daniel and me have some new results for the FPU using inline assembler. Our work-around with the HW FPU is in the attachment.

I will reported the bug.

Best regards,

To reconstruct the error, the code attached gives an internal compile error using the HW FPU resulting from the floating point comparison.

I still can't reproduce the bug with a toolchain built from ToT of SVN,
_but_ I see the ICE when trying to compile with the experimental 4.8.0 toolchain.
I have yet to compare what differs, but did you try to build a toolchain from SVN?

Ok, mystery solved, this issue was fixed by SVN commit 663
"Fix a bug with hardware floating point in GCC."

Thank you very much for this hint.
Our working copy of the SVN is at revision 811,
but maybe we did the installation from an older revision and did not update it.
I'll run a fresh installation of the gcc tool chain and check if it is working then.

I rebuilt the tool chain from revision 811:
>svn info
Path: .
URL: http://opencores.org/ocsvn/openrisc/openrisc/trunk/gnu-src
Repository Root: http://opencores.org/ocsvn/openrisc
Repository UUID: 04c7f051-eaf3-4997-922d-f29d9d8c0f3f
Revision: 811
Node Kind: directory
Schedule: normal
Last Changed Author: jeremybennett
Last Changed Rev: 681
Last Changed Date: 2012-02-29 20:20:33 +0100 (Wed, 29 Feb 2012)

Still ,the internal compiler error persists. It is reported for any code with if statement on floating point values that is compiled with the -mhard-float option.

Is there any option you have to set while building the toolchain?
I uses the standard command from the opencores website:
./bld-all.sh --force --prefix ${our_path1}/openrisc --or1ksim-dir ${our_path2}/or1ksim --uclibc-dir uClibc --linux-dir linux

Hi Daniel

It is very strange that you still see the error, but stekern can't reproduce it. Could you check that you really are picking up your new build of gcc, by running or32-elf-gcc --version.

Thanks,

Jeremy

Hi Jeremy,

thank you for the suggestion: The version is:
or32-elf-gcc (OpenRISC 32-bit toolchain for or32-elf (built 20111116)) 4.5.1-or32-1.0rc4 Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Is this what it is supposed to be?

Daniel

Hi Daniel,

I think this reveals the problem. It is reporting that it was built on 20111116, i.e. 16th November 2011. Yet your ealier post says you have just rebuilt it, so I would expect a built date of something like 20120716!

I think you are almost certainly picking up an old version on your search path. You could try which or32-elf-gcc to find out where you are picking it up from. The use ls `which or32-elf-gcc` to find out when that file was created.

You'll need to make sure your PATH is pointing at the version you have just built.

HTH

Jeremy