98, it is! (was: C++ PATCH: PR 28261)

[Gerald Pfeifer]

On Tue, 17 Oct 2006, Mark Mitchell wrote:
> This patch fixes PR c++/28261, an ICE-on-invalid when an
> enum-definition appeared in an constructor parmeter declaration.

Unless I'm mistaken, this means we are down to less than 100 serious 
regressions!

(Richi has been giving me the current number twice a day recently, I
guess he'll open a big bottle of $BEVERAGE now. :-)

Gerald

Re: GCC 4.2 branch created; mainline open in Stage 1

[Gerald Pfeifer]

On Tue, 24 Oct 2006, Robert Schwebel wrote:
> I don't understand yet how the next steps for 4.2 will look like; will
> there be further snapshots (ftp://gcc.gnu.org/pub/gcc/snapshots/) of the
> 4.2 branch, or will the next snapshots be only for 4.3?

The GCC 4.2 snapshots will now track the 4.2 release branch, and GCC 4.3
snapshots will be made from our mainline development tree.

So, going forward we will release snapshots of GCC 4.0, 4.1, 4.2, and 4.3.

I will probably reshuffle the days of the weeks the snapshots are built a
bit, and I don't know how long we'll do snapshots for GCC 4.0, but for the
time being it's these four snapshots a week.

> We would like to re-test our ARM, PowerPC and MIPS trees with the latest 
> compilers against well known revisions, in order to have a chance to 
> submit further bugs and/or patches before the release - or shall we 
> better test against svn?

Testing against SVN may be better in that you do not depend on the weekly
snapshots.  You just have to remember the revision your tests are based
on.  This you can get via "svn info".

Gerald

Re: gcc trunk

[Gerald Pfeifer]

Hi Murali,

On Thu, 26 Oct 2006, Murali Vemulapati wrote:
> what is the release number for gcc trunk (mainline)? currently there
> are two branches 4.2.0 and 4.3.0 which are accepting patches.

we tried to provide this information on our main web page at
http://gcc.gnu.org.  If this does not relay this sufficiently
clear, please let us know what's confusing and I'll see what
I can do about it!

Gerald

Re: memory benchmark of tuples branch

[Gerald Pfeifer]

On Thu, 26 Oct 2006, Aldy Hernandez wrote:
> Having analyzed about 8000 functions taken from Diego's .i sandbox (includes
> GCC files, spec files, and a potpourri of other .i files), here are the
> average memory savings:
> 
>   -O0:-0.243863%
>   -O1:-0.977962%
>   -02:-0.968168%
> 
> As we have hoped, every single function exhibits memory savings.  Yay.

When this goes in, please don't by shy and update gcc-4.3/changes.html;
and potentially submit a news entry for our main page as well -- we've
got way too few there... :-)

Gerald

Re: build failure, GMP not available

[Gerald Pfeifer]

On Mon, 30 Oct 2006, Geoffrey Keating wrote:
> configure: error: Building GCC requires GMP 4.1+ and MPFR 2.2+.  Try the
> --with-gmp and/or --with-mpfr options.

Indeed, as a user I ran into problems with this on a system where both of
these actually were installed.

This is because I had the run-time libraries, but not headers which at
some distros (such as openSUSE) are in different packages such as pkg.rpm
versus pkg-devel.rpm.

I predicit this is going to hit quite many naive users (such as myself).

Kaveh, would you mind looking into whether we could referine the autoconf
magic you added?  Something like first checking for the libraries being
present, and then for headers, and in the case we've got the former but
not the latter issue an appropriate warning?

Gerald

Re: gcc trunk

[Gerald Pfeifer]

On Thu, 26 Oct 2006, Brooks Moses wrote:
> I would say, on looking at it, that the order of items under "Status" is 
> slightly confusing; it seems to me that "Active Development" ought go 
> next to "Next Release Series".

That's a good point.

>From a user perspective, how about
 
  Current (4.1)
  Previous (4.0)
  Next (4.2)
  Active development (4.3)

Another alternative would be

  Active development (4.3)
  Next (4.2)
  Current (4.1)
  Previous (4.0)

which would be more regular of an order and more developer-centric.  
Thoughts?

Gerald

PS: The patch below implements the first proposal above.
  
  
 
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.582
diff -u -3 -p -r1.582 index.html
--- index.html  22 Oct 2006 14:33:33 -  1.582
+++ index.html  2 Nov 2006 13:09:18 -
@@ -101,21 +101,6 @@ interface for C, C++ and Fortran.
 
 
 
-Next release series:
-  GCC 4.2.0 (changes)
-
-  Status: Stage 3;
-  http://gcc.gnu.org/ml/gcc/2006-10/msg00390.html";>2006-10-17
-  (regression fixes and docs only).
-  
-  http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.2&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&;
 field0-0-0=noop&type0-0-0=noop&value0-0-0=">Serious
-  regressions.
-  http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.2&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-
 0=">All
-  regressions.
-
-
 Current release series:
   GCC 4.1.1
 
@@ -143,6 +128,21 @@ interface for C, C++ and Fortran.
   Regressions.
 
 
+Next release series:
+  GCC 4.2.0 (changes)
+
+  Status: Stage 3;
+  http://gcc.gnu.org/ml/gcc/2006-10/msg00390.html";>2006-10-17
+  (regression fixes and docs only).
+  
+  http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.2&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&;
 field0-0-0=noop&type0-0-0=noop&value0-0-0=">Serious
+  regressions.
+  http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.2&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-
 0=">All
+  regressions.
+
+
 Active development:
   GCC 4.3.0 (changes)
 

Re: build failure, GMP not available

[Gerald Pfeifer]

On Mon, 30 Oct 2006, Kaveh R. GHAZI wrote:
> Do we have a GCC FAQ somewhere?  Maybe we can add GMP/MPFR build problems
> and solutions there.  You can add your experiences to that collection.

, but I believe increasing the "intelligence"
of configure and documenting all this in doc/install.texi probably is the
better approach than adding something to this FAQ.

Gerald

RE: gcc trunk

[Gerald Pfeifer]

On Thu, 2 Nov 2006, Dave Korn wrote:
>> From a user perspective, how about
>> 
>>   Current (4.1)
>>   Previous (4.0)
>>   Next (4.2)
>>   Active development (4.3)
> Let's be user-centric.  Us developers can be expected to cope.

Okay. ;-)  Nobody else chimed in, so I went ahead and committed the
patch below.

Gerald

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.583
diff -u -3 -p -r1.583 index.html
--- index.html  6 Nov 2006 07:36:09 -   1.583
+++ index.html  12 Nov 2006 20:46:12 -
@@ -106,21 +106,6 @@ interface for C, C++ and Fortran.
 
 
 
-Next release series:
-  GCC 4.2.0 (changes)
-
-  Status: Stage 3;
-  http://gcc.gnu.org/ml/gcc/2006-10/msg00390.html";>2006-10-17
-  (regression fixes and docs only).
-  
-  http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.2&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&;
 field0-0-0=noop&type0-0-0=noop&value0-0-0=">Serious
-  regressions.
-  http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.2&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-
 0=">All
-  regressions.
-
-
 Current release series:
   GCC 4.1.1
 
@@ -148,6 +133,21 @@ interface for C, C++ and Fortran.
   Regressions.
 
 
+Next release series:
+  GCC 4.2.0 (changes)
+
+  Status: Stage 3;
+  http://gcc.gnu.org/ml/gcc/2006-10/msg00390.html";>2006-10-17
+  (regression fixes and docs only).
+  
+  http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.2&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&;
 field0-0-0=noop&type0-0-0=noop&value0-0-0=">Serious
+  regressions.
+  http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.2&target_milestone=4.0.4&target_milestone=4.1.2&target_milestone=4.2.0&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-
 0=">All
+  regressions.
+
+
 Active development:
   GCC 4.3.0 (changes)
 

Re: Abt long long support

[Gerald Pfeifer]

On Mon, 6 Nov 2006, Ian Lance Taylor wrote:
> gcc always supports "long long" for all targets.

I just noticed that while the base compiler may support "long long", this 
extension fails to interact well with at least one other extension: hash_map<>
in libstdc++.

Specifically, the following example program will fail to compile with 
  error: no match for call to '(const __gnu_cxx::hash) (const 
long long int&)'

Example program:

  #include 

  using namespace __gnu_cxx;

  typedef long long T;

  void f() {
hash_set t;

t.insert(1);
t.erase(1);
  }

Now filed as libstdc++/29898.

Gerald

PATCH for Re: Missing web link

[Gerald Pfeifer]

Bruce,

On Thu, 19 Oct 2006, Bruce Korb wrote:
> I was going to re-subscribe my dropped subscription to gcc-patches,
> but the only links (that I can find) on gcc.gnu.org lead to the archives,
> not to the subscription page.  Thanks - Bruce

I understand your immediate issue has been addressed already, but I agree
that there is something we should (and can) improve on the web pages.

The patch below, which I just installed, is my first attempt to do so.

  Add pointers to subscription instructions and list policies to the 
  beginning of the page.

Do you have further ideas that would have helped you?

Gerald

