Re: [Ada] Standard.Interger'Size = 32?

[Bernd Trog]

On Thu, 3 Mar 2005, Robert Dewar wrote:

> Bernd Trog wrote:
> > according to the gnat ref. manual
> >
http://gcc.gnu.org/onlinedocs/gnat_rm/Implementation-Defined-Characteristics.html
> > 
> > Standard.Interger'Size is 32 bit for the compilation target.
> >
> > I'd like to know if the Ada frontend (not the runtime
> > system) depends on this (target) setting in any way? 
> 
> Yes, the front end uses Ada strings which are indexed by Integer.
> Integer cannot be 16 bits. The Ada RM does allow this, but I am  
> pretty sure GNAT counts on integer being 32 bits.

OK. So the user should be warned (by documentation and the compiler) 
when he tries to use the Ada frontent with backend that can set 
INT_TYPE_SIZE to 16, right?

A 'grep INT_TYPE_SIZE' lists avr, h8300, ip2k, m68hc11, m68k,
pdp11 and stormy16 as possible candidates for such a warning.







__ 
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web 
http://birthday.yahoo.com/netrospective/

Re: [Ada] Standard.Interger'Size = 32?

[Laurent GUERBY]

On Sun, 2005-03-06 at 04:12 -0800, Bernd Trog wrote:
> On Thu, 3 Mar 2005, Robert Dewar wrote:
> 
> > Bernd Trog wrote:
> > > according to the gnat ref. manual
> > >
> http://gcc.gnu.org/onlinedocs/gnat_rm/Implementation-Defined-Characteristics.html
> > > 
> > > Standard.Interger'Size is 32 bit for the compilation target.
> > >
> > > I'd like to know if the Ada frontend (not the runtime
> > > system) depends on this (target) setting in any way? 
> > 
> > Yes, the front end uses Ada strings which are indexed by Integer.
> > Integer cannot be 16 bits. The Ada RM does allow this, but I am  
> > pretty sure GNAT counts on integer being 32 bits.
> 
> OK. So the user should be warned (by documentation and the compiler) 
> when he tries to use the Ada frontent with backend that can set 
> INT_TYPE_SIZE to 16, right?

Getting GNAT to be hosted on a 16 bit machine is probably not
workable. On the other side, targetting a 16 bit machine from a >= 32
bit host should be doable for Ada.

> A 'grep INT_TYPE_SIZE' lists avr, h8300, ip2k, m68hc11, m68k,
> pdp11 and stormy16 as possible candidates for such a warning.

I believe Stéphane Carrez was able to run some Ada on a m68hc11,
see http://gel.sourceforge.net/ada_example.php

Laurent

Re: [Ada] Standard.Interger'Size = 32?

[Robert Dewar]

Laurent GUERBY wrote:
Getting GNAT to be hosted on a 16 bit machine is probably not
workable. On the other side, targetting a 16 bit machine from a >= 32
bit host should be doable for Ada. 
No question about that, the issue is whether type Integer can
or cannot be 16 bits. As I said before, I suspect that making
Integer 16 bits, while certainly possible, would not be easy,
and you would find numerous issues to be fixed in the run time.
Of course if you write bare bones programs not using the run
time things should be much easier.

Re: [Ada] Standard.Interger'Size = 32?

[Robert Dewar]

Bernd Trog wrote:
A 'grep INT_TYPE_SIZE' lists avr, h8300, ip2k, m68hc11, m68k,
pdp11 and stormy16 as possible candidates for such a warning.
Note that there is a standard port of GNAT for the m68k, which
is used by some large scale customers, but it does have
integer'size set as 32.

Statically linking fortify functions

[Mike Hearn]

Hi,

When using FORTIFY_SOURCE I think some new symbols are required from very
recent glibcs. This makes sense when you are compiling binaries just for
your own system or distribution but it'd be nice to be able to statically
link this code (the *_chk functions etc) so fortified binaries can be run
on older systems. Is this possible? If so, how do you do it?

thanks -mike

Bug in libiberty configure

[Sam Lauber]

I am configuring `libiberty', but during `libiberty' 
configure on DJGPP (without a working vfork), configure 
reports that I have a working vfork.  This is a bug in 
configure.ac.  

Samuel Lauber
-- 
_
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze

PATCH RFA: Use years for ChangeLog names

[Ian Lance Taylor]

As originally proposed here:
http://gcc.gnu.org/ml/gcc/2005-01/msg00031.html

I propose switching the ChangeLogs to use year-based names rather than
numeric indexes.

Specifically, I propose adding these files:

ChangeLog-1997: from last part of ChangeLog.0
ChangeLog-1998: from first part of ChangeLog.0 and last part of ChangeLog.1
ChangeLog-1999: from first part of ChangeLog.1 and all of ChangeLog.2
ChangeLog-2000: from ChangeLog.3 and ChangeLog.4
ChangeLog-2001: from ChangeLog.5 and ChangeLog.6
ChangeLog-2002: from ChangeLog.7 and ChangeLog.8
ChangeLog-2003: from ChangeLog.9 and ChangeLog.10
ChangeLog-2004: from ChangeLog.11 and ChangeLog.12

