Re: git.infradead.org missing most GCC SVN branches?

[Nix]

On 6 Jul 2008, Daniel Berlin spake thusly:

> gcc.gnu.org/git/gcc.git tracks all branches.

Updating now, thank you :) an official GCC git repo, whoo!

> Just remember to tell it to fetch all remote refs (since git-svn
> branches are done as remotes)

That's the default for `git remote add', I think.

git.infradead.org missing most GCC SVN branches?

[Nix]

[David, my fallible memory says that you operate this incredibly useful
 service: if not, feel free to ignore it / tell me who does / forward
 it on.]

I just had reason to want to look at the 4.3 branch (as opposed to HEAD
as usual) and found that the git mirror on git.infradead.org isn't
tracking it:

* remote origin
  URL: git://git.infradead.org/gcc.git
  Remote branch merged with 'git pull' while on branch trunk
trunk
  Tracked remote branches
autovect-branch fixed-point gcc-4_1-branch gcc-4_2-branch master trunk

Might it be a good idea to expand the set of GCC SVN branches that this
repository is tracking a bit? I'm not asking for every random weird
branch, but release branches and perhaps major branches under
development might be a good idea.

Re: Git and GCC

[Nix]

On 8 Dec 2007, Johannes Schindelin said:

> Hi,
>
> On Sat, 8 Dec 2007, J.C. Pizarro wrote:
>
>> On 2007/12/07, "Linus Torvalds" <[EMAIL PROTECTED]> wrote:
>>
>> > SHA1 is almost totally insignificant on x86. It hardly shows up. But 
>> > we have a good optimized version there.
>> 
>> If SHA1 is slow then why dont he contribute adding Haval160 (3 rounds) 
>> that it's faster than SHA1? And to optimize still more it with SIMD 
>> instructions in kernelspace and userland.
>
> He said SHA-1 is insignificant.

Actually davem also said it *is* significant on SPARC. But of course
J. C. Pizarro's suggested solution won't work because you can't just go
around replacing SHA-1 in git with something else :) you could *add* new
hashing methods, but you couldn't avoid SHA-1, and adding a new hashing
method would bloat every object and every hash in objects like commits
with an indication of which hashing method was in use.

(But you know this.)

>> 1.   "Don't compress this repo but compact this uncompressed repo
>>   using minimal spanning forest and deltas"

... and then you do a git-gc. Oops, now what?

... or perhaps you want to look something up in the pack. Now you have to
unpack a large hunk of the whole damn thing.

>> 2.   "After, compress this whole repo with LZMA (e.g. 48MiB) from 7zip before
>>   burning it to DVD for backup reasons or before replicating it to
>>  internet".
>
> Patches? ;-)

Replicating a pack to the internet is almost invariably replicating
*parts* of a pack anyway, which reduces to the problem with option 1
above...

-- 
`The rest is a tale of post and counter-post.' --- Ian Rawlings
   describes USENET

Re: C++ man pages?

[Nix]

On Sun, 23 Apr 2006, Joe Buck prattled cheerily:
> 
>> On 20 Apr 2006, Joe Buck moaned:
>> > There is online documentation at
>> > 
>> > http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html
>> > 
>> > It doesn't exist in "man page" form.
> 
> On Sun, Apr 23, 2006 at 08:30:01PM +0100, Nix wrote:
>> Um, what does `make -C your-platform-directory/libstdc++-v3 doxygen-man' 
>> produce, then?
> 
> A greatly inferior version lacking class diagrams, hyperlinks, tables of
> contents, etc.

Yes, they are nasty, but they're manpages, and have the notable
advantage of being about three keystrokes away in most editors.
I use them to look up prototypes in about half the time (the
other half the time I use the Standard).

> But at least you get to say "Gotcha!"

Oh, that would be juvenile. I just carve another notch into the side of
my monitor...

-- 
`On a scale of 1-10, X's "brokenness rating" is 1.1, but that's only
 because bringing Windows into the picture rescaled "brokenness" by
 a factor of 10.' --- Peter da Silva

Re: C++ man pages?

[Nix]

On 20 Apr 2006, Joe Buck moaned:
> On Thu, Apr 20, 2006 at 03:09:16PM -0400, Philip Goetz wrote:
>> I know this is such a basic question, but I've been through dozens of
>> websites and several FAQs without finding an answer...
>> 
>> Where can I get C++ language man pages for use with gcc?  Not the man
>> page for gcc, but the man pages for the C++ library functions?
> 
> There is online documentation at
> 
> http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html
> 
> It doesn't exist in "man page" form.

Um, what does `make -C your-platform-directory/libstdc++-v3 doxygen-man' 
produce, then?

