On Thu, 13 Mar 2003, Luke Mewburn wrote:

> On Wed, Mar 12, 2003 at 05:45:54PM -0700, Rick Kelly wrote:
>   | Luke Mewburn said:
>   |
>   | >I do this on an Ultra5/270.  It did run NetBSD/sparc64, but I found
>   | >certain applications (e.g, squid) wouldn't run correctly because of
>   | >codegen bugs in the current sparc64 compiler in NetBSD (gcc 2.95).
>   |
>   | Is there any testing going on with gcc 3.xx? It seems to work pretty well
>   | on Solaris 8 and 9.
>
> I haven't personally tested it myself, but I have seen reports that
> gcc 3.x (especially 3.2.x and 3.3) should greatly improve things.

I spent last weekend trying to compile sparc64-current with gcc 3.2.2
(until I gave up trying to convince the build system to build the netbsd
specific tools, but use an already installed compiler, that is..) and I
am now trying to compile a "standalone" sparc->sparc64 cross-compiler
with newlib for an other project. While I can't really say anything on
code quality yet, gcc 3.2.2 indeed seems to be a major improvement on
at least sparc64. The obsolete in-tree 2.95.3+patches gcc will quickly
SEGV if -O2 is used, which so far doesn't seem to happen with 3.2.2
-- that alone is a great improvement.

One thing I did notice however which may or may not affect sparc32 too,
is that gcc outputs invalid instructions; e.g. when compiling
newlib/libc/stdlib/getenv_r.c, I get "Assembler messages: invalid
operands" which turned out to be:

  ba,pt,a	%xcc, .LL1

which according to my SPARCv9 asm manual should be (GNU as agrees):

  ba,a,pt	%xcc, .LL1

i.e. it gets the attributes[0] in the wrong order. I am not sure if order
is meant to be significant, but either way gcc outputs assembly that its
own assembler doesn't understand.

Also, I have seen (probably platform-indepdendet)
inline-asm-in-inline-functions bugs in gcc-3.x.y on ARM7 that may be worth
knowing about. It will sometimes confuse itself while optimizing an
inline function, e.g "do foo with whatever register a is in and stuff it
in somereg" (I hope I got the parameter order right here, but...):


inline void foo(int a) {
  asm volatile ("foo %0, somereg" :: "r"(a));
}

..will sometimes incorrectly "optimize away" the parameter "a"
completely and just pick the first argument-passing register of
the ABI in use, which is very likely to be all wrong when the
function gets inlined. Rewriting it as:

inline void foo(int a)
  int something_for_gcc_to_chew_on = a;
  asm volatile ("foo %0, somereg" :: "r"(something_for_gcc_to_chew_on));
}

makes it work; it's as if GCC's optimization needs something to chew on
to get it right. :-)

[0] Those branch attributes, btw: they are present all over in the manual,
    but they aren't documented anywhere! I know "a" is the "annul delay
    slot instruction" attribute, but what is "pt" and "pn"? "Predict" and
    "Predict Never"?

-- 
/ali
:wq