There is one entry at the end of ChangeLog.11 which would move into
ChangeLog-2003 rather than ChangeLog-2004.

Then these files would be removed:

ChangeLog.0
ChangeLog.1
ChangeLog.2
ChangeLog.3
ChangeLog.4
ChangeLog.5
ChangeLog.6
ChangeLog.7
ChangeLog.8
ChangeLog.9
ChangeLog.10
ChangeLog.11
ChangeLog.12

Going forward, in early July of each year ChangeLog would be moved
into ChangeLog-.  Then in early January, ChangeLog would be moved
to the front of ChangeLog-.

The intent of this patch is to make it easier to find old ChangeLog
entries when you know the approximate date.  Rather than having to
remember the association of ChangeLog indexes and years, you can just
look at the ChangeLog for the appropriate year.  This is also how some
other GNU programs organize their ChangeLog files, including libhava
and libstdc++-v3.

When I proposed this a couple of months ago, Hans-Peter objected:
http://gcc.gnu.org/ml/gcc/2005-01/msg00640.html
I honestly didn't understand the objection.  Hans-Peter, let me know
if you want to try again to explain it.

If this patch is approved, I will follow up with a similar patch for
gcc/cp/ChangeLog*.  In fact, perhaps that one could be pre-approved.

Ian

SVN Repo updated (please look)

[Daniel Berlin]