Index: lists.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v
retrieving revision 1.99
diff -u -3 -p -r1.99 lists.html
--- lists.html  21 Sep 2006 14:17:36 -  1.99
+++ lists.html  19 Nov 2006 14:43:31 -
@@ -16,6 +16,8 @@
 (and http://gcc.gnu.org/lists.html#searchbox";>searchable)
 as well as in
 ftp://gcc.gnu.org/pub/gcc/mail-archives/";>mbox format.
+Please make yourself familiar with our policies
+before subscribing and posting to these lists.
 
 
 
@@ -140,7 +142,7 @@ as well as in
 
 To post a message, just send mail to 
listname@gcc.gnu.org.
 
-Policies
+Policies
 
 Our lists have a maximum message size of 100KB, only the gcc-prs list
 allows for a larger maximum message size of 2MB.  If your message exceeds

Re: 4.1.1 spec files missing, FAQ misinformation

[Gerald Pfeifer]

On Wed, 4 Oct 2006, Daniel Jacobowitz wrote:
>>>  "This file can be found in the same directory that
>>>   contains cc1 (run gcc -print-prog-name=cc1 to find it)."
>>   I think that indicates someone trying to be overly clever when they
>> configured your gcc package.  Normally libdir and libexecdir point to the 
>> same
>> dir.  What output do you see from "gcc -v"?
> Not any more.   The default changed some time ago.  Some distributors
> configure them to the same location.
> 
> Jeff, for background, up until a few releases ago cc1 and specs would
> always be in the same directory.

Daniel, Dave, if one of you could have a look at 
  http://gcc.gnu.org/faq.html#rpath
and update that, that would be great!  If you prefer, just provide any 
edits/changes to me, and I'll take care of updating that web page, markup
and committing.

Thanks,

Gerald

Re: Announce: MPFR 2.2.1 is released

[Gerald Pfeifer]

On Sat, 2 Dec 2006, Kaveh R. GHAZI wrote:
> Gerald, would you please copy the mpfr-2-2.1 tarball to the gcc
> infrastructure directory and delete 2.2.0 and the cumulative patch from
> there?  Thanks. http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2

Sure -- done it is.

Gerald

PS: I will most probably be without Internet access for at least two
weeks starting on Monday; if we'd like to see such an update during
the period I recommend to ask [EMAIL PROTECTED], for example.

Re: compile time testsuite [Re: alias slowdown?]

[Gerald Pfeifer]

Hi Richie,

On Tue, 21 Nov 2006, Richard Guenther wrote:
> Public monitoring would be more useful.  If you have working single-file 
> testcases that you want be monitored for compile-time and memory-usage 
> just contact me and I can add them to the daily tester 
> (http://www.suse.de/~gcctest/c++bench/).

that's a neat one.  Would you mind adding this to the list of performance
testers at

  http://gcc.gnu.org/benchmarks/ 

?  That would be nice.

Honzo, you may want to add your memory tester to

  http://gcc.gnu.org/testing/

as well?

Thanks,
Gerald

Re: build failure, GMP not available

[Gerald Pfeifer]

Hi Kaveh,

On Thu, 16 Nov 2006, Kaveh R. GHAZI wrote:
> I'm wondering, can we can solve this with a better error message?  That
> should tickle enough brain cells to hopefully lower the chance of someone
> being bit by this.  Let me know your thoughts.

yes, this definitely looks like a very good approach.  The enhanced 
message in the patch certainly will help in such a situation.

Thanks a lot (and sorry for my delay in responding to this one)!

Gerald

Re: compile time testsuite [Re: alias slowdown?]

[Gerald Pfeifer]

On Tue, 21 Nov 2006, Diego Novillo wrote:
> With the exception of DLV and SPEC2000, we could probably add most of 
> them to the check-compile testsuite.  I don't know if Gerald would be 
> able to allow DLV to be included.

I am, unfortunately, not able to make it completely public but if further 
GCC developers in addition to you would like to use it for doing compiler 
work (like Honza and Richie have been doing, for example) that's surely 
fine.

Since I'll be mostly offline for the next few weeks, please do feel
free to share the sources with other GCC developers, Diego and Richie!

(The rules are simple: do not publish sources and let me know who you 
provided it to so that we can keep them informed in case we do some
relevant update/fix.  That's it. :-)

On Tue, 21 Nov 2006, Benjamin Kosnik wrote:
> I suppose for SPEC and DLV you could do the same thing that Cygnus used
> to do for the dejagnu testing of Perennial and Plum Hall... you could
> just require links and or env variables, and if the required
> links/directories/variables were not set, you'd skip it.

That sounds like a nice idea.

Gerald

Re: poisened macro definitions

[Gerald Pfeifer]

On Tue, 5 Dec 2006, Markus Franke wrote:
> I want to port an existing backend (based on version gcc-2.7.2.3) on the
> most recent release (gcc-4.1.1). During compilation process I get
> several messages about some poisened macro definitions. The macros which
> make problems are listed below:

In addition to the concrete suggestions others provided, let me note that 
this wouldn't be an issue were that backend upstream -- for backends in 
our tree, such updates happen automatically, which is one of the benefits
of donating code to the FSF GCC project.

Gerald

Re: should fastjar be built?

[Gerald Pfeifer]

On Wed, 27 Dec 2006, Jack Howarth wrote:
> I noticed that fastjar no longer appears to be built and installed on 
> darwin in gcc 4.2 branch or trunk. What is the status of this utility 
> for gcc?

It was removed earlier this year:

  http://gcc.gnu.org/ml/java-patches/2006-q1/msg00381.html

Gerald

Re: configuration options policy (at toplevel or only inside gcc/)?

[Gerald Pfeifer]

On Thu, 14 Dec 2006, Basile STARYNKEVITCH wrote:
> I really think that such information should go into GCC internal
> documentation, where I was not able to find it out. Do you believe
> that some of the descriptions in this thread and in the Wiki page just
> cited should go into the documentation? Is the documentation expected
> to help new GCC contributors, or is it only for users?

Both.  As far as contributors go, most documentation on processes etc.
is on our web pages and the Wiki, whereas documentation of internals
is in the texinfo documentation (and source code, of course ;-).

> In particular, IMHO the commands to re-generate the configure scripts 
> should be documented if the documentation also targets potential GCC 
> contributors.

I agree, that sounds useful.  DJ, Alexandre, Paolo, what's your take
on this.  Any recommendations?

> I could write (by copying phrases from the wiki page) a few sentences
> into the documentation (gcc/doc/sourcebuild.texi)? Is it worthwhile;
> in other words for whom is this documentation written: for users of
> GCC (including the few people compiling GCC to use it) or for
> potential contributors (GCC hackers)?

Both. ;-)  Let's see what our configury maintainers think about your
proposal.

Thanks,
Gerald

Re: Question on BOOT_CFLAGS vs. CFLAGS

[Gerald Pfeifer]

On Fri, 15 Dec 2006, Paolo Bonzini wrote:
>>> http://gcc.gnu.org/install/build.html
> The counter quote is obviously wrong, thanks for the report.

If I see this correctly, Mike's quote came from our installation 
documentation in gcc/doc/install.texi.  Are you going to have a
stab at that, based on Mike's report?

Gerald

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Gerald Pfeifer]

On Sun, 31 Dec 2006, Robert Dewar wrote:
> If you do it in signed expecting wrapping, then the optimization
> destroys your code. Yes, it is technically your fault, but this
> business of telling users
> 
> "sorry, your code is non-standard, gcc won't handle it as you
> expect, go fix your code"

My understanding of previous messages in this thread was that other
compilers (like ICC) do enable the optimization we are talking about
here by default.

Did I misunderstand?

Gerald

Re: [PATCH] Relocated compiler should not look in $prefix.

[Gerald Pfeifer]

On Tue, 12 Dec 2006, Mark Mitchell wrote:
> If you want to make a patch, and Gerald approves it, it's fine by me.
> But, fwprop is described as a new feature (faster compiler, better
> code), and the build system affects people building the compiler.  The
> change we're talking about seems to affect only people debugging the
> compiler.

I think these indeed are relevant differences.  At the same time, I am 
sure there are GCC hackers/power users in addition to those regularily 
reading all of gcc@ and gcc-patches@, and it may be desirable to announce 
such changes to them as well.

So, how about adding a section "Developer-relevant Changes" at the end of 
gcc-4.2/changes.html?

Andrew, if you want to hack up a patch towards that end, I'll be glad to 
review/approve (unless some others strongly disagree, in which we'll need
to consider this in more detail).

Gerald

Re: GCC optimizes integer overflow: bug or feature?

[Gerald Pfeifer]

On Tue, 19 Dec 2006, Ian Lance Taylor wrote:
> Here is a quick list of optimizations that mainline gcc performs which
> rely on the idea that signed overflow is undefined.  All the types
> are, of course, signed.  I made have made some mistakes.  I think this
> gives a good feel for the sorts of optimizations we can make with this
> assumption.

Thanks for compiling this exhaustive list, Ian!

Currently our documentation on -fwrapv is rather short and does not
provide examples or anything to provide such a feel:

  This option instructs the compiler to assume that signed arithmetic 
  overflow of addition, subtraction and multiplication wraps around
  using twos-complement representation.  This flag enables some 
  optimizations and disables others.  This option is enabled by default 
  for the Java front-end, as required by the Java language specification.

"This flag enables some optimizations and disables others" is all we
have.  I wonder whether you could perhaps add (part of) your list to
this documentation?  Or would that be too specific?

Gerald

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Gerald Pfeifer]

On Tue, 2 Jan 2007, Gabriel Dos Reis wrote:
>|>   for (i = 1; i < m; ++i)
>|> {
>|>   if (i > 0)
>|> bar ();
>|> }
>| Of course, this is an example where either the programmer is doing 
>| something very silly or else is expecting overflow and depending on 
>| wrap semantics, so it seems to me marginal to remove that "if".  My 
>| suggestion would be to issue a warning saying that the test will never 
>| be false, but leaving it in.
> That make sense to me.

I'm worried about our ability to optimize deeply inlined code and things 
like template-heavy C++ code if do skip optimizations like this.

Gerald

Re: mpfr issues when Installing gcc 3.4 on fedora core

[Gerald Pfeifer]

On Thu, 4 Jan 2007, Matt Fago wrote:
>>From: drizzle drizzle <[EMAIL PROTECTED]>
>>
>>svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc_3_4_6_release
> This is checking out the latest trunk, not version 3.4. The last argument 
> only changes the name of the directory name on your local machine. The 
> 'svn://'  is what specifies the tag (in this case 'trunk').

Drizzle drozzle, booble bubble, or whatever,

please refer to our fine documentation at http://gcc.gnu.org/svn.html#tags
for how to check out using SVN.

For releases, you can also obtain tarballs from 
http://gcc.gnu.org/mirrors.html.

Gerald

PATCH for Re: 3 new GCC mirrors

[Gerald Pfeifer]

On Thu, 21 Dec 2006, Marco Rinaudo - Internet.bs Corp. wrote:
> I am pleased to announce 3 new GCC mirrors located in London (UK), Hong 
> Kong and Toronto (CANADA), daily resync.

Thanks!  These servers seem to be well connected.

> Please feel free to add the 3 mirrors to the official list of mirrors
> located here: http://gcc.gnu.org/mirrors.html

I just committed the patch below to properly document this.

Gerald

Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.176
diff -u -3 -p -r1.176 mirrors.html
--- mirrors.html3 Jan 2007 21:50:31 -   1.176
+++ mirrors.html4 Jan 2007 23:08:02 -
@@ -28,7 +28,9 @@ Key fingerprint = 90AA 4704 69D3 965A 87
 
 Austria: ftp://gd.tuwien.ac.at/gnu/gcc/";>gd.tuwien.ac.at, 
thanks to Antonin dot Sprinzl at tuwien dot ac dot at
 Brasil (no snapshots): ftp://ftp.softaplic.com.br/pub/sourceware/gcc/";>ftp.softaplic.com.br
+Canada, Toronto: http://gcc-ca.internet.bs";>http://gcc-ca.internet.bs, thanks to 
Internet.bs (info at internet dot bs)
 China: ftp://linuxforum.net/ftp.gcc.gnu.org/";>ftp://linuxforum.net/ftp.gcc.gnu.org/,
 thanks to David Deng (david99deng at yahoo dot com)
+China, Hong Kong: http://gcc-hk.internet.bs";>http://gcc-hk.internet.bs, thanks to 
Internet.bs (info at internet dot bs)
 France (no snapshots): ftp://ftp.lip6.fr/pub/gcc/";>ftp.lip6.fr, thanks to ftpmaint at lip6 
dot fr
 France, Brittany: ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/";>ftp.irisa.fr, thanks 
to ftpmaint at irisa dot fr
 France, Versailles: ftp://ftp.uvsq.fr/pub/gcc/";>ftp.uvsq.fr, 
thanks to ftpmaint at uvsq dot fr
@@ -45,6 +47,7 @@ Key fingerprint = 90AA 4704 69D3 965A 87
 Slovakia, Bratislava: http://gcc.fyxm.net/";>gcc.fyxm.net, 
thanks to Jan Teluch (admin at 2600 dot sk)
 Taiwan: ftp://ftp.nctu.edu.tw/computer-languages/C/gcc/";>ftp.nctu.edu.tw, 
thanks to ftpadm at ftp dot nctu dot edu dot tw
 UK: ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/";>ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/,
 thanks to mirror at mirrorservice dot org
+UK, London: http://gcc-uk.internet.bs";>http://gcc-uk.internet.bs, thanks to 
Internet.bs (info at internet dot bs)
 US, Virginia: ftp://mirrors.rcn.net/pub/sourceware/gcc/";>mirrors.rcn.net (also 
available via http://mirrors.rcn.net/pub/sourceware/gcc/";>http)
 US, St. Louis (no snapshots): ftp://mirrors.laffeycomputer.com/pub/gcc.gnu.org/pub/gcc/";>mirrors.laffeycomputer.com,
 thanks to mirrormaster at laffey dot biz
 

Re: Retiring IPA-branch

[Gerald Pfeifer]

On Tue, 2 Jan 2007, Jan Hubicka wrote:
> I would hope to retire that branch, since it has gained a lot of
> dust and also a lot of things has been renamed while merging to mainline
> making it outdated.

I assume you will update svn.html accordingly once this is done...

> At the end of stage 1 I would also like to open new branch targeted to
> further improvements and cleanups of IPA infrastructure that can
> co-exist in parallel with LTO branch solving other aspects we need to
> address before getting useable link time optimization.

...and when you are going to create the new branch?  ;-)

Gerald

Build snapshots according to a more regular schedule

[Gerald Pfeifer]

This is something I've had on my disk for a few months; committed and
also activated on gcc.gnu.org.

In case anyone wonders, the reason why some snapshot was created earlier
during the day was due to me debugging something at one point. :-)

Gerald

2007-01-05  Gerald Pfeifer  <[EMAIL PROTECTED]>

* crontab: Spread snapshots more evenly throughout the week, and
in "ascending" order.  Build all at the same time of the day.

Index: crontab
===
--- crontab (revision 120450)
+++ crontab (working copy)
@@ -1,7 +1,7 @@
 16  0 * * * sh /home/gccadmin/scripts/update_version_svn
 50  0 * * * sh /home/gccadmin/scripts/update_web_docs_svn
 55  0 * * * sh /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
-32 22 * * 4 sh /home/gccadmin/scripts/gcc_release -s 
4.0:branches/gcc-4_0-branch -l -d /sourceware/snapshot-tmp/gcc all
-32 22 * * 5 sh /home/gccadmin/scripts/gcc_release -s 
4.1:branches/gcc-4_1-branch -l -d /sourceware/snapshot-tmp/gcc all
-43 17 * * 2 sh /home/gccadmin/scripts/gcc_release -s 
4.2:branches/gcc-4_2-branch -l -d /sourceware/snapshot-tmp/gcc all
-43 17 * * 6 sh /home/gccadmin/scripts/gcc_release -s 4.3:trunk   -l -d 
/sourceware/snapshot-tmp/gcc all
+32 22 * * 0 sh /home/gccadmin/scripts/gcc_release -s 
4.0:branches/gcc-4_0-branch -l -d /sourceware/snapshot-tmp/gcc all
+32 22 * * 1 sh /home/gccadmin/scripts/gcc_release -s 
4.1:branches/gcc-4_1-branch -l -d /sourceware/snapshot-tmp/gcc all
+32 22 * * 3 sh /home/gccadmin/scripts/gcc_release -s 
4.2:branches/gcc-4_2-branch -l -d /sourceware/snapshot-tmp/gcc all
+32 22 * * 5 sh /home/gccadmin/scripts/gcc_release -s 4.3:trunk   -l -d 
/sourceware/snapshot-tmp/gcc all

Closing the GCC 4.0 branch (was: Build snapshots according to a more regular schedule)

[Gerald Pfeifer]

[ omitting gcc-patches ]

On Fri, 5 Jan 2007, Joe Buck wrote:
> I'd like to see it closed.  We have some bugs that are only open
> because they are targeted for 4.0.4 (fixed on all branches but 4_0).

If there is consensus, I'll be happy to take the appropriate steps,
which include:

 1. Updating our web pages
 2. Sending a notification to the gcc list
 3. Running a final snapshot (so that we have a tarball matching
the head of that tree)
 4. Stopping the snapshot mechanism

How about waiting ten days, say, see whether anyone has substantial
objections, and proceed as noted above?  (We are usually operating
on Internet time, but giving people more than a week is fair, I think.)

Gerald

Re: proposal to clean up @node Warning Options in invoke.texi

[Gerald Pfeifer]

Chris,

I see you have not received any response to this yet, so let me give
it a try.

On Sat, 28 Oct 2006, Chris Pickett wrote:

1.  Create a default section, at the top, and put all options enabled by
default there.


This sounds like an interesting proposal.  Gaby, Joseph, what do you 
think?



5.  Fix what I have labelled as errors.