-- 
`On a scale of 1-10, X's "brokenness rating" is 1.1, but that's only
 because bringing Windows into the picture rescaled "brokenness" by
 a factor of 10.' --- Peter da Silva

Re: Problem with gfortran or did I messsed up GMP installation?

[Nix]

On 13 Jan 2006, Eric Botcazou mused:
>> GMP is used by the compiler, not by the application, so you only need
>> the version that the compiler will use.
> 
> Right, that's what I previously said. :-)  But Aleksandar apparently insists 
> on having both versions installed.

Doesn't Solaris have an equivalent of /usr/lib64 where you could put the
64-bit-only version?

In any case this is an OS/shared library loader thing, not anything that
anyone here can reasonably solve, I'd think.

-- 
`I must caution that dipping fingers into molten lead
 presents several serious dangers.' --- Jearl Walker

Re: config.cache question

[Nix]

On 13 Jan 2006, Ben Elliston uttered the following:
>> I apologize if this question has already been answered but I would
>> like to know if there is a way to reuse the same config.cache file
>> for all the builds of all the subdirectories of a bootstrap ?
> 
> It should be possible, but the configure scripts do not update the
> config.cache file in a concurrency-safe fashion, so this would make
> parallel building impossible--something which is no doubt a bigger
> win.

Also, configure may give different answers when rerun on some
subdirectories with different compilers (particularly when multilibbing,
or for directories like libiberty which are configured both with the
bootstrap compiler and with others).

configure runs never take long compared to everything else building
GCC involves, anyway (well, except on Solaris boxes when you forget to
set SHELL appropriately!)

-- 
`I must caution that dipping fingers into molten lead
 presents several serious dangers.' --- Jearl Walker

Re: Missing GNAT docs

[Nix]

On 10 Jan 2006, Jonathan Wakely uttered the following:
> I can't help to put the 3.4.5 docs there, but the 3.4.4 docs are
> available, just change the 5 in the broken URLs to a 4.
> 
> I don't know for certain, but I doubt the changes were very significant.

A brief `svn diff' shows that there were no changes at all.

-- 
`I must caution that dipping fingers into molten lead
 presents several serious dangers.' --- Jearl Walker

Re: default cflags to compile

[Nix]

On 8 Dec 2005, Nuno Lopes gibbered uncontrollably:
> I need to generate a gcc binary that will always enable the
> -fabi-version=1, because I have a library built with gcc 3.3 and I
> need to link with it, but I would like to use gcc 4.

The libstdc++ ABI broke between these releases, so unless your library
doesn't use libstdc++ at all (somewhat unlikely), there is little point
to this.q

> Is there a simple way to do this (a configure option,..) ? or do I
> need to patch the gcc/c-cppbuiltin.c file to always define
> _GXX_ABI_VERSION as 102?

The latter, as far as I know.

-- 
`Don't confuse the shark with the remoras.' --- Rob Landley

Re: A couple more subversion notes

[Nix]

On 19 Oct 2005, Giovanni Bajo yowled:
> Andreas Schwab <[EMAIL PROTECTED]> wrote:
> 
>>> If I remove the socket file, it just does a normal connection.
>> 
>> It doesn't for me.
>> 
>> $ ssh gcc.gnu.org
>> Couldn't connect to /var/tmp/schwab/ssh_%h: No such file or directory
> 
> Ah, maybe it's a later fix? I'm using:
> 
> $ ssh -V
> OpenSSH_4.2p1, OpenSSL 0.9.7f 22 Mar 2005

A typical case of `horrid bug fixed by a merge the day after the
release':

,
| 20050525
| [...]
|- [EMAIL PROTECTED] 2005/04/26 13:08:37
|  [ssh.c ssh_config.5]
|  fallback gracefully if client cannot connect to ControlPath. ok djm@
| [...]
| 20050524
| [...]
|  - Release 4.1p1
`

4.2p1 has the fix (as does 4.1, but I doubt that's much use unless you're
running OpenBSD).