Due to some massive speedups i've implemented in cvs2svn, the full gcc
repo, including all non-broken tags (more in a moment), is now
available.  It would have taken ~7 days before, and now it takes less
than 2 (it's almost completely disk bound now, and my 7200rpm disks just
aren't fast enough apparently :P)

This is what one should expect our converted gcc repo to look like, plus
a hooks directory at the base, and maybe wwwdocs (this is still up in
the air).

The following branch was excluded due to rtag -F issues:

x86-64-branch

Unless someone *wants* this branch, i would exclude it from the actual
converted repo as well. I can make this branch work with some amount of
work, but it would really have to be worth it :P


The following tags were excluded, for the noted reasons:

.*-ss-.* snapshot tags, which we agreed were not necessary

.*_ss_.* ditto

gcc-3_2-rhl8-branchpointrtag -F usage (this is just the branch point,
*not* the actual branch

pchmerge-branchpointrtag -F usage

meisner-ppc-modsrtag -F usage

cfg-postmerger-20020701 rtag -F usage

cxx-reflexion-merge.*   rtag -F usage (this looks like a messup of the
cxx-reflection-merge tags)

two cxx-reflection-merge tags  rtag -F usage


Same policy. Unless someone wants these specific tags, i would exclude
them from the actual converted repo as well.

Again, this is what one should expect the final converted repo to look
like.


I have converted most all of our scripts at this point, and verified
they work trivially (IE that changing something in www makes it update
the www dir)

The main waiting thing at htis point is for subversion 1.2 and for
sourceware to get new hardware.

--Dan

Re: PATCH RFA: Use years for ChangeLog names

[Sam Lauber]

> As originally proposed here:
>  http://gcc.gnu.org/ml/gcc/2005-01/msg00031.html
> 
> I propose switching the ChangeLogs to use year-based names rather than
> numeric indexes.
> 
> Specifically, I propose adding these files:
> 
> ChangeLog-1997: from last part of ChangeLog.0
> ChangeLog-1998: from first part of ChangeLog.0 and last part of ChangeLog.1
> ChangeLog-1999: from first part of ChangeLog.1 and all of ChangeLog.2
> ChangeLog-2000: from ChangeLog.3 and ChangeLog.4
> ChangeLog-2001: from ChangeLog.5 and ChangeLog.6
> ChangeLog-2002: from ChangeLog.7 and ChangeLog.8
> ChangeLog-2003: from ChangeLog.9 and ChangeLog.10
> ChangeLog-2004: from ChangeLog.11 and ChangeLog.12
> 
> There is one entry at the end of ChangeLog.11 which would move into
> ChangeLog-2003 rather than ChangeLog-2004.
> 
> Then these files would be removed:
> 
> ChangeLog.0
> ChangeLog.1
> ChangeLog.2
> ChangeLog.3
> ChangeLog.4
> ChangeLog.5
> ChangeLog.6
> ChangeLog.7
> ChangeLog.8
> ChangeLog.9
> ChangeLog.10
> ChangeLog.11
> ChangeLog.12
> 
> Going forward, in early July of each year ChangeLog would be moved
> into ChangeLog-.  Then in early January, ChangeLog would be moved
> to the front of ChangeLog-.
> 
> The intent of this patch is to make it easier to find old ChangeLog
> entries when you know the approximate date.  Rather than having to
> remember the association of ChangeLog indexes and years, you can just
> look at the ChangeLog for the appropriate year.  This is also how some
> other GNU programs organize their ChangeLog files, including libhava
> and libstdc++-v3.
> 
> When I proposed this a couple of months ago, Hans-Peter objected:
>  http://gcc.gnu.org/ml/gcc/2005-01/msg00640.html
> I honestly didn't understand the objection.  Hans-Peter, let me know
> if you want to try again to explain it.
I'm not him, but everybody in the world dosen't agree about 
things.  Some of us disagree and think things are enough.  
> If this patch is approved, I will follow up with a similar patch for
> gcc/cp/ChangeLog*.  In fact, perhaps that one could be pre-approved.
I would like that.  Since ChangeLogs are primarily for 
historical intrest, a year would make it easier to find.  

Samuel Lauber
-- 
_
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze

Re: [PING] [PATCH]: New Port(MAXQ)

[Mark Mitchell]

Giovanni Bajo wrote:
Mark, how does this port fit in the 4.1 plan? Since it is totally
self-contained (it does not modify anything in GCC proper but the usual
configuration additions), I think it could be merged any time, assuming a
global maintainer can spend some time on a review. To be fair, this patch was
posted last December with mainline in Stage 3 (and got almost no comments), so
if the patch is approved, it could be added to 4.0 too (given absolutely zero
risk).
We've allowed new ports to go in on release branches before, if they 
don't modify target-independent code in any substantial way, and I don't 
see any reason to modify this policy.  The same certainly goes for 4.1. 
 As you say, what's needed is a reviewer.

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

gcc-4.1-20050306 is now available

[gccadmin]

Snapshot gcc-4.1-20050306 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050306/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.1 CVS branch
with the following options:  -D2005-03-06 17:43 UTC

You'll find:

gcc-4.1-20050306.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20050306.tar.bz2 C front end and core compiler

gcc-ada-4.1-20050306.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20050306.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20050306.tar.bz2  C++ front end and runtime

gcc-java-4.1-20050306.tar.bz2 Java front end and runtime

gcc-objc-4.1-20050306.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20050306.tar.bz2The GCC testsuite

Diffs from 4.1-20050227 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: PATCH RFA: Use years for ChangeLog names

[Joseph S. Myers]

On Sun, 6 Mar 2005, Ian Lance Taylor wrote:

> look at the ChangeLog for the appropriate year.  This is also how some
> other GNU programs organize their ChangeLog files, including libhava
> and libstdc++-v3.

Not consistently, however.  libjava/ChangeLog-1999 has entries from 1998, 
libjava/ChangeLog-2001 has entries from 2000, libstdc++-v3/ChangeLog-2000 
has entries from 1998 and 1999.  Perhaps a followup patch could also fix 
those?

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: SVN Repo updated (please look)

[Joseph S. Myers]

On Sun, 6 Mar 2005, Daniel Berlin wrote:

> I have converted most all of our scripts at this point, and verified
> they work trivially (IE that changing something in www makes it update
> the www dir)

Could the current patches to the scripts in contrib/ and 
maintainer-scripts/, wwwdocs/bin if done and the replacement hooks for 
handling commits with auto-checkout (wwwdocs) and mailing to lists (both 
wwwdocs and gcc) and the proposed web page changes to be made during and 
after conversion be posted (or such subset of them as has been done) so 
they can be reviewed before the conversion?

> The main waiting thing at htis point is for subversion 1.2 and for
> sourceware to get new hardware.

At what stage will new mirroring arrangements be discussed with the 
savannah administrators?  The way I understand the basic steps for a final 
conversion  has savannah 
mirroring set up from the start of the new repository (so that almost all 
anonymous users - once they see the README-MOVED-FROM-CVS-TO-SVN file 
checked in to toplevel just before conversion or see an announcement on 
gcc-announce - will from the beginning be using the mirror rather than 
having a lot on gcc.gnu.org as you would if mirroring was only set up some 
time after initial announcement).

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: PATCH RFA: Use years for ChangeLog names

[Ian Lance Taylor]

"Joseph S. Myers" <[EMAIL PROTECTED]> writes:

> On Sun, 6 Mar 2005, Ian Lance Taylor wrote:
> 
> > look at the ChangeLog for the appropriate year.  This is also how some
> > other GNU programs organize their ChangeLog files, including libhava
> > and libstdc++-v3.
> 
> Not consistently, however.  libjava/ChangeLog-1999 has entries from 1998, 
> libjava/ChangeLog-2001 has entries from 2000, libstdc++-v3/ChangeLog-2000 
> has entries from 1998 and 1999.  Perhaps a followup patch could also fix 
> those?

Sure, I'll volunteer to tackle that, if the first patch is approved.

Offlist Daniel Berlin mentioned that maybe any such renaming should
wait until we move to a version control system which supports file
renaming (if indeed we do move).  Personally I don't think it matters
since I don't think anybody really cares about doing "cvs log" or "cvs
annotate" (or equivalent) on a ChangeLog file.  But if anybody feels
differently, please speak up now.

Ian

Re: SVN Repo updated (please look)

[Daniel Berlin]

On Sun, 2005-03-06 at 18:34 +, Joseph S. Myers wrote:
> On Sun, 6 Mar 2005, Daniel Berlin wrote:
> 
> > I have converted most all of our scripts at this point, and verified
> > they work trivially (IE that changing something in www makes it update
> > the www dir)
> 
> Could the current patches to the scripts in contrib/ and 
> maintainer-scripts/, wwwdocs/bin if done and the replacement hooks for 
> handling commits with auto-checkout (wwwdocs) and mailing to lists (both 
> wwwdocs and gcc) and the proposed web page changes to be made during and 
> after conversion be posted (or such subset of them as has been done) so 
> they can be reviewed before the conversion?

Sure
I'll start posting them soon.


> 
> > The main waiting thing at htis point is for subversion 1.2 and for
> > sourceware to get new hardware.
> 
> At what stage will new mirroring arrangements be discussed with the 
> savannah administrators?  The way I understand the basic steps for a final 
> conversion  has savannah 
> mirroring set up from the start of the new repository (so that almost all 
> anonymous users - once they see the README-MOVED-FROM-CVS-TO-SVN file 
> checked in to toplevel just before conversion or see an announcement on 
> gcc-announce - will from the beginning be using the mirror rather than 
> having a lot on gcc.gnu.org as you would if mirroring was only set up some 
> time after initial announcement).

I have no clue how the savannah mirroring works now, or who to contact.
Pointers would be appreciated.

If they mirror via rsync, they just need to change the directory they
mirror from.
If they mirror via some other method, we'll need to replace that method
(which should not be hard, there are a myriad of ways to mirror an svn
repo)

Re: SVN Repo updated (please look)

[Joseph S. Myers]

On Sun, 6 Mar 2005, Daniel Berlin wrote:

> I have no clue how the savannah mirroring works now, or who to contact.
> Pointers would be appreciated.
> 
> If they mirror via rsync, they just need to change the directory they
> mirror from.
> If they mirror via some other method, we'll need to replace that method
> (which should not be hard, there are a myriad of ways to mirror an svn
> repo)

I think it's rsync.  I don't know who to contact, or whether savannah 
currently has subversion installed so it's an easy switch for them.

In any case, perhaps a note to gcc-announce that a move is proposed and 
people who use anoncvs or mirror the CVS tree might like to make sure they 
are ready (in particular, check whether subversion works on their 
platforms) would be a good idea well in advance.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: PATCH RFA: Use years for ChangeLog names

[Hans-Peter Nilsson]

On Sun, 6 Mar 2005, Ian Lance Taylor wrote:
> Going forward, in early July of each year ChangeLog would be moved
> into ChangeLog-.  Then in early January, ChangeLog would be moved
> to the front of ChangeLog-.

More natural would be to split off ChangeLog entries for the
previous year early January.

> When I proposed this a couple of months ago, Hans-Peter objected:
> http://gcc.gnu.org/ml/gcc/2005-01/msg00640.html
> I honestly didn't understand the objection.  Hans-Peter, let me know
> if you want to try again to explain it.

Nope.  If you feel strongly enough to rename and fiddle with the
old files, go ahead.  I still feel the change is unnecessary
(and as such should only apply to new splits) but I don't feel
strongly about it.

brgds, H-P

Re: SVN Repo updated (please look)

[Daniel Berlin]

On Sun, 2005-03-06 at 18:34 +, Joseph S. Myers wrote:
> On Sun, 6 Mar 2005, Daniel Berlin wrote:
> 
> > I have converted most all of our scripts at this point, and verified
> > they work trivially (IE that changing something in www makes it update
> > the www dir)
> 
> Could the current patches to the scripts in contrib/ and 
> maintainer-scripts/, wwwdocs/bin if done and the replacement hooks for 
> handling commits with auto-checkout (wwwdocs) and mailing to lists (both 
> wwwdocs and gcc) and the proposed web page changes to be made during and 
> after conversion be posted (or such subset of them as has been done) so 
> they can be reviewed before the conversion?
> 

The current hooks (I'm adding them over the next few hours) are at
svn://www.dberlin.org/hooks

Committing there will update the hooks dir on the repo.

Note that almost all of the checkout scripts are simply slightly
modified versions of synchooks.sh,

They no longer send out mail, since mailer.py does that.

mailer.conf needs a bit more configuration to get all the right messages
to the right mailing lists, but that's trivial.

Feel free to take a look.

Re: SVN Repo updated (please look)

[Daniel Berlin]

On Sun, 2005-03-06 at 18:53 +, Joseph S. Myers wrote:
> On Sun, 6 Mar 2005, Daniel Berlin wrote:
> 
> > I have no clue how the savannah mirroring works now, or who to contact.
> > Pointers would be appreciated.
> > 
> > If they mirror via rsync, they just need to change the directory they
> > mirror from.
> > If they mirror via some other method, we'll need to replace that method
> > (which should not be hard, there are a myriad of ways to mirror an svn
> > repo)
> 
> I think it's rsync.  I don't know who to contact, or whether savannah 
> currently has subversion installed so it's an easy switch for them.
> 
> In any case, perhaps a note to gcc-announce that a move is proposed and 
> people who use anoncvs or mirror the CVS tree might like to make sure they 
> are ready (in particular, check whether subversion works on their 
> platforms) would be a good idea well in advance.
> 

I was under the impression that gcc-announce was moderated in some
manner, so that only certain people could send to it.
If someone who can, wants to send out a message mentioning the proposed
move (which i'm happy to prepare), please tell me who to send it to for
posting to gcc-announce.

Re: PATCH RFA: Use years for ChangeLog names

[Nathan Sidwell]

Hans-Peter Nilsson wrote:
On Sun, 6 Mar 2005, Ian Lance Taylor wrote:

When I proposed this a couple of months ago, Hans-Peter objected:
   http://gcc.gnu.org/ml/gcc/2005-01/msg00640.html
I honestly didn't understand the objection.  Hans-Peter, let me know
if you want to try again to explain it.

Nope.  If you feel strongly enough to rename and fiddle with the
old files, go ahead.  I still feel the change is unnecessary
(and as such should only apply to new splits) but I don't feel
strongly about it.
I think this would be excellent.  Many times I have had to go and do
some gcc archeology to find some patch to backport to some old version
of the compiler.  The disconnect between changelog file names and dates
is just one more thing that makes it an annoying process.
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

GCC generating invalid assembly

[Sam Lauber]

I compiled unexec.c from Emacs 21.3 with -O2, and I got the 
error from GNU as on line 1498:

Fatal error: C_EFCN symbol out of scope

I'm on the x86.  This only happens if all three of the 
following are satisfied

 1) -gcoff debugging information is being generated
 2) -funit-at-a-time is on
 3) -O is on

Turning off -O caused it to work fine.  Turning off 
-funit-at-a-time caused it to work fine.  Using a diffrent 
debugging information format caused it to work fine.  

Samuel Lauber

-- 
_
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.

Powered by Outblaze

Re: SVN Repo updated (please look)

[Joseph S. Myers]

On Sun, 6 Mar 2005, Daniel Berlin wrote:

> mailer.conf needs a bit more configuration to get all the right messages
> to the right mailing lists, but that's trivial.

(And to ensure that the messages have the right sender address, i.e. 
[EMAIL PROTECTED] (not @sourceware.org).)

I notice the facility to send diffs, so after conversion to SVN fixing bug 
1634 (request for gcc-cvs-patches list) will be trivial.  (I'd suggest not 
doing this until the conversion is live and working, as this is a new 
feature and so not needed for the conversion.  As I understand the script 
for generating diffs it won't include the content of a file being copied 
with no changes, so it should be safe to configure it to send diffs for 
all of add, copy, modify and delete without generating excessively large 
diffs for routine tag/branch operations.)

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: Pascal front-end integration

[Joseph S. Myers]

On Sun, 6 Mar 2005, Frank Heckenbach wrote:

> So to make it short, for my own productive work I'm not going to use
> gpc with a backend that hasn't been tested with gpc for at least
> several months. Therefore, I'm not going to do my own frontend work
> on such a version, as I want to be able to try it immediately. So if
> you think dropping older backends is the only way to support 4.x, a
> fork would be inevitable. But I'm not convinced this is really
> necessary.

Testing for 4.x and making stable with 4.x is the sort of thing naturally 
done on a branch.  This is what was done in GCC CVS on the tree-ssa 
branch: support for the old way of doing things was replaced with support 
for the new, while changes made in mainline were regularly merged to the 
tree-ssa branch.

As I understand it, James Morrison has proposed to do more or less that, 
though in his own repository since GPC lacks a public repository: port to 
the 4.x back end and merge in changes made to mainline GPC until there is 
a stable 4.x-based front end aligned with the mainline GPC front end.

> So IMHO the best thing for a smooth transition would be to add 4.x
> support as far as we can, with conditionals, so everyone can test it
> and we can drop earlier backend as soon as (safely) possible.

If you can make such conditionals work, then fine.  I'm just doubtful of 
how clean the result will be given the extent of the changes to the 
front-end interface with tree-ssa, and as soon as it goes in GCC CVS it's 
inevitable changes tested only with GCC CVS will happen to break support 
for some previous back end.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: SVN Repo updated (please look)

[Daniel Berlin]

On Sun, 6 Mar 2005, Joseph S. Myers wrote:
On Sun, 6 Mar 2005, Daniel Berlin wrote:
mailer.conf needs a bit more configuration to get all the right messages
to the right mailing lists, but that's trivial.
(And to ensure that the messages have the right sender address, i.e.
[EMAIL PROTECTED] (not @sourceware.org).)
I notice the facility to send diffs, so after conversion to SVN fixing bug
1634 (request for gcc-cvs-patches list) will be trivial.  (I'd suggest not
doing this until the conversion is live and working, as this is a new
feature and so not needed for the conversion.  As I understand the script
for generating diffs it won't include the content of a file being copied
with no changes, so it should be safe to configure it to send diffs for
all of add, copy, modify and delete without generating excessively large
diffs for routine tag/branch operations.)
I actually turned this off on purpose to match what we do now.
You can tell it to suppress adds and delete diffs, we can add diff limits, 
etc.
Unlike our current ad-hoc scripts, mailer.py is very easy to modify.

--Dan

Re: SVN Repo updated (please look)

[Joseph S. Myers]

On Sun, 6 Mar 2005, Daniel Berlin wrote:

> The main waiting thing at htis point is for subversion 1.2 and for

With regard to this point, will accessing the repository via SVN protocols 
need 1.2 on the client, or will it only be needed on the server and if 
mirroring the repository?

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: SVN Repo updated (please look)

[Joseph S. Myers]

On Sun, 6 Mar 2005, Daniel Berlin wrote:

> I actually turned this off on purpose to match what we do now.
> You can tell it to suppress adds and delete diffs, we can add diff limits,
> etc.
> Unlike our current ad-hoc scripts, mailer.py is very easy to modify.

I think matching what we do now is quite correct for the initial 
conversion.  gcc-svn-patches should be a separate list from the present 
gcc-cvs rather than suddenly starting to send much larger messages to the 
gcc-cvs subscribers.  I don't think gcc-svn-patches needs to have any 
message size limit (or if it does it should be very large, e.g. 50MB) 
though it might be worth considering sending diffs more than say 1MB as 
compressed attachments if that's reasonably simple to do.  But we can 
refine gcc-svn-patches later, including such things as attaching binary 
files for which we can't send diffs and attaching diffs for non-UTF-8 
files (some message catalogs and testcases) to avoid problems with 
messages claiming to be in UTF-8 which aren't.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

successfully built gnu 3.4.3

[Henddher Pedroza]

/config.guess
 i686-pc-linux-gnu

linux:/usr/local/bin # ./gcc -v
Reading specs from
/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure
Thread model: posix
gcc version 3.4.3


linux:/etc/hotplug # cat /etc/issue

Welcome to SuSE Linux 9.1 (i586) - Kernel \r (\l).


linux:/usr/local/bin # uname -a
Linux linux 2.6.4-52-default #1 Wed Apr 7 02:08:30 UTC
2004 i686 i686 i386 GNU/Linux

linux:/etc/hotplug # rpm -q glibc
glibc-2.3.3-97



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: SVN Repo updated (please look)

[Daniel Berlin]

On Sun, 6 Mar 2005, Joseph S. Myers wrote:
On Sun, 6 Mar 2005, Daniel Berlin wrote:
The main waiting thing at htis point is for subversion 1.2 and for
With regard to this point, will accessing the repository via SVN protocols
need 1.2 on the client, or will it only be needed on the server and if
mirroring the repository?
It's not strictly necessary.
It will, however, give you significnat speedups.
All clients 1.0.x+ will work against all servers 1.0.x+ and vice versa.
AFIAK

Re: RFC: Plan for cleaning up the "Addressing Modes" macros

[Ian Lance Taylor]

Zack Weinberg <[EMAIL PROTECTED]> writes:

> So, the plan: Step 1 introduces - one at a time - target hooks
> corresponding to each of the above macros.  All callers are changed to
> use the hooks.  The default definitions of the hooks invoke the
> existing macros.  The hardest part of this is working out exactly what
> their sole callers expect of LEGITIMIZE_ADDRESS and
> LEGITIMIZE_RELOAD_ADDRESS.  The manual, unfortunately, is not very
> clear.  I think that in both cases it amounts to "either replace X
> with a new value and jump to WIN, or leave X unmodified and drop
> through", which can be translated to "return a new value for X, or
> NULL", but I'm not sure, particularly about LEGITIMIZE_RELOAD_ADDRESS
> and its interaction with push_reload.

I'm replying to a week old message here--I may have missed something
in the interim.

I think this change is a great idea.  I want to point out something
you probably already noticed: some definitions of
LEGITIMIZE_RELOAD_ADDRESS rely on the fact that they appear in
reload.c in the only caller, find_reloads_address.  For example, the
definition in avr.h calls make_memloc, which is a static function in
reload.c.  I thought there was at least one other case, but maybe it
has been fixed.

In general writing LEGITIMIZE_RELOAD_ADDRESS requires a good knowledge
of what reload does and does not do.  It is possible to call
push_reload on some portion of X, not change X, and still jump to WIN.
This would be appropriate if the default reloading of operands isn't
optimal for some reason, but the address can indeed be reloaded.
E.g., alpha_legitimize_reload_address, or the definition in avr.h.
That said, a hook in which returning non-NULL should trigger "goto
win" would be perfectly reasonable.  The troubling case would be one
which modified X and did *not* jump to WIN.  While that is
theoretically possible, it is unnecessary--if you know how to reload
the address, it's a lot simpler to call push_reload yourself than to
construct something which will cause find_reloads_address to make the
right calls.

Ian

re: GCC generating invalid assembly

[Dan Kegel]

[EMAIL PROTECTED] wrote:
I compiled unexec.c from Emacs 21.3 with -O2, and I got the 
error from GNU as on line 1498:

Fatal error: C_EFCN symbol out of scope
I'm on the x86.  This only happens if all three of the 
following are satisfied

 1) -gcoff debugging information is being generated
 2) -funit-at-a-time is on
 3) -O is on