That we definitely should do.  I believe some things have been changed
in our current development tree (to become GCC 4.3) already.  It would
be great could you have a look and perhaps produce a patch for one or
more of these; is this something you could consider?

Gerald

Clarify policy on documentation changes [wwwdocs]

[Gerald Pfeifer]

I just committed the patch below which clarifies that maintainers are 
allowed to make/approve changes to those parts of our documentation
that are related to their area of maintainership.

This is not a change in policy, just a clarification, but since there
has been some uncertainty in this area I am also posting this to the
gcc list, not just gcc-patches.

Gerald

PS: The change from "files" to "areas" in the second hunk is necessary
because one file with documentation usually covers several, if not many
areas of the compiler (think gcc/doc/invoke.texi, for example).

Index: svnwrite.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svnwrite.html,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -3 -p -r1.13 -r1.14
--- svnwrite.html   21 Sep 2006 14:17:36 -  1.13
+++ svnwrite.html   7 Jan 2007 00:12:34 -   1.14
@@ -105,9 +105,10 @@ developer to follow the appropriate poli
   Localized write permission.
   This is for people who have primary responsibility for ports,
   front ends, or significant hunks of code in the compiler.  These
-  folks are allowed to make changes in code they maintain without
+  folks are allowed to make changes in code they maintain and
+  documentation related to that code without
   approval from anyone else, and approve other people's changes in
-  those files. They must get approval from the appropriate maintainers
+  those areas. They must get approval from the appropriate maintainers
   for changes elsewhere in the compiler.
 
   Maintainers of a port maintain the files in config/port/,

Re: Mis-handled ColdFire submission?

[Gerald Pfeifer]

On Wed, 10 Jan 2007, Joe Buck wrote:
> On Wed, Jan 10, 2007 at 02:56:48PM -0700, Tom Tromey wrote:
>> The patch tracker would help with that.
>> 
>> I noticed recently that contribute.html doesn't seem to mention the
>> patch tracker.  Is there a reason for this omission?
> I guess no one submitted a patch to the web page yet (hint, hint).

Late last year Daniel volunteered to write up a bit, I assume it just
didn't pop to the head of his queue.

Gerald

-Wconversion versus libstdc++

[Gerald Pfeifer]

I noticed that -Wconversion now issues warnings in libstdc++.

For now I have opened two bug reports, and I plan to continue testing and 
file further bug reports once these have been fixed but I wonder if anyone 
plans to do a more systemastic set of checks?

  libstdc++/30463 [regression] -Wconversion triggers warnings for 
vector<>::push_back()
  libstdc++/30464 [regression] -Wconversion triggers warnings for 
deque<>::push_back()

Technically, libstdc++ did not regress.  However, from a user perspective 
this really are regressions, not the least as we make break -Werror builds 
due to these issues in our own libraries.

There may be similar issues with some of the other warnings added or
improved recently.

Gerald

Re: RFC: Extending --help

[Gerald Pfeifer]

On Fri, 12 Jan 2007, Nick Clifton wrote:
>   What do you think ?

I like this idea.  (Not the least because it will help verify
answers/questions that are coming up regularily among users and
in discussions on the gcc lists even.)

Gerald

Re: -Wconversion versus libstdc++

[Gerald Pfeifer]

On Mon, 15 Jan 2007, Paolo Carlini wrote:
> All in all, I think we can definitely add casts to the library, would be only
> a few tens of lines worth of patch, I think. Whether the warning is useful to
> the entire GCC community, I cannot say... But I hope we can resolve the issue
> rather quickly, because, in case, I'd like to start the audit of the library
> as soon as possible and be done with the issue as far as we are concerned...

Would it make sense to add these case in any case, regardless of what
we are going to do about the warning?

(My rationale is that this would document that we are aware of the 
potential issue there and our assessment showed that this particular
use is safe.  But I may be wrong here...)

Gerald

Re: Jan Hubicka and Uros Bizjak appointed i386 maintainers

[Gerald Pfeifer]

On Mon, 8 Jan 2007, David Edelsohn wrote:
> I am pleased to announce that the GCC Steering Committee has appointed 
> Jan Hubicka and Uros Bizjak as co-maintainers of the i386 port.

That's good timing. ;-)

i386 (but not i686) has started failing to bootstrap a few days ago
-- bootstrap/30467.

Gerald

[wwwdocs] PATCH for Re: http://gcc.gnu.org/svnwrite.html points to non-existing source http://gcc.gnu.org/ml/gcc-SVN/

[Gerald Pfeifer]

On Wed, 17 Jan 2007, Ben Elliston wrote:
>>  I found out that page http://gcc.gnu.org/svnwrite.html points to
>> http://gcc.gnu.org/ml/gcc-SVN/ mailing list but it doesn't exist. It's
>> in section "Write access policies" above "Free for all" subsection.
>> It seems that correct list is http://gcc.gnu.org/ml/gcc-cvs/.
> Nicely spotted.  I think someone got overzealous with search and
> replace.  :-)

Fixed thusly.  Now I just wonder whether I did not see this with my
semi-regular link check runs, but there were so many to fix that I
might have missed this one...

Gerald

Index: svnwrite.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svnwrite.html,v
retrieving revision 1.14
diff -u -3 -p -r1.14 svnwrite.html
--- svnwrite.html   7 Jan 2007 00:12:34 -   1.14
+++ svnwrite.html   19 Jan 2007 21:02:36 -
@@ -134,7 +134,7 @@ in the MAINTAINERS file in the GCC distr
 When you have checked in a patch exactly as it has been approved,
 you do not need to tell that to people -- including the approver.
 People interested in when a particular patch is committed can check
-SVN or the http://gcc.gnu.org/ml/gcc-SVN/";>gcc-SVN
+SVN or the http://gcc.gnu.org/ml/gcc-cvs/";>gcc-cvs
 list.
 
 Free for all

Re: Running GCC tests on installed compiler

[Gerald Pfeifer]

On Sun, 14 Jan 2007, Dominique Dhumieres wrote:
>> So please use contrib/test_installed
> This script seems quite outdated: it tests g77 and not gfortran, even with 
> the latest 4.3.0 snapshot (20070112).  As I was primarily interested in 
> the gfortran tests, I replaced g77 by gfortran everywhere (keeping the 
> different capitalizations) and it worked.  The script also ignores java 
> tests.

Would you mind submitting this as a patch?  I do not know whether you
have a copyright assignment on file, but perhaps it is simply enough
that we can take it even without one.

> I looked again to the manual (http://gcc.gnu.org/install/test.html) and 
> did not find this script documented anywhere.  Am I missing something or 
> is this a place where the manual can be improved?  

The latter, I believe.  Do you think you could provide a patch against
gcc/doc/install.texi? ;-)  I'll be happy to work with you on this if
contributing to GCC is an option for you.

Gerald

How to enforce the use of libjava/scripts/jar?

[Gerald Pfeifer]

Looking at libjava/configure.ac, I understand that we only use and 
install libjava/scripts/jar.in if no version of jar nor fastjar is
already present in $PATH:

   AC_CHECK_PROGS([JAR], [jar fastjar], no)
   AC_PATH_PROG([ZIP], [zip], no)
   AC_PATH_PROG([UNZIP], [unzip], unzip)
   AM_CONDITIONAL(BASH_JAR, test "$JAR" = no)
   if test "$ZIP" = no; then
 if test "$JAR" = no; then
   AC_MSG_ERROR([cannot find neither zip nor jar, cannot continue])
 fi
   else
 # InfoZIP available, use the 'guaranteed' Bourne-shell JAR to build libjava
 JAR=`pwd`/scripts/jar
   fi

Now there are some cases where I would like us to always use scripts/jar,
regardless of what is already installed.

The FreeBSD Ports Collection is such an example, where a user may, or
may not, have jar or fastjar in his path, and the result of the build 
ill become less deterministic, especially wrt. the package list.

Also, if the user at one point "looses" jar or fastjar from her path, 
which may have come from a non-RPM or non-package, GCC will partly stop 
working because we relied on that instead of using and installing our
own copy, but the package database could not model this properly.

My question now is: Is there any way to enforce the use and installation
of our own copy of ${PREFIX}/bin/jar${PROGRAMSUFFIX}?

And if there is none, could we add one?

Gerald

Re: raising minimum version of Flex

[Gerald Pfeifer]

On Mon, 21 Jan 2007, Ian Lance Taylor wrote:
> That doesn't sound right.  It see flex being run every time I create a
> new object directory, even though I don't modify the flex input files.
> We ship gengtype-lex.c with releases, so people building the compiler
> from releases shouldn't have to worry, but it is still an issue for
> developers.

...and testers.  Ever since MPFR became a mandatory requirement this
has been hurting me and other testers (and reduced test coverage).

Our documentation and my own experience both agree with Ian:

  @item Flex version 2.5.4 (or later)

  Necessary when modifying @file{*.l} files.

  Necessary to build GCC during development because the generated output
  files are not included in the SVN repository.  They are included in
  releases.

I checked several system available to me, and nearly all of them still
run flex 2.5.4.  Some, like SUSE Linux 10.0, are just about a year old.  
openSUSE 10.2 now comes with flex 2.5.33, but FreeBSD, for example, still 
is at flex 2.5.4.  Just some additional data pointes...

Gerald

Re: How to enforce the use of libjava/scripts/jar?

[Gerald Pfeifer]

On Mon, 22 Jan 2007, Andreas Schwab wrote:
>> My question now is: Is there any way to enforce the use and installation
>> of our own copy of ${PREFIX}/bin/jar${PROGRAMSUFFIX}?
> Set JAR to no before configuring.

Works like a charm.  Thanks for the hint, Andreas!

Gerald

Re: How to enforce the use of libjava/scripts/jar?

[Gerald Pfeifer]

On Sun, 21 Jan 2007, Tom Tromey wrote:
> I think we should never install the jar script -- we now have a gjar
> tool from Classpath which we can use.  On svn trunk we do build and
> install this, for native systems (I think to avoid mixing host and
> target executables in bindir).  I think we should treat the jar script
> as something that is useful for the build, but nothing else.

No objection from my side!  My problem here was that we *sometimes*
install the jar script, and sometimes we don't.  Never installing it
would also work for me. ;-)

Gerald

Re: [RFC] Our release cycles are getting longer

[Gerald Pfeifer]

On Tue, 23 Jan 2007, Diego Novillo wrote:
There was some discussion on IRC that I would like to move to the 
mailing list so that we get a wider discussion.  There's been thoughts 
about skipping 4.2 completely, or going to an extended Stage 3, etc.

Thoughts?


I believe that going forward we should not branch for a release unless
we have a very clear plan, that is "We need to address these four bugs
and potential true blockers/evil regressions that are found before we
release", with a time horizon of maybe two weeks.

Either the release is nearly in shape, then we can branch, or it is
not, in which case we will have a starving release branch for too long
and most focus on Stage 1.

(At least this is the impression that I got; YMMV.)

Gerald

[PATCH for] Re: gcc-4.0-20070128 is now available

[Gerald Pfeifer]

On Sun, 28 Jan 2007, Joe Buck wrote:
> It's probably time to turn off 4.0 snapshots; the last ones will
> probably be Gaby's prerelease snapshots, and the release should come
> soon.

That's a good idea.  You're right, there is no need to wait until
the 4.0.4 release itself.

Done thusly.  I also updated the gccadmin account on gcc.gnu.org.

Gerald

2007-01-29  Gerald Pfeifer  <[EMAIL PROTECTED]>

* crontab: No longer build snapshots for 4.0.x.

Index: crontab
===
--- crontab (revision 121282)
+++ crontab (working copy)
@@ -1,7 +1,6 @@
 16  0 * * * sh /home/gccadmin/scripts/update_version_svn
 50  0 * * * sh /home/gccadmin/scripts/update_web_docs_svn
 55  0 * * * sh /home/gccadmin/scripts/update_web_docs_libstdcxx_svn
-32 22 * * 0 sh /home/gccadmin/scripts/gcc_release -s 
4.0:branches/gcc-4_0-branch -l -d /sourceware/snapshot-tmp/gcc all
 32 22 * * 1 sh /home/gccadmin/scripts/gcc_release -s 
4.1:branches/gcc-4_1-branch -l -d /sourceware/snapshot-tmp/gcc all
 32 22 * * 3 sh /home/gccadmin/scripts/gcc_release -s 
4.2:branches/gcc-4_2-branch -l -d /sourceware/snapshot-tmp/gcc all
 32 22 * * 5 sh /home/gccadmin/scripts/gcc_release -s 4.3:trunk   -l -d 
/sourceware/snapshot-tmp/gcc all

Failure to build libjava on 512MB machine

[Gerald Pfeifer]

I can no longer build libjava on a machine with "just" 512MB of main 
memory (FreeBSD/i386 5.4 in this case).

Three weeks ago the build worked on that very machine; did we raise
our minimum requirements or is this simply a bug?

Gerald