-- 
`"Gun-wielding recluse gunned down by local police" isn't the epitaph
 I want. I am hoping for "Witnesses reported the sound up to two hundred
 kilometers away" or "Last body part finally located".' --- James Nicoll

Re: Some svn numbers

[Nix]

On 12 Oct 2005, Daniel Berlin murmured woefully:
> (I'd recommend a 1.2.x client, or 1.3.x in a few weeks.  1.2.x has much
> fsater working copy than 1.2.x)

So this is some sort of Zen version control, is it? :)

(I assume you mean that 1.2.x is much faster than 1.1.x, and 1.3.x is a
little faster than 1.2.x...)

-- 
`Next: FEMA neglects to take into account the possibility of
fire in Old Balsawood Town (currently in its fifth year of drought
and home of the General Grant Home for Compulsive Arsonists).'
--- James Nicoll

Re: New port contribution - picoChip

[Nix]

On 12 Sep 2005, Steven Bosscher gibbered uncontrollably:
> I think people should object.  What is the point in having a free
> software compiler if e.g. users can't use a complete free toolchain;
> or gcc developers not being able to test changes when some patch
> needs changes in every port.

Well, that kills HP-UX and Tru64 and many other targets.

A *lot* of targets don't have free-software linkers, in particular.

-- 
`One cannot, after all, be expected to read every single word
 of a book whose author one wishes to insult.' --- Richard Dawkins

Re: Cross Compiler Unix - Windows

[Nix]

On 29 Aug 2005, Gerald Pfeifer said:
> On Fri, 26 Aug 2005, Nix wrote:
>> --enable-version-specific-runtime-libs and
>> --program-{prefix,suffix,transform-name} and make slight adjustments
>> after installation (ditch libiberty.a and some locale and manpage stuff
>> that doesn't get its name suitably adjusted).
> 
> mudflap is an offender as well, see Bugzilla #18244 (libmudflap
> installs include/mf-runtime.h in version-independent path).
> 
> Java has libdata/pkgconfig/libgcj.pc and include/ffi.h.
> 
> And, like the man pages, the info files do not honor --program-suffix,
> but for regular C, C++, Objective-C and Fortran development neither of
> is a real killer, agreed.

Well, the man and info pages are always the same (assuming you're
installing the same GCC release targetted differently), so there's
no real problem there. The same seems to be true of libgcj.pc and
mf-runtime.h.

The ffi.h thing really is a bug with consequences: the thing's got
target-dependent contents :/

-- 
`... published last year in a limited edition... In one of the
 great tragedies of publishing, it was not a limited enough edition
 and so I have read it.' --- James Nicoll

Re: Cross Compiler Unix - Windows

[Nix]

On 26 Aug 2005, Kai Ruottu complained:
>Not even mentioning Linux and its GCC idea: "There can
> be only one!", seemingly borrowed from the "Highlander" -- that all the
> GCCs on a host system should use a common $prefix has seemingly been
> totally unknown by the Linux people and they really expected the native
> GCC to be the only GCC ever on that host! Or that if one needs more
> GCCs, they can only be other versions for the native GCC...

This is nonsense. I have a dozen cross-compilers on this box, all
installed into /usr. They do not collide as long as you configure with
--enable-version-specific-runtime-libs and
--program-{prefix,suffix,transform-name} and make slight adjustments
after installation (ditch libiberty.a and some locale and manpage stuff
that doesn't get its name suitably adjusted).

There is nothing whatsoever special about the system compiler on Linux.
It's just a GCC configured with particular switches, that is all.

>   The '--with-sysroot' tries to keep the 'proprietary' layouts even on
> the cross-hosts, where people could always use the "standard install
> layout for GCC", every GCC installed using just the same rules. So the
> situation where all crosscompilers use their own proprietary layouts
> has somehow been seen being better that trying to standardize the GCC
> installation layout.

Er, GCC will always look in ${tooldir}/lib for libraries, ${tooldir)/bin
for binaries, and so on. (Your comments below indicate that you know this:
so what are you talking about here?)

>   The current cross-GCC install layout has its problems : there is only
> one $target dependent place for the libraries when a typical native GCC
> has at least two, '/lib' and '/usr/lib'.

If you are installing libgcc_s.so* into /lib, you'd better damned well
know what you're doing, as you'll be overwriting the distribution's
copy. Doing it automatically strikes me as a seriously bad idea: anyone
installing an old GCC in parallel with a new one would stand at risk of
wrecking every program on their system dynamically linked against
libgcc_s. (Those of us who don't use distributions generally have
installation-time scripts that can do the necessary by-hand mv.)

There were huge flamewars^W^Wintense debates about this when libgcc
was made into a shared library: look at the list archives.

>  Meanwhile a cross-GCC has two
> places for the headers: the '$tooldir/include' for the standard (posix)
> headers and the '$tooldir/sys-include' for the system-specific
> (non-posix etc.) headers.

Personally I've never quite seen the point of sys-lib and sys-include.
I just dump all the target libraries and headers into the target-
specific lib and include directories. :)

