headers
Timothy J. Wood | 1 Nov 2003 02:34
Gravatar

Re: The need for a libobjc maintainer


On Friday, October 31, 2003, at 11:26  AM, Ziemowit Laski wrote:
> Yes, absolutely.  It would be good to have one maintainer who actually 
> lives on the GNU runtime day-to-day, and then another who has exposure 
> to the Darwin side of things (esp. differences between the GNU and 
> NeXT runtimes).  So, if Nicola agrees to run for office :-), I'm 
> definitely for nominating both him and Andrew.

   Just commenting as a very interested bystander, so feel free to 
ignore me if I'm being an idiot, but ... it would be even better to 
have a pair of maintainers, GNUstep and Darwin that were committed to 
(a) LGPL-ing the Apple runtime (possibly dual license with APSL), (b) 
merging the runtimes and (c) simplifying the objc compiler bits by 
getting rid of the -ffoo-runtime switch.

   I know this is probably wishful thinking on my part (backwards 
compatibility, Apple legal issues, practical and philosophical 
differences on whether __builtin_apply is better than assembly 
messengers, runtime+crt0 initialization issues), but I can't help but 
worry that the runtimes are going to continue diverging and maintenance 
is only going to get harder.

   A guy can dream, can't he?  :)

   I did some work a while back to take a MinGW release and the Darwin 