echo 
/sw/test/GCC/trunk/libjava/classpath/lib/gnu/javax/swing/text/html/parser/*.class
 > gnu/javax/swing/text/html/parser.list
/bin/sh ./libtool --mode=compile /files/pfeifer/OBJ-0129-2308/gcc/gcj 
-B/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/ 
-B/files/pfeifer/OBJ-0129-2308/gcc/ -ffloat-store -fomit-frame-pointer 
-fclasspath= -fbootclasspath=/sw/test/GCC/trunk/libjava/classpath/lib 
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -o 
gnu/javax/swing/text/html/parser.lo 
-fsource-filename=/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/classpath/lib/classes
 -MT gnu/javax/swing/text/html/parser.lo -MD -MP -MF 
gnu/javax/swing/text/html/parser.deps @gnu/javax/swing/text/html/parser.list
/files/pfeifer/OBJ-0129-2308/gcc/gcj 
-B/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/ 
-B/files/pfeifer/OBJ-0129-2308/gcc/ -ffloat-store -fomit-frame-pointer 
-fclasspath= -fbootclasspath=/sw/test/GCC/trunk/libjava/classpath/lib 
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c 
-fsource-filename=/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava/classpath/lib/classes
 -MT gnu/javax/swing/text/html/parser.lo -MD -MP -MF 
gnu/javax/swing/text/html/parser.deps @gnu/javax/swing/text/html/parser.list 
-fPIC -o gnu/javax/swing/text/html/.libs/parser.o
jc1: out of memory allocating 4072 bytes after a total of 536273352 bytes
gmake[3]: *** [gnu/javax/swing/text/html/parser.lo] Error 1
gmake[3]: Leaving directory 
`/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory 
`/files/pfeifer/OBJ-0129-2308/i386-unknown-freebsd5.4/libjava'
gmake[1]: *** [all-target-libjava] Error 2
gmake[1]: Leaving directory `/files/pfeifer/OBJ-0129-2308'
gmake: *** [bootstrap-lean] Error 2

Re: Failure to build libjava on 512MB machine

[Gerald Pfeifer]

On Tue, 30 Jan 2007, Andrew Haley wrote:
> 78.67user 1.29system 1:20.01elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
> 
> and indeed, it does want a lot of memory - at peak some 550m.  It'll
> be smaller on a 32-bit box, but not much smaller.

Ouch.  I can confirm that on a 32-bit box of mine it fails with about
500MB of main memory.

On Tue, 30 Jan 2007, Tom Tromey wrote:
> I suppose with some awful build hacking we could split this .o into
> multiple parts.  I'm fine with the situation as it is, myself, but I
> will do this if the consensus is that we should.

Please, pleeease.  This really hurts.  No I can no longer build libgcj
on my notebook and one or two older (but not that old) testers of mine.

Ger ``begging'' ald

Re: Failure to build libjava on 512MB machine

[Gerald Pfeifer]

On Wed, 31 Jan 2007, Andrew Haley wrote:
> Can you tell us a bit more about the config?  It really shouldn't be
> failing to compile this program.

The tester where this problem first surfaced as a 32-bit Athlon machine,
with 512MB main memory and 1GB swap.  The machine runs FreeBSD 5.4.

I agree with your intuition that even if the machines is swapping heavily, 
this amount of virtual memory (1.5GB) should suffice.

However, a bit of investigations makes me believe that, at least in the 
default configuration, FreeBSD 5.4 will refuse to allocate more memory to 
a single process than the system has main memory.

At least this is what the output of the following quick test program I
hacked indicates:

  #include 
  #include 
  #include 

  #define MB 1024*1024

  main() {
for(int i=1; i <= 600; i++) {
  printf("%dMB  ",i); fflush(stdout);

  char *p=(char*)malloc(MB);
  if( p == NULL ) {
printf("\nCrap!\n");
return 1;
  }
}
  }

After 512MB, the output I get is

  510MB
  511MB
  512MB
  Crap!

while, at the same time, a GCC bootstrap is nicely proceeding on the
same machine.  I do not know how many other system may behave similarly,
but at least this explains my (unexpected) bootstrap failures.

Gerald

Re: Failure to build libjava on 512MB machine

[Gerald Pfeifer]

On Thu, 1 Feb 2007, Gerald Pfeifer wrote:
> The tester where this problem first surfaced as a 32-bit Athlon machine,
> with 512MB main memory and 1GB swap.  The machine runs FreeBSD 5.4.
> 
> I agree with your intuition that even if the machines is swapping heavily, 
> this amount of virtual memory (1.5GB) should suffice.
> 
> However, a bit of investigations makes me believe that, at least in the 
> default configuration, FreeBSD 5.4 will refuse to allocate more memory to 
> a single process than the system has main memory.

I know managed to track this down:

  http://plone.org/documentation/faq/freebsd-memory-error

  By default in FreeBSD 5.X or 4.X the kernel will limit the amount
  of RAM any one process can use to 512MB (older versions of FreeBSD
  this was lower).

  You can tweak this in /boot/loader.conf [...]

So, it's not a question of main memory or swap, but a limit in terms
of virtual memory per process on this specific tester.  I don't know
how common such limitations/systems are, so this may be less critical
than it originally seemed.

Still, this shows that we did have an increase in memory use recently,
which may be worth looking into.  (And, of course, I'm happily testing
Tom's patch as we speak.)

Gerald

Re: Failure to build libjava on 512MB machine

[Gerald Pfeifer]

On Fri, 2 Feb 2007, Paolo Bonzini wrote:
> I'd be curious to know the effect of removing the "complexity" field of 
> struct tree_exp.  It should be possible to bootstrap C/C++/Java/Fortran 
> with a two line patch removing the field from tree.h, and the only 
> reference to it in tree.c (via the macro TREE_COMPLEXITY).

You mean, like the patch below?

Doesn't work:

  trunk/gcc/cp/pt.c: In function 'tsubst_expr':
  trunk/gcc/cp/pt.c:8924: error: 'struct tree_exp' has no member named 
'complexity'

Gerald

Index: tree.c
===
--- tree.c  (revision 121482)
+++ tree.c  (working copy)
@@ -2931,7 +2931,6 @@
 #else
   SET_EXPR_LOCUS (t, NULL);
 #endif
-  TREE_COMPLEXITY (t) = 0;
   TREE_OPERAND (t, 0) = node;
   TREE_BLOCK (t) = NULL_TREE;
   if (node && !TYPE_P (node))
Index: tree.h
===
--- tree.h  (revision 121482)
+++ tree.h  (working copy)
@@ -1498,7 +1498,6 @@
 
 /* In ordinary expression nodes.  */
 #define TREE_OPERAND(NODE, I) TREE_OPERAND_CHECK (NODE, I)
-#define TREE_COMPLEXITY(NODE) (EXPR_CHECK (NODE)->exp.complexity)
 
 /* In gimple statements.  */
 #define GIMPLE_STMT_OPERAND(NODE, I) GIMPLE_STMT_OPERAND_CHECK (NODE, I)
@@ -1724,7 +1723,6 @@
 {
   struct tree_common common;
   source_locus locus;
-  int complexity;
   tree block;
   tree GTY ((special ("tree_exp"),
 desc ("TREE_CODE ((tree) &%0)")))

Re: Failure to build libjava on 512MB machine

[Gerald Pfeifer]

On Sat, 3 Feb 2007, Gerald Pfeifer wrote:
>> I'd be curious to know the effect of removing the "complexity" field of 
>> struct tree_exp.
> Doesn't work:
> 
>   trunk/gcc/cp/pt.c: In function 'tsubst_expr':
>   trunk/gcc/cp/pt.c:8924: error: 'struct tree_exp' has no member named 
> 'complexity'

The updated patch below works, but still runs into the out of memory
situation building gnu/javax/swing/text/html/parser/HTML_401F.lo.

Gerald

Index: gcc/tree.c
===
--- gcc/tree.c  (revision 121572)
+++ gcc/tree.c  (working copy)
@@ -2931,7 +2931,6 @@
 #else
   SET_EXPR_LOCUS (t, NULL);
 #endif
-  TREE_COMPLEXITY (t) = 0;
   TREE_OPERAND (t, 0) = node;
   TREE_BLOCK (t) = NULL_TREE;
   if (node && !TYPE_P (node))
Index: gcc/tree.h
===
--- gcc/tree.h  (revision 121572)
+++ gcc/tree.h  (working copy)
@@ -1498,7 +1498,6 @@
 
 /* In ordinary expression nodes.  */
 #define TREE_OPERAND(NODE, I) TREE_OPERAND_CHECK (NODE, I)
-#define TREE_COMPLEXITY(NODE) (EXPR_CHECK (NODE)->exp.complexity)
 
 /* In gimple statements.  */
 #define GIMPLE_STMT_OPERAND(NODE, I) GIMPLE_STMT_OPERAND_CHECK (NODE, I)
@@ -1724,7 +1723,6 @@
 {
   struct tree_common common;
   source_locus locus;
-  int complexity;
   tree block;
   tree GTY ((special ("tree_exp"),
 desc ("TREE_CODE ((tree) &%0)")))
Index: gcc/cp/pt.c
===
--- gcc/cp/pt.c (revision 121572)
+++ gcc/cp/pt.c (working copy)
@@ -8921,7 +8921,9 @@
tree op0, op1;
op0 = RECUR (TREE_OPERAND (t, 0));
op1 = RECUR (TREE_OPERAND (t, 1));
+/*
finish_omp_atomic (OMP_ATOMIC_CODE (t), op0, op1);
+*/
   }
   break;
 
Index: gcc/cp/semantics.c
===
--- gcc/cp/semantics.c  (revision 121572)
+++ gcc/cp/semantics.c  (working copy)
@@ -3899,7 +3899,9 @@
 {
   stmt = build2 (OMP_ATOMIC, void_type_node, orig_lhs, orig_rhs);
   OMP_ATOMIC_DEPENDENT_P (stmt) = 1;
+/*
   OMP_ATOMIC_CODE (stmt) = code;
+*/
 }
   add_stmt (stmt);
 }

Re: meaning of --enable-checking flags

[Gerald Pfeifer]

On Sun, 11 Feb 2007, Larry Evans wrote:

[snip]
I tried downloading and editying
http://gcc.gnu.org/install/configure.html; however, I soon ran into problems.
Attached is a diff between the original .html and the
modifications I tried.  It shows that even the comments in config.in
are confusing :(


I can't comment on the contents, but that HTML file is generated from 
our texinfo documentation; the master source for that is


 gcc/doc/install.texi

in our SVN repository.

Gerald

Re: GCC mirror set up in Germany

[Gerald Pfeifer]

On Sat, 10 Feb 2007, Sascha Schwarz wrote:
> To support your efforts we put up a mirror on our website Cybermirror.org
> under http://gcc.cybermirror.org.

Thanks, but this currently gets me a

  ZUGRIFF NICHT ERLAUBT
  Die angeforderte Seite darf nicht angezeigt werden.
 
(which translates to "access denied -- the requested page must not be
shown).

Gerald

Announcing Kaz as sh maintainer

[Gerald Pfeifer]

It is my pleasure to announce that the steering committee has appointed 
Kaz Kojima maintainer of the sh port.  Kaz has already been serving as 
maintainer for sh libraries/configury, and I know that Alexandre and Joern
are in full support of this nomination.

Please adjust the MAINTAINERS file accordingly, Kaz.

Happy hacking!

Gerald

Re: GCC 4.2.0 Status Report (2007-02-19)

[Gerald Pfeifer]

On Mon, 19 Feb 2007, Brooks Moses wrote:
> The 4.2.0 release is fairly significant to GFortran.  In my opinion, it's
> really the first 4.x release for which we have a mature Fortran compiler

FWIW, this is something I have clearly heard from FreeBSD ports 
maintainers responsible for ports being built with GCC.  Feedback
on our current GCC 4.2.0 snapshots was pretty positive.

Gerald

Re: "Installing GCC" documentation: Why a nonstandard title page?

[Gerald Pfeifer]

On Wed, 21 Feb 2007, Brooks Moses wrote:
> Given that the _real_ situation seems to be that no two manuals have the 
> same title format (except for gcc.texi and gccint.texi), are there any 
> opinions on me coming up with a standard format for this, and proposing 
> a patch to standardize them?

Yes: Go for it! :-)

Gerald

Re: Running GCC tests on installed compiler

[Gerald Pfeifer]

[ gcc -> gcc-patches ]

Dominique,

thanks a lot for your patch.  I have tested this on i686-suse-linux,
comparing the output of contrib/test_installed both before and after
your patch and committed it with the following ChangeLog entry:

  2007-02-26  Dominique Dhumieres  <[EMAIL PROTECTED]>

* test_installed: Adjust to the move from g77 to gfortran.

Find the committed patch at the end of this message.

On Sat, 20 Jan 2007, Dominique Dhumieres wrote:
> If this is OK along with no copyright assignment, I can submit a PR.
> The copyright should probably extended to 2007. I think also than one 
> should notify Alexandre Oliva. 

You're right, I don't think this requires a copyright assignment.  As
you indicated, I updated the coypright year and am also Cc:ing Alexandre.

>> The latter, I believe.  Do you think you could provide a patch against
>> gcc/doc/install.texi?  ;-) I'll be happy to work with you on this if
>> contributing to GCC is an option for you.
> This part is trickier.  First I'll have to learn the basics of texi, since
> I have never used it.  Second I am afraid to be writing challenged.  Third
> I don't have much time to overcome these shortcomings.  
> [...]
> My guess is that people interested by postinstall testing will be
> able to run the script from its comments and, if I am wrong, feedback will
> help to put the entry in better shape.

That's a good point.  I'll see what I can do about the documentation
and try to carve up a patch.

Thanks for your help here!

Gerald

Index: test_installed
===
--- test_installed  (revision 122322)
+++ test_installed  (working copy)
@@ -1,6 +1,6 @@
 #! /bin/sh
 
-# (C) 1998, 2000, 2002, 2003 Free Software Foundation
+# (C) 1998, 2000, 2002, 2003, 2007 Free Software Foundation
 # Originally by Alexandre Oliva <[EMAIL PROTECTED]>
 
 # This script is Free Software, and it can be copied, distributed and