>   However anyone who has built more than 10 GCCs for more than 10 targets
> and then installed them on the same development platform, has somehow
> got used to the current (but limiting) layout, and has solved the
> problems somehow. For instance what to do with the Solaris2 '/usr/lib',
> '/usr/ccs/lib', '/usr/ucblib', '/usr/ccs/ucblib' and so on library
> places someone recently had some problems with.

I created ${tooldir}/ccs/lib et al and just had a site-config script
construct suitable -L arguments to GCC. (If you're doing much
cross-compilation you'll end up with a site-config script full of all
sorts of stuff anyway. This is nothing by comparison.)

>   Ok, as long as there are those stupid installs to '/usr' on the native
> front, as long people must think how on earth the natively installed
> C libraries can be copied to the cross host.

Er, NFS? cp? tar? All of them work.

>  Linux is a good example
> about this stupidity in the very beginning. Instead of thinking how
> one could produce apps for Linux easily on ANY host, it was thought
> how one could produce apps for Linux ONLY on the Linux host and so
> trying to make cross-compiling to Linux as hard as possible.

It's not hard. Just lump everything in /lib into the same place as
everything in /usr/lib on the compilation host, and everything will
work fine.

>   Not using '--with-sysroot=' at all, but simply putting the '/lib'
> and '/usr' stuff below a '$sysroot' and then symlinking the
> '$sysroot/usr/include' and '$sysroot/usr/lib' to be seen as 'include'
> and 'lib' on the $gcc_tooldir, adding a couple more symlinks to the
> 'lib' and editing the absolute paths away from the 'libc.so', enables
> one to get a Linux-targeted GCC to work.

Indeed it does. (The libc.so absolute paths are... silly, but that's
not something you can blame on GCC. Best of luck convincing Ulrich
to change it.)

>  With 64-bit bi-arch targets
> one of course uses the default 'lib64' as the place here the
> $gcc_tooldir/lib' leads to... No need for '--with-sysroot=' with the
> 64-bit bi-arch targets either.

Yeah, but they're not really cross-compilers in that sense: they're

Re: What systems (if any) have fprintf_unlocked?

[Nix]

On 14 Aug 2005, Zack Weinberg yowled:
> Kaveh R. Ghazi said:
>> Hmm I'm curious, what systems (if any) have fprintf_unlocked?
> 
> At the time I thought glibc had it, but I don't see it on my (2.3.5)
> system now.

It doesn't appear in the changelogs either.

Is it possible you got confused with fputs_unlocked() or something?

-- 
`I work in computers so, of course, I'm an expert on everything.'
 --- Simon Rumble

Re: PATCH: Enable FTZ/DAZ for SSE via fast math

[Nix]

On 10 Aug 2005, H. J. Lu said:
> +  /* SSE is the part of 64bit. Only need to check it for 32bit.  */

Grammar nit: this should probably be

+  /* All 64-bit targets have SSE; only check it explicitly for 32-bit ones.  */

or something like that.

> + : "i" (0x0020));
> +  if (((eax ^ ebx) & 0x0020) == 0)
> +  if (edx & (1 << 25))

Am I the only person here who gets squicked by all this use of magic
numbers?

-- 
`I work in computers so, of course, I'm an expert on everything.'
 --- Simon Rumble

Re: does -fstack-protector work for gcc 4.1 on Darwin 8?

[Nix]

On 4 Aug 2005, Richard Henderson whispered secretively:
> On Wed, Aug 03, 2005 at 09:39:13PM -0400, Jack Howarth wrote:
>> Do you think I should be able to build gcc itself with the
>> -fstack-protector flag and what is the most appropriate way to
>> achieve that (ie brute force using a CFLAG or some configure
>> flag)?
> 
> Considering that I don't think that self-building with 
> -fstack-protector will ever be common, I don't think we
> ought to spend too many brain cells on this.

