OpenCores

OpenCores

or32-gcc: Current status + new version

no use

no use

1/1

no use

no use

or32-gcc: Current status + new version by Unknown on Dec 15, 2003			Not available!
Hi folks, there is more and more different versions of what should be just one version. An openrisc C/C++ compiler. Lets try to have a single compiler version that is used by everyone and if there is a bug, lets fix this single version. This way everybody will benefit from the concept of sharing development efforts in open source manner (reuse etc). It is essential that there is a common place where all the tools are available and to me it seems that openrisc web page on opencores is the best way, with all the source code actually be put in opencores cvs. If somebody wants to have their own version of the compiler, you can do that. But we should strive to have a common one for the majority of the community. regards, Damjan ----- Original Message ----- From: "Heiko Panther" <<A HREF="mailto:heiko.panther@web.de">heiko.panther@web.de</A>> To: <<A HREF="mailto:openrisc@opencores.org">openrisc@opencores.org</A>> Sent: Wednesday, December 17, 2003 10:17 PM Subject: [openrisc] or32-gcc: Current status + new version [q] Hi folks, there has been some confusion about the various gcc compilers and their respective bugs or features. I did some research and a lot of experimenting, and here's my summary. Testing objectives - I tested if the optimization (-O2) works by running eCos, which has in the past produced errors in printf()-like routines when the compiler had -O2 enabled. - I checked if the gcc could build newlib (important for the folks who don't run eCos or other OSes which include a libc). To achieve this, I created symbolic links for newlib and libgloss from the newlib dir into the gcc dir, and used the gcc --with-newlib configure option. - Since it's important for me, I checked for availability of the -msoft-mul flag. - Lastly, I compiled my app, which includes eCos and a user application, and noted down the binary size, compiled with -O2. Compilers that produce buggy code with -O2 weren't checked. Test results opencores(oc) gcc-3.2.3 -O2 buggy. Builds newlib. Has -msoft-mul. oc-gcc-3.2.3 Scott Furman version Scott sent me his modification, which includes an ABI change. This means you have to recompile everything, including libs, for use with this. Scott says this modified ABI is faster, too. When I built my app with this, it wouldn't come up - eCos died while doing the static constructors. Didn't yet check why that happened. Builds newlib. Has -msoft-mul. Binary size: 420k. University Cantabria (uc) gcc-3.4 Is built with a developmental version of gcc-3.4, which is probably the reason for not building newlib and the large binary size. Fixes the -O2 bug without changing the ABI. Can't build newlib. Doesn't have -msoft-mul. Binary size: 470k. New version Based on this, I decided to put a new gcc together, taking the target config from uc-gcc-3.4 and putting it into oc-gcc-3.2.3. I added the -msoft-mul support from oc-gcc-3.2.3. No ABI change. newlib has to be installed seperately (cd to newlib subdir of gcc build dir and make install). -O2 working. Builds newlib. Has -msoft-mul. Binary size: 385k. So, with this, we should have a reliably working and optimizing compiler. The files and instructions are at <A HREF="http://homepage.mac.com/hpanther/gcc-3.2.3-oc-to-uc-patch.tgz">http://homepage.mac.com/hpanther/gcc-3.2.3-oc-to-uc-patch.tgz</A> I invite you to try and build you apps and OSes with this version. If everyone is satisfied (or no one complains, whichever happens first), I shall put the files into CVS (given that I'm granted CVS write access, wink wink. Otherwise, maybe one of the opencores maintainers will do[/q] that). [q] Heiko _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A>[/q] Hi folks, there is more and more different versions of what should be just one version. An openrisc C/C++ compiler. Lets try to have a single compiler version that is used by everyone and if there is a bug, lets fix this single version. This way everybody will benefit from the concept of sharing development efforts in open source manner (reuse etc). It is essential that there is a common place where all the tools are available and to me it seems that openrisc web page on opencores is the best way, with all the source code actually be put in opencores cvs. If somebody wants to have their own version of the compiler, you can do that. But we should strive to have a common one for the majority of the community. regards, Damjan ----- Original Message ----- From: "Heiko Panther" heiko.panther@web.de> To: openrisc@opencores.org> Sent: Wednesday, December 17, 2003 10:17 PM Subject: [openrisc] or32-gcc: Current status + new version Hi folks, there has been some confusion about the various gcc compilers and their respective bugs or features. I did some research and a lot of experimenting, and here's my summary. Testing objectives - I tested if the optimization (-O2) works by running eCos, which has in the past produced errors in printf()-like routines when the compiler had -O2 enabled. - I checked if the gcc could build newlib (important for the folks who don't run eCos or other OSes which include a libc). To achieve this, I created symbolic links for newlib and libgloss from the newlib dir into the gcc dir, and used the gcc --with-newlib configure option. - Since it's important for me, I checked for availability of the -msoft-mul flag. - Lastly, I compiled my app, which includes eCos and a user application, and noted down the binary size, compiled with -O2. Compilers that produce buggy code with -O2 weren't checked. Test results opencores(oc) gcc-3.2.3 -O2 buggy. Builds newlib. Has -msoft-mul. oc-gcc-3.2.3 Scott Furman version Scott sent me his modification, which includes an ABI change. This means you have to recompile everything, including libs, for use with this. Scott says this modified ABI is faster, too. When I built my app with this, it wouldn't come up - eCos died while doing the static constructors. Didn't yet check why that happened. Builds newlib. Has -msoft-mul. Binary size: 420k. University Cantabria (uc) gcc-3.4 Is built with a developmental version of gcc-3.4, which is probably the reason for not building newlib and the large binary size. Fixes the -O2 bug without changing the ABI. Can't build newlib. Doesn't have -msoft-mul. Binary size: 470k. New version Based on this, I decided to put a new gcc together, taking the target config from uc-gcc-3.4 and putting it into oc-gcc-3.2.3. I added the -msoft-mul support from oc-gcc-3.2.3. No ABI change. newlib has to be installed seperately (cd to newlib subdir of gcc build dir and make install). -O2 working. Builds newlib. Has -msoft-mul. Binary size: 385k. So, with this, we should have a reliably working and optimizing compiler. The files and instructions are at http://homepage.mac.com/hpanther/gcc-3.2.3-oc-to-uc-patch.tgz I invite you to try and build you apps and OSes with this version. If everyone is satisfied (or no one complains, whichever happens first), I shall put the files into CVS (given that I'm granted CVS write access, wink wink. Otherwise, maybe one of the opencores maintainers will do that). Heiko _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