@@ -16,12 +16,12 @@
 # will be appended to the srcdir.
 
 # You may specify where the binaries to be tested should be picked up
-# from.  If you specify --prefix=/some/dir, gcc, g++ and g77 will be
+# from.  If you specify --prefix=/some/dir, gcc, g++ and gfortran will be
 # looked for at /some/dir/bin.  Each one may be overridden by
 # specifying --with-gcc=/pathname/to/gcc, --with-g++=/pathname/to/g++
-# and --with-g77=/pathname/to/g77.  If you specify --without-gcc,
-# --without-g++ or --without-g77, the test for the specified program
-# will be skipped.  By default, gcc, g++ and g77 will be searched in
+# and --with-gfortran=/pathname/to/gfortran.  If you specify --without-gcc,
+# --without-g++ or --without-gfortran, the test for the specified program
+# will be skipped.  By default, gcc, g++ and gfortran will be searched in
 # the PATH.
 
 # An additional argument may specify --tmpdir=/some/dir; by default,
@@ -50,16 +50,16 @@
   --prefix=*) prefix=`echo "$1" | sed 's/[^=]*=//'`; shift;;
   --with-gcc=*) GCC_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; shift;;
   --with-g++=*) GXX_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; shift;;
-  --with-g77=*) G77_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; shift;;
+  --with-gfortran=*) GFORTRAN_UNDER_TEST=`echo "$1" | sed 's/[^=]*=//'`; 
shift;;
   --without-gcc) GCC_UNDER_TEST=no; shift;;
   --without-g++) GXX_UNDER_TEST=no; shift;;
-  --without-g77) G77_UNDER_TEST=no; shift;;
+  --without-gfortran) GFORTRAN_UNDER_TEST=no; shift;;
   --without-objc) OBJC_UNDER_TEST=no; shift;;
 
   --tmpdir=*) tmpdir=`echo "$1" | sed 's/[^=]*=//'`; shift;;
 
   --help) cat <<\EOF
-Runs the testsuite for an installed version of gcc/g++/g77/objc
+Runs the testsuite for an installed version of gcc/g++/gfortran/objc
 Copyright (C) 1998  Free Software Foundation
 by Alexandre Oliva <[EMAIL PROTECTED]>
 
@@ -71,13 +71,13 @@
 --srcdir=/some/dirsame as --with-testsuite=/some/dir/gcc/testsuite
   [deduced from shell-script pathname]
 
---prefix=/some/diruse gcc, g++ and g77 from /some/dir/bin [PATH]
+--prefix=/some/diruse gcc, g++ and gfortran from /some/dir/bin 
[PATH]
 --with-gcc=/some/dir/bin/gcc  use specified gcc program [gcc]
 --with-g++=/some/dir/bin/g++  use specified g++ program [g++]
---with-g77=/some/dir/bin/g77  use specified g77 program [g77]
+--with-gfortran=/some/dir/bin/gfortran  use specified gfortran program 
[gfortran]
 --without-gcc do not run gcc testsuite
 --without-g++ do not run g++ testsuite
---without-g77 do not run g77 testsuite
+--without-gfortrando not run gfortran testsuite
 --without-objcdo not run objc testsuite
 
 --tmpdir=/some/dircreate temporaries and leave failed programs
@@ -109,13 +109,13 @@
 set CXXFLAGS ""
 set GCC_UNDER_TEST "${GCC_UNDER_TEST-${prefix}${prefix+/bin/}gcc}"
 set GXX_UNDER_TEST "${GXX_UNDER_TEST-${prefix}${prefix+/bin/}g++}"
-set G77_UNDER_TEST "${G77_UNDER_T

Re: Failed

[Gerald Pfeifer]

On Fri, 2 Mar 2007, Andrew Pinski wrote:
>> -> http://www.gnu.org/software/gcc/gcc.html
>>
>> Failed Validation of W3C  !
>>
>> This page is not Valid XHTML 1.0 Transitional !
>>
>>
>> W3C rules specify that XHTML tags have to be written in lowercase.
>> You have just to replace every "DIV" by "div" and validation will succeed.

Thanks for the report, Michel!

> Plus http://gcc.gnu.org/ valids as valid XHTML 1.0 Transitional.  So
> something in the conversion method that www.gnu.org does to the web
> pages break the validation.

I investigated a bit, and it seems that unlike gcc.gnu.org, www.gnu.org 
lacks the latest revision (at least) of the bin/preprocess script in our 
wwwdocs module:

  revision 1.43
  date: 2006/06/10 21:52:24;  author: gerald;  state: Exp;  lines: +2 -0
  Use sed to work around MetaHTML brokenness wrt. .

I have contacted the GNU sysadmins and asked them to update to the latest
version of the script.

Gerald

Re: obsolete maintainers

[Gerald Pfeifer]

On Fri, 2 Mar 2007, Mark Mitchell wrote:
> OK.  If any of those people decide they want to be listed again, with
> new email addresses, they can let us know, and we can put them back.
> 
> You can remove that one too:
>> Alex Samuel[EMAIL PROTECTED]
> Alex left CodeSourcery about five years ago.

On a related note, we should start clearing accounts as well.  Anyone
interested?  If not, I can give it a stab -- basically, everyone who
has an account on gcc.gnu.org that is in the gcc group and is not listed
in MAINTAINERS should be looked at.

Gerald

Re: GCC 4.2.0 Status Report (2007-03-04)

[Gerald Pfeifer]

On Mon, 5 Mar 2007, Manuel López-Ibáñez wrote:
> In addition, there are two trivial doc fixes for GCC 4.2, one in
> invoke.texi and another in opts.c, where it says -Werror- and it
> should say -Werror=
> Can I commit them as obvious or do I need to submit a patch?

Both. :-)  That is, go ahead and commit the patch but post it to the
gcc-patches list as well.

Gerald

Re: Failed

[Gerald Pfeifer]

On Sun, 4 Mar 2007, Gerald Pfeifer wrote:
> I investigated a bit, and it seems that unlike gcc.gnu.org, www.gnu.org 
> lacks the latest revision (at least) of the bin/preprocess script in our 
> wwwdocs module:
> 
>   revision 1.43
>   date: 2006/06/10 21:52:24;  author: gerald;  state: Exp;  lines: +2 -0
>   Use sed to work around MetaHTML brokenness wrt. .
> 
> I have contacted the GNU sysadmins and asked them to update to the latest
> version of the script.

I got a heads up that they did that now, so the problem should be resolved
going forward.  Please give www.gnu.org twenty-four hours to sync up.

Gerald

Re: Documenting -fargument-noalias-anything in gcc-4.2/changes.html

[Gerald Pfeifer]

On Sat, 7 Apr 2007, Toon Moene wrote:
> I do not have easy access to the HTML repository anymore.

That's something we should be able to fix; just drop me (or 
[EMAIL PROTECTED]) a note!

> Martin Michlmayr asked me to add to the 4.2 changes list the inclusion 
> of the new compile time option -fargument-noalias-anything.
> 
> I constructed the following out of the invoke.texi document, to be 
> included in gcc-4.2/changes.html, after "General Optimizer 
> Improvements":

Thanks.  I rewrote and adjusted this a bit; here is what I committed.

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.2/changes.html,v
retrieving revision 1.28
diff -u -3 -p -r1.28 changes.html
--- changes.html27 Mar 2007 16:10:25 -  1.28
+++ changes.html9 Apr 2007 22:08:22 -
@@ -21,6 +21,17 @@
 
 General Optimizer Improvements
 
+
+  New command-line options specify the possible relationships among
+parameters and between parameters and global data.  For example,
+-fargument-noalias-anything specifies that arguments
+do not alias any other storage.
+
+Each language will automatically use whatever option is required
+by the language standard.  You should not need to use these options
+yourself.
+
+
 New Languages and Language specific improvements
 
 

[wwwdocs] PATCH for Re: GCC 4.2.0 Status Report (2007-04-15)

[Gerald Pfeifer]

Installed.

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.607
diff -u -3 -p -r1.607 index.html
--- index.html  23 Mar 2007 08:31:00 -  1.607
+++ index.html  16 Apr 2007 08:51:28 -
@@ -128,7 +128,7 @@ mission statement.
   GCC 4.2.0 (changes)
 
   Status: Stage 3;
-  http://gcc.gnu.org/ml/gcc/2007-03/msg00865.html";>2007-03-22
+  http://gcc.gnu.org/ml/gcc/2007-04/msg00509.html";>2007-04-15
   (regression fixes & docs only).
   
   

Re: assign numbers to warnings; treat selected warnings as errors

[Gerald Pfeifer]

On Fri, 20 Apr 2007, Manuel López-Ibáñez wrote:
> Not only that, but you can do -Werror -Wno-error=foo, to get errors
> for everything except -Wfoo. Also, you can do
> -fdiagnostics-show-options to find out which -Wfoo option generates
> each warning message. It is unfortunate that this is missing from
> gcc-4.2/changes.html.

Could I talk you (or someone else who has better knowledge about this
than me ;-) to add this to gcc-4.2/changes.html?

Anything else we are missing there?

Gerald

Bootstrap failure on i386-unknown-freebsd6.2: conflicting types for 'strsignal'

[Gerald Pfeifer]