It was always possible with the SSP implementation, FWIW.
(This was useful to get a libgcc compiled with -fstack-protector,
although it's true that changing the TCFLAGS in gcc/Makefile
also lets you do that.)

> The only way to bootstrap with -fstack-protector without
> existing support in libc is to use a top-level bootstrap.

... which is reasonable, I think. (This was also true of
SSP.)

-- 
`Tor employs several thousand editors who they keep in dank
 subterranean editing facilities not unlike Moria' -- James Nicoll 

Re: Large, modular C++ application performance ...

[Nix]

On 29 Jul 2005, Florian Weimer announced authoritatively:
> * michael meeks:
> 
>>  I've been doing a little thinking about how to improve OO.o startup
>> performance recently; and - well, relocation processing happens to be
>> the single, biggest thing that most tools flag.
> 
> Have you tried prelinking?

Prelinking is mentioned near the start of the paper and was actually
implemented with OOo (and KDE) in mind.

Alas, it's ineffective for dlopen()ed objects, and OOo dlopen()s nearly
everything. (To my mind the solution is `don't do that then; DT_NEEDED
has a purpose dammit'... certainly this is less disruptive than a change
to the C++ ABI, requiring cooperation with other vendors and a rebuild
of the entire known C++ universe yet again! But I am but an egg in these
waters.)

-- 
`Tor employs several thousand editors who they keep in dank
 subterranean editing facilities not unlike Moria' -- James Nicoll 

Re: (SOLVED) Re: GCC 4.0.1 testsuite uses installed g++ instead of newly bootstrapped g++

[Nix]

On 28 Jul 2005, Joe Buck announced authoritatively:
> Glad you found this.  Your experience is why I've always objected when
> someone suggests a .gccrc or a GCC_OPTIONS environment variable or the
> like; people will forget that they have such files and report
> unreproducible bugs.

Instead, people can wrap GCC in shell scripts, use site-config files,
use automated build infrastructures... we already *have* ways to do
this, some with all the downsides of a .gccrc: the only advantage
is that things like specs files are ill-documented, so people don't
mess with them unless they know what they're doing.

Fundamentally, what we want is `gcc -v' output :) don't the bug
reporting guidelines already ask for this?

