Re: Backporting to 4_0 the latest friend bits
Mark Mitchell wrote:
Those are somewhat above my pain threshold. Is there something else
that we could do for the 4.0 branch? Like issue a warning and ignore
the friend declaration?
Sorry for long delay. I just got back from a trip (but I will be away
next week as well.) Doing what you suggest, ignoring friend declarations,
would break other valid code now accepted by 4.0 such as below:
class A {};
namespace N {
class B {
friend class A;
// more stuff here
};
class A {
// accessing B private/protected members
};
}
> Am I correct in understand that the problem
> case is that the friend declaration looks like "friend class C" where
> there is a C in a containing scope, but no C in the class with the
> friend declaration?
The problem here is name conflict of C in two different scope
via using declaration/directive.
I see that either the patch (actually only one of the two fixes this issue:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01283.html ) applied or
leave the current behavior as is. It would do more harm than good
if we try to do something different.
--Kriang
Testing the performance of Instruction Scheduler..
Hi, How can we measure the performance benefits of GCC instruction scheduler? Are there any testcases to measure it? -- Sachin
Re: GCC 4.1: Buildable on GHz machines only?
Tom Tromey <[EMAIL PROTECTED]> writes: > > Splitting up libgcj.so probably makes sense even for the Linux distro > case (the one I am most concerned with at the moment), just so that > apps that don't use AWT or Swing don't really pay for it. The Hmm? Unless you initialize AWT/swing in all programs that code should never be paged in for non GUI programs. Ok in theory if you use a random build order then a lot of pages could contain GUI and non GUI code together, but that is probably unlikely. The only reason to split it out would be to allow a libgcj installation that is not dependent on the X11 libraries on the RPM/dpkg/etc. level for small setups, but I am not sure how useful that is anymore for most distributions. And perhaps to make the linking steps in the gcc build a bit faster, but just for that it seems like a lot of work. > overhead of, say, BC-compiling AWT and putting it in a separate .so > doesn't seem unreasonable, based on our experiences with BC compiling > large apps. (Even this situation has its losers, for instance CNI > users accessing AWT, like the xlib peers. It looks impossible to > please everybody 100%.) > > This split would help Windows users, too, I think, as at least AWT and > Swing are fairly useless on that platform (no native peers; you can > run the Gtk peers but that is weird). > > For embedded platforms, I would not mind seeing patches to allow > completely disabling parts of the build based on configure switches. > E.g., a switch to drop AWT entirely would be fine by me. Someone Shouldnt the linker do that already at runtime? Ok you pay the cost of building it when gcc is built and storing the libraries on disk, but in the final executable all should be only linked in when actually referenced. I know it can take quite some effort to make libraries really static linking friendly so that libraries dont pull in other code intentionally (take a look at nm of a a static glibc program to see how it should be not done), but I would hope at least that the GUI and non GUI parts of libgcj are clearly separated. -Andi
RE: successful build on i686-pc-cygwin
Original Message >From: Jørgen Havsberg Seland >Sent: 06 May 2005 23:30 > additional information: > Important to mount all binary folders with the -X option, as otherwise > command-lines will be too long, for instance: > >mount -f -X c:/cygwin/bin /bin > > Important: This also goes for the executables built, so having your > objdir inside a mount with cygexec enabled is required. > > j Strange that, I didn't have any similar trouble. Did you unpack the source into a directory that had a fairly long path name to start with? cheers, DaveK -- Can't think of a witty .sigline today
Building a cross-language aspect weaver in GCC 4.0
Hi, For my PhD research, I'm working on an aspect language for C, called Aspicere. References on Aspect-Oriented Programming (AOP) can be found on http://aosd.net, but basically aspects are modules which encapsulate all related functionality (called advice) of a particular concern (logging, persistence, ...) as well as conditions (pointcut expressions) expressed on a regular program to indicate where advice should be triggered during execution of that base program. As such, multiple concerns are separated more cleanly to facilitate better code reuse, program comprehensibility, ... . A weaver mixes both aspects and base program at compile/load/run-time. Most AOP tools are developed for Java (AspectJ, ...), but in fact AOP is not tied to one language, nor to OO-languages. Currently, Aspicere's weaver transforms a C program by manipulating an XML-representation of its Abstract Syntax Tree (AST) and then hands it down to GCC (so it's a source-to-source weaver). A new prototype will be available soon on http://allserv.ugent.be/~kdschutt/aspicere/, featuring a Prolog-based pointcut language. To extend our work to C++ or even Java, we'd face two main problems: offering a suitable pointcut language for each particular language and an efficient way to effectively weave aspects. The former problem can be handled by designing different layers of Prolog predicates, such that the frontend predicates for the different languages eventually rely on the same basic predicates. The latter issue would force us to invent new XML-representations for all the desired base languages or, much more challenging, design one uniform formalism for all of them. These solutions are either tiresome or too monolithic. And what about the efficiency of either the woven code and the weaver itself? GCC is the primary compiler on Unix/Linux systems and has also been ported to numerous computer architectures. The new GCC 4.0.0 features two incarnations of a new intermediate representation (IR): GENERIC and GIMPLE trees. If we let our weaver operate on these instead of on custom XML representations, our second problem can be solved. Because all GCC-supported languages (C, C++, Objective-C, Fortran, Java, and Ada) fall back on the same IR, advice code written in C could theoretically be applied to e.g. a Fortran application. So, apart from more efficient weaving capabilities on a plethora of platforms, building an aspect weaver into GCC itself would also facilitate language-independent weaving. A very schematic outline of what I'm intending to do: 1) C's frontend generates IR of base program and aspects (advice code is pure C) 2) Prolog engine is given a Prolog representation of pointcut expressions as well as access to IRs 3) Prolog engine selects appropriate IR-nodes where corresponding advice should be woven 4) IR is modified (actual weaving of advice in base program) 5) normal GCC operations continue So, I'm about to investigate these ideas. As I'm fairly new to GCC's internals and source code structure, I'd like to pose the following questions: 1) Are these plans feasible? Is somebody else already doing similar things? 2) Where can I find the most documentation about the SSA trees, navigating through them, modifying them, ...? 3) Where should I start to look in the source code? Any comments or suggestions are welcome. If some things seem rather unclear, don't hesitate to ask for more explanation. Kind regards, Bram Adams SEL, INTEC, Ghent University (Belgium)
Re: building gcc 4.0.0 on Solaris
> > Bug ID: 4910101 > > Synopsis: fbe needs a way to reference section labels > > Category: compiler > > Subcategory: assembler-x86 > > Apparently this problem only shows up for x86 when using Sun tools, but > when using GNU tools, it also shows up for sparc. Do you have a testcase? AFAIK the problem only shows up with the Sun tools. -- Eric Botcazou
Re: successful build on i686-pc-cygwin
On Sat, May 07, 2005 at 04:44:44PM +0100, Dave Korn wrote: >Original Message >>From: J?rgen Havsberg Seland >>Sent: 06 May 2005 23:30 > >>additional information: Important to mount all binary folders with the >>-X option, as otherwise command-lines will be too long, for instance: >> >>mount -f -X c:/cygwin/bin /bin >> >>Important: This also goes for the executables built, so having your >>objdir inside a mount with cygexec enabled is required. > >Strange that, I didn't have any similar trouble. Did you unpack the >source into a directory that had a fairly long path name to start with? It could also be an environment variable problem. Too many environment variables could overflow the windows enviroment buffer unless you use "-X". cgf
gcc-4.0-20050507 is now available
Snapshot gcc-4.0-20050507 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050507/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 CVS branch with the following options: -rgcc-ss-4_0-20050507 You'll find: gcc-4.0-20050507.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20050507.tar.bz2 C front end and core compiler gcc-ada-4.0-20050507.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20050507.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20050507.tar.bz2 C++ front end and runtime gcc-java-4.0-20050507.tar.bz2 Java front end and runtime gcc-objc-4.0-20050507.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20050507.tar.bz2The GCC testsuite Diffs from 4.0-20050430 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 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.
Questions about a constant array reference in the C++ front end
Hi,
I have two questions about the C++ front end.
Consider a C++ program
static const int array[] = { 0, 0, 0, 1, 1, 1, 2, 2, 2 };
int
foo (int a)
{
return array[7];
}
I am trying to fold array[7] into 2. It turns out that if T is an
ARRAY_REF,
TREE_READONLY (TREE_OPERAND (T, 0))
is 0. Why? This would be 1 if the program is fed into the C front
end, which is needed to safely fold a constant array reference.
Another question. How is a RANGE_EXPR used in a C++'s array
constructor? The CONSTRUCTOR section of tree.def says
The TREE_PURPOSE of each node is the corresponding index.
If the TREE_PURPOSE is a RANGE_EXPR, it is a short-hand for many nodes,
one for each index in the range. (If the corresponding TREE_VALUE
has side-effects, they are evaluated once for each element. Wrap the
value in a SAVE_EXPR if you want to evaluate side effects only once.)
I created an array with more than one thousand elements. I still did
not see a RANGE_EXPR in the array's CONSTRUCTOR. How do I get a
RANGE_EXPR in a CONSTRUCTOR?
Kazu Hirata