I am trying to track down a bootstrap failure on i386-unknown-freebsd6.2
that was introduced between 48 hours and 24 hours ago, roughly:

  gcc -c   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings 
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H -DGENERATOR_FILE -I. 
-Ibuild -I/sw/test/GCC/trunk/gcc -I/sw/test/GCC/trunk/gcc/build 
-I/sw/test/GCC/trunk/gcc/../include -I./../intl 
-I/sw/test/GCC/trunk/gcc/../libcpp/include -I/usr/local/include  
-I/sw/test/GCC/trunk/gcc/../libdecnumber 
-I/sw/test/GCC/trunk/gcc/../libdecnumber/dpd -I../libdecnumber-o 
build/genmodes.o /sw/test/GCC/trunk/gcc/genmodes.c
  In file included from /sw/test/GCC/trunk/gcc/genmodes.c:23:
  /sw/test/GCC/trunk/gcc/system.h:418: error: conflicting types for 'strsignal'
  /usr/include/string.h:104: error: previous declaration of 'strsignal' was here
  /sw/test/GCC/trunk/gcc/system.h:418: error: conflicting types for 'strsignal'
  /usr/include/string.h:104: error: previous declaration of 'strsignal' was here
  gmake[3]: *** [build/genmodes.o] Error 1
  gmake[3]: Leaving directory `/usr/nabil-files/pfeifer/OBJ-0501-2228/gcc'
  gmake[2]: *** [all-stage1-gcc] Error 2
  gmake[2]: Leaving directory `/usr/nabil-files/pfeifer/OBJ-0501-2228'
  gmake[1]: *** [stage1-bubble] Error 2
  gmake[1]: Leaving directory `/usr/nabil-files/pfeifer/OBJ-0501-2228'
  gmake: *** [bootstrap-lean] Error 2

I've been wading through ChangeLogs, svn blame, and svn logs, but
somehow got stuck tracking this bugger down.  This does not reproduce
on i686-suse-linux, and I don't see why this started to fail out of
a sudden.

In gcc/auto-host.h in the build tree I have:

  #define HAVE_DECL_STRSIGNAL 0
  #define HAVE_STRSIGNAL 1

In /usr/include/string.h I have:

  #if __BSD_VISIBLE
  char*strsep(char **, const char *);
  char*strsignal(int);
  #endif

And gcc/system.h, which hasn't changed for some months, has:

  /* If the system doesn't provide strsignal, we get it defined in
 libiberty but no declaration is supplied.  */
  #if !defined (HAVE_STRSIGNAL) \
  || (defined (HAVE_DECL_STRSIGNAL) && !HAVE_DECL_STRSIGNAL)
  # ifndef strsignal
  extern const char *strsignal (int);
  # endif
  #endif

Any recommendations on where I might want to look or what might be
causing this build failure out of a sudden?

Gerald

Re: Weeeeee! ;)))

[Gerald Pfeifer]

I'll be offline until March 13th.

  Ich werde bis 13. Maerz offline sein.

I will process this and any further messages as soon as possible.

  Ich werde diese und etwaige weitere Nachrichten so rasch wie
  moeglich bearbeiten.

Gerald Pfeifer
-- 
Gerald Pfeifer (Jerry)   [EMAIL PROTECTED]   http://www.pfeifer.com/gerald/

Re: Inlining and estimate_num_insns

[Gerald Pfeifer]

On Tue, 1 Mar 2005, Steven Bosscher wrote:
>>> You still didn't get into the fun part of actually inlining all the
>>> inlines in in Gerald's testcase ;)
> It got killed on a box with 4GB of RAM after 11 hours and 43 minutes
> with "virtual memory exhausted: Cannot allocate memory".  In the
> latest oprofiles, the cgraph functions still accounted for more than
> 95% of the time, so probably it was still inlining things.

We've got some "slightly" bigger machines here, and once the cgraph
stuff has been partly addressed, I'd love to see what happens on one
of these (and then do benchmarks to see how going down that extreme
path affects run-time performance, given current cache sizes).

Gerald

Re: dejagnu help needed - tests get confused by column numbers

[Gerald Pfeifer]

On Mon, 28 Mar 2005, Janis Johnson wrote:
> There are several workarounds in the GCC testsuite for things that could
> be better handled in DejaGnu if the next release of GCC could require a
> new DejaGnu version.  That might be the right thing to do for GCC 4.1.
> Ben Elliston is the DejaGnu maintainer; he's expressed interest in the
> past in modifying DejaGnu to support GCC's needs.

I'm one of those who haven't been too happy about requiring new versions 
of tools required for testing GCC (not the least because I've been using 
several systems where I just had limited access).

However, if we can reap real benefits from requiring a newer version of
DejaGnu and have a bit of a lead time (i.e., the new DejaGnu version is
released a few months before GCC 4.1), relying on such a new version does
sound like an okay plan.

Gerald

Re: RFC: #pragma optimization_level

[Gerald Pfeifer]

On Fri, 1 Apr 2005, Joe Buck wrote:
> Unfortunately, where there is a good argument for not using empty loops
> as busy-waits, at one time it was documented GCC behavior that it would
> work, so we can't really blame the users for trusting the doc.

However, it's really a looong time since we clarified that:

  Mon Dec 28 19:26:32 1998  Gerald Pfeifer  <[EMAIL PROTECTED]>

* gcc.texi (Non-bugs): ``Empty'' loops will be optimized away in
the future; indeed that already happens in some cases.

Gerald

Re: How is lang.opt processed?

[Gerald Pfeifer]

Steve, Toon,

On Thu, 10 Mar 2005, Steve Kargl wrote:
> Jim,
> 
> Thanks for the detailed explanation of how GCC options work.

On Fri, 11 Mar 2005, Toon Moene wrote:
> Ditto.  Jim, are you reading from some documentation about this option 
> processing that I couldn't find ?  I've spend hours and hours to try to 
> deduce the option processing rules from debugging various parts of the 
> gcc driver, with no success.

any chance I could convince you to document Jim's explanations and your
new findings for "future generations"?

Gerald

Re: [rtl-optimization] Improve Data Prefetch for IA-64

[Gerald Pfeifer]

On Mon, 28 Mar 2005, James E Wilson wrote:
> Steven Bosscher wrote:
>> OK, so I know this is not a popular subject, but can we *please* stop
>> working on loop.c and focus on getting the new RTL and tree loop passes
>> to do what we want?
> I don't think anyone is objecting to this. [...]
> I would however make a distinction here between new development work and
> maintenance.  It would be better if new development work happened in the new
> loop optimizer.  However, we still need to do maintenance work in loop.c.

...and since Canqun reported 2.5% improvement on SPEC CFP2000 on ia64 with 
his current patch, I really think we should consider it.

We all know how hard it is to get this kind of improvement on any of the 
SPECs -- and in fact improving the current optimizers will make raise the
bar for the new ones. ;-)

Question is: who is going review/potentially approve this patch?

Gerald

Re: ISO C prototype style for libiberty?

[Gerald Pfeifer]

On Fri, 25 Mar 2005, Joe Buck wrote:
> Any retro people out there still trying to run SunOS 4.x?

Richard K., as evidenced by the missing Reference:s headers in his
mails.  But I doubt he's actually bootstrapping GCC on that machine.
:-}

Gerald

Re: "personal" branch?

[Gerald Pfeifer]

On Tue, 5 Apr 2005, Ben Elliston wrote:
> I am doing some academic work on GCC and am finding it hard to manage
> my patches locally.  Would anyone have any strong objections if I were
> to indulge in creating a branch in the FSF repository for little old
> me?  The volume of my deltas will not be large.

I'm not aware of restrictions we are placing on branches in our CVS
repository, and in fact that's something we wanted to encourage with
our open development model.  Just follow the usual naming conventions
and update cvs.html accordingly, I'd say.

Gerald

Re: http://gcc.gnu.org/install/specific.html#*-*-solaris2*

[Gerald Pfeifer]

On Wed, 9 Mar 2005, Dimitri Papadopoulos-Orfanos wrote:
> On this page:
>   http://gcc.gnu.org/install/specific.html
> there's a link to:
>   #*-*-solaris2*
> but it doesn't work. Instead from what I can undersatnd it should be:
>   #g_t*-*-solaris2*

Hmm, that's interesting, so I'm Cc:ing the texinfo folks on this one:

In the GCC sources (gcc/doc/install.texi), we have the following line

  @heading @anchor{sparc-sun-solaris2*}sparc-sun-solaris2*

which expands to
  
  *-*-solaris2*

Now I now (and understand) that you changed the mangling of filenames,
but where does the "g_t" come from, and why?

http://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#anchor
did not provide any explanation.  Bug or feature?

Gerald

Re: http://gcc.gnu.org/install/specific.html#*-*-solaris2*

[Gerald Pfeifer]

On Wed, 6 Apr 2005, Karl Berry wrote:
> Catering to XHTML's stupidity.  I mentioned it in:
> 
> http://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html#HTML-Xref-Link-Basics
> viz.
> One exception: the algorithm for node name expansion prefixes the
> string `g_t' when the node name begins with a non-letter. This kludge
> (due to XHTML rules) is not necessary for filenames, and is
> therefore omitted.

Thanks for the clarification.  I was afraid it would be something like
that...  I'll see that I update the GCC installation notes to fix the
thusly broken links.

Gerald

Re: 2 suggestions

[Gerald Pfeifer]

On Thu, 7 Apr 2005, Kaveh R. Ghazi wrote:
>>> Not necessary.  If people would simply follow the directions here:
>>>  by setting
> Also, when I click on the link above, it doesn't follow down the page
> to the anchor.  I'm not sure why that is.  Gerald?

Just a few days ago I learned that this is a "feature" in current
versions of texinfo: apparently XHTML disallows characters like "*"
at the beginning of an anchor, so makeinfo now prepends some magic
string.

I'm afraid we'll have to rename all of these in some way, either
by replacing "*" by "x" or by prepending some string.  I'm not too
fond of either, but just using "x" instead "*" might be less ugly.
Somewhat.

What do you think?

Gerald

Re: install

[Gerald Pfeifer]

On Thu, 14 Apr 2005, Master Faris wrote:
> I would like to install gcc on solaris 9
> sun4u sparc SUNW,Sun-Fire-V440
> 
> can you give me some directions or where to find instructions please as this
> is my first time doing it

Please have a look at our website http://gcc.gnu.org, specifically
http://gcc.gnu.org/install.

Note that this list is on the development *of* GCC, not the installation
of or development *with* GCC, so this kind of question is off-topic here.

Gerald

Re: 2 suggestions

[Gerald Pfeifer]

On Wed, 13 Apr 2005, Kaveh R. Ghazi wrote:
> I like prepending a string, for example target= or triplet=, etc.

Okay.  However,...

On Thu, 14 Apr 2005, Georg Bauhaus wrote:
> If "*-*-solaris2*" should appear as/in the "name" attribute of an ,
> prepending a name start character is not enough, because this attribute
> is of type NMTOKEN. Therefore it cannot contain * at all.

...if we are absolutely disallowed to use "*", probably just replacing
"*" by "x" without any prefix might be the lesser of all evils?

> If international character sets in XHTML are o.K., maybe there are
> some letter sets to choose from. Here is a sample.

I feel this might be worse, because it'll look as if everything was okay,
but when someone copies and pastes the string, it won't work as a proper
target string.  (Thanks for your expert input, by the way.)

Okay?

Gerald

Re: GCC 4.0 RC1 Available

[Gerald Pfeifer]

On Thu, 14 Apr 2005, Joseph S. Myers wrote:
>> gcc/doc/install.texi still mentions gcc 3.5 in a few places.
> Fixed thus (and a similar reference in cpp.texi).  It passes "make info", 
> "make dvi" and "install.texi2html".  Applied to mainline and 4.0 branch 
> (as a doc patch for which the branch is still open).

Fortunately I just checked my mailbox, because I was going to the same.
Well, in that case I'll take the other open doc issue. ;-)

Gerald

Re: 2 suggestions

[Gerald Pfeifer]

On Thu, 14 Apr 2005, Hugh Sasse Staff Elec Eng wrote:
>> ...if we are absolutely disallowed to use "*", probably just replacing
>> "*" by "x" without any prefix might be the lesser of all evils?
> So long as things to get ported to the x-box?

That port wouldn't be called x-box, because dash separates the different 
parts of a target tripplet (which is why the platform by the marketing 
name of AMD64 is spelled x86_64 instead x86-64).
 
On Thu, 14 Apr 2005, Kaveh R. Ghazi wrote:
> I guess "x" is fine with me.  However can we use "x" only in the
> anchor and not the link's text label?  E.g.:
> 
>   alpha*-*-*
> 
> That way, the part people actually read in the document still uses
> asterisk that they are used to seeing.

Your wish is my command.  Patch proposal below for comments

This patch accomplishes the goal to get rid of asterisks in @anchor
names by

 - replacing components of a target triplet which read "*" by "x",
 - and omiting trailing asterisks from all other components.

Tested by running doc/install.texi2html and selecting every single
link in the directory of specific.html.

Gerald


2005-04-14  Gerald Pfeifer  <[EMAIL PROTECTED]>

* doc/install.texi: Avoid using asterisks in @anchor names.
Remove i?86-*-esix from platform directory.
Remove powerpc-*-eabiaix from platform directory.

Index: doc/install.texi
===
RCS file: /cvs/gcc/gcc/gcc/doc/install.texi,v
retrieving revision 1.344
diff -u -3 -p -r1.344 install.texi
--- doc/install.texi6 Apr 2005 15:36:04 -   1.344
+++ doc/install.texi14 Apr 2005 21:40:28 -
@@ -2167,19 +2167,19 @@ GNU Compiler Collection on your machine.
 @ifhtml
 @itemize
 @item
[EMAIL PROTECTED],,alpha*-*-*}
[EMAIL PROTECTED],,alpha*-*-*}
 @item
[EMAIL PROTECTED],,alpha*-dec-osf*}
[EMAIL PROTECTED],,alpha*-dec-osf*}
 @item
[EMAIL PROTECTED],,alphaev5-cray-unicosmk*}
[EMAIL PROTECTED],,alphaev5-cray-unicosmk*}
 @item
[EMAIL PROTECTED],,arc-*-elf}
[EMAIL PROTECTED],,arc-*-elf}
 @item
[EMAIL PROTECTED],,arm-*-elf}
[EMAIL PROTECTED],,arm-*-coff}
[EMAIL PROTECTED],,arm-*-aout}
[EMAIL PROTECTED],,arm-*-elf}
[EMAIL PROTECTED],,arm-*-coff}
[EMAIL PROTECTED],,arm-*-aout}
 @item
[EMAIL PROTECTED],,xscale-*-*}
[EMAIL PROTECTED],,xscale-*-*}
 @item
 @uref{#avr,,avr}
 @item
@@ -2189,39 +2189,37 @@ GNU Compiler Collection on your machine.
 @item
 @uref{#dos,,DOS}
 @item
[EMAIL PROTECTED],,*-*-freebsd*}
[EMAIL PROTECTED],,*-*-freebsd*}
 @item
 @uref{#h8300-hms,,h8300-hms}
 @item
[EMAIL PROTECTED],,hppa*-hp-hpux*}
[EMAIL PROTECTED],,hppa*-hp-hpux*}
 @item
[EMAIL PROTECTED],,hppa*-hp-hpux10}
[EMAIL PROTECTED],,hppa*-hp-hpux10}
 @item
[EMAIL PROTECTED],,hppa*-hp-hpux11}
[EMAIL PROTECTED],,hppa*-hp-hpux11}
 @item
[EMAIL PROTECTED],,*-*-linux-gnu}
[EMAIL PROTECTED],,*-*-linux-gnu}
 @item
[EMAIL PROTECTED],,i?86-*-linux*aout}
[EMAIL PROTECTED],,i?86-*-linux*aout}
 @item
[EMAIL PROTECTED],,i?86-*-linux*}
[EMAIL PROTECTED],,i?86-*-linux*}
 @item
[EMAIL PROTECTED],,i?86-*-sco3.2v5*}
[EMAIL PROTECTED],,i?86-*-sco3.2v5*}
 @item
[EMAIL PROTECTED],,i?86-*-udk}
[EMAIL PROTECTED],,i?86-*-udk}
 @item
[EMAIL PROTECTED],,i?86-*-esix}
[EMAIL PROTECTED],,ia64-*-linux}
 @item
[EMAIL PROTECTED],,ia64-*-linux}
[EMAIL PROTECTED],,ia64-*-hpux*}
 @item
[EMAIL PROTECTED],,ia64-*-hpux*}
[EMAIL PROTECTED],,*-ibm-aix*}
 @item
[EMAIL PROTECTED],,*-ibm-aix*}
[EMAIL PROTECTED],,ip2k-*-elf}
 @item
[EMAIL PROTECTED],,ip2k-*-elf}
[EMAIL PROTECTED],,iq2000-*-elf}
 @item
[EMAIL PROTECTED],,iq2000-*-elf}
[EMAIL PROTECTED]
[EMAIL PROTECTED],,m32r-*-elf}
[EMAIL PROTECTED],,m32r-*-elf}
 @item
 @uref{#m6811-elf,,m6811-elf}
 @item
@@ -2229,63 +2227,61 @@ GNU Compiler Collection on your machine.
 @item
 @uref{#m68k-hp-hpux,,m68k-hp-hpux}
 @item
[EMAIL PROTECTED],,mips-*-*}
[EMAIL PROTECTED],,mips-*-*}
 @item
 @uref{#mips-sgi-irix5,,mips-sgi-irix5}
 @item
 @uref{#mips-sgi-irix6,,mips-sgi-irix6}
 @item
[EMAIL PROTECTED],,powerpc*-*-*, powerpc-*-sysv4}
[EMAIL PROTECTED]
[EMAIL PROTECTED],,powerpc-*-darwin*}
[EMAIL PROTECTED],,powerpc*-*-*, powerpc-*-sysv4}
 @item