or32-gcc: Current status + new version by Unknown on Dec 17, 2003			Not available!
Hi folks, there has been some confusion about the various gcc compilers and their respective bugs or features. I did some research and a lot of experimenting, and here's my summary. Testing objectives - I tested if the optimization (-O2) works by running eCos, which has in the past produced errors in printf()-like routines when the compiler had -O2 enabled. - I checked if the gcc could build newlib (important for the folks who don't run eCos or other OSes which include a libc). To achieve this, I created symbolic links for newlib and libgloss from the newlib dir into the gcc dir, and used the gcc --with-newlib configure option. - Since it's important for me, I checked for availability of the -msoft-mul flag. - Lastly, I compiled my app, which includes eCos and a user application, and noted down the binary size, compiled with -O2. Compilers that produce buggy code with -O2 weren't checked. Test results opencores(oc) gcc-3.2.3 -O2 buggy. Builds newlib. Has -msoft-mul. oc-gcc-3.2.3 Scott Furman version Scott sent me his modification, which includes an ABI change. This means you have to recompile everything, including libs, for use with this. Scott says this modified ABI is faster, too. When I built my app with this, it wouldn't come up - eCos died while doing the static constructors. Didn't yet check why that happened. Builds newlib. Has -msoft-mul. Binary size: 420k. University Cantabria (uc) gcc-3.4 Is built with a developmental version of gcc-3.4, which is probably the reason for not building newlib and the large binary size. Fixes the -O2 bug without changing the ABI. Can't build newlib. Doesn't have -msoft-mul. Binary size: 470k. New version Based on this, I decided to put a new gcc together, taking the target config from uc-gcc-3.4 and putting it into oc-gcc-3.2.3. I added the -msoft-mul support from oc-gcc-3.2.3. No ABI change. newlib has to be installed seperately (cd to newlib subdir of gcc build dir and make install). -O2 working. Builds newlib. Has -msoft-mul. Binary size: 385k. So, with this, we should have a reliably working and optimizing compiler. The files and instructions are at <A HREF="http://homepage.mac.com/hpanther/gcc-3.2.3-oc-to-uc-patch.tgz">http://homepage.mac.com/hpanther/gcc-3.2.3-oc-to-uc-patch.tgz</A> I invite you to try and build you apps and OSes with this version. If everyone is satisfied (or no one complains, whichever happens first), I shall put the files into CVS (given that I'm granted CVS write access, wink wink. Otherwise, maybe one of the opencores maintainers will do that). Heiko Hi folks, there has been some confusion about the various gcc compilers and their respective bugs or features. I did some research and a lot of experimenting, and here's my summary. Testing objectives - I tested if the optimization (-O2) works by running eCos, which has in the past produced errors in printf()-like routines when the compiler had -O2 enabled. - I checked if the gcc could build newlib (important for the folks who don't run eCos or other OSes which include a libc). To achieve this, I created symbolic links for newlib and libgloss from the newlib dir into the gcc dir, and used the gcc --with-newlib configure option. - Since it's important for me, I checked for availability of the -msoft-mul flag. - Lastly, I compiled my app, which includes eCos and a user application, and noted down the binary size, compiled with -O2. Compilers that produce buggy code with -O2 weren't checked. Test results opencores(oc) gcc-3.2.3 -O2 buggy. Builds newlib. Has -msoft-mul. oc-gcc-3.2.3 Scott Furman version Scott sent me his modification, which includes an ABI change. This means you have to recompile everything, including libs, for use with this. Scott says this modified ABI is faster, too. When I built my app with this, it wouldn't come up - eCos died while doing the static constructors. Didn't yet check why that happened. Builds newlib. Has -msoft-mul. Binary size: 420k. University Cantabria (uc) gcc-3.4 Is built with a developmental version of gcc-3.4, which is probably the reason for not building newlib and the large binary size. Fixes the -O2 bug without changing the ABI. Can't build newlib. Doesn't have -msoft-mul. Binary size: 470k. New version Based on this, I decided to put a new gcc together, taking the target config from uc-gcc-3.4 and putting it into oc-gcc-3.2.3. I added the -msoft-mul support from oc-gcc-3.2.3. No ABI change. newlib has to be installed seperately (cd to newlib subdir of gcc build dir and make install). -O2 working. Builds newlib. Has -msoft-mul. Binary size: 385k. So, with this, we should have a reliably working and optimizing compiler. The files and instructions are at http://homepage.mac.com/hpanther/gcc-3.2.3-oc-to-uc-patch.tgz I invite you to try and build you apps and OSes with this version. If everyone is satisfied (or no one complains, whichever happens first), I shall put the files into CVS (given that I'm granted CVS write access, wink wink. Otherwise, maybe one of the opencores maintainers will do that). Heiko

