gcc mirror in Portugal
Already exists a mirror in Portugal that distribute gcc ftp://ftp.ist.utl.pt/pub/GNU/gnu/gnu/gcc/ Sincerily yours, -- Pedro Sá da Costa mail: [EMAIL PROTECTED] site: pedrosacosta.no.sapo.pt
Re: new libjava regression on darwin
Geoffrey Keating writes:
>
> 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. Could this be related to your change...
> >
> > This is just a timeout.
>
> It's actually an timing-dependent infinite loop, or at least that's
> what I remember from the last time I looked at it several years ago.
No, it isn't:
public static void main(String args[])
{
try
{
long start = System.currentTimeMillis();
System.out.println("sleeping");
Thread.sleep(50);
long end = System.currentTimeMillis();
if ((end - start) < 50)
System.out.println ("failed");
else
System.out.println("ok");
}
catch (InterruptedException x)
{
System.out.println("error: Thread interrupted.");
}
}
Andrew.
Re: new libjava regression on darwin
I analysed this problem. It appears that the pthread_cond_timedwait on at least darwin8 sometimes returns a few microseconds early; this may be related to having ntpd running. On darwin9 (and/or darwin8 with -D_APPLE_C_SOURCE defined), sometimes this test hangs, due to a different, known, bug in pthread_cond_timedwait. I would suggest just xfailing this test on Darwin, except I don't see how to do that in this directory. Alternatively, the problem can be suppressed by testing for 49 instead of 50. According to the Java language specification, it is not actually incorrect for this test to fail. In section 17.9, it says "Thread.sleep causes the currently executing thread to sleep (temporarily cease execution) for the specified duration, subject to the precision and accuracy of system timers and schedulers." The implication is that Thread.sleep might use a different system timer than currentTimeMillis (one which runs at a different rate), which I think is what's actually happening at least in the darwin8 case. smime.p7s Description: S/MIME cryptographic signature
Re: GCC 4.3 Projects Page
> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes: > Please add your project page to the bottom of: >http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning I just added a page for the tuples work. Aldy
[patch] Add tuples work to svn.html (was Re: [tuples] gimple-tuples-branch created)
> Can you make sure you update svn.html for the new branch? Sure can! Is this ok? Index: svn.html === RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v retrieving revision 1.36 diff -u -r1.36 svn.html --- svn.html11 Sep 2006 18:59:51 - 1.36 +++ svn.html12 Sep 2006 12:00:46 - @@ -260,6 +260,16 @@ be marked with the tag [mem-ssa] in the subject line. + gimple-tuples + This branch contains the implementation of GIMPLE tuples, a new + representation for GIMPLE statements and expressions that replaces the + current notion of treating everything as a tree + (http://gcc.gnu.org/wiki/tuples";> + http://gcc.gnu.org/wiki/tuples). + This branch is maintained by Aldy Hernandez and will be routinely merged + with mainline. Patches and discussion on this branch should be marked with + the tag [tuples] in the subject line. + yara-branch This branch contains Yet Another Register Allocator (YARA). The branch is maintained by Vladimir Makarov <
Re: Branch st/cli opened to host development of CLI back-end
Hello Gerald, I added the branch description to htdocs/svn.html. I also wrote a page (htdocs/projects/cli.html) with a longer description about the CLI back-end project. Currently, it contains the essential information only, but many more details are to come. Cheers, Roberto Gerald Pfeifer wrote: Hi Roberto, On Thu, 7 Sep 2006, Roberto COSTA wrote: following previous discussions in this mailing list and the approval from RMS and the steering committee about a CLI port of gcc, I've opened a development branch to host its development. The branch is st/cli. would you mind adding a description of that branch (and the rules governing it) to htdocs/svn.html in our wwwdocs CVS module, alongside the other development branches? If you'd like to add a page under htdocs/projects with a longer description, that might be a good idea as well (but that part is optional). Thanks, Gerald
Re: question about -print-search-dirs
Ian, For both lists of libraries, the directories exist. So I don't understand your answer. Kate Minola University of Maryland, College Park On 11 Sep 2006 13:21:12 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: "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 directories which actually exist, and which actually are directories. Ian
Re: question about -print-search-dirs
"Kate Minola" <[EMAIL PROTECTED]> writes: > For both lists of libraries, the directories exist. So I don't understand > your answer. In that case, I don't understand either. It does work as expected for me. I should note that there is one general exception: /lib and /usr/lib will not be passed as -L options, on the assumption that the linker will search them anyhow. Note that a/b/c/../../../x will only exist if a/b/c exists. Ian > On 11 Sep 2006 13:21:12 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > "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 directories which actually exist, > > and which actually are directories. > > > > Ian > >
Re: question about -print-search-dirs
On Tue, Sep 12, 2006 at 08:58:40AM -0700, Ian Lance Taylor wrote: > "Kate Minola" <[EMAIL PROTECTED]> writes: > > > For both lists of libraries, the directories exist. So I don't understand > > your answer. > > In that case, I don't understand either. It does work as expected for > me. I should note that there is one general exception: /lib and > /usr/lib will not be passed as -L options, on the assumption that the > linker will search them anyhow. > > Note that a/b/c/../../../x will only exist if a/b/c exists. Looking at the original example, Kate, what exactly were you confused about? If it was the "/../lib64" suffix, those are added _after_ the list of directories to search are decided. They're added when we consider whether the user asked for -m32 or -m64 (see multilib in the documentation). -- Daniel Jacobowitz CodeSourcery
Re: [patch] Add tuples work to svn.html (was Re: [tuples] gimple-tuples-branch created)
On Tue, 2006-09-12 at 08:03 -0400, Aldy Hernandez wrote: > > Can you make sure you update svn.html for the new branch? > > Sure can! > > Is this ok? Yes and it is obvious as it is part of the creating the branch process. Thanks, Andrew Pinski
Re: question about -print-search-dirs
On 9/12/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: Looking at the original example, Kate, what exactly were you confused about? If it was the "/../lib64" suffix, those are added _after_ the list of directories to search are decided. They're added when we consider whether the user asked for -m32 or -m64 (see multilib in the documentation). Much thanks for the explanation. This is precisely what was confusing me. Is there a gcc debug option (or another way) to determine if gcc is defaulting to -m32 or -m64 mode? Or what I really want, the _actual_ search libraries - with "/../lib64" if in -m64 mode? The reason I ask is that libtool (or more precisely the m4 macro AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4) uses "gcc -print-search-dirs" to set sys_lib_search_path_spec. But if gcc is in -m64 mode but -print-search-dirs is only listing -m32 libraries, then bad things happen later on. Kate Minola University of Maryland, College Park
Re: [patch] Add tuples work to svn.html (was Re: [tuples] gimple-tuples-branch created)
On Tue, 12 Sep 2006, Aldy Hernandez wrote: > Is this ok? Yup, looks good, and falls under the obvious rule for web pages ;-). I was going to suggest to sort this in alphabetically, but currently there is not apparent sort order at all; perhaps I'll have a look after I see your patch go in, certainly nothing I'm asking you to do. Gerald
Re: gcc mirror in Portugal
On Tue, 12 Sep 2006, [EMAIL PROTECTED] wrote: > Already exists a mirror in Portugal that distribute gcc > > ftp://ftp.ist.utl.pt/pub/GNU/gnu/gnu/gcc/ Thanks for the pointer. I had a look, and this actually a GNU mirror, not a gcc.gnu.org specific mirror (which also carries our snapshots, for example). At http://gcc.gnu.org/mirrors.html we only list the latter, and refer to the GNU mirror list for the former, so I did not add this mirror to our list. Gerald
Re: debugging tmpdir-gcc.dg-struct-layout-1 failures
Jakub, I don't believe I'm using ALT_CC_UNDER_TEST or ALT_CC_UNDER_TEST. However I do have to explicitly pass -m64 so that I test that compile flag at the same time I pass -DDBG. I haven't been able to puzzle out an invocation of make check that does that. If I use... make -k check-gcc RUNTESTFLAGS="struct-layout-1.exp --target_board=unix/'-m64 -DDBG'" it thinks I want to run unix/-m64 and unix/-DDBG when actually I want both to get passed at the same time. Any ideas? Jack
Re: question about -print-search-dirs
On Sep 13, 2006, at 3:57 AM, Kate Minola wrote: The reason I ask is that libtool (or more precisely the m4 macro AC_LIBTOOL_SYS_DYNAMIC_LINKER in libtool.m4) uses "gcc -print-search-dirs" to set sys_lib_search_path_spec. But if gcc is in -m64 mode but -print-search-dirs is only listing -m32 libraries, then bad things happen later on. Yes, -print-search-dirs is not appropriate for the multilib case, please bring this up (again) on the libtool or bug-libtool lists. Peter
noise from gcc.dg/torture/fp-convert tests
So, these are xfailed, but still produce quite a bit of noise on both x86_64-darwin and x86_64-linux since they fail to produce a working executable and then xfail. Should we move them to skip or link only and xfail them. With link only they do manage to be quiet in the logs and we'll still notice if they start linking correctly and can move them to run then. thoughts? pre-approved? :) -eric
Re: noise from gcc.dg/torture/fp-convert tests
On Tue, 12 Sep 2006, Eric Christopher wrote: > So, these are xfailed, but still produce quite a bit of noise on both > x86_64-darwin and x86_64-linux since they fail to produce a working executable > and then xfail. Should we move them to skip or link only and xfail them. With > link only they do manage to be quiet in the logs and we'll still notice if > they start linking correctly and can move them to run then. > > thoughts? pre-approved? :) Add a means to XFAIL the link of an execute test, if such a means doesn't already exist in the testsuite infrastructure. -- Joseph S. Myers [EMAIL PROTECTED]
Re: noise from gcc.dg/torture/fp-convert tests
Joseph S. Myers wrote: On Tue, 12 Sep 2006, Eric Christopher wrote: So, these are xfailed, but still produce quite a bit of noise on both x86_64-darwin and x86_64-linux since they fail to produce a working executable and then xfail. Should we move them to skip or link only and xfail them. With link only they do manage to be quiet in the logs and we'll still notice if they start linking correctly and can move them to run then. thoughts? pre-approved? :) Add a means to XFAIL the link of an execute test, if such a means doesn't already exist in the testsuite infrastructure. As opposed to changing the test to a link, find a way to xfail at the link stage instead of at the run stage? -eric
Re: noise from gcc.dg/torture/fp-convert tests
On Tue, 12 Sep 2006, Eric Christopher wrote: > Joseph S. Myers wrote: > > On Tue, 12 Sep 2006, Eric Christopher wrote: > > > > > So, these are xfailed, but still produce quite a bit of noise on both > > > x86_64-darwin and x86_64-linux since they fail to produce a working > > > executable > > > and then xfail. Should we move them to skip or link only and xfail them. > > > With > > > link only they do manage to be quiet in the logs and we'll still notice if > > > they start linking correctly and can move them to run then. > > > > > > thoughts? pre-approved? :) > > > > Add a means to XFAIL the link of an execute test, if such a means doesn't > > already exist in the testsuite infrastructure. > > As opposed to changing the test to a link, find a way to xfail at the link > stage instead of at the run stage? Yes. Some marking so that the compile/link is expected to fail (and so doesn't produce a WARNING) but if it succeeds (XPASS) then the execute test is run. -- Joseph S. Myers [EMAIL PROTECTED]
Re: debugging tmpdir-gcc.dg-struct-layout-1 failures
Jakub,
Okay. I managed to get the testcase built but -DDBG at -m64
by just changing the ifdef for DBDG to an ifndef in the header.
The results on Darwin PPC are as follows...
fail 94.72
FAIL: tmpdir-gcc.dg-struct-layout-1/t001 c_compat_x_tst.o-c_compat_y_tst.o
execute
...which in testsuite/gcc/gcc.dg-struct-layout-1/t001_test.h is...
T(94,struct atal16{}a;,)
fail 693.55
fail 760.55
FAIL: tmpdir-gcc.dg-struct-layout-1/t003 c_compat_x_tst.o-c_compat_y_tst.o
execute
...which in gcc.dg-struct-layout-1/t003_test.h are...
T(693,double atal2 a;Tal16long b;short int
c;struct{}d;,F(693,a,-9109.968750,89665.703125)F(693,b,-2780362564512530142LL,-188249301918206LL)F(693,c,29451,-6341))
T(760,float a;long double b;unsigned long int c;signed char
d;,F(760,a,-218391.812500,-167965.062500)F(760,b,-122404.406250,-90172.859375)F(760,c,2933687826322174624ULL,14862826394269793540ULL)F(760,d,55,64))
fail 998.55
FAIL: tmpdir-gcc.dg-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o
execute
...which in testsuite/gcc/gcc.dg-struct-layout-1/t005_test.h is...
T(998,df a;Talllong b:BQN(20);long long int c:BQN(1);TE4 d:19;long int
e;,F(998,a,140017.484375,-160009.218750)B(998,b,-303431,345440)B(998,c,0,0)B(998,d,e4_253,e4_2)F(998,e,3562377756672343063LL,5761410617366885841LL))
fail 1082.72
FAIL: tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o
execute
...which in testsuite/gcc/gcc.dg-struct-layout-1/t006_test.h is...
T(1082,struct{char b;TE0 c[7];char * d[20];long double e atal16;long long int
f;}a[0];,)
fail 1234.55
fail 1234.55
FAIL: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o
execute
...which in testsuite/gcc/gcc.dg-struct-layout-1/t008_test.h is...
T(1234,double a;signed char atal16 b;union{unsigned int d;struct{}e;}c;short
int f;unsigned char
g;,F(1234,a,-125234.421875,-6063.015625)F(1234,b,-105,88)F(1234,c.d,3504478143U,3116938342U)F(1234,f,-15109,-23068)F(1234,g,236U,127U))
fail 1604.55
FAIL: tmpdir-gcc.dg-struct-layout-1/t016 c_compat_x_tst.o-c_compat_y_tst.o
execute
...which in testsuite/gcc/gcc.dg-struct-layout-1/t016_test.h is...
T(1604,char a;TE7 b;enum E6 c;unsigned int d;long int e;char f[6];float g;short
int atal16 h;int *
i;,F(1604,a,76U,30U)F(1604,b,e7_m2147483647,e7_m2147483645)F(1604,c,e6_2,e6_2)F(1604,d,3007045619U,3425526240U)F(1604,e,7127725064803830888LL,2212588498547332024LL)F(1604,f[4],64U,30U)F(1604,g,-67359.484375,-251776.203125)F(1604,h,17064,8859)F(1604,i,(int
*)&intarray[89],(int *)&intarray[249]))
fail 2017.72
FAIL: tmpdir-gcc.dg-struct-layout-1/t024 c_compat_x_tst.o-c_compat_y_tst.o
execute
...which in testsuite/gcc/gcc.dg-struct-layout-1/t024_test.h is...
T(2017,union{}a atal16;,)
fail 2464.72
fail 2468.55
FAIL: tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o-c_compat_y_tst.o
execute
...which in testsuite/gcc/gcc.dg-struct-layout-1/t026_test.h are...
T(2464,struct{double b;TE1 c[5];Tldouble d;}a[0];,)
T(2468,float a;long double b;Tchar c;Tal8llong
d;,F(2468,a,3100.906250,83925.484375)F(2468,b,-156603.906250,244908.156250)F(2468,c,99U,35U)F(2468,d,5510104998541940327LL,8962187912153613792LL))
fail 2810.72
FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o-c_compat_y_tst.o
execute
...which in testsuite/gcc/gcc.dg-struct-layout-1/t028_test.h is...
T(2810,v16qi a[0];,)
Does anyone recognize any sort of pattern to these failures which might suggest
why they
fail on Darwin PPC at -m64 and not on ppc64?
Jack
Re: debugging tmpdir-gcc.dg-struct-layout-1 failures
One other note about the tmpdir-gcc.dg-struct-layout-1 failures. I wonder if they could be another manifestation of the latent bug in float to integer conversion which I described in http://gcc.gnu.org/ml/gcc/2006-08/msg00500.html? Jack
Re: debugging tmpdir-gcc.dg-struct-layout-1 failures
Does anyone recognize any sort of pattern to these failures which might suggest why they fail on Darwin PPC at -m64 and not on ppc64? We do have a radar about the lack of aligned uninitialized variable support, i.e. .comm x,size,align that references t001 and t025. -eric
Re: debugging tmpdir-gcc.dg-struct-layout-1 failures
Eric, Do you see the same set of failures... > 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-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o > execute > FAIL: tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o > execute > FAIL: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o > execute > FAIL: tmpdir-gcc.dg-struct-layout-1/t016 c_compat_x_tst.o-c_compat_y_tst.o > execute > FAIL: tmpdir-gcc.dg-struct-layout-1/t024 c_compat_x_tst.o-c_compat_y_tst.o > execute > FAIL: tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o-c_compat_y_tst.o > execute > FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o-c_compat_y_tst.o > execute ..on x86_64 Darwin as I do on Darwin PPC at -m64? Or are these only PPC failures? Jack
Re: debugging tmpdir-gcc.dg-struct-layout-1 failures
Jack Howarth wrote: Eric, Do you see the same set of failures... 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-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t016 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t024 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o-c_compat_y_tst.o execute ..on x86_64 Darwin as I do on Darwin PPC at -m64? Or are these only PPC failures? I do not see these on x86_64 darwin. After removing some noise here are the failures for x86_64 darwin: FAIL: gcc.c-torture/execute/20030928-1.c execution, -O1 FAIL: gcc.c-torture/execute/20030928-1.c execution, -O2 FAIL: gcc.c-torture/execute/20030928-1.c execution, -Os FAIL: gcc.c-torture/execute/mayalias-2.c compilation, -O3 -g (internal compiler error) FAIL: gcc.dg/cpp/_Pragma6.c (test for excess errors) FAIL: gcc.dg/asm-fs-1.c scan-assembler-not \\*_bar FAIL: gcc.dg/darwin-weakimport-1.c scan-assembler-not weak_[a-z \t]*_b FAIL: gcc.dg/darwin-weakimport-3.c scan-assembler-not coalesced FAIL: gcc.dg/framework-1.c (test for excess errors) FAIL: gcc.dg/visibility-11.c scan-assembler [EMAIL PROTECTED] FAIL: gcc.dg/torture/fp-int-convert-float128.c -O0 (test for excess errors) FAIL: gcc.dg/torture/fp-int-convert-float128.c -O1 (test for excess errors) FAIL: gcc.dg/torture/fp-int-convert-float128.c -O2 (test for excess errors) FAIL: gcc.dg/torture/fp-int-convert-float128.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.dg/torture/fp-int-convert-float128.c -O3 -g (test for excess errors) FAIL: gcc.dg/torture/fp-int-convert-float128.c -Os (test for excess errors) FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vectorized 0 loops 1 FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vectorized 0 loops 1 FAIL: gcc.dg/tree-ssa/loop-3.c scan-tree-dump-times step: 1 FAIL: gcc.target/i386/asm-4.c (test for excess errors) -eric
Re: debugging tmpdir-gcc.dg-struct-layout-1 failures
Eric, Yesterday's gcc trunk (with the residual TImode patch) shows the following gcc testsuite failures at -m64... 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-struct-layout-1/t005 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t006 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t008 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t016 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t024 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t026 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: tmpdir-gcc.dg-struct-layout-1/t028 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: gcc.dg/cpp/_Pragma6.c (test for excess errors) FAIL: gcc.dg/20020919-1.c (test for errors, line 108) FAIL: gcc.dg/20020919-1.c (test for errors, line 126) FAIL: gcc.dg/20020919-1.c (test for errors, line 135) FAIL: gcc.dg/20020919-1.c (test for errors, line 162) FAIL: gcc.dg/20020919-1.c (test for errors, line 180) FAIL: gcc.dg/20020919-1.c (test for errors, line 234) FAIL: gcc.dg/array-9.c (internal compiler error) FAIL: gcc.dg/array-9.c (test for excess errors) FAIL: gcc.dg/asm-b.c execution test FAIL: gcc.dg/cleanup-10.c execution test FAIL: gcc.dg/cleanup-11.c execution test FAIL: gcc.dg/cleanup-8.c execution test FAIL: gcc.dg/cleanup-9.c execution test FAIL: gcc.dg/framework-1.c (test for excess errors) FAIL: gcc.dg/torture/fp-int-convert-timode.c -O0 execution test FAIL: gcc.dg/torture/fp-int-convert-timode.c -O1 execution test FAIL: gcc.dg/torture/fp-int-convert-timode.c -O2 execution test FAIL: gcc.dg/torture/fp-int-convert-timode.c -O3 -fomit-frame-pointer execution test FAIL: gcc.dg/torture/fp-int-convert-timode.c -O3 -g execution test FAIL: gcc.dg/torture/fp-int-convert-timode.c -Os execution test FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors) FAIL: gcc.dg/vect/section-anchors-pr27770.c execution test FAIL: gcc.dg/vect/section-anchors-vect-69.c (test for excess errors) FAIL: gcc.dg/vect/section-anchors-vect-69.c scan-tree-dump-times Alignment of access forced using peeling 4 FAIL: gcc.target/powerpc/darwin-bool-1.c (test for excess errors) FAIL: gcc.target/powerpc/ppc-negeq0-1.c scan-assembler-not cntlzw FAIL: gcc.target/powerpc/ppc64-abi-1.c (test for excess errors) FAIL: gcc.target/powerpc/stabs-attrib-vect-darwin.c scan-assembler .stabs.*vi:\\(0,16\\)[EMAIL PROTECTED] Hopefully we can drive some of this down in the next few weeks though. Jack
