Geoff,
Is this a potential problem in the compilation of libgcj on Darwin PPC
at -m64? I am seeing the following warning...
/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/./gcc/
-B/sw/lib/gcc4/powerpc-apple-darwin8/
Geoff,
We seem to have the same issue in libffi when compiled on Darwin PPC
at -m64...
/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/./gcc/
-B/sw/lib/gcc4/powerpc-apple-darwin8/bin/
-B/sw/lib/gcc4/powerpc-apple-d
Mark Mitchell wrote:
Anyhow, I think that a combination of compiler/linker help and
programmer help are useful. There are some cases where you can do this
automatically, and others where you might need programmer help. Just as
-ffast-math is useful, so might -fmerge-functions or
__attribute_
Daniel Berlin wrote:
Actually, even for non-POD types, it catches a lot of templatized
member functions that mainly depend on size (but they are still
container classes).
Just another ( maybe stupid :-) ) idea. What about "partial merge"?
static int x = 0;
void a()
{
printf( "aaa" );
x
> I'm trying to add a hook for aligning vectors for loads.
>
> I'm using the altivec rs6000 code as a baseline.
>
> However, the instruction is like the iwmmxt_walign instruction in the
> ARM port; it takes
> a normalish register and uses the bottom bits... it doesn't use a
> full-width vector.
>
>
"Devang Patel" <[EMAIL PROTECTED]> wrote on 11/09/2006 07:30:17 PM:
> > Can these type casts (from uchar to schar and back) be cleaned away
> > by some pass before vectorization, or do we need to teach the
vectorizer
> > to ignore such type casts?
>
> This was considered as tree-combiner's respons
On 2006-09-07 14:30:50 -0500, Chris Talley wrote:
> Thanks for the tip. I'll try to recompile GMP and MPFR. GMP and MPFR
> are VERY difficult to compile correctly on a Darwin system. Any hints
> on proper configure settings for GMP-4.2.1 / MPFR-2.2.0-patched on
> Darwin?
>
> On Sep 7, 2006,
I don't recall the exact problem Chir was having but I would
mention that on fink for MacOS X 10.4, we package our gmp 4.2.1
using a build with the following patch...
http://swox.com/list-archives/gmp-discuss/2006-May/002333.html
http://swox.com/list-archives/gmp-discuss/2006-May/002344.html
M
Has anyone noticed that on Darwin PPC we are building
the shared library libgcjgc.1.0.2.dylib in the boehm-gc
subdirectory but it never is installed? Isn't this a bug?
Jack
I finally got around to building and testing the objc
support in gcc on Darwin PPC at -m64. The results aren't good
with 634 additional failures compared to the 10 at -m32. These
seem to be linkage issues of the form below as shown in...
http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00844
Another observation regarding the previous failure I
reported in the objc testsuite. If I manually execute...
/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/gcc/
/sw/src/fink.build/gcc4-4.1.-20060915/gcc-4.2-2006
"Erich Plondke" <[EMAIL PROTECTED]> wrote on 16/09/2006 05:26:50 PM:
> On 9/16/06, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
> > Looks like it's a bug in the vectorizer - we treat both the return
value of
> > the mask_for_load builtin, and the 3rd argument to the realign_load
stmt
> > (e.g. Altivec'
With latest svn trunk and Bud's splay patch. I don't think this is related to
Bud's patch because regression testing and NIST testing passed fine.
While compiling LAPACK with -O3 -funroll-loops -march=nocona I got the following
error message:
I am not sure I can reduce the case. But I can tr
Shouldn't we have something in gcc/testsuite/lib/objc*.exp
to short-circuit out of running any of those -m64 testsuites
for Darwin8 and earlier? If we won't have 64-bit objc runtimes
in Darwin until Leopard, it seems rather pointless to test
-m64 for objc at all, no? Also, I am baffled as to how
Hi Jerry,
While compiling LAPACK with -O3 -funroll-loops -march=nocona I got the
following error message:
BFD: BFD 2.16.91.0.6 20060212 internal error, aborting at
../../bfd/elfcode.h line 190 in bfd_elf32_swap_symbol_in
If you are able to reproduce this bug, then please try using the lates
Snapshot gcc-4.2-20060916 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060916/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Jerry DeLisle wrote:
BFD: BFD 2.16.91.0.6 20060212 internal error, aborting at
../../bfd/elfcode.h line 190 in bfd_elf32_swap_symbol_in
BFD: Please report this bug.
make[1]: *** [complex16] Error 1
make[1]: *** Waiting for unfinished jobs
BFD: BFD 2.16.91.0.6 20060212 internal error, ab
Ross Ridge writes:
>No, and I can't see how how you've came up with such an abusurd
>misintepretation of what I said. As I said clearly and explicity,
>the example I gave was where you'd want to use function merging.
Daniel Berlin writes:
>Whatever. Why would you turn on function merging if you
Nick Clifton wrote:
Hi Jerry,
While compiling LAPACK with -O3 -funroll-loops -march=nocona I got the
following error message:
BFD: BFD 2.16.91.0.6 20060212 internal error, aborting at
../../bfd/elfcode.h line 190 in bfd_elf32_swap_symbol_in
If you are able to reproduce this bug, then pleas
Ross Ridge <[EMAIL PROTECTED]> writes:
[...]
| >>I think this is best done by linker which
| >>can much more reliably compare the contents of functions to see if they
| >>are the same.
| >
| >No it can't. It has no idea what a function consists of other than a
| >bunch of bytes, in pretty much al
On Sat, 2006-09-16 at 10:57 -0700, Tim Prince wrote:
> BFD is acknowledging that it may be buggy. Does this occur with current
> binutils, e.g. from ftp.kernel.org?
Don't even dare use those binutils. Those are not the official binutils
at all. Those are HJL's crazy patched binutils which mo
Gabriel Dos Reis write:
>Not very logn ago I spoke with the VC++ manager about this, and he
>said that their implementation currently is not conforming -- but
>they are working on it. The issue has to with f and f
>required to have difference addresses -- which is violated by their
>implementation
>No it can't. It has no idea what a function consists of other than a
>bunch of bytes, in pretty much all cases. ... Stupid byte
>comparisons of functions generally won't save you anything truly
>interesting.
Microsoft's implementation has proven that "stupid" byte comparions can
generate signif
Ross Ridge writes:
>Microsoft's implementation has proven that "stupid" byte comparions can
>generate significant savings.
Daniel Berlin wrtes:
>No they haven't.
So Microsoft and everyone who says they've got significant savings using
it is lying?
>But have fun implementing it in your linker, an
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
| > >No it can't. It has no idea what a function consists of other than a
| > >bunch of bytes, in pretty much all cases. ... Stupid byte
| > >comparisons of functions generally won't save you anything truly
| > >interesting.
| >
| > Microsoft's implemen
On 9/16/06, Ross Ridge <[EMAIL PROTECTED]> wrote:
Ross Ridge writes:
>Microsoft's implementation has proven that "stupid" byte comparions can
>generate significant savings.
Daniel Berlin wrtes:
>No they haven't.
So Microsoft and everyone who says they've got significant savings using
it is lyin
The documention on VECTOR_CST is not clear if we can have missing
elements in that the remaining elements are zero. Right we produce such
VECTOR_CST for things like:
#define vector __attribute__((vector_size(16) ))
vector int a = {1, 2};
But is that valid? We currently produce a VECTOR_CST with
Daniel Berlin writes
>Do you really want me to sit here and knock down every single one of
>your arguments?
Why would you think I would've wanted your "No, it isn't" responses
instead?
>Your functions you are trying to optimize for multiple cpu
>types and compiled with different flags may be outp
I just got crazy idea, since we really don't like CONSTRUCTOR that much
and we already know the lengths of Vectors, we can have a VECTOR_EXPR
which we could then use instead of CONSTRUCTORs.
This would also save some memory as then we don't need a real
VEC(constructor_elt) but more like what TREE_
29 matches
Mail list logo
