Re: [RFC] Documenting support functions and data structures
On 16/04/15 06:12, Mikhail Maltsev wrote: > So, I want to create a similar page in GCC's internal docs, but I don't > know what should be included (i.e. did I miss something important, or > did I include something obsolete), so I ask for some assistance. The real challenge here is not generating the docs but keeping them in step with the source code. History tells us that this is almost never done well. It's better not to have docs than have wrong docs. If you can find some way to ensure that the docs are always correct (e.g. by structured comments in the source code) that will help. Andrew.
Re: broken link for Programming Languages Software Award on gcc homepage
Hi! On Wed, 15 Apr 2015 10:31:59 +0200, Tom de Vries wrote: > the link for 'ACM SIGPLAN Programming Languages Software Award' in the news > list > on gcc.gnu.org is http://www.sigplan.org/node/231, as discussed here ( > https://gcc.gnu.org/ml/gcc/2014-06/msg00136.html ). > > Following the link gives me: > ... > Page Not Found > > The page you were looking for was not found. Sorry. > > You were looking for > > http://www.sigplan.org/node#231 > > Please email the SIGPLAN Information Director, if you think the file should > be > here, and we will fix it. > ... > > A generic link mentioning the award is : > http://www.sigplan.org/Awards/Software/ . I also had noticed that a while ago. Now fixed as follows: Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.963 retrieving revision 1.964 diff -u -p -r1.963 -r1.964 --- index.html 15 Apr 2015 15:10:47 - 1.963 +++ index.html 16 Apr 2015 09:13:20 - 1.964 @@ -135,7 +135,7 @@ mission statement. [2014-06-12] -http://www.sigplan.org/node/231";>ACM SIGPLAN Programming Languages Software Award +http://www.sigplan.org/Awards/Software/#2014";>ACM SIGPLAN Programming Languages Software Award [2014-06-10] Grüße, Thomas signature.asc Description: PGP signature
Re: Re: [RFC] Documenting support functions and data structures
On 16/04/15 10:04, Andrew Haley wrote: On 16/04/15 06:12, Mikhail Maltsev wrote: So, I want to create a similar page in GCC's internal docs, but I don't know what should be included (i.e. did I miss something important, or did I include something obsolete), so I ask for some assistance. The real challenge here is not generating the docs but keeping them in step with the source code. History tells us that this is almost never done well. It's better not to have docs than have wrong docs. If you can find some way to ensure that the docs are always correct (e.g. by structured comments in the source code) that will help. I don't buy this argument in general nor in particular for this case. In general, because it is much harder to write the docs than fixing them. If the docs are wrong at least someone might notice that they are and notice the discrepancy. If there are no docs, there is no way to even start understanding the code. Note that your argument applies also to source code comments: There are plenty of outdated comments in GCC's source code. The conclusion would be that no comments are better than some wrong comments. Do we want to remove all comments because some might be wrong? In particular in this case, he is basically creating an index of fundamental data structures in GCC. The index can briefly summarize the data structures, but it can also simply point out to comments in the code for more info. I would consider a positive step even if just the draft above was texified and added to gccint (after appropriate fixes). And yes, I would also be extremely happy if someone figured out a way to ensure the docs match the comments. We can probably automatically generate from the *.opt files most of invoke.texi and even the list of what enables what. But there are significant non-technical hurdles to achieve that (See https://gcc.gnu.org/wiki/DocumentationOverviewIssues#Legal_and_Licensing_Issues). Should we say that no updates to invoke.texi are accepted until someone implements this automatic generation? It does not seem wise to prevent progress (and new contributions) simply because the solution is not perfect. It is also not fair to dump the hardest more complex problems that no professional long-time GCC developer has figured out how to solve on the shoulders of new contributors. Cheers, Manuel.
Re: [RFC] Documenting support functions and data structures
On Thu, Apr 16, 2015 at 08:12:17AM +0300, Mikhail Maltsev wrote: > Hi, all! > > I think GCC documentation is missing a description of commonly used data > structures and support functions. For example, "GCC internals" document > contains information about, say, GIMPLE IR and functions for > manipulating it. But it does not describe general data structures, such > as hash maps or vectors. > In fact, these structures are documented rather well in the source code, > but I could not find a list of them. > I mean something like this: > http://llvm.org/docs/ProgrammersManual.html#important-and-useful-llvm-apis > > So, I want to create a similar page in GCC's internal docs, but I don't > know what should be included (i.e. did I miss something important, or > did I include something obsolete), so I ask for some assistance. > > Here is a draft (a list of relevant files from ./gcc, ./include and > ./libiberty directories). This list does not yet include functions for > interacting with host OS (it's a separate issue) and does not include > compiler-specific structures (like, say, control flow graph or varpool) > and algorithms. Ordering is somewhat random. First a general comment where something has both a header and a .c file it probably makes sense to mention both. > > === Memory management === > gcc/alloc-pool.c - pool allocator > gcc/ggc* - mark-and-sweep garbage collector (includes sources of > gengtype, a program which generates traversal routines from > annotated C++ code) I wonder if that doesn't fit better in the category of gcc specific things. > gcc/ggc-page.c - size-class based allocator (used by garbage collector). > (?? isn't it the same as "slab allocator") I guess its basically a slab allocator, but its pretty tied in with the rest of ggc currently. > gcc/hash-table.h - contains some simple allocator templates I'm not particularly convinced those are useful, and actually pretty tempted to remove them when I get around to it. afaik nobody actually uses an allocator other than the one that calls xmalloc, and they don't help you work with ggc as the ggc support in hash_table shows. > libiberty/xmalloc.c - wrappers for malloc and friends with checking > > === Data structures === > gcc/bitmap.c - sparse integer set (based on linked lists of chunks) > gcc/sbitmap.c - "simple bitmap" - vector-based bitmap > gcc/et-forest.c - ET-forest data structure (used for efficient solution > of dynamic least common ancestor problem) > gcc/fibonacci_heap.h (header-only) - mergeable priority queues > gcc/graphds.c - graph representation and manipulation functions > gcc/hash-table.c - hash table implementation (base for hash-set and > hash-map) > gcc/hash-map.h (header-only) - hash map > gcc/hash-set.h (header-only) - hash set > gcc/sparse-set.c - another sparse set implementation (I think, I'll make > a table, with comparison of different > implementations w.r.t. size, available operations and their run time) > gcc/vec.c - vector template, implements several different memory > allocation strategies > include/obstack.h - object stack "objet stack" doesn't seem very descriptive to me. "bump allocator pool" or something might be a better description? > libiberty/splay-tree.c - splay tree > > === RTTI, type manipulation === > gcc/is-a.h (header-only) - customizable low-overhead RTTI and dynamic casts > gcc/system.h (header-only) - several implementations of const_cast This is another that doesn't seem very useful now, and I'll probably remove when I get around to it. > === Algorithms === > libiberty/md5.c, sha1.c - corresponding hash functions > libiberty/crc32.c - CRC32 checksum (BTW, why is bitwise implementation > from tree.c used everywhere instead of table algorithm?) > gcc/inchash.c - incremental hashing > libiberty/bsearch.c - binary search (and other stuff reimplementing libc > functions - is this a workaround for broken system libc?) > > === Multiprecision arithmetics === > gcc/hwint.c - "host wide int" - macros for representing host system's > int64_t/uint64_t in a portable way and some related functions most of this is also deprecated gcc requires the system have 64 bit integer types now, but there's still a bunch of old code to remove. Trev > gcc/wide-int.cc, namespace hw - generic finite precision integers > (including variable-precision and target-dependent precision integers > + traits) > gcc/double-int.c - 128-bit fixed precision integer type > gcc/fixed-value.c - fixed precision real arithmetics, uses > target-dependent representation > gcc/real.c - floating-point arithmetics, including target-dependent > representation > gcc/mpfr.c - conversion routines from GCC internal float representation > to MPFR > gcc/sreal.c - simple software floating-point arithmetics > > === Debugging, statistics === > gcc/dbgcnt.c - debug counters > gcc/errors.c - diagnostics for internal use (in generator programs) > gcc/statistics.c - arbitrary statistics counters and histograms > gcc/timevar.c - timing
Re: Undefined Local Symbol on PowerPC
On 4/15/2015 10:38 PM, Alan Modra wrote: > On Wed, Apr 15, 2015 at 04:10:33PM -0500, Joel Sherrill wrote: >> Based on the grep, the .4byte directives are referencing a bogus symbol. >> >> Does this look like a GCC bug? > Yes, unless you have some horrible asm there referencing the symbol. > Nope. Just plain old zlib.c. :) It is 65779. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985
Re: [RFC] Documenting support functions and data structures
On 04/16/2015 02:22 PM, Manuel López-Ibáñez wrote: > On 16/04/15 10:04, Andrew Haley wrote: >> On 16/04/15 06:12, Mikhail Maltsev wrote: >>> So, I want to create a similar page in GCC's internal docs, but I don't >>> know what should be included (i.e. did I miss something important, or >>> did I include something obsolete), so I ask for some assistance. >> >> The real challenge here is not generating the docs but keeping them in >> step with the source code. History tells us that this is almost never >> done well. It's better not to have docs than have wrong docs. >> >> If you can find some way to ensure that the docs are always correct >> (e.g. by structured comments in the source code) that will help. > > I don't buy this argument in general nor in particular for this > case. In general, because it is much harder to write the docs than > fixing them. If the docs are wrong at least someone might notice > that they are and notice the discrepancy. They might. > If there are no docs, there is no way to even start understanding > the code. Note that your argument applies also to source code > comments: There are plenty of outdated comments in GCC's source > code. Sure, but external docs seem to be less likely to be kept up to date than internal comments. > The conclusion would be that no comments are better than some wrong > comments. Do we want to remove all comments because some might be > wrong? No, and this does not follow from what I wrote. It is better to have no comments than incorrect comments, but this does not imply we should delete all comments, just incorrect ones. I did not say "Do not document the structures", I said "Let's try to make sure the documentation is kept up to date" and suggested a mechanism by which this might be achieved. > And yes, I would also be extremely happy if someone figured out a > way to ensure the docs match the comments. We can probably > automatically generate from the *.opt files most of invoke.texi and > even the list of what enables what. But there are significant > non-technical hurdles to achieve that (See > https://gcc.gnu.org/wiki/DocumentationOverviewIssues#Legal_and_Licensing_Issues). > Should we say that no updates to invoke.texi are accepted until > someone implements this automatic generation? Certainly not. > It does not seem wise to prevent progress (and new contributions) > simply because the solution is not perfect. It is also not fair to > dump the hardest more complex problems that no professional > long-time GCC developer has figured out how to solve on the > shoulders of new contributors. That's an excellent point. I withdrew my suggestion that a newcomer should be trying to solve this problem. I don't want to discourage anyone from helping. However, I am advising caution, particularly when documenting structures whose shape might soon change. And with respect to new contributions, it would be a shame if someone came along, did a great job of documenting the structures and interfaces, then left after a while, leaving the docs to rot. Andrew.
Re: [RFC] Documenting support functions and data structures
On 16 April 2015 at 17:15, Andrew Haley wrote: > However, I am advising caution, particularly when documenting > structures whose shape might soon change. And with respect to new > contributions, it would be a shame if someone came along, did a great > job of documenting the structures and interfaces, then left after a > while, leaving the docs to rot. That is life, and it can happen to a newcomer or a long-time contributor. If there is interest, it will be maintained, if not they will rot until the point that it is better to delete them. At least we can easily delete rotten docs, not so easy with code. Having something like this in gccint or in the wiki can motivate someone to, for example, finally get rid of obsolete data structures that are rarely used. It could also be a starting point to continue this: https://gcc.gnu.org/wiki/ModularGCC by categorizing files in terms of their purpose and putting them together. Also to identify things in liberty that GCC does not actually use (thus no need documenting them) and things that are duplicated with gnulib (we should just use the gnulib version). Even if the only benefit of the list was to make easier for Mikhail to continue contributing to GCC, it would be a net win. Of course, if someone knows that a particular structure is going to change soon, then please tell Mikhail to not bother documenting in detail that one in particular just yet. Cheers, Manuel.
Re: Selecting an architecture tuple for the Rumprun toolchain
Joseph Myers writes ("Re: Selecting an architecture tuple for the Rumprun
toolchain"):
> If you would use a different glibc port, but providing access to
> Linux-specific interfaces, then the tuple would be
> ---gnu, much like *-*-kfreebsd-gnu describes a glibc
> port running on the FreeBSD kernel.
As Martin says, rumprun is not using glibc (and is not expected to any
time soon). So it should not have -gnu.
The problem we are having here is that rumprun doesn't fit in the nice
tidy scheme of these arch tuples. I think the right thing to do is to
consider how these tuples are usually used, to try to understand how
best to express reality within the existing framework.
There are three contexts for the arch tuple:
1. Toolstack name prefixes (and header and library path prefixes).
For this purpose it is necessary to have _different_ names for
different rumprun targets. This is necessary because object
files, libraries, etc. etc., are compiled differently for
different rumprun execution environments.
So we need a string in the tuple like `posix' or `xen' which
indicates the underlying target.
2. Selecting the correct portability options in existing software
For this purpose we need primarily to specify that this is netbsd.
This is because the libc is netbsd, and the system calls, insofar
as they are useable, are generally very like netbsd. This should
appear in the tuple in the place where the libc and/or kernel are
normally reported.
We also need to specify the cpu architecture.
3. Selecting rumpkernel-specific options in rumpkernel-aware software
Some (rare) software wants to do something special in a rumpkernel
environment. So we need to specify `rumprun' or `rumpkernel' or
something, somewhere.
Existing netbsd seems to use
-unknown-netbsdSOMETHING
These considerations lead me to suggest:
-rumprun{posix,xen,baremetal}-netbsd
We need to wedge the target environemnt and rumprun into the same part
of the tuple because we need existing consumers of the tuple to ignore
it thinking it's an irrelevant `vendor'.
Note that the target environment is nothing like the `kernel'.
rumprun applications do not normally get access to the target
environment. It does not provide `system calls'.
Indeed rumprun applications are in the usual case deliberately kept
oblivious of the target environment. So in that sense it does
resemble the `emulation environment' case, and Joseph is right to say
that the application doesn't and shouldn't (normally) need to know.
However, the _user_ does need to know because (as I say) the ABIs,
object formats, header files, etc. etc. etc., are different. So since
the tuple is used not only to tell the application about the
environment but also by the user to specify how to build, it must
contain this information.
Thanks,
Ian.
gcc-4.8-20150416 is now available
Snapshot gcc-4.8-20150416 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20150416/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 222159 You'll find: gcc-4.8-20150416.tar.bz2 Complete GCC MD5=eee331a72986bce8f64055503c40d1ca SHA1=b053104c941db9dfcada2c662666900952ebdd52 Diffs from 4.8-20150409 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Mirror Changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey, We have changed our company name, hostnames and contact information. Please remove the current BBLN mirror (mirror.bbln.org) and replace it with our three new ones: - --- http://mirror0.babylon.network/gcc/ https://mirror0.babylon.network/gcc/ ftp://mirror0.babylon.network/gcc/ rsync://mirror0.babylon.network/gcc/ Location: Gravelines, France Contact: Tim Semeijn (noc@babylon.network) at Babylon Network - --- http://mirror1.babylon.network/gcc/ https://mirror1.babylon.network/gcc/ ftp://mirror1.babylon.network/gcc/ rsync://mirror1.babylon.network/gcc/ Location: Roubaix, France Contact: Tim Semeijn (noc@babylon.network) at Babylon Network - --- http://mirror2.babylon.network/gcc/ https://mirror2.babylon.network/gcc/ ftp://mirror2.babylon.network/gcc/ rsync://mirror2.babylon.network/gcc/ Location: Amsterdam, The Netherlands Contact: Tim Semeijn (noc@babylon.network) at Babylon Network - --- I will also send this e-mail from noc@babylon.network to confirm the request. Thanks in advance! - -- Tim Semeijn pgp 0x08CE9B4D -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJVMEW+AAoJEB4F+FYIzptNcH8H/RUVkmAsUcgNe82nQN+wU76K SJBDD85pf01BqcoSIRpDc8HsjSU7FxhrDmr0u9BXRlIE0XFvRws3YvQqMl3yhTf0 fqATCq/b2KEGnc/mElmn6hO8H2wRMsjh7xPkVq2ysYJoNdBiyZJbZrL6i4TxAUf2 dXFTR18t5VAEOWCREfnkE9dzr4WcFiyiIVP2BeK0086WMLhF++TezuC5pwhlt1nW /D+ncBKJG1bE8poDt6LeHjeqpL+3CdIFLq/NQdNUj5ETyWmbeDV0p7kDgydDLcrA KOyfokNhTSof5p1IkccAsHPVStyq8B9DvLTPtODpuvqYZ0Iut0FJ7a1sszRScaU= =XOBV -END PGP SIGNATURE-
Confirmation Mirror Changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey, [[[ This is a confirmation of the request sent from n...@bbln.org ]]] We have changed our company name, hostnames and contact information. Please remove the current BBLN mirror (mirror.bbln.org) and replace it with our three new ones: - --- http://mirror0.babylon.network/gcc/ https://mirror0.babylon.network/gcc/ ftp://mirror0.babylon.network/gcc/ rsync://mirror0.babylon.network/gcc/ Location: Gravelines, France Contact: Tim Semeijn (noc@babylon.network) at Babylon Network - --- http://mirror1.babylon.network/gcc/ https://mirror1.babylon.network/gcc/ ftp://mirror1.babylon.network/gcc/ rsync://mirror1.babylon.network/gcc/ Location: Roubaix, France Contact: Tim Semeijn (noc@babylon.network) at Babylon Network - --- http://mirror2.babylon.network/gcc/ https://mirror2.babylon.network/gcc/ ftp://mirror2.babylon.network/gcc/ rsync://mirror2.babylon.network/gcc/ Location: Amsterdam, The Netherlands Contact: Tim Semeijn (noc@babylon.network) at Babylon Network - --- Thanks in advance! - -- Tim Semeijn Babylon Network pgp 0x5B8A4DDF -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVMEXGAAoJEIZioqpbik3fcIUP/2Nqh4RB8GbHMu3YaXz48DPy BvBSlh5HRKIqwNnnT6dR0LPp/Se9bU8rUq86c/hfecr7kqldru1bY39aHTY/LjqE poI3ACELS9KeGqP/qvdX0jifaJTw2PWwaSsVnxOUzlpJlQP9AT3q9QvgTTuyxkWu TU8mdUAy8gfzvDQ2aD2s1sCFbic85DymLlKEKo2KH7r4xRFvNPY5dhTSGKbuOwtR DxdAoA7a8jJaD0/Ke6fgdCjq5g/O80kNkzW13F4ZHpQ38Kjs64MDB1FsVUm57SML 5KZ0liKkyHsJQaz6NA/oZkCJccaxN0LoFHbgXg3t49oVyquv3cw/lMxxgi7//HzS uw6iMVHvJ7dVuk3MnTaqRfufYeiRhe3gqZ1E/SDPJGgYchxvgpntK7UT7/+jJRll 8kAJ/yty7kgmC6i8ZMlFCpdgOR7tJ2vOJ8c5s+T0/NKbUXY5etazgHUXe7XhOz+T 7L9woHYQ/Q6q3+JQqEF3kmuZLA7fmr8KjJvGhpw35RIjJkeeKKW+QbAn4W91b8Bi yTG3/crmc2mqvYfM43zm3gzYxb7sv8d1ZIB2TYdYDnQiO5QhyQqHBZQuhcxYZ+PT FAkyl+StCMc7Ucn7kY2+eMQzuFLEst/4UIBewtTqnX70s8o3rYTPtMIgf1qTpEY/ ZKf9FOq7t5U8ZkMxO3yE =RjV6 -END PGP SIGNATURE-