Turning off -O caused it to work fine.  Turning off 
-funit-at-a-time caused it to work fine.  Using a diffrent 
debugging information format caused it to work fine. 
You forgot to say which version of gcc.
Is this maybe http://gcc.gnu.org/PR9963 ?
- Dan
--
Trying to get a job as a c++ developer?  See 
http://kegel.com/academy/getting-hired.html

Re: GCC generating invalid assembly

[Andrew Pinski]

On Mar 6, 2005, at 6:39 PM, Dan Kegel wrote:
[EMAIL PROTECTED] wrote:
I compiled unexec.c from Emacs 21.3 with -O2, and I got the error 
from GNU as on line 1498:
Fatal error: C_EFCN symbol out of scope
I'm on the x86.  This only happens if all three of the following are 
satisfied
 1) -gcoff debugging information is being generated
 2) -funit-at-a-time is on
 3) -O is on
Turning off -O caused it to work fine.  Turning off -funit-at-a-time 
caused it to work fine.  Using a diffrent debugging information 
format caused it to work fine.
You forgot to say which version of gcc.
Is this maybe http://gcc.gnu.org/PR9963 ?
Also note that -gcoff is not really tested or supported any more, 
especially
on elf targets.  I would not use it at all.  stabs or dwarf-2 is more
supported formats.  Dwarf-2 support is also in the current version of 
gcc
for cygwin.

