[detail] sparc v8plus build problem
I have a strange build error when compiling for sparc solaris. In particular there are errors of the form: error: cannot use v8plus instructions in a non-v8plus target binary After a bit of digging the error is coming from the compare_and_swap function in boost/detail/sp_counted_base_gcc_sparc.hpp This function has some inline assembly that uses the "cas" (compare and swap) opcode. The sparc assembler is effectively complaining that the instruction isn't supported. If I manually hack the Makefile to give -sBUILD='<instruction-set>v9' to bjam then everything compiles properly. I think that boost/detail/sp_counted_base.hpp has a problem in the lines #elif defined(__GNUC__) && ( defined( __sparcv8 ) || defined( __sparcv9 ) ) # include <boost/detail/sp_counted_base_gcc_sparc.hpp> The cas instruction is supported on the sparc v8plus and v9. Support for just sparc v8 is inadequate. In that case you need to use the swap instruction and some looping to do something similar to a cas. Another wrinkle is that just removing the defined(__sparcv8) from the above condition doesn't quite do the right thing with gcc. From what I can tell gcc is setting __sparcv8 even if -mcpu=v9 is specified. I have a v9 processor but I'm running 32 bit solaris so could gcc be basing the __sparcv8/v9 defines on the OS rather than the cpu type? The biggest difference between the v8 and v9 cpus is 64bit support. Thanks, -glenn
Glenn Schrader wrote:
The cas instruction is supported on the sparc v8plus and v9. Support for just sparc v8 is inadequate. In that case you need to use the swap instruction and some looping to do something similar to a cas. Another wrinkle is that just removing the defined(__sparcv8) from the above condition doesn't quite do the right thing with gcc. From what I can tell gcc is setting __sparcv8 even if -mcpu=v9 is specified. I have a v9 processor but I'm running 32 bit solaris so could gcc be basing the __sparcv8/v9 defines on the OS rather than the cpu type? The biggest difference between the v8 and v9 cpus is 64bit support.
The problem is that some versions of GCC are setting the v9 macro only in 64-bit builds (probably because of existing code that makes this assumption) and I'm not sure what we can do about that. Is __sparcv8plus defined for you? It's the right macro in principle, but I suspect that it's not being used because it doesn't work.
Peter Dimov wrote:
Glenn Schrader wrote:
The cas instruction is supported on the sparc v8plus and v9. Support for just sparc v8 is inadequate. In that case you need to use the swap instruction and some looping to do something similar to a cas. Another wrinkle is that just removing the defined(__sparcv8) from the above condition doesn't quite do the right thing with gcc. From what I can tell gcc is setting __sparcv8 even if -mcpu=v9 is specified. I have a v9 processor but I'm running 32 bit solaris so could gcc be basing the __sparcv8/v9 defines on the OS rather than the cpu type? The biggest difference between the v8 and v9 cpus is 64bit support.
The problem is that some versions of GCC are setting the v9 macro only in 64-bit builds (probably because of existing code that makes this assumption) and I'm not sure what we can do about that. Peter,
Is __sparcv8plus defined for you? It's the right macro in principle, but I suspect that it's not being used because it doesn't work. The only macro that gets defined is __sparcv8. I also haven't found a
That is consistent with the behavior that I'm seeing with gcc 4.1.1. direct way to tell gcc that the cpu is a v8plus. For instance -mcpu=v8plus doesn't work. If GCC itself is currently broken in this regard and we'll have to live with it (for now) then there should be a note in the build procedure on how to do a successful build. Thanks much, -glenn
Glenn Schrader wrote:
The only macro that gets defined is __sparcv8. I also haven't found a direct way to tell gcc that the cpu is a v8plus. For instance -mcpu=v8plus doesn't work.
If GCC itself is currently broken in this regard and we'll have to live with it (for now) then there should be a note in the build procedure on how to do a successful build.
According to Steve Clamage's post in this thread: http://forum.java.sun.com/thread.jspa?threadID=5071294&messageID=9262082 "(v8plus corresonds to UltraSPARC, the only architecture that has been available since about 1995.)" we can safely assume that all SPARCs where boost needs to run are v8+/v9. Since GCC doesn't accept v8plus, our only option is to use -mcpu=v9 -m32. There is also -mv8plus, but it doesn't select an architecture, but an ABI. It's on by default on v9/32. http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/SPARC-Options.html#SPARC-Options It seems that to fix the problem we need to set v9 as default in Boost.Build. I admit that I have no idea how to do that. Searching *.jam for -mcpu turned up nothing. The instruction-set feature doesn't seem to be used by gcc.jam. (The CVS only has Boost.Build v2 now; it could've worked with v1.)
Peter Dimov wrote:
It seems that to fix the problem we need to set v9 as default in Boost.Build. I admit that I have no idea how to do that. Searching *.jam for -mcpu turned up nothing. The instruction-set feature doesn't seem to be used by gcc.jam. (The CVS only has Boost.Build v2 now; it could've worked with v1.)
I can add the architecture and cpu options into BBv2, from BBv1. But we probably don't want to do that in the 1.34 branch as I don't think we want the chance of upsetting testing. Is that reasonable, or is this an urgent problem? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
"Rene Rivera" <grafikrobot@gmail.com> wrote in message news:458B0F43.3050201@gmail.com...
Peter Dimov wrote:
It seems that to fix the problem we need to set v9 as default in Boost.Build. I admit that I have no idea how to do that. Searching *.jam for -mcpu turned up nothing. The instruction-set feature doesn't seem to be used by gcc.jam. (The CVS only has Boost.Build v2 now; it could've worked with v1.)
I can add the architecture and cpu options into BBv2, from BBv1. But we probably don't want to do that in the 1.34 branch as I don't think we want the chance of upsetting testing. Is that reasonable, or is this an urgent problem?
As of now Boost.Test doesn't build on Sun with gcc in my environment. IMO it's pretty important to be fixed Gennadiy
"Thomas Witt" <witt@acm.org> wrote in message news:emvkbe$rvb$1@sea.gmane.org...
Gennadiy Rozental wrote:
As of now Boost.Test doesn't build on Sun with gcc in my environment. IMO it's pretty important to be fixed
Are you talking about HEAD or RC_1_34_0?
Both, if both affected Gennady
Gennadiy Rozental wrote:
"Thomas Witt" <witt@acm.org> wrote in message news:emvkbe$rvb$1@sea.gmane.org...
Gennadiy Rozental wrote:
As of now Boost.Test doesn't build on Sun with gcc in my environment. IMO it's pretty important to be fixed Are you talking about HEAD or RC_1_34_0?
Both, if both affected
Sorry, but my question was whether they are affected. So again does Boost.Test RC_1_34_0 build on Sun gcc? Thanks Thomas -- Thomas Witt witt@acm.org
Rene Rivera wrote:
Peter Dimov wrote:
It seems that to fix the problem we need to set v9 as default in Boost.Build. I admit that I have no idea how to do that. Searching *.jam for -mcpu turned up nothing. The instruction-set feature doesn't seem to be used by gcc.jam. (The CVS only has Boost.Build v2 now; it could've worked with v1.)
I can add the architecture and cpu options into BBv2, from BBv1. But we probably don't want to do that in the 1.34 branch as I don't think we want the chance of upsetting testing. Is that reasonable, or is this an urgent problem?
I see that the g++/SPARC version of sp_counted_base is not on RC_1_34_0, only on HEAD. So there should be no need to do anything for 1.34.
Peter Dimov wrote:
I see that the g++/SPARC version of sp_counted_base is not on RC_1_34_0, only on HEAD. So there should be no need to do anything for 1.34.
I added some of the options from BBv1 (excluding the mips options as they are not so easy to make work correctly). Some testing appreciated, as I can only do minimal testing on the platforms I have. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
"Glenn Schrader" <gschrad@ll.mit.edu> wrote in message news:4587C156.8030803@ll.mit.edu...
I have a strange build error when compiling for sparc solaris. In particular there are errors of the form:
error: cannot use v8plus instructions in a non-v8plus target binary
Yeah. I've been bitten by this today. I couldn't build Boost.Test on Sun Solaris with gcc. Is there any way this could be addressed? Gennadiy
participants (5)
-
Gennadiy Rozental -
Glenn Schrader -
Peter Dimov -
Rene Rivera -
Thomas Witt