FX Coudert wrote:
Hi all,
I reviewed this afternoon the postings from the gcc-testresults
mailing-list for the past month, and we have a couple of gfortran
testsuite failures showing up on various targets. Could people with
access to said targets (possibly maintainers) please file PRs in
bug
> FX Coudert wrote:
> > Hi all,
> >
> > I reviewed this afternoon the postings from the gcc-testresults
> > mailing-list for the past month, and we have a couple of gfortran
> > testsuite failures showing up on various targets. Could people with
> > access to said targets (possibly maintainers) ple
> * hppa-unknown-linux-gnu: gfortran.dg/cray_pointers_2.f90
Fails due to timeout (slow system?):
real5m45.735s
user1m33.506s
sys 4m11.716s
I should note that the compilation time doesn't seem consistent from
one run to the next. Here's the detailed breakdown:
GNU F95 version 4.3.0
Hello all,
I have a need to read the VCG files (generated by -dv -fdump-rtl),
parse them and do some graph manipulations on them (drop some rtl instructions,
change graph layout, ...).
Is there any library for parsing and manipulating these VCG files ?
Thank You
sunzir
Dorit Nuzman wrote:
FX Coudert wrote:
Hi all,
I reviewed this afternoon the postings from the gcc-testresults
mailing-list for the past month, and we have a couple of gfortran
testsuite failures showing up on various targets. Could people with
access to said targets (possibly maintainers)
Test Run By igor on Sat Apr 14 03:32:31 2007
Native configuration is powerpc-apple-darwin7.9.0
=== gcc tests ===
Schedule of variations:
unix
FAIL: gcc.c-torture/compile/pr23237.c -O0 (test for excess errors)
FAIL: gcc.c-torture/compile/pr23237.c -O1 (test for excess err
...
> laST_UPDATED: Obtained from SVN: trunk revision 123799
>
> Native configuration is ia64-unknown-linux-gnu
>
> === gcc tests ===
>
>
for this one:
> FAIL: gcc.dg/vect/pr30771.c scan-tree-dump-times vectorized 1 loops 1
there should be { target vect_unpack } added to the check. i.e.:
-
I am working on SSE4.1 intrinsic. For code:
typedef long long __m128i __attribute__ ((__vector_size__ (16), __may_alias__));
typedef long long __v2di __attribute__ ((__vector_size__ (16)));
extern __m128i res[2];
void
foo(long long x, __m128i val)
{
res[0] = ((__m128i) __builtin_ia32_vec_set_v2
On Sat, Apr 14, 2007 at 11:28:59AM -0700, H. J. Lu wrote:
> __builtin_ia32_vec_set_v2di will be expanded to
>
> [(set (match_operand:V2DI 0 "register_operand" "=x")
> (vec_merge:V2DI
> (vec_duplicate:V2DI
> (match_operand:DI 2 "nonimmediate_operand" "rm"))
>
On Sat, Apr 14, 2007 at 02:49:47PM -0400, Daniel Jacobowitz wrote:
> On Sat, Apr 14, 2007 at 11:28:59AM -0700, H. J. Lu wrote:
> > __builtin_ia32_vec_set_v2di will be expanded to
> >
> > [(set (match_operand:V2DI 0 "register_operand" "=x")
> > (vec_merge:V2DI
> > (vec_duplicate
On 4/14/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
__builtin_ia32_vec_set_v2di is
v2di __builtin_ia32_vec_set_v2di (v2di, long long, const int)
v2di and m128i are the same type except for may_alias which only
matters when taking its address.
--Pinski
On Sat, Apr 14, 2007 at 12:23:24PM -0700, Andrew Pinski wrote:
> On 4/14/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> >
> >__builtin_ia32_vec_set_v2di is
> >
> >v2di __builtin_ia32_vec_set_v2di (v2di, long long, const int)
>
> v2di and m128i are the same type except for may_alias which only
> matters
On Saturday 14 April 2007 20:32, H. J. Lu wrote:
> On Sat, Apr 14, 2007 at 12:23:24PM -0700, Andrew Pinski wrote:
> > On 4/14/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > >__builtin_ia32_vec_set_v2di is
> > >
> > >v2di __builtin_ia32_vec_set_v2di (v2di, long long, const int)
> >
> > v2di and m128i a
I managed to regtest libffi and got the following summary:
=== libffi tests ===
Running target unix
FAIL: libffi.call/cls_align_longdouble.c -O0 -W -Wall output pattern test, is
12 7.29112e-304 191 0 1.98612e-309 0: 12 7.29114e-304 191
FAIL: libffi.call/nested_struct5.c -O0 -W -
>
> I have added the design document and links to most of the discussions
> we've had so far. Aldy updated the document to reflect the latest thread.
>
> http://gcc.gnu.org/wiki/tuples
Looks great, still I think "locus" and "block" could be both merged into
single integer, like RTL land has INS
Jan Hubicka wrote on 04/14/07 16:14:
> Looks great, still I think "locus" and "block" could be both merged into
> single integer, like RTL land has INSN_LOCATOR.
That's the idea. But it's simpler to do this for now. The insn locator
is easily done at anytime during the implementation.
> Also s
> Jan Hubicka wrote on 04/14/07 16:14:
>
> > Looks great, still I think "locus" and "block" could be both merged into
> > single integer, like RTL land has INSN_LOCATOR.
>
> That's the idea. But it's simpler to do this for now. The insn locator
> is easily done at anytime during the implementat
Jan Hubicka wrote on 04/14/07 21:14:
> I just wondered if your document is documenting the final shape or what
> should be done during hte first transition. If the second, probably 2
> words should be accounted for location as source_locues is currently a
> structure.
The document is describing
> Jan Hubicka wrote on 04/14/07 21:14:
>
> > I just wondered if your document is documenting the final shape or what
> > should be done during hte first transition. If the second, probably 2
> > words should be accounted for location as source_locues is currently a
> > structure.
>
> The documen
On 4/14/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Jan Hubicka wrote on 04/14/07 16:14:
> Looks great, still I think "locus" and "block" could be both merged into
> single integer, like RTL land has INSN_LOCATOR.
That's the idea. But it's simpler to do this for now. The insn locator
is easi
On 4/14/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Jan Hubicka wrote on 04/14/07 21:14:
> I just wondered if your document is documenting the final shape or what
> should be done during hte first transition. If the second, probably 2
> words should be accounted for location as source_locues i
> PRE is only using stmt_ann->uid as a convenient place to store the uid
> for local dominance for purposes of Load PRE.
> It's making up the UID on it's own :).
>
> If there was stmt->aux we'd put it there instead (note that the
> current way wastes memory, since we really only care about UID's f
22 matches
Mail list logo