-- Pinski

tag request

[Alfonso Urdaneta]

I'd like to start hacking on osx gcc.  What tag is recommented to check 
out ?  Also, what areas need work most?  I'm an experienced programmer, 
but I know jack about gcc.

--
alfonso e. urdaneta
www.red82.com - are you ready ?

Re: PATCH RFA: Use years for ChangeLog names

[Mark Mitchell]

Nathan Sidwell wrote:
Hans-Peter Nilsson wrote:
On Sun, 6 Mar 2005, Ian Lance Taylor wrote:

When I proposed this a couple of months ago, Hans-Peter objected:
   http://gcc.gnu.org/ml/gcc/2005-01/msg00640.html
I honestly didn't understand the objection.  Hans-Peter, let me know
if you want to try again to explain it.

Nope.  If you feel strongly enough to rename and fiddle with the
old files, go ahead.  I still feel the change is unnecessary
(and as such should only apply to new splits) but I don't feel
strongly about it.

I think this would be excellent.  Many times I have had to go and do
some gcc archeology to find some patch to backport to some old version
of the compiler.  The disconnect between changelog file names and dates
is just one more thing that makes it an annoying process.
I agree.  And, I'm not worried about file-renaming affecting ChangeLogs. 
 As you say, nobody does "cvs log" on ChangeLogs, and, anyhow, since 