or32-gcc: Current status + new version by Unknown on Dec 17, 2003			Not available!
Great work! I'm going to try your patches on uClinux & linux and if it builds them i'm all for merging it into opencores mainline. The binary size savings are nice too. I'd like to caution you about -msoft-mul. I've only briefly checked it after i've implemented it but i didn't do any extensive testing. It should work ok, but don't count on it. ;) The toolchain issue reamaining i know of is ld with -r flag. I tried the Scott patches but the linker then just core dumped. I didn't have time to really look into it... I'll fix this as soon as i have some time since many bugs i saw that look like gcc are actually because of linker. i'm also interested why you say that opencores gcc with -O2 is buggy. i tried building linux & uclinux with it and it worked just as good as with -O flag. can you provide some more details... best regards, p. * Heiko Panther (<A HREF="mailto:heiko.panther@web.de">heiko.panther@web.de</A>) wrote: [q] Hi folks, there has been some confusion about the various gcc compilers and their respective bugs or features. I did some research and a lot of experimenting, and here's my summary. Testing objectives - I tested if the optimization (-O2) works by running eCos, which has in the past produced errors in printf()-like routines when the compiler had -O2 enabled. - I checked if the gcc could build newlib (important for the folks who don't run eCos or other OSes which include a libc). To achieve this, I created symbolic links for newlib and libgloss from the newlib dir into the gcc dir, and used the gcc --with-newlib configure option. - Since it's important for me, I checked for availability of the -msoft-mul flag. - Lastly, I compiled my app, which includes eCos and a user application, and noted down the binary size, compiled with -O2. Compilers that produce buggy code with -O2 weren't checked. Test results opencores(oc) gcc-3.2.3 -O2 buggy. Builds newlib. Has -msoft-mul. oc-gcc-3.2.3 Scott Furman version Scott sent me his modification, which includes an ABI change. This means you have to recompile everything, including libs, for use with this. Scott says this modified ABI is faster, too. When I built my app with this, it wouldn't come up - eCos died while doing the static constructors. Didn't yet check why that happened. Builds newlib. Has -msoft-mul. Binary size: 420k. University Cantabria (uc) gcc-3.4 Is built with a developmental version of gcc-3.4, which is probably the reason for not building newlib and the large binary size. Fixes the -O2 bug without changing the ABI. Can't build newlib. Doesn't have -msoft-mul. Binary size: 470k. New version Based on this, I decided to put a new gcc together, taking the target config from uc-gcc-3.4 and putting it into oc-gcc-3.2.3. I added the -msoft-mul support from oc-gcc-3.2.3. No ABI change. newlib has to be installed seperately (cd to newlib subdir of gcc build dir and make install). -O2 working. Builds newlib. Has -msoft-mul. Binary size: 385k. So, with this, we should have a reliably working and optimizing compiler. The files and instructions are at <A HREF="http://homepage.mac.com/hpanther/gcc-3.2.3-oc-to-uc-patch.tgz">http://homepage.mac.com/hpanther/gcc-3.2.3-oc-to-uc-patch.tgz</A> I invite you to try and build you apps and OSes with this version. If everyone is satisfied (or no one complains, whichever happens first), I shall put the files into CVS (given that I'm granted CVS write access, wink wink. Otherwise, maybe one of the opencores maintainers will do that). Heiko[/q] Great work! I'm going to try your patches on uClinux & linux and if it builds them i'm all for merging it into opencores mainline. The binary size savings are nice too. I'd like to caution you about -msoft-mul. I've only briefly checked it after i've implemented it but i didn't do any extensive testing. It should work ok, but don't count on it. ;) The toolchain issue reamaining i know of is ld with -r flag. I tried the Scott patches but the linker then just core dumped. I didn't have time to really look into it... I'll fix this as soon as i have some time since many bugs i saw that look like gcc are actually because of linker. i'm also interested why you say that opencores gcc with -O2 is buggy. i tried building linux & uclinux with it and it worked just as good as with -O flag. can you provide some more details... best regards, p. * Heiko Panther (heiko.panther@web.de) wrote: Hi folks, there has been some confusion about the various gcc compilers and their respective bugs or features. I did some research and a lot of experimenting, and here's my summary. Testing objectives - I tested if the optimization (-O2) works by running eCos, which has in the past produced errors in printf()-like routines when the compiler had -O2 enabled. - I checked if the gcc could build newlib (important for the folks who don't run eCos or other OSes which include a libc). To achieve this, I created symbolic links for newlib and libgloss from the newlib dir into the gcc dir, and used the gcc --with-newlib configure option. - Since it's important for me, I checked for availability of the -msoft-mul flag. - Lastly, I compiled my app, which includes eCos and a user application, and noted down the binary size, compiled with -O2. Compilers that produce buggy code with -O2 weren't checked. Test results opencores(oc) gcc-3.2.3 -O2 buggy. Builds newlib. Has -msoft-mul. oc-gcc-3.2.3 Scott Furman version Scott sent me his modification, which includes an ABI change. This means you have to recompile everything, including libs, for use with this. Scott says this modified ABI is faster, too. When I built my app with this, it wouldn't come up - eCos died while doing the static constructors. Didn't yet check why that happened. Builds newlib. Has -msoft-mul. Binary size: 420k. University Cantabria (uc) gcc-3.4 Is built with a developmental version of gcc-3.4, which is probably the reason for not building newlib and the large binary size. Fixes the -O2 bug without changing the ABI. Can't build newlib. Doesn't have -msoft-mul. Binary size: 470k. New version Based on this, I decided to put a new gcc together, taking the target config from uc-gcc-3.4 and putting it into oc-gcc-3.2.3. I added the -msoft-mul support from oc-gcc-3.2.3. No ABI change. newlib has to be installed seperately (cd to newlib subdir of gcc build dir and make install). -O2 working. Builds newlib. Has -msoft-mul. Binary size: 385k. So, with this, we should have a reliably working and optimizing compiler. The files and instructions are at http://homepage.mac.com/hpanther/gcc-3.2.3-oc-to-uc-patch.tgz I invite you to try and build you apps and OSes with this version. If everyone is satisfied (or no one complains, whichever happens first), I shall put the files into CVS (given that I'm granted CVS write access, wink wink. Otherwise, maybe one of the opencores maintainers will do that). Heiko

