>A silly little testcase which the vectorizer doesn't vectorize:
>
> autovecttest.c:11: note: not vectorized: relevant stmt not
> supported: D.1861_9 = (signed char) D.1860_8
Can these type casts (from uchar to schar and back) be cleaned away by some
pass before vectorization, or do we ne
Geoff,
If the autoconf patch isn't going in to gcc trunk, would someone
at Apple please nudge the folks who maintain www.opensource.apple.com
to post the Xcode Tools 2.4 source code release? Either than or post
a new cctools based off the same to the gcc ftp site. We really need
to be able to cr
Joseph S. Myers wrote:
On Fri, 8 Sep 2006, Edmar Wienskoski wrote:
Ok. I am starting to see the whole picture now.
So the whole thing appears to work with --disable-shared, just because the way
the linker
loads symbols in presence of libgcc_s.so versus libgcc.a.
Follow up question:
The e50
On 9/11/06, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
>A silly little testcase which the vectorizer doesn't vectorize:
>
> autovecttest.c:11: note: not vectorized: relevant stmt not
> supported: D.1861_9 = (signed char) D.1860_8
Can these type casts (from uchar to schar and back) be clean
> Edmar Wienskoski writes:
Edmar> Second, is the long double ABI problem. In the past gcc always generated
function calls to _q_* functions. (Per ABI Chapter 5)
Edmar> For this code:
Edmar> long double foo (long double x, long double y){ return x + y; }
Edmar> gcc-4.0, target powerpc-eabise a
On Mon, 11 Sep 2006, Edmar Wienskoski wrote:
> There are 2 issues here:
> First, It is libgcc that is generating undefined references to __*tf*
> functions. If gcc can provide them with "softfp_float_modes := sf df tf", I
> think is reasonable to do that. For completeness sake you can do as you
>
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 responsibility. However, I do not
know what is the current state and plan of tree-combine
"Daniel Berlin" <[EMAIL PROTECTED]> wrote on 11/09/2006 06:27:16 PM:
> On 9/11/06, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
> > >A silly little testcase which the vectorizer doesn't vectorize:
> > >
> >
> > > autovecttest.c:11: note: not vectorized: relevant stmt not
> > > supported: D.18
Perhaps a kind person would explain what -print-search-dirs is printing.
The manual entry is not very enlightening.
When I do
%gcc -print search-dirs
I get output of which the "libraries=" line lists the following libraries
libraries:
=/usr/local/gcc-4.1.1/x86_64-Linux/lib/gcc/x86_64-unknown-
"Kate Minola" <[EMAIL PROTECTED]> writes:
> I guess I would have expected that the two lists of libraries would be the
> same,
> or perhaps that the second list would be contained in the first. But
> this does not
> seem to be the case.
>
> What am I missing?
gcc only generates a -L option for
Geoff,
Did you notice that a new libjava regression occured today on Darwin
apparently after revision 116838 but by revision 116843? The testcase...
FAIL: Thread_Sleep -O3 -findirect-dispatch output - bytecode->native test
now fails. Could this be related to your change...
---
On 11/09/2006, at 3:51 PM, Jack Howarth wrote:
Geoff,
Did you notice that a new libjava regression occured today on
Darwin
apparently after revision 116838 but by revision 116843? The
testcase...
FAIL: Thread_Sleep -O3 -findirect-dispatch output - bytecode-
>native test
now fails. C
>
> Geoff,
>Did you notice that a new libjava regression occured today on Darwin
> apparently after revision 116838 but by revision 116843? The testcase...
>
> FAIL: Thread_Sleep -O3 -findirect-dispatch output - bytecode->native test
>
> now fails. Could this be related to your change...
Th
On 11/09/2006, at 3:59 PM, Andrew Pinski wrote:
Geoff,
Did you notice that a new libjava regression occured today on
Darwin
apparently after revision 116838 but by revision 116843? The
testcase...
FAIL: Thread_Sleep -O3 -findirect-dispatch output - bytecode-
>native test
now fails.
On Darwin PPC at -m64, we are seeing a slew of failures
in the tmpdir-gcc.dg-struct-layout-1 tests...
FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o
execute
FAIL: tmpdir-gcc.dg-s
On Tue, Sep 12, 2006 at 12:32:35AM -0400, Jack Howarth wrote:
> On Darwin PPC at -m64, we are seeing a slew of failures
> in the tmpdir-gcc.dg-struct-layout-1 tests...
>
> FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o
> execute
> FAIL: tmpdir-gcc.dg-struct-layou
16 matches
Mail list logo