[EMAIL PROTECTED],,powerpc-*-elf, powerpc-*-sysv4}
[EMAIL PROTECTED],,powerpc-*-darwin*}
 @item
[EMAIL PROTECTED],,powerpc*-*-linux-gnu*}
[EMAIL PROTECTED],,powerpc-*-elf, powerpc-*-sysv4}
 @item
[EMAIL PROTECTED],,powerpc-*-netbsd*}
[EMAIL PROTECTED],,powerpc*-*-linux-gnu*}
 @item
[EMAIL PROTECTED],,powerpc-*-eabiaix}
[EMAIL PROTECTED],,powerpc-*-netbsd*}
 @item
[EMAIL PROTECTED],,powerpc-*-eabisim}
[EMAIL PROTECTED],,powerpc-*-eabisim}
 @item
[EMAIL PROTECTED],,powerpc-*-eabi}
[EMAIL PROTECTED],,powerpc-*-eabi}
 @item
[EMAIL PROTECTED],,powerpcle-*-elf, powerpcle-*-sysv4}
[EMAIL PROTECTED],,powerpcle-*-elf, powerpcle-*-sysv4}
 @item
[EMAIL PROTECTED],,powerpcle-*-eabisim}
[EMAIL PROTECTED],,powerpcle-*-eabisim}
 @item
[EMAIL PROTECTED],,power

Joseph appointed i18n maintainer

[Gerald Pfeifer]

It is my pleasure to announce that the steering committee has appointed 
Joseph Myers i18n maintainer, an area he's been taking care of for quite
some time now.

Please adjust the MAINTAINERS file accordingly, Joseph, and Happy hacking!

Gerald

Re: 2 suggestions

[Gerald Pfeifer]

On Thu, 14 Apr 2005, Gerald Pfeifer wrote:
> This patch accomplishes the goal to get rid of asterisks in @anchor
> names by
> 
>  - replacing components of a target triplet which read "*" by "x",
>  - and omiting trailing asterisks from all other components.
> 
> Tested by running doc/install.texi2html and selecting every single
> link in the directory of specific.html.

Applied now to mainline and the 4.0-branch with the following ChangeLog.

  2005-04-16  Gerald Pfeifer  <[EMAIL PROTECTED]>

* doc/install.texi (Specific): Avoid using asterisks in @anchor
names related to target triplets.
Remove i?86-*-esix from platform directory.
Remove powerpc-*-eabiaix from platform directory.

Gerald

Re: Vectorizing my loops. Some problems.

[Gerald Pfeifer]

On Sat, 16 Apr 2005, Øystein Johansen wrote:
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> make: *** [neuralnet.o] Error 1
> 
> Should I report this to the bug database or is this a known bug? And
> what is it and what can I do?
> 
> It's still gcc-4.1-20050313

Update to a current version/snapshot, since that one's already a month
old, and there have been many changes since then.

If the problem persists, please file a Bugzilla with detailed information
that will allow a developer to reproduce this (which include preprocessed
sources).

Thanks,
Gerald

Re: at web: /install/specific.html

[Gerald Pfeifer]

On Tue, 1 Mar 2005, Alec Voropay wrote:
>  It seems, the local  on the GCC web page
> http://gcc.gnu.org/install/specific.html
> does not work due to wrong HTML format.

I'm afraid that, originally, I didn't understand what you meant by this,
but I believe that I do now and thus I committed a fix for this problem
two days ago.

If you're still seeing this, would you mind providing some more details
on what does not work for you?  Something like "When I select the link
labeled X, I would expect Y to happen, but actually see Z." would be
helpful in that case.

Thanks,
Gerald

Re: Packaging error in 4.0RC1 docs? [was RE: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0 ]

[Gerald Pfeifer]

On Tue, 12 Apr 2005, Dave Korn wrote:
>> When I look in gcc-4.0.0-20050410/INSTALL at specific.html
>   Oh, BTW, it seems the internal links in that page are b0rked in the usual
> sort of way, owing to the mangling of 'special' characters.  A link like:
> 
> *-ibm-aix*
> 
> doesn't actually link up with an anchor like
> 
> 
> 
>  name="_002a_002dibm_002daix_002a">*-ibm-aix*

This should work now; I committed a patch a few days ago.

>   Oh, and there are TOC entries for chapters that don't exist at all, such
> as 
> 
> powerpc-*-eabiaix

I removed two such obsolete TOC entries in specific.html; if you are
aware of any further issues, please let us know.

Gerald

makeinfo 4.8 generates non-standard HTML for @emph{..@samp{..}..}

[Gerald Pfeifer]

In the GCC documentation (gcc/doc/install.texi) we have the following
texinfo snippet

  @emph{You should substitute @samp{i686} in the above command with the 
  appropriate processor for your host.}