or32-gcc: Current status + new version by Unknown on Dec 18, 2003			Not available!
Matjaz, > i'm also interested why you say that opencores gcc with -O2 is > buggy. i tried building linux & uclinux with it and it worked just as > good > as with -O flag. can you provide some more details... The problems I've seen happen with double integer types. eCos uses them a lot. Maybe uclinux does not? Anyway, I have an OS-less test case here: <A HREF="http://www.opencores.org/forums/openrisc/2003/11/00023">http://www.opencores.org/forums/openrisc/2003/11/00023</A> It will need some editing, since it's for my platform, but you should be able to reproduce it. With -O2 the function will not work. There is a // for(i=0; i<5; i++); which, when you remove the comment mark, will also make the error disappear. Sorry, but I didn't resolve what exactly goes wrong, it's just a test case to see if it works or not. Heiko Matjaz, > i'm also interested why you say that opencores gcc with -O2 is > buggy. i tried building linux & uclinux with it and it worked just as > good > as with -O flag. can you provide some more details... The problems I've seen happen with double integer types. eCos uses them a lot. Maybe uclinux does not? Anyway, I have an OS-less test case here: http://www.opencores.org/forums/openrisc/2003/11/00023 It will need some editing, since it's for my platform, but you should be able to reproduce it. With -O2 the function will not work. There is a // for(i=0; i