-- 
`Tor employs several thousand editors who they keep in dank
 subterranean editing facilities not unlike Moria' -- James Nicoll 

Re: duplicate -lgcc --as-needed -lgcc_s --no-as-needed

[Nix]

On 2 Jun 2005, Peter S. Mazinger murmured:
> On Thu, 2 Jun 2005, Jakub Jelinek wrote:
> 
>> On Thu, Jun 02, 2005 at 01:59:46PM +0200, Peter S. Mazinger wrote:
>> > Hello!
>> > 
>> > the sequence used for linking on x86 (but most archs will have it too)
>> > -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s 
>> > --no-as-needed
>> > contains duplicate. Is this really necessary?
> 
> Is it necessary to have it before -lc and after?

Probably not.  I think the first --as-needed -lgcc_s --no-as-needed
could probably be removed, but this would actually introduce complexity:
both of the `-lgcc --as-needed -lgcc_s- --no-as-needed' sequences come
from expansion of the same %G spec, so we'd have to introduce a new spec
letter just to deal with this, for, effectively, no benefit.  (Maybe
we'd save an unmeasurably small of time in the link phase.)

>> > Will the '--as-needed -lgcc_s --no-as-needed' ever apply?
>> 
>> > The missing symbols will be found in -lgcc.
>> 
>> That's not true.  The EH stuff is not in -lgcc, so if -lc needs it,
>> it wouldn't be found.
> 
> so this construct is used only to get EH stuff from libgcc_s.so? Is there 
> stuff in libgcc.a that is not present in libgcc_s.so too? If not, what 
> about moving this around (or remove -lgcc) and get everything from 
> libgcc_s, if we already depend on it?

The point of that trickery is to avoid introducing a dependency on the
shared libgcc for programs that don't use exception handling. If they
do, it'll come from the shared libgcc: otherwise, the shared libgcc gets
entirely dropped thanks to --as-needed. (This is *not* quite the same as
dropping it for C programs and keeping it for C++ programs: C programs
can be linked with -fexceptions for the same of exception propagation
from C++, and then they'd pull in symbols from libgcc_s, even if they
are themselves not using the symbol anywhere else: perhaps they're a
shared library, or will dlopen() something written in C++ which may
throw.)

-- 
`Once again, I must remark on the far-reaching extent of my
 ladylike nature.' --- Rosie Taylor

Re: some question about gc

[Nix]

[Disclaimer: the transition to GC happened around the time I started
 paying attention to GCC, so my knowledge of the pre-GC situation
 may be inaccurate.]

On 16 May 2005, zouq suggested tentatively:
> and now i am thinking that why use garbage collection in gcc,
> is it because of its high efficiency?

The opposite. Back in days of yore (GCC 1.x and 2.x), GCC managed
virtually everything using obstacks, i.e., `stacks of objects' with the
usual stack property that you can only add and remove from the end of
the stack; you could also free a whole stack at once.

For some objects, this made sense: you could build up a bunch of RTL
expressions on an obstack with ease, say. But if you wanted to *change*
that sequence in ways that added, removed, or reordered elements, things
got hairier. (And, of course, that's basically what many of the RTL
optimizers do.)

The contortions needed to ensure correct ownership of every obstack and
to arrange that GCC never needed to add or remove anything in the middle
of the obstacks grew rather extreme, and a considerable number of bugs
were tripped by freeing an obstack and then referencing some pointer
that turned out to point into the middle of it, and so on.

Around the long development cycle that led to GCC 3.0, this finally grew
overwhelming, and a GC was implemented. Mike Stump (I think it was) and
others have collected evidence indicating that the GC was actually
responsible for a substantial overall compiler *slowdown*, not because
it was slow at collecting garbage, but because related objects now got
allocated far apart in memory, so they tended not to share cachelines
anymore. As a consequence, some time-critical parts of GCC have actually
been moving back towards using obstacks again, and new GC algorithms
(the zone allocator in particular) have been worked on which might fix
this.


But, on balance, GC has probably been a boon, I feel: the code is much
more comprehensible now[1], and changing it is not nearly so
hair-raising[1].  Some performance loss is worth it if the consequence
is a working compiler, I'd say.


[1] except for reload

-- 
`End users are just test loads for verifying that the system works, kind of
 like resistors in an electrical circuit.' - Kaz Kylheku in c.o.l.d.s

Re: Packing booleans?

[Nix]

On 4 May 2005, Sam Lauber stipulated:
> Would it be possible to have a -fpack-bools option that packs booleans into
> the smallest form possible (8 booleans -> 1 8-bit reg, etc.) into a register
> (or memory, as the case may be)?

How could you do that without breaking the semantics of the program?

Among other things, you couldn't take the address of such a packed
boolean: if the idea is to quietly suppress boolean packing for booleans
whose address is taken, then this will suppress packing for any boolean
shared between translation units, or possibly even between procedures.

-- 
`End users are just test loads for verifying that the system works, kind of
 like resistors in an electrical circuit.' - Kaz Kylheku in c.o.l.d.s

Re: GCC 4.1: Buildable on GHz machines only?

[Nix]

On 30 Apr 2005, Giovanni Bajo uttered the following:
> There is no outcome, because it is just the Nth legend. Like people say "I
> believe GCC is slow because of pointer indirection" or stuff like that.

Don't we have actual *evidence* that it's slow because of cache
thrashing?

-- 
`End users are just test loads for verifying that the system works, kind of
 like resistors in an electrical circuit.' - Kaz Kylheku in c.o.l.d.s

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

[Nix]

On Thu, 21 Apr 2005, John David Anglin said:
> Yes, a total of more than 4GB has been allocated.  However, most of
> this memory has been freed.  Thus, the total isn't particularly
> informative.

[insert moan about absence of xfree() to adjust count down here]

-- 
This is like system("/usr/funky/bin/perl -e 'exec sleep 1'");
   --- Peter da Silva

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

[Nix]

On Wed, 20 Apr 2005, Daniel Jacobowitz stipulated:
> On Wed, Apr 20, 2005 at 08:16:22PM +0100, Nix wrote:
>> On 14 Apr 2005, John David Anglin spake:
>> >> : out of memory allocating 12016 bytes after a total of 4161654476 bytes
>> > 
>> > You need to increase the application limits for data on your system.
>> 
>> No, something is very wrong here, I think. genattrtab has allocated
>> *4Gb*!
[snip]
> Note that that's a total allocation, not a peak allocation.  The 4GB
> total isn't unlikely, with all the PPC DFAs.

Oh, right: I misread this as an OS-sourced message, not the one from
xmalloc(). Sorry for the misinformation.

Getting useful information out of this has just become practical.
Good. :)

-- 
This is like system("/usr/funky/bin/perl -e 'exec sleep 1'");
   --- Peter da Silva

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

[Nix]

On 14 Apr 2005, John David Anglin spake:
>> : build/genattrtab 
>> /home/kate/gcc-4.0.0-20050410/src/gcc-4.0.0-20050410/gcc/config/rs6000/ 
>> rs6000.md > tmp-attrtab.c
>> : 
>> : out of memory allocating 12016 bytes after a total of 4161654476 bytes
> 
> You need to increase the application limits for data on your system.

No, something is very wrong here, I think. genattrtab has allocated
*4Gb*!

Not even the monster which is x86 needs anywhere near that much storage
when running genattrtab.

Whether this is a genattrtab bug or a genattrtab miscompilation is a
question best left to those with access to this platform (i.e, I
can't answer it).

-- 
This is like system("/usr/funky/bin/perl -e 'exec sleep 1'");
   --- Peter da Silva

Re: RFC: #pragma optimization_level

[Nix]

[Cc: list drastically trimmed.]

On Tue, 5 Apr 2005, Marcin Dalecki spake:
> On 2005-04-05, at 01:28, Nix wrote:
>> On 4 Apr 2005, Marcin Dalecki stipulated:
>>> I don't agree with the argument presented by Geert Bosch. It's even more 
>>> difficult to
>>> muddle through the atrocities of autoconf/automake to find the places where 
>>> compiler
>>> switches get set in huge software projects
>>
>> What's so hard about
>>
>> find . \( -name 'configure.*' -o -name Makefile.am \) -print | xargs grep 
>> CFLAGS
>>
>> anyway?
> 
> Tha fact the you actually *seldomly* have the precise version
> of autoconf/automake/perl/gawk installed on the host you wont to reproduce the
> THRE stages to get a hand and Makefile.

The GNU toolchain has become a little more automated in the last, oh, five 
years:
`autoreconf && configure' will do the trick.

I've found that the combination of autoconf-2.59, automake-1.9.x and
libtool-1.5.10 can handle all but the most complex
configure.in/Makefile.am combinations, even those intended for much
older versions of autoconf and not updated: the only ones that I haven't
locally upgraded are for XEmacs and GCC (both of which are fearfully
complex).

> I could turn the question back: What's so hard about grepping the source?

Because one does not expect to find compilation flags embedded in the
source?  Because generated source is fairly common? Because eventually
that runs you into `what's so hard about predicting the behaviour of
this code generator in order to...' and then you ram straight into
the halting problem, or, worse, Qt's qmake program. :)

(None of these are strong arguments, I'll admit, but if your argument
*for* is `it's convenient', then an argument *against* of `it's
unexpected' is stronger than it looks.)

>>  A few minutes will suffice for all but the most ludicrously
>> byzantine project (and I'm not talking `uses automake', here, I'm
>> talking `generates C code in order to compute CFLAGS to use when
>> compiling other code'.)
> 
> Thus by your definition most projects are byzantine. glibc, tetex ans
> so on...

teTeX -> plain autoconf, automake. No difficulties (there used to be
some back in the teTeX-1.x days, so I fixed them and submitted patches).

gcc -> exceptionally complex, but you frotz with CFLAGS here at your
peril (I do it, but I'm a risk-taking lunatic).

glibc -> definitely byzantine and unique, but when you get down to it
autoconf + ordinary Makefile (if a very, very complex one). Plus, all
the expected ways of globally overriding CFLAGS work there: you can set
CFLAGS and LDFLAGS in the environment, on the configure command line,
and in site-config files, and glibc will carefully override just those
parts that conflict with particular files when needed.

Actually, glibc is a good argument *against* the need for this feature:
it has a large number of places where unusual one-off CFLAGS are
required, and it manages to do them all via one-file overrides in the
makefiles. See e.g. linuxthreads/sysdeps/i386/Makefile for an extensive
use of this. csu/Makefile has an example of *completely* overriding the
CFLAGS for a single file that is especially delicate (initfini.s).

I think this feature would be convenient in some circumstances,
principally to work around places where optimizations turn into
pessimizations for specific compiler versions in speed-critical code:
but the difficulty of changing CFLAGS in makefiles isn't a good reason
for it. :)

-- 
This is like system("/usr/funky/bin/perl -e 'exec sleep 1'");
   --- Peter da Silva

Re: RFC: #pragma optimization_level

[Nix]

On 4 Apr 2005, Marcin Dalecki stipulated:
> I don't agree with the argument presented by Geert Bosch. It's even more 
> difficult to
> muddle through the atrocities of autoconf/automake to find the places where 
> compiler
> switches get set in huge software projects

What's so hard about

find . \( -name 'configure.*' -o -name Makefile.am \) -print | xargs grep CFLAGS

anyway?

I think this is a straw man. Manipulating CFLAGS is just *not that
hard*. A few minutes will suffice for all but the most ludicrously
byzantine project (and I'm not talking `uses automake', here, I'm
talking `generates C code in order to compute CFLAGS to use when
compiling other code'.)

Very little goes that far (one package here out of 2,271). The *vast*
majority just set CFLAGS and/or AM_CFLAGS in one or more places, collate
the result, and that's it. Getting to grips with that is not killingly
difficult.

-- 
This is like system("/usr/funky/bin/perl -e 'exec sleep 1'");
   --- Peter da Silva

Re: Hand-written rec-descent parser of GCC-4.1 is WRONG!!!.

[Nix]

On 16 Mar 2005, Joe Buck stated:
> On Wed, Mar 16, 2005 at 02:41:12AM +0100, [EMAIL PROTECTED] wrote:
>> Writing Hand-written recursive-descent parser miss-cleans the source code
>> and goes hardfully to maintain it!!!
> 
> Not if you know how to write one correctly.

... and I must say that Mark's parser is a joy to behold.

>> The best option is a clean grammar in Yacc/Bison!.
> 
> GCC had such parsers for over a decade, and yet they are being replaced.

Well, actually, the C++ parser was never *clean*, and the C/ObjC parser
wasn't/isn't exactly nice to look at either. :)

The best option is a clean and maintainable parser. Whether it uses a
parser generator or not is comparatively academic...

-- 
This is like system("/usr/funky/bin/perl -e 'exec sleep 1'");
   --- Peter da Silva

Re: How does g++ implement error handling?

[Nix]

On 22 Feb 2005, Aaron W. LaFramboise murmured woefully:
> I'm also interested in any overview-level information about the Dwarf2
> unwinding mechanism.

Aldy Hernandez wrote one: .

-- 
> ...Hires Root Beer...
What we need these days is a stable, fast, anti-aliased root beer
with dynamic shading. Not that you can let just anybody have root.
 --- John M. Ford

Re: Accessing the subversion repository

[Nix]

On 17 Feb 2005, Marc Espie said:
> No need for fsh or anything. Didn't this feature make it into portable 
> openssh ?

Yes, it did, but as usual with OpenSSH entirely without documentation
other than a changelog entry and silent change to the manpage describing
the extra options but not how to use them. As a result, I wasn't sure
how to use it for anything. Your example there is the first I've seen,
and is decidedly helpful: thanks!

-- 
> ...Hires Root Beer...
What we need these days is a stable, fast, anti-aliased root beer
with dynamic shading. Not that you can let just anybody have root.
 --- John M. Ford

Re: License text irregularity in gcc/config/mips/linux-unwind.h

[Nix]

On 11 Feb 2005, Sam Lauber mused:
> As for the exception missing, it should be kept that way.  

As libgcc is linked against every program linked using the GCC driver,
and is required by code generated with GCC, this would make it illegal
to distribute any non-GPL software built with GCC.

This is patently ridiculous and would make GCC almost useless,
regardless of technical merit. Hence the exception clause.

(Well, *clauses* really: the precise wording is different for the Ada
libraries than for libgcc, and different yet again for the libstdc++
headers, corresponding to the different ways in which normal use of the
compiler would incorporate those things into programs built with GCC.)

-- 
Synapsids unite! You have nothing to lose but your eggshells!