makeinfo 4.8 translates this to

  You should substitute `i686
  ' in the above command with the appropriate processor 
  for your host.

which is not valid HTML 4.01 nor XHTML 1.0 transitional according to 
validator.w3.org.

(The original file is at .)

Gerald

Re: at web: /install/specific.html

[Gerald Pfeifer]

On Wed, 20 Apr 2005, Patrick McFarland wrote:
>>> http://gcc.gnu.org/install/specific.html
> I think he meant it has the wrong doctype. That is clearly an xhtml 
> document, but it has an html4 doctype.

If you pass this page through validator.w3.org, you'll see that this 
is clearly *not* an XHTML document, not even XHTML 1.0 transitional.

It's not an HTML 4.01 document, either, but I believe this is only
due to a minor makeinfo bug which I just reported to the authors.

Gerald

[wwwdocs] PATCH for GCC 4.0 branch open for regression fixes

[Gerald Pfeifer]

On Fri, 22 Apr 2005, Mark Mitchell wrote:
> The GCC 4.0 branch is now open for regression fixes only, under the usual
> release branch rules.

Documented thusly.

Gerald

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.489
diff -u -3 -p -r1.489 index.html
--- index.html  21 Apr 2005 17:10:07 -  1.489
+++ index.html  24 Apr 2005 19:38:15 -
@@ -38,7 +38,8 @@ mission statement.
 Current release series:
   GCC 4.0.0 (released 2005-04-20)
 
-  Branch status: frozen.
+  Branch status:
+  open for regression and documentation fixes.
 
 
 Previous release series:

RE: http://gcc.gnu.org/gcc-3.4/changes.html

[Gerald Pfeifer]

On Tue, 1 Mar 2005, Johan Bergman (KI/EAB) wrote:
> Here is a unified diff for the proposed change (I think).

Johan, Giovanni, I just noticed that this one apparently feel trough
the cracks?

I had assumed that Giovanni would just go ahead an apply it since he's
an expert in that area and the patch even was rather short, but I do not
see it in CVS, so I just committed it.

Gerald

Tweak description of alternative solution for name lookup problem.
By Johan Bergman (KI/EAB) <[EMAIL PROTECTED]> 

--- changes.htm%2005-02-28 21:46:56.0 +0100
+++ changes.htm 2005-02-28 21:46:56.0 +0100
@@ -429,10 +429,10 @@
template  struct C : B {
  void h ()
  {
-   m = 0; // error
-   f ();  // error
-   n = 0; // ::n is modified
-   g ();  // ::g is called
+   m = 0; // error
+   f ();  // error
+   n = 0; // ::n is modified
+   g ();  // ::g is called
  }
};
You must make the names dependent, e.g. by prefixing them
@@ -446,7 +446,8 @@
  this->n = 0
  this->g ();
}
-   As an alternative solution, you may use using
+   As an alternative solution (unfortunately not backwards
+   compatible with GCC 3.3), you may use using
declarations instead of this->:

template  struct C : B {
@@ -456,10 +457,10 @@
  using B::g;
  void h ()
  {
-   m = 0;
-   f ();
-   n = 0;
-   g ();
+   m = 0;
+   f ();
+   n = 0;
+   g ();
  }
};
 

Re: i?86-*-sco3.2v5* / i?86-*-solaris2.10 / x86_64-*-*, amd64-*-*

[Gerald Pfeifer]

On Fri, 29 Apr 2005, Dimitri Papadopoulos-Orfanos wrote:
> Some links are broken on this page:
>   http://gcc.gnu.org/install/specific.html
> 
> Specifically:
>   i?86-*-sco3.2v5*
>   i?86-*-solaris2.10
>   x86_64-*-*, amd64-*-*
>   all ELF targets

That's even further collateral damage caused by the design changes in
recent versions of GNU makeinfo for strict HTML/XHTML support. :-(

Thanks for the clear report, Dimitri.  I just installed the following
change to mainline (which will become GCC 4.1) and will shortly do the
same on the 4.0 branch.  Please allow up to 24 hours until this has
propagated to the http://gcc.gnu.org/install/specific.html web page.

I tested this patch by running gcc/doc/install.texi2html and also
verified that the changed links still work when using makeinfo 4.5

Gerald

2005-05-01  Gerald Pfeifer  <[EMAIL PROTECTED]>

* doc/install.texi (Specific): Omit dots in the @anchors names
for i?86-*-sco3.2v5*, i?86-*-solaris2.10, and sparc-sun-solaris2.7.
Omit underscores for x86_64-*-* and the "all ELF targets" entry.

Index: doc/install.texi
===
RCS file: /cvs/gcc/gcc/gcc/doc/install.texi,v
retrieving revision 1.350
diff -u -3 -p -r1.350 install.texi
--- doc/install.texi28 Apr 2005 22:53:21 -  1.350
+++ doc/install.texi1 May 2005 13:34:14 -
@@ -2207,9 +2207,9 @@ GNU Compiler Collection on your machine.
 @item
 @uref{#ix86-x-linux,,i?86-*-linux*}
 @item
[EMAIL PROTECTED],,i?86-*-sco3.2v5*}
[EMAIL PROTECTED],,i?86-*-sco3.2v5*}
 @item
[EMAIL PROTECTED],,i?86-*-solaris2.10}
[EMAIL PROTECTED],,i?86-*-solaris2.10}
 @item
 @uref{#ix86-x-udk,,i?86-*-udk}
 @item
@@ -2267,7 +2267,7 @@ GNU Compiler Collection on your machine.
 @item
 @uref{#sparc-sun-solaris2,,sparc-sun-solaris2*}
 @item
[EMAIL PROTECTED],,sparc-sun-solaris2.7}
[EMAIL PROTECTED],,sparc-sun-solaris2.7}
 @item
 @uref{#sparc-x-linux,,sparc-*-linux*}
 @item
@@ -2281,7 +2281,7 @@ GNU Compiler Collection on your machine.
 @item
 @uref{#x-x-vxworks,,*-*-vxworks*}
 @item
[EMAIL PROTECTED],,x86_64-*-*, amd64-*-*}
[EMAIL PROTECTED],,x86_64-*-*, amd64-*-*}
 @item
 @uref{#xtensa-x-elf,,xtensa-*-elf}
 @item
@@ -2296,7 +2296,7 @@ GNU Compiler Collection on your machine.
 
 @itemize
 @item
[EMAIL PROTECTED],,all ELF targets} (SVR4, Solaris 2, etc.)
[EMAIL PROTECTED],,all ELF targets} (SVR4, Solaris 2, etc.)
 @end itemize
 @end ifhtml
 
@@ -2897,7 +2897,7 @@ found on @uref{http://www.bitwizard.nl/s
 @html
 
 @end html
[EMAIL PROTECTED] @anchor{ix86-x-sco3.2v5}i?86-*-sco3.2v5*
[EMAIL PROTECTED] @anchor{ix86-x-sco32v5}i?86-*-sco3.2v5*
 Use this for the SCO OpenServer Release 5 family of operating systems.
 
 Unlike earlier versions of GCC, the ability to generate COFF with this
@@ -2941,7 +2941,7 @@ GCC, version 2.95.3.  It is useful for b
 @html
 
 @end html
[EMAIL PROTECTED] @anchor{ix86-x-solaris2.10}i?86-*-solaris2.10
[EMAIL PROTECTED] @anchor{ix86-x-solaris210}i?86-*-solaris2.10
 Use this for Solaris 10 or later on x86 and x86-64 systems.  This
 configuration is supported by GCC 4.0 and later versions only.
 
@@ -3649,7 +3649,7 @@ or later system, the canonical target tr
 @html
 
 @end html
[EMAIL PROTECTED] @anchor{sparc-sun-solaris2.7}sparc-sun-solaris2.7
[EMAIL PROTECTED] @anchor{sparc-sun-solaris27}sparc-sun-solaris2.7
 
 Sun patch 107058-01 (1999-01-13) for Solaris 7/SPARC triggers a bug in
 the dynamic linker.  This problem (Sun bug 4210064) affects GCC 2.8
@@ -3808,7 +3808,7 @@ VxWorks will incorporate this module.)
 @html
 
 @end html
[EMAIL PROTECTED] @anchor{x86_64-x-x}x86_64-*-*, amd64-*-*
[EMAIL PROTECTED] @anchor{x86-64-x-x}x86_64-*-*, amd64-*-*
 
 GCC supports the x86-64 architecture implemented by the AMD64 processor
 (amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and [EMAIL 
PROTECTED]
@@ -3921,7 +3921,7 @@ current GCC) is to be found in the GCC t
 @html
 
 @end html
[EMAIL PROTECTED] @anchor{elf_targets}all ELF targets (SVR4, Solaris 2, etc.)
[EMAIL PROTECTED] @anchor{elf}all ELF targets (SVR4, Solaris 2, etc.)
 
 C++ support is significantly better on ELF targets if you use the
 @uref{./configure.html#with-gnu-ld,,GNU linker}; duplicate copies of

Re: i?86-*-sco3.2v5* / i?86-*-solaris2.10 / x86_64-*-*, amd64-*-*

[Gerald Pfeifer]

On Sun, 1 May 2005, Gerald Pfeifer wrote:
> Thanks for the clear report, Dimitri.  I just installed the following
> change to mainline (which will become GCC 4.1) and will shortly do the
> same on the 4.0 branch.

This is the variant of the patch I applied on the 4.0 branch.

Gerald

2005-05-01  Gerald Pfeifer  <[EMAIL PROTECTED]>

* doc/install.texi (Specific): Omit dots in the @anchors names
for i?86-*-sco3.2v5* and sparc-sun-solaris2.7.
Omit underscores for x86_64-*-* and the "all ELF targets" entry.

Index: doc/install.texi
===
RCS file: /cvs/gcc/gcc/gcc/doc/install.texi,v
retrieving revision 1.248.4.33
diff -u -3 -p -r1.248.4.33 install.texi
--- doc/install.texi30 Mar 2005 07:42:31 -  1.248.4.33
+++ doc/install.texi1 May 2005 17:56:59 -
@@ -2156,7 +2156,7 @@ GNU Compiler Collection on your machine.
 @item
 @uref{#ix86-*-linux*,,i?86-*-linux*}
 @item
[EMAIL PROTECTED],,i?86-*-sco3.2v5*}
[EMAIL PROTECTED],,i?86-*-sco3.2v5*}
 @item
 @uref{#ix86-*-udk,,i?86-*-udk}
 @item
@@ -2218,7 +2218,7 @@ GNU Compiler Collection on your machine.
 @item
 @uref{#sparc-sun-solaris2*,,sparc-sun-solaris2*}
 @item
[EMAIL PROTECTED],,sparc-sun-solaris2.7}
[EMAIL PROTECTED],,sparc-sun-solaris2.7}
 @item
 @uref{#sparc-*-linux*,,sparc-*-linux*}
 @item
@@ -2232,7 +2232,7 @@ GNU Compiler Collection on your machine.
 @item
 @uref{#*-*-vxworks*,,*-*-vxworks*}
 @item
[EMAIL PROTECTED],,x86_64-*-*, amd64-*-*}
[EMAIL PROTECTED],,x86_64-*-*, amd64-*-*}
 @item
 @uref{#xtensa-*-elf,,xtensa-*-elf}
 @item
@@ -2247,7 +2247,7 @@ GNU Compiler Collection on your machine.
 
 @itemize
 @item
[EMAIL PROTECTED],,all ELF targets} (SVR4, Solaris 2, etc.)
[EMAIL PROTECTED],,all ELF targets} (SVR4, Solaris 2, etc.)
 @end itemize
 @end ifhtml
 
@@ -2840,7 +2840,7 @@ This will be fixed in future releases of
 @html
 
 @end html
[EMAIL PROTECTED] @anchor{ix86-*-sco3.2v5*}i?86-*-sco3.2v5*
[EMAIL PROTECTED] @anchor{ix86-*-sco32v5*}i?86-*-sco3.2v5*
 Use this for the SCO OpenServer Release 5 family of operating systems.
 
 Unlike earlier versions of GCC, the ability to generate COFF with this
@@ -3565,7 +3565,7 @@ plain @option{-g}.
 @html
 
 @end html
[EMAIL PROTECTED] @anchor{sparc-sun-solaris2.7}sparc-sun-solaris2.7
[EMAIL PROTECTED] @anchor{sparc-sun-solaris27}sparc-sun-solaris2.7
 
 Sun patch 107058-01 (1999-01-13) for Solaris 7/SPARC triggers a bug in
 the dynamic linker.  This problem (Sun bug 4210064) affects GCC 2.8
@@ -3724,7 +3724,7 @@ VxWorks will incorporate this module.)
 @html
 
 @end html
[EMAIL PROTECTED] @anchor{x86_64-*-*}x86_64-*-*, amd64-*-*
[EMAIL PROTECTED] @anchor{x86-64-*-*}x86_64-*-*, amd64-*-*
 
 GCC supports the x86-64 architecture implemented by the AMD64 processor
 (amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD.
@@ -3837,7 +3837,7 @@ current GCC) is to be found in the GCC t
 @html
 
 @end html
[EMAIL PROTECTED] @anchor{elf_targets}all ELF targets (SVR4, Solaris 2, etc.)
[EMAIL PROTECTED] @anchor{elf}all ELF targets (SVR4, Solaris 2, etc.)
 
 C++ support is significantly better on ELF targets if you use the
 @uref{./configure.html#with-gnu-ld,,GNU linker}; duplicate copies of

Re: i?86-*-sco3.2v5* / i?86-*-solaris2.10 / x86_64-*-*, amd64-*-*

[Gerald Pfeifer]

On Sun, 1 May 2005, Gerald Pfeifer wrote:
> This is the variant of the patch I applied on the 4.0 branch.

Sorry, that was a typo: for the 4.0 branch I used exactly the same
version as for mainline.  This slightly different patch is what I
applied on the 3.4 branch.

> 2005-05-01  Gerald Pfeifer  <[EMAIL PROTECTED]>
> 
>   * doc/install.texi (Specific): Omit dots in the @anchors names
>   for i?86-*-sco3.2v5* and sparc-sun-solaris2.7.
>   Omit underscores for x86_64-*-* and the "all ELF targets" entry.

Gerald

Re: Should there be a GCC 4.0.1 release quickly?

[Gerald Pfeifer]

On Mon, 2 May 2005, Michael Matz wrote:
> I'm a fan of release early, release often.  Really.  Even if this means 
> we would end up with a 4.0.20 after half a year.

While I wouldn't be _that_ agressive, on FreeBSD where I maintain GCC
in the ports collection, I'm usually tracking our weekly snapshots of
release branches and with good experience so far, and also the Linux
kernel releases rather often these days.

This does not mean that we should switch to weekly release cycles, 
especially considering resource constraints, but for some classes of
users having 4.0.1 a few weeks after 4.0.0, and 4.0.2 after another
month sounds like a desirable option.

Gerald

Re: Revamp WWW review process?

[Gerald Pfeifer]

On Fri, 11 Mar 2005, Giovanni Bajo wrote:
>> You may not have noticed that Gerald is away until 13 March.  Otherwise
>> website patches do get reviewed quickly.
> I think they are not reviewed quickly enough anyway. I do not have 
> evidence (statistics) to bring forward, so feel free to ignore my 
> opinion.

I thought there might be some further discussion on this, potentially
with some delay, but there hasn't been, so let me pick this up.

> I'm not trying to accuse Gerald, I just believe that we should just
> find a faster path to get www patches in.

Here are some of measures we currently have to speed up the process:

1. (old) There is this robot of mine which checks every commit for 
syntactic correctness so that other reviewers (who might be experts in
the field, but not web savvy) can approve patches more easily, people
can apply patches under the obvious rule with less hesitation, and I
can review patches faster because I don't have to care about details
too much.

2. I set up an automated link checker which will help along the same
lines plus ensure that the quality of our site will not degrade when
it comes to broken links.

3. As of today, I added documentation on marking web releated patches by 
prefixing the subject with [wwwdocs] and I set up filters in my e-mail 
client to highlight these to get my highest attention in the GCC lists.

> I'm unimpressed that changes.html is always incomplete, and develepors 
> often update it only after explicit prompts from the Bugmasters.

I wanted the comment at the top of our gcc-x.y/changes.html pages

  

to indicate that very maintainer is free to add/review items in his areas.  
If it does not relay my intention clearly enough, this is an annoying bug 
we should fix!  Would you mind suggesting a better phrasing?

Also, I had hoped that I managed to relay the fact that I would like us
to interpret the "obviously correct" clause rather liberaly when it comes
to the web pages, but reading your comments that apparently was not too 
successfull.  How can we relay this better?

That said, if there are people interested in regularily helping with the
web pages, I definitely would not mind, rather to the contrary!

Gerald

[wwwdocs] patch for Re: Access to benchmark page from our front page

[Gerald Pfeifer]

On Tue, 3 May 2005, Diego Novillo wrote:
> ISTR a link from GCC's home page into http://gcc.gnu.org/benchmarks/
> but it doesn't seem to be there anymore.  Shouldn't it be on the
> index on the left at least?

You mean, like the following?  Good idea.

Installed.

Gerald

Index: style.mhtml
===
RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v
retrieving revision 1.74
diff -u -3 -p -r1.74 style.mhtml
--- style.mhtml 17 Nov 2004 05:57:51 -  1.74
+++ style.mhtml 3 May 2005 22:33:35 -
@@ -241,6 +241,7 @@
   Front ends
   Back ends
   Extensions
+  Benchmarks
   
   
   

Re: No link to benchmarks page ?

[Gerald Pfeifer]

On Tue, 3 May 2005 [EMAIL PROTECTED] wrote:
> is there any link to gcc.gnu.org/benchmarks on the web pages ?

Yes, but _rather_ well hidden, to be honest.

Thanks for the hint! I just added a pointer to that page from the 
navigation bar on our main page.

Gerald

Re: new bounds-checking patches

[Gerald Pfeifer]

On Fri, 6 May 2005, Herman ten Brugge wrote:
> I just released 2 new releases for gcc-3.3.6 and gcc-4.0.0 of my
> bounds-checking patch.
> The patches can be found on http://sourceforge.net/projects/boundschecking
> 
> Can some one update the extension page (http://gcc.gnu.org/extensions.html).
> This page still points to http://web.inter.NL.net/hcc/Haj.Ten.Brugge/

I'll make this change in a minute, but I'll note that the old page has
no obvious reference to the new one nor does it automatically redirect
-- had you set up the latter, I would have noticed this via my regular
checks and updated in any case.

Gerald

Moving the pkgconfig directory from lib/ to libdata/?

[Gerald Pfeifer]

Is the pkgconfig directory at the correct location when put under lib/,
or shouldn't this be libdata/ instead?

I've seen the following patch in use, that's why I'm wondering.

Gerald

--- libjava/Makefile.in.origTue Aug 31 09:39:04 2004
+++ libjava/Makefile.in Tue Aug 31 09:39:46 2004
@@ -180,7 +180,7 @@
 
 toolexecmainlib_DATA = libgcj.spec
 
-pkgconfigdir = $(libdir)/pkgconfig
+pkgconfigdir = $(prefix)/libdata/pkgconfig
 pkgconfig_DATA = libgcj.pc
 
 jardir = $(datadir)/java

Re: Moving the pkgconfig directory from lib/ to libdata/?

[Gerald Pfeifer]

On Wed, 11 May 2005, Roman Kennke wrote:
>>> Is the pkgconfig directory at the correct location when put under lib/,
>>> or shouldn't this be libdata/ instead?
>> What system has $(prefix)/libdata?  None I'm familiar with.
> The BSDs for example use libdata dirs. I suppose the patch is from a BSD 
> port?

Yes, indeed.  It came from a FreeBSD user.

So I guess I should rephrase $SUBJECT as: How can we properly set the 
pkgconfig directory to $(prefix)/libdata/ for FreeBSD and potentially 
others?  Any chance for someone with auto* skills to hack this up?

Gerald

Properly setting the pkcconfig directory (was: Moving the pkgconfig directory from lib/ to libdata/?)

[Gerald Pfeifer]

On Sun, 15 May 2005, Ralf Corsepius wrote:
>> So I guess I should rephrase $SUBJECT as: How can we properly set the 
>> pkgconfig directory to $(prefix)/libdata/ for FreeBSD and potentially 
>> others?
> Using $(prefix)/libdata without any doubt would be wrong.

By "potentially others" I was referring to other BSDs, for example; not
all systems in general.

>>   Any chance for someone with auto* skills to hack this up?
> There is no real need to do so.
> 
> make pkgdatadir=/libdata install
> 
> already should do the job.

This is fine to use, but our configure/build system really should
be clever enough to automatically set pkgdatadir to the correct
value in the first place: $(prefix)/libdata/pkgconfig on FreeBSD,
and $(libdir)/pkgconfig elsewhere.

Gerald

Re: Link to GCC Wiki?

[Gerald Pfeifer]

On Sun, 15 May 2005 [EMAIL PROTECTED] wrote:
> The only link to the GCC wiki is the initial Jan 27
> announcement.  I think a link to
> http://gcc.gnu.org/wiki/ should be added to the
> Documention links on the left of the
> http://gcc.gnu.org/ page.

Indeed I'll make this change and add a link to the navigation bar in
the next couple of days unless someone else beats me to it.

Gerald

Re: [gnu.org #232556] GNU Mirror: SWITCHmirror replaces Swiss SunSITE

[Gerald Pfeifer]

On Thu, 5 May 2005, John Sullivan wrote:
> I've updated the mirror list on gnu.org. I'm passing this on to you so
> you can consider it for the GCC mirrors list as per his request.

Thanks.

Please note that for http://gcc.gnu.org/mirrors.html we only add mirrors
which specifically mirror the ftp area from gcc.gnu.org, whereas we refer
to the GNU mirror site list for those sites that mirror ftp.gnu.org (and
thus GCC releases).

Gerald
-- 
Gerald (Jerry) Pfeifer   [EMAIL PROTECTED]   http://www.pfeifer.com/gerald/