or32-gcc: Current status + new version by Unknown on Dec 18, 2003			Not available!
* Heiko Panther (<A HREF="mailto:heiko.panther@web.de">heiko.panther@web.de</A>) wrote: [q] Matjaz, [q]> i'm also interested why you say that opencores gcc with -O2 is > buggy. i tried building linux & uclinux with it and it worked just as > good > as with -O flag. can you provide some more details...[/q] The problems I've seen happen with double integer types. eCos uses them a lot. Maybe uclinux does not?[/q] Ok, this one i knew of. But when i tried it in linux it didn't work even with just -O, that's why i asked... regards, m. * Heiko Panther (heiko.panther@web.de) wrote: Matjaz, > i'm also interested why you say that opencores gcc with -O2 is > buggy. i tried building linux & uclinux with it and it worked just as > good > as with -O flag. can you provide some more details... The problems I've seen happen with double integer types. eCos uses them a lot. Maybe uclinux does not? Ok, this one i knew of. But when i tried it in linux it didn't work even with just -O, that's why i asked... regards, m.

or32-gcc: Current status + new version by Unknown on Dec 27, 2003			Not available!
[q] The problems I've seen happen with double integer types. eCos uses them a lot.[/q] I've have problems with 64-bit types (unsigned long long) also with GCC3.2.x and GCC3.3.x, this when compiling ARM-code with arm-elf-gcc target and -O2. I think its the GCC optimizer that is buggy, not especially OR related maybe. I think that what happened when compiling 64-bit arithmetic for an 32-bit processor, the operation is divided into two 32-bit instructions. The optimizer seems to allow reordering of the latter instruction, which in some cases can cause that the 64-bit result is used before its completely calculated. Only the first 32-bit half is done when its used. It would be interesting to compile your sample code also for other GCC-targets. Maybe this is something rather for the GCC-team to look into? Best Regards, /Fredrik Hederstierna The problems I've seen happen with double integer types. eCos uses them a lot. I've have problems with 64-bit types (unsigned long long) also with GCC3.2.x and GCC3.3.x, this when compiling ARM-code with arm-elf-gcc target and -O2. I think its the GCC optimizer that is buggy, not especially OR related maybe. I think that what happened when compiling 64-bit arithmetic for an 32-bit processor, the operation is divided into two 32-bit instructions. The optimizer seems to allow reordering of the latter instruction, which in some cases can cause that the 64-bit result is used before its completely calculated. Only the first 32-bit half is done when its used. It would be interesting to compile your sample code also for other GCC-targets. Maybe this is something rather for the GCC-team to look into? Best Regards, /Fredrik Hederstierna

or32-gcc: Current status + new version by Unknown on Dec 28, 2003			Not available!
I've applied the patch that should resolve this. can you confirm this problem still exists in most recent gcc-3.2.3 from opencores cvs ? regards, p. * <A HREF="mailto:fredrik@wespot.com">fredrik@wespot.com</A> (<A HREF="mailto:fredrik@wespot.com">fredrik@wespot.com</A>) wrote: [q]> The problems I've seen happen with double integer types. eCos uses > them > a lot.[/q] I've have problems with 64-bit types (unsigned long long) also with GCC3.2.x and GCC3.3.x, this when compiling ARM-code with arm-elf-gcc target and -O2. I think its the GCC optimizer that is buggy, not especially OR related maybe. I think that what happened when compiling 64-bit arithmetic for an 32-bit processor, the operation is divided into two 32-bit instructions. The optimizer seems to allow reordering of the latter instruction, which in some cases can cause that the 64-bit result is used before its completely calculated. Only the first 32-bit half is done when its used. It would be interesting to compile your sample code also for other GCC-targets. Maybe this is something rather for the GCC-team to look into? Best Regards, /Fredrik Hederstierna _______________________________________________ <A HREF="http://www.opencores.org/mailman/listinfo/openrisc">http://www.opencores.org/mailman/listinfo/openrisc</A>[/q] I've applied the patch that should resolve this. can you confirm this problem still exists in most recent gcc-3.2.3 from opencores cvs ? regards, p. * fredrik@wespot.com (fredrik@wespot.com) wrote: > The problems I've seen happen with double integer types. eCos uses > them > a lot. I've have problems with 64-bit types (unsigned long long) also with GCC3.2.x and GCC3.3.x, this when compiling ARM-code with arm-elf-gcc target and -O2. I think its the GCC optimizer that is buggy, not especially OR related maybe. I think that what happened when compiling 64-bit arithmetic for an 32-bit processor, the operation is divided into two 32-bit instructions. The optimizer seems to allow reordering of the latter instruction, which in some cases can cause that the 64-bit result is used before its completely calculated. Only the first 32-bit half is done when its used. It would be interesting to compile your sample code also for other GCC-targets. Maybe this is something rather for the GCC-team to look into? Best Regards, /Fredrik Hederstierna _______________________________________________ http://www.opencores.org/mailman/listinfo/openrisc