ObjC runtime and get MinGW produce output for the Darwin runtime and 
then modified the Darwin runtime to work on Win32/x86 (not too hard 
since the x86 messenger code is already there).  I know this is a very 
small step in the grand scheme of things, but if anyone is interested 
in the bits, I can put them up somewhere (they are fairly old at this
(Continue reading)

Permalink | Reply | 0 comments |
headers
Giannis Aggelis | 1 Nov 2003 03:02
Picon

Successful bootstrap: 3.3.2/i386-pc-solaris2.9

Built with Sun ONE Studio 8, Compiler Collection, Sun ld and as and GNU make
3.80

daouti:/usr/local/src/gcc-3.3.2 # ./config.guess
i386-pc-solaris2.9

daouti:/usr/local/gcc/bin # ./gcc -v
Reading specs from ./../lib/gcc-lib/i386-pc-solaris2.9/3.3.2/specs
Configured with:
../configure --prefix=/usr/local/gcc --with-as=/usr/ccs/bin/as --with-ld=/us
r/ccs/bin/ld --enable-threads=posix --enable-shared --disable-nls
Thread model: posix
gcc version 3.3.2

daouti:/usr/local/gcc/bin # file gcc
gcc:            ELF 32-bit LSB executable 80386 Version 1, dynamically
linked, stripped

daouti:/usr/local/gcc/bin # uname -srvmpi
SunOS 5.9 Generic_112234-08 i86pc i386 i86pc

daouti:/usr/local/gcc/bin # isainfo -v
32-bit i386 applications

daouti:/usr/local/gcc/bin # make -v
GNU Make 3.80
Copyright (C) 2002  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Kargl | 1 Nov 2003 06:34
Picon

[tree-ssa] configuring g77 appears broken

% cvs -qz9 -d :pserver:anoncvs <at> subversions.gnu.org:/cvsroot/gcc update \
-PAd -r tree-ssa-20020619-branch gcc
% cd obj
% ../gcc/configure --prefix=$HOME/gcc-ssa/work --enable-languages=c,f95,f77 \
--with-gmp=/usr/local
%gmake
(much spewing deleted)
checking linker read-only and read-write section mixing... read-write
checking linker PT_GNU_EH_FRAME support... yes
checking linker position independent executable support... no
configure: error: 
The following requested languages were not found: f77
The following languages were available: c c++ f95 java objc
gmake: *** [configure-gcc] Error 1

Is this intentional?  I can't find a Changelog entry
noting that g77 was removed from tree-ssa.

--

-- 
Steve
Permalink | Reply | 9 comments |
headers
Mike Stump | 1 Nov 2003 08:02
Picon
Favicon

Re: powerpc & unaligned block moves with fp registers

On Friday, October 31, 2003, at 02:45  PM, Dale Johannesen wrote:
> On Friday, October 31, 2003, at 07:47  AM, David Edelsohn wrote:
>> 1. Do we *ever* want to use fp regs for unaligned mem-mem moves?  Is
>>    there any 32-bit PPC chip where an unaligned 64-bit fp move is
>>    faster than two (maybe unaligned, maybe mot) 32-bit moves?
>>
>> 	What about volatile?
>
> I don't believe 'volatile' requires atomic accesses.  You can have 
> objects of
> volatile-qualified struct types, and can copy them.

We should be very careful to not remove `working' and reasonable 
semantics that are widely implemented and depended on by existing code, 
just because some standard can be read in such a way that suggest that 
something might not be mandated to work.
Permalink | Reply | 0 comments |
headers
Stephan T. Lavavej | 1 Nov 2003 08:47
Picon
Favicon

gcc-3.4-20031029 bootstrap FAILURE (MinGW)

Working in /c/temp/gcc/build with an empty directory /c/temp/gcc/dest and
source extracted to /c/temp/gcc/src, I executed:

../src/configure --prefix=/c/temp/gcc/dest --enable-languages=c,c++
--enable-sjlj-exceptions --enable-threads=win32 --disable-win32-registry
--disable-shared --without-newlib --disable-nls --disable-debug

Then:

make "CFLAGS=-O3 -fomit-frame-pointer -ffast-math" "LDFLAGS=-s
-Wl,--stack=0x00800000" bootstrap

This eventually fails with:

make[3]: Entering directory `/c/temp/gcc/build/gcc'
for d in libgcc; do \
  if [ -d $d ]; then true; else /bin/sh ../../src/gcc/mkinstalldirs $d; fi;
\
done
mkdir -p -- libgcc
if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi
./xgcc -B./ -B/c/temp/gcc/dest/i686-pc-mingw32/bin/ -isystem
/c/temp/gcc/dest/i686-pc-mingw32/include -isystem
/c/temp/gcc/dest/i686-pc-mingw32/sys-include -L/c/temp/gcc/build/gcc/../ld
-O2 -I../../src/gcc/../winsup/w32api/include -DIN_GCC    -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include
-g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I
-I../../src/gcc -I../../src/gcc/ -I../../src/gcc/../include  -DL_chkstk
-xassembler-with-cpp -c ../../src/gcc/config/i386/cygwin.asm -o
libgcc/./_chkstk.o
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Hubicka | 1 Nov 2003 12:35
Picon

Re: Inner-loop optimization regression from 3.3 to 3.4

Hi,
I am sorry for taking so long time to update the patch.  I used by
mistake SMP machine for testing that brought so much noise into
benchmark so it took me a while to work out what is going on.
The gains on single CPU x86-64 are roughtly 0.3% without profiling and
0.7% with profiling at no measurable compile time costs.
> On Fri, Oct 17, 2003 at 04:10:02PM +0200, Jan Hubicka wrote:
> > + 	/* Convert (a >= 0) into (a >> (bits_per_mode - 1)) != -1.  */
> 
> Comment's wrong.

I don't get this :(
> 
> > + 	if (op1 == const0_rtx && BRANCH_COST > 1)
> > + 	  {
> > + 	  nonnegative:
> > + 	    return expand_simple_binop (GET_MODE (op0), ASHIFTRT, op0,
> > + 				        GEN_INT (GET_MODE_BITSIZE
> > + 						 (GET_MODE (op0)) - 1),
> > + 					NULL_RTX, 1, OPTAB_DIRECT);
> 
> Overall this looks reasonable.  It does however need to check rtx
> costs a lot more.  On Alpha for instance, LT is 2 to 6 times cheaper
> than ASHIFTRT, depending on how you count costs.  I think ia64 has
> similar issues with its shifter.

I've added rtx_cost check for this one.  The other checks looks safe to
me as they use basic arithmetic operations so are unlikely slower.  Not
sure whether my sollution is ideal - at least it results in redundant
construction of RTL expression (not a big deal as we match rarely)
(Continue reading)

Permalink | Reply | 7 comments |
headers
Richard Guenther | 1 Nov 2003 12:46
Picon

Re: attribute((leafify)) for 3.4

On Fri, 31 Oct 2003, Jan Hubicka wrote:

> > On Fri, 31 Oct 2003, Jan Hubicka wrote:
> >
> > initialization up to avoid going endlessly through callgraph loops.
> > Recursive inlining seems to be prevented somehow at least for not-direct
>
> Ah, I see, there is still recursive inlining preventing code in
> tree-inline I wanted to remove after killing old heuristics code.
> OK, still you mark maybe_inline in cyclic way in the callgraph that will
> eventually bring you problems if you attempt to get right the code size
> estimation (BTW you should at least increase global_insns during
> leafifying or you will get the leafifed function inlined too many times)

I dont update the code size because we wont inline leafified functions
anyway, as documented (I clear edge.inline_call for them).   I suspect the
code size estimates would be overly pessimistic anyway (thats the reason
for using leafify, otherwise the heuristics would work, too).

> > I won't submit this officially for 3.4, as I dont have a copyright
> > assignment yet and I suspect this would last too long to be accepted late
> > in stage 3 anyways. Also the concept of leafify needs some arguments.
> > Apart from this I think it is trivial for you to implement this
> > functionality after cleanup in 3.5, so I wont need to fiddle around with
> > copyright assignments.
>
> OK, I will try to get into this soon.

Thanks,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Robert Dewar | 1 Nov 2003 13:21

Re: powerpc & unaligned block moves with fp registers

> We should be very careful to not remove `working' and reasonable 
> semantics that are widely implemented and depended on by existing code, 
> just because some standard can be read in such a way that suggest that 
> something might not be mandated to work.

I would think that many C programs assume that access to a volatile variable
is in fact atomic if the machine can easily generate instructions to make
it so, given that standard C lacks a mechanism for specifying atomic access,
so I would agree with Mike that you want to be careful here on making changes.
Permalink | Reply | 1 comment |
headers
Toon Moene | 1 Nov 2003 13:50
Picon

Re: [tree-ssa] configuring g77 appears broken

Steve Kargl wrote:

> % cvs -qz9 -d :pserver:anoncvs <at> subversions.gnu.org:/cvsroot/gcc update \
> -PAd -r tree-ssa-20020619-branch gcc
> % cd obj
> % ../gcc/configure --prefix=$HOME/gcc-ssa/work --enable-languages=c,f95,f77 \
> --with-gmp=/usr/local
> %gmake
> (much spewing deleted)
> checking linker read-only and read-write section mixing... read-write
> checking linker PT_GNU_EH_FRAME support... yes
> checking linker position independent executable support... no
> configure: error: 
> The following requested languages were not found: f77
> The following languages were available: c c++ f95 java objc
> gmake: *** [configure-gcc] Error 1
> 
> Is this intentional?  I can't find a Changelog entry
> noting that g77 was removed from tree-ssa.

Yes, Richard Henderson removed it:

http://gcc.gnu.org/ml/gcc-cvs/2003-10/msg01057.html

I haven't seen him give a reason for this, but it might be that followon 
patches broke g77 completely, because it isn't ready for the new 
tree-ssa infrastructure.

We discussed that before; see:
(Continue reading)

Permalink | Reply | 8 comments |
headers
Gerald Pfeifer | 1 Nov 2003 14:23

Re: Plans for 3.3 series

On Wed, 29 Oct 2003, Gabriel Dos Reis wrote:
> My plan for the 3.3 series is [...]

Based on this information, I updated our main page per the patch below
(and also "moved" mainline into stage 3).

> The tentative release date for GCC-3.3.3 is set January 31th.

Would you mind updating htdocs/develop.html with this information? (I'm
currently moving and Internet access is quite limited...)

Gerald

Index: index.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.402
diff -u -3 -p -r1.402 index.html
--- index.html	19 Oct 2003 22:46:05 -0000	1.402
+++ index.html	1 Nov 2003 12:27:55 -0000
 <at>  <at>  -51,28 +51,23  <at>  <at>  to maintain and improve quality.</p>
 <dt><strong>Current release series:</strong>
   <a href="gcc-3.3/">GCC 3.3.2</a> (released 2003-10-17)
 </dt><dd>
-  The branch is open for regression fixes only.
+  Branch status:
+     <a href="http://gcc.gnu.org/ml/gcc/2003-10/msg01390.html">2003-10-29</a>
+  (open for regression fixes).
 </dd>
(Continue reading)

Permalink | Reply | 2 comments |

Gmane