On Thu, Sep 28, 2006 at 08:09:15PM +0100, Dave Korn wrote:
>Haven't had to suffer through an htDig session in a looong time now.
We haven't used htDig on sourceware for a few months now.
It's mnogosearch these days.
cgf
I noticed that on Darwin PPC we get warnings of the form...
symbol _fabsf used from dynamic library /usr/lib/libm.dylib(fabs.o) not from
earlier dynamic library /sw/lib/gcc4/lib/libgcj.8.dylib(sf_fabs.o)
symbol _fabs used from dynamic library /usr/lib/libm.dylib(fabs.o) not from
earlier dynam
I'm a little confused by the current usage of getsectdatafromheader_64 in
unwind-dw2-fde-darwin.c on Darwin PPC. I see a build warning of...
/sw/src/fink.build/gcc4-4.1.-20060928/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc4-4.1.-20060928/darwin_objdir/./gcc/
-B/sw/lib/gcc4/powe
On Debian system (Mobile Intel P4 2.20GHz):
kernel: 2.6.17-1-686
binutils: 2.17-1
LAST_UPDATED: Thu Sep 28 09:12:24 UTC 2006 (revision 117274)
Native configuration is i686-pc-linux-gnu
=== gcc tests ===
Running target unix
FAIL: gcc.c-torture/execute/mayalias-2.c compilation,
I am conflicted about making Darwin a primary platform. A primary
platform is not a hammer with which to make other developers fix problems
important to Darwin. Darwin definitely is popular and widely used.
However, maintenance of Darwin in the FSF repository has been very
inconsistent.
"Daniel Berlin" <[EMAIL PROTECTED]> writes:
> I really object to darwin being a primary platform until it is
> actually possible to build it on a released darwin system without
> passing extra configure flags, etc.
The regression tester routinely builds Darwin and uses no special
configure flags.
On Sat, 2006-09-30 at 18:25 -0400, Daniel Berlin wrote:
> I really object to darwin being a primary platform until it is
> actually possible to build it on a released darwin system without
> passing extra configure flags, etc.
In fact I object even ppc-darwin being a secondary target because right
I really object to darwin being a primary platform until it is
actually possible to build it on a released darwin system without
passing extra configure flags, etc.
It seems every couple weeks something new is broken in the configure
so that you have to add another flag.
Really, on our primary p
The following changes eliminate the warnings when
l10nflist.c is compiled...
--- /Users/howarth/gcc/intl/l10nflist.c 2006-08-13 14:29:20.0 -0400
+++ l10nflist.c 2006-09-30 17:24:19.0 -0400
@@ -139,12 +139,12 @@
#endif /* !_LIBC && !HAVE___ARGZ_STRINGIFY */
#if !defined _LIB
Has anyone noticed that we are breaking the strict-aliasing ruls in
natVMVirtualMachine.cc?
/sw/src/fink.build/gcc4-4.1.-20060928/darwin_objdir/./gcc/xgcc
-shared-libgcc -B/sw/src/fink.build/gcc4-4.1.-20060928/darwin_objdir/./gcc
-nostdinc++ -L/sw/src/fink.build/gcc
4-4.1.-200609
While reviewing my gcc trunk build log on Darwin PPC, I noticed the
following...
/sw/src/fink.build/gcc4-4.1.-20060928/darwin_objdir/./prev-gcc/xgcc
-B/sw/src/fink.build/gcc4-4.1.-20060928/darwin_objdir/./prev-gcc/
-B/sw/lib/gcc4/powerpc-apple-darwin8/bin
/ -c -I/sw/include -g -O2 -md
Snapshot gcc-4.2-20060930 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060930/
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
> That doesn't explain why the bit value isn't normalized to be smaller
> than BITS_PER_UNIT; any whole bytes could be incorporated into the
> variably sized offset.
It can't be normalized to BITS_PER_UNIT, but to DECL_OFFSET_ALIGN since
we are asserting that DECL_FIELD_OFFSET is aligned to DECL
13 matches
Mail list logo