or32-gcc: Current status + new version by Unknown on Dec 29, 2003			Not available!
<A HREF="mailto:fredrik@wespot.com">fredrik@wespot.com</A> wrote: [q] I've have problems with 64-bit types (unsigned long long) also with GCC3.2.x and GCC3.3.x, this when compiling ARM-code with arm-elf-gcc target and -O2. I think its the GCC optimizer that is buggy, not especially OR related maybe.[/q] Not sure about that. The bugs we're seeing are most certainly not there on other, more mainstream gcc platforms, such as powerpc or x86. Someone would have noticed. [q] I think that what happened when compiling 64-bit arithmetic for an 32-bit processor, the operation is divided into two 32-bit instructions. The optimizer seems to allow reordering of the latter instruction, which in some cases can cause that the 64-bit result is used before its completely calculated. Only the first 32-bit half is done when its used.[/q] That could well be a bug in the ARM target code for gcc. You specify stuff like that there. [q] It would be interesting to compile your sample code also for other GCC-targets. Maybe this is something rather for the GCC-team to look into?[/q] If you can reproduce it for other targets, that would be most interesting. Keep us posted. On a related note, I was planning to fiddle with our target config more. Those who did that before, what tools did you use to assert that your modified target config was working correctly? Anyone used the gcc test cases? Anyone used DejaGNU? Regards, Heiko fredrik@wespot.com wrote: I've have problems with 64-bit types (unsigned long long) also with GCC3.2.x and GCC3.3.x, this when compiling ARM-code with arm-elf-gcc target and -O2. I think its the GCC optimizer that is buggy, not especially OR related maybe. Not sure about that. The bugs we're seeing are most certainly not there on other, more mainstream gcc platforms, such as powerpc or x86. Someone would have noticed. I think that what happened when compiling 64-bit arithmetic for an 32-bit processor, the operation is divided into two 32-bit instructions. The optimizer seems to allow reordering of the latter instruction, which in some cases can cause that the 64-bit result is used before its completely calculated. Only the first 32-bit half is done when its used. That could well be a bug in the ARM target code for gcc. You specify stuff like that there. It would be interesting to compile your sample code also for other GCC-targets. Maybe this is something rather for the GCC-team to look into? If you can reproduce it for other targets, that would be most interesting. Keep us posted. On a related note, I was planning to fiddle with our target config more. Those who did that before, what tools did you use to assert that your modified target config was working correctly? Anyone used the gcc test cases? Anyone used DejaGNU? Regards, Heiko

or32-gcc: Current status + new version by Unknown on Dec 29, 2003			Not available!
* Heiko Panther (<A HREF="mailto:heiko.panther@web.de">heiko.panther@web.de</A>) wrote: [q] <A HREF="mailto:fredrik@wespot.com">fredrik@wespot.com</A> wrote: On a related note, I was planning to fiddle with our target config more. Those who did that before, what tools did you use to assert that your modified target config was working correctly? Anyone used the gcc test cases? Anyone used DejaGNU?[/q] it would be really nice if you could commit all the enhancments into opencores cvs. also making all the gcc torture tests pass & test or32/gcc with it would be very welcome. if you'll make an automated script or similar you can just send it to me and i'll look into integrating it into ATS (automated test system) on opencores cvs... best regards, m. * Heiko Panther (heiko.panther@web.de) wrote: fredrik@wespot.com wrote: On a related note, I was planning to fiddle with our target config more. Those who did that before, what tools did you use to assert that your modified target config was working correctly? Anyone used the gcc test cases? Anyone used DejaGNU? it would be really nice if you could commit all the enhancments into opencores cvs. also making all the gcc torture tests pass & test or32/gcc with it would be very welcome. if you'll make an automated script or similar you can just send it to me and i'll look into integrating it into ATS (automated test system) on opencores cvs... best regards, m.

no use

no use

1/1

no use

no use

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.