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
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: Threa
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,
> "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
> 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
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 w
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 th
"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
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 shoul
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
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 f
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, certai
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 exa
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 RUNTESTF
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
l
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 not
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
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
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
> > > a
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/
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
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
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_t
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_
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: tmp
25 matches
Mail list logo