we've been rotating stuff out of ChangeLog into ChangeLog.X, there are 
odd discontinuities.  So your patch/plan is approved.

(A more controversial plan would be to then put ChangeLog entries into 
ChangeLog. in the first place, rather than putting them in ChangeLog 
and moving them, but I realize that this is (a) contrary to the GNU 
coding standards, and (b) not as friendly to some editors.)

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: tag request

[Ed Smith-Rowland]

> I'd like to start hacking on osx gcc. What tag is recommented to 
check out ? Also, what areas > need work most? I'm an experienced 
programmer, but I know jack about gcc.
>

--
alfonso e. urdaneta
www.red82.com - are you ready ?
I would work on mainline.  It bootstraps just fine - usually ;-) - on 
MacOSX.
This is where all the interesting new work goes on (by definition).
Watch the list and see what people are talking about.
One thing of particular interest for MacOSX GCC is getting ObjC++ front end 
integrated
into mainline.  It seems Apple is interested in this but doesn't have time for 
it.  The
GNUStep people are also interested.
Good Luck!
Ed Smith-Rowland

Re: Question w.r.t. `'class Foo' has virtual functions but non-virtualdestructor` warning.

[Gabriel Dos Reis]

Chris Lattner <[EMAIL PROTECTED]> writes:

| Karel Gardas wrote:
| > Yes, that's undefined, but I just define this class to be able to do:
| > Foo* f = dynamic_cast(x);
| > l = f->iiop_version();
| > there is nothing like delete involved. Anyway, I agree with you that
| > emit warning about this is probably the right thing to do and so I
| > will fix my code.
| 
| I've run into this warning with C++ code as well, and it is quite
| annoying.

Quite very annoying.  

[...]

| It seems that the warning could be improved to be emitted when the
| *delete* is seen of a class without a virtual dtor (but that does have

Agreed.

-- Gaby

Re: Question w.r.t. `'class Foo' has virtual functions but non-virtualdestructor` warning.

[Gabriel Dos Reis]

Mark Mitchell <[EMAIL PROTECTED]> writes:

[...]

| > It seems that the warning could be improved to be emitted when the
| > *delete* is seen of a class without a virtual dtor (but that does
| > have virtual methods).  If you never actually do the questionable
| > behavior, you'd never get the warning.  It seems like a bug to emit
| > it for the class definition.
| 
| Age-old debate: better to warn early about possibly broken interfaces,
| or late about definitely broken usage?  I think that warning early,
| together with what DJ is calling fine-grained warning control is the
| best solution.

When that is a nuisance, I don't see how it is best solution.

-- Gaby

Re: Question w.r.t. `'class Foo' has virtual functions but non-virtualdestructor` warning.

[Gabriel Dos Reis]

Joe Buck <[EMAIL PROTECTED]> writes:

| On Fri, Mar 04, 2005 at 08:06:27PM -0600, Chris Lattner wrote:
| > In my mind, the times you want to silence the warning (without defining 
| > the virtual dtor) are when you *know* that it will never be used that way, 
| > because it's part of the contract of the class.
| 
| In my view, if a class defines virtual functions, then this implies
| that the class is intended to be derived from, so a non-virtual

I agree that implies that it is class that is intended to be derived
from; but that does not imply it is a class intended to be used as
"delete argument". 

Here, we have lots of classes here of that type -- interface classes +
implementation classes with no resource management.  Adding a virtual   
destructor just to silent a misguided warning is close to "silly
compiler" in my book.

| destructor is asking for trouble and should be warned about, even
| if there is no "delete".

-- Gaby

Re: Question w.r.t. `'class Foo' has virtual functions but non-virtualdestructor` warning.

[Gabriel Dos Reis]

David Carlton <[EMAIL PROTECTED]> writes:

| On Fri, 04 Mar 2005 19:15:41 -0600 (CST), Chris Lattner <[EMAIL PROTECTED]> 
said:
| 
| > It's not a matter of warning vs not warning: it's a matter of
| > emitting bogus warnings *sometimes* when you can emit the proper
| > warning *all of the time*.
| 
| I don't think you can emit the proper warning all of the time on
| destruction, either:
| 
| void deleteB( B *obj ) {
|   delete obj;
| }
| 
| If B is a base class with a non-virtual destructor, then this is safe
| if obj's dynamic type is B, unsafe otherwise.

That is correct; but the number of false positive is reduced --
significantly in case where those classes appear in header files.

-- Gaby

Re: PowerPC 64 x 32 bits performance

[Alan Modra]

On Fri, Mar 04, 2005 at 04:59:25PM -0600, Edmar Wienskoski wrote:
> and notice a considerable number of load instructions in the 64 bits one.
> 
> Does anyone have an insight on why this is happening ?

These are most likey 64-bit address constant loads.  On ppc32, a 32-bit
address constant can be calculated in at most 2 instructions.  A 64-bit
address takes up to 5 instructions to calculate in-line, or a TOC memory
load.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

A preliminary result of fold_buildN (memory usage included)

[Kazu Hirata]

Hi,

Here is a preliminary result for fold_buildN from my personal tree.  I
compiled cc1-i files with ./cc1 -quiet -O2 -fomit-frame-pointer
-fmem-report -o /dev/null.  I used --enable-gather-detailed-mem-stats
to see how many nodes and bytes we are allocating for trees.  (Thanks
Honza!)  I then summed up the memory usage of trees.

original   patched   diff%
#nodes24,234,58923,577,245 -2.712%
#bytes 1,228,797,315 1,205,528,427 -1.893%

As far as compile time, I consistently see improvements of 0.1% or a
bit more.

In case you are wondering what fold_buildN is,

  fold_build1 (code, type, op0)

is equivalent to

  fold (build (code, type, op0))

except that fold_build1 does not build a scratch node when folding is
successful.  fold_build2 operates in a similar way.

Note that ternary expressions did not take advantage of this
fold_build3 mechanism because of the handling of CALL_EXPR in
fold_ternary.  Since ternary expressions are not as common as binary
expressions, I don't except much difference even after we start using
fold_build3.

Kazu Hirata

Java Classes and Non-virtual Destructors

[Ranjit Mathew]

Hi Mark,

  After your patch for PR c++/19733, there have been tonnes
of warnings during a libjava build complaining about "class
Foo has virtual functions but non-virtual destructor".

Here's a simple testcase:
-- 8< --
~/tmp > cat y.cpp
extern "Java"
{
  class Foo
  {
  public:
virtual void bar( void);
  };
}

~/tmp > mygxx -Wall -fsyntax-only y.cpp
y.cpp:4: warning: 'class Foo' has virtual functions but non-virtual destructor
-- 8< --

If I do add a virtual destructor, I get:
-- 8< --
~/tmp > mygxx -Wall -fsyntax-only y.cpp
y.cpp:7: error: Java class 'Foo' cannot have a destructor
-- 8< --

which is correct, AFAICT.

Therefore, can you please suppress the warning for a "Java"
C++ class?

Thanks,
Ranjit.

-- 
Ranjit Mathew  Email: rmathew AT gmail DOT com

Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/

Re: tag request

[Mike Stump]

On Sunday, March 6, 2005, at 05:17  PM, Alfonso Urdaneta wrote:
I'd like to start hacking on osx gcc.  What tag is recommented to 
check out ?  Also, what areas need work most?  I'm an experienced 
programmer, but I know jack about gcc.
You have a few choices.  Mainline is best, and what I would recommend.  
You might be interested in apple-ppc-branch, if you require something 
that more closely resembles a compiler that Apple might ship.  In 
addition, there are 3.4.x release branches and 4.0.x release branches...

What areas?  Ones that interest you would be best, as then you'l be 
more motivated to continue...  :-)  If you want ideas, there is a 
beginners page, plus, you could check out the projects page, or, you 
can wade through the bugs database...

And welcome.