Re: Ada Broken with h_errno change
> RTEMS has networking functions but they are not available at this stage > during the build. You only have the .h files provided with newlib. So > this patch is needed to make *-rtems compile again. OK to commit? Please post the corresponding ChangeLog so that this patch can be reviewed and approved, thanks. > Index: gcc/ada/socket.c > === > --- gcc/ada/socket.c(revision 107093) > +++ gcc/ada/socket.c(working copy) > @@ -190,6 +190,10 @@ > #elif defined(VMS) >return errno; > #else > +#if defined(__rtems__) > + /* No networking .h files are available from newlib so extern this. */ > + extern int h_errno; > +#endif >return h_errno; > #endif > }
Re: Link-time optimzation
Daniel Berlin <[EMAIL PROTECTED]> wrote: >> Thanks for woking on this. Any specific reason why using the LLVM >> bytecode wasn't taken into account? > > It was. > A large number of alternatives were explored, including CIL, the JVM, > LLVM, etc. > >> It is proven to be stable, high-level enough to >> perform any kind of needed optimization, > > This is not true, unfortunately. > That's why it is called "low level virtual machine". > It doesn't have things we'd like to do high level optimizations on, > like dynamic_cast removal, etc. Anyway, *slightly* extending an existing VM which already exists, is production-ready, is GPL compatible, is supported by a full toolchain (including interpreters, disassemblers, jitters, loaders, optimizers...) looks like a much better deal. Also, I'm sure Chris would be willing to provide us with all the needed help. I also think CIL would have egregiously worked. I'm sure the reasons to refuse it are more political than tecnical, so it's useless to go into further details I presume. Giovanni Bajo
Cirrus arm Maverick Crunch fixes
Hello everybody As you may already know the code that supports cirrus arm processors with maverick crunch floating point unit (-mfpu=maverick), which is included in gcc 4.x, is nearly complete but, as of now, broken. So I'm going to spend some time in fixing it, but I'm pretty new in gcc development. That's why I ask for the assistance of the arm developers, hoping they will help me. I would like to start with this bug report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24861 Could you give me some hints on where is the problem? Best regards, Dario
Re: Cirrus arm Maverick Crunch fixes
On Thu, 2005-11-17 at 10:23, Dario Massarin wrote: > I would like to start with this bug report: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24861 > > Could you give me some hints on where is the problem? It just happens that I fixed that last night :-) R.
Re: Cirrus arm Maverick Crunch fixes
> On Thu, 2005-11-17 at 10:23, Dario Massarin wrote: > > > I would like to start with this bug report: > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24861 > > > > Could you give me some hints on where is the problem? > > It just happens that I fixed that last night :-) Wow! Really? So fast? Thanks! Ok. Now I'm going to try your change. If maverick still needs some work, I'll point it out and try to fix it. Thanks again. Best regards, Dario
Re: Link-time optimzation
On Thu, 2005-11-17 at 01:27, Mark Mitchell wrote: > Richard Henderson wrote: > > In Requirement 4, you say that the function F from input files a.o and > > b.o should still be named F in the output file. Why is this requirement > > more than simply having the debug information reflect that both names > > were originally F? I see you go to some length in section 3 to ensure > > actual symbol table duplicates, and I don't know why. > > Our understanding was that the debugger actually uses the symbol table, > in addition to the debugging information, in some cases. (This must be > true when not running with -g, but I thought it was true in other cases > as well.) It might be true for other tools, too. > > It's true that, from a correctness or code-generation point of view, it > shouldn't matter, so, for non-GNU assemblers, we could fall back to > F.0/F.1, etc. We spend a lot of time printing out the results of compilation as assembly language, only to have to parse it all again in the assembler. Given some of the problems this proposal throws up I think we should seriously look at bypassing as much of this step as possible, and of generating object files from directly in the compiler. Ultimately we'd only need to parse assembly statements for inline asm constructs. R.
Is there a GIMPLE equivalent of UNSPEC?
Hello, I am working on a private GCC port. Currently I am trying to move it from 3.3.2 to 4.1.x. I have some strange constructs in the expansion of the va_arg macro. In 3.3.2 I used two "unspec" RTL constructs to solve that problem. Now va_arg has to be transformed to GIMPLE. So my question: is there some equivalent. I looked at the documentation and did not find any explicitly machine specific part. I think the notion of builtin function can be (ab)used to achieve what I need. I do not like that idea and I am looking for a cleaner solution. Thanks in Advance, Erwin Erwin Unruh, Fujitsu Siemens Computers, C/C++ compiler group
Re: Is there a GIMPLE equivalent of UNSPEC?
On Nov 17, 2005 01:11 PM, "Unruh, Erwin" <[EMAIL PROTECTED]> wrote: > is there some > equivalent. No, there isn't. You are not being very specific about the problem you are trying to solve. You'll have to tell more before anyone can give you a more helpful answer. Gr. Steven
Re: Is there a GIMPLE equivalent of UNSPEC?
On Thursday 17 November 2005 07:11, Unruh, Erwin wrote: > Now va_arg has to be transformed to GIMPLE. So my question: is there > some equivalent. > There isn't one. Have you looked at gimplify_va_arg_expr? What is it in your construct that cannot be expressed in trees? There are several targets that do specialized things in va_arg expansion. Maybe you could look at one similar to your target.
Re: apps built w/ -fstack-protector-all segfault
On Thu, 17 Nov 2005, Peter S. Mazinger wrote: > On Wed, 16 Nov 2005, Richard Henderson wrote: > > > On Wed, Nov 16, 2005 at 10:32:45PM +0100, Peter S. Mazinger wrote: > > > what happens w/ -fstack-protector-all -fstack-protector (in this order) ? > > > do we have (2) or (1) > > > > We have 1. > > > > > so now it does > > > -fstack-protector #define __SSP__ 1 ; #undef __SSP_ALL__ > > > -fstack-protector-all #define __SSP_ALL__ 2 ; #undef __SSP__ > > > > > > and the last wins. > > > > I don't know what you're looking at, but it isn't mainline. > > The defines are not controled this way. > > The defines are exactly like this (only undef is not done, because the > last wins) > > so -fstack-protector -fstack-protector-all will have only __SSP_ALL__ 2 > -fstack-protector-all -fstack-protector will have only __SSP__ 1 > > so in any case the last wins > > -fstack-protector-all (all protection) being superset of -fstack-protector > (random protection) it should also define __SSP__ 1 or maybe better, remove __SSP_ALL__ and define __SSP__ 2 for -all Peter -- Peter S. MazingerID: 0xA5F059F2 Key fingerprint = 92A4 31E1 56BC 3D5A 2D08 BB6E C389 975E A5F0 59F2
Re: Link-time optimzation
Ian Lance Taylor wrote: > In section 3.4 (Linker) I have the same comment: for non-GNU targets, > the native linker is sometimes required, so modifying the linker > should not be a requirement. And the exact handling of .a files is > surprisingly target dependent, so while it would be easy to code an > archive searcher in gcc, it would be tedious, though doable, to get it > right for all platforms. > > Conversely, I don't know much we are going to care about speed here, > but I assume that we are going to care a bit. For the linker to > determine which files to pull in from an archive, it is going to have > to read the symbol tables of all the input objects, and it is going to > have to read the archive symbol table, and it is going to have to read > the symbols table of each object included from an archive. It will > have to build a symbol hash table as it goes along. This isn't fast; > it's a significant component of link time. Since the compiler is also > going to have to build a symbol hash table, it is going to be faster > to have the compiler search the archive symbol table and decide which > objects to pull in. Searching an archive symbol table isn't hard; the > target dependencies come in when deciding which objects to include. I'm wondering whether we can't simply employ the linker to handle all those issues: Have the driver always (not just as fall-back) call "ld -r" and the linker will pull together all input files, including those from archives, and combine them into one single object file. Then invoke the new "link-optimizer" on that single object file, resulting in an optimized object file. Any reasons why this cannot work? Bye, Ulrich -- Dr. Ulrich Weigand Linux on zSeries Development [EMAIL PROTECTED]
RE: Is there a GIMPLE equivalent of UNSPEC?
OK, here are the details:
first, I have a PDImode pointer and do not want to have general arithmetic on
that. So I invented a special RTL instruction to align a pointer. Within the
va_arg sometimes I need to align the pointer. In 3.3.2 the code snippet in
EXPAND_BUILTIN_VA_ARG looked like
tree t = ... // address of next parameter
/* If the value is more aligned than a word, align the pointer. */
if (align > PARM_BOUNDARY)
{
rtx r;
r = expand_expr (t, addr_rtx, Pmode, EXPAND_NORMAL);
r = private_align_pmode (r, align / BITS_PER_UNIT);
t = make_tree (TREE_TYPE (ovf), r);
t = build (MODIFY_EXPR, TREE_TYPE (ovf), ovf, t);
TREE_SIDE_EFFECTS (t) = 1;
expand_expr (t, const0_rtx, VOIDmode, EXPAND_NORMAL);
t = save_expr (ovf);
}
Second, when passing a pointer (Pmode) via va_arg, I need a special instruction
to retrieve its value. In 3.3.2 I used
rtx addr_rtx = ... // address of parameter
rtx value_rtx = gen_reg_rtx (Pmode);
rtx r = gen_rtx_MEM (Pmode, addr_rtx);
set_mem_alias_set (r, get_varargs_alias_set ());
emit_insn (gen_private_va_arg_pdi (value_rtx, r));
addr_rtx = gen_reg_rtx (Pmode);
r = gen_rtx_ADDRESSOF (Pmode, value_rtx, REGNO (value_rtx), 0);
emit_move_insn (addr_rtx, r);
// addr_rtx can now be used as a normal pointer to a Pmode entity
In both cases using an RTL unspec was a convenient way to go. All optimizing
phases knew how to handle that.
If I do not find a simple way to represent those constructs in GIMPLE, I have
to think about other ways to handle the underlying problem.
Erwin
Erwin Unruh, Fujitsu Siemens Computers, C/C++ compiler group
-Original Message-
From: Steven Bosscher [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 17, 2005 1:22 PM
To: Unruh, Erwin
Cc: GCC mailing list
Subject: Re: Is there a GIMPLE equivalent of UNSPEC?
On Nov 17, 2005 01:11 PM, "Unruh, Erwin"
<[EMAIL PROTECTED]> wrote:
> is there some
> equivalent.
No, there isn't. You are not being very specific about the problem you are
trying to solve. You'll have to tell more before anyone can give you a more
helpful answer.
Gr.
Steven
Re: Link-time optimzation
On Wed, 2005-11-16 at 20:33 -0700, Jeffrey A Law wrote: > > Our understanding was that the debugger actually uses the symbol table, > > in addition to the debugging information, in some cases. (This must be > > true when not running with -g, but I thought it was true in other cases > > as well.) It might be true for other tools, too. > I can't offhand recall if GDB actually uses the minimal symbols (the > symbol table) for anything if there are debug symbols available. It does, but only after trying the debug symbols first. I discovered this when deep hacking into the symbol code of GDB a while ago. Apparently, some people enjoy breakpointing symbols by using the fully mangled name, which appears (nowadays) mainly in the minsym table. > But > even if we prove GDB doesn't use those symbols, we should still > keep them -- other tools, or even other debuggers (Etnus?) might still > use the symbols from the symbol table. > > Jeff >
m68k does not build on head
Doing an overnight build of all rtems targets, I can across this
new breakage for m68k-rtems4.7. I last built this target on Nov 3
from the head and it compiled then.
/home/joel/gcc-work/head/b-m68k-rtems4.7/./gcc/xgcc
-B/home/joel/gcc-work/head/b-m68k-rtems4.7/./gcc/ -nostdinc
-B/home/joel/gcc-work/head/b-m68k-rtems4.7/m68k-rtems4.7/newlib/
-isystem
/home/joel/gcc-work/head/b-m68k-rtems4.7/m68k-rtems4.7/newlib/targ-include
-isystem /home/joel/gcc-work/head/gcc-head-test/newlib/libc/include
-B/home/joel/gcc-41-test//m68k-rtems4.7/bin/
-B/home/joel/gcc-41-test//m68k-rtems4.7/lib/ -isystem
/home/joel/gcc-41-test//m68k-rtems4.7/include -isystem
/home/joel/gcc-41-test//m68k-rtems4.7/sys-include -c -DHAVE_CONFIG_H -O2
-g -O2 -I. -I../../../gcc-head-test/libiberty/../include -W -Wall
-pedantic -Wwrite-strings -Wstrict-prototypes
../../../gcc-head-test/libiberty/getopt1.c -o geto
pt1.o
../../../gcc-head-test/libiberty/regex.c: In function
'byte_common_op_match_null_string_p':
../../../gcc-head-test/libiberty/regex.c:7724: error: insn does not
satisfy its constraints:
(insn 158 85 159 8
../../../gcc-head-test/libiberty/regex.c:7699 (set (reg:SI 2 %d2)
(sign_extend:SI (reg:HI 1 %d1 [59]))) 65 {*68k_extendhisi2} (nil)
(nil))
../../../gcc-head-test/libiberty/regex.c:7724: internal
compiler error: in reload_cse_simplify_operands, at postreload.c:393
This is with gcc SVN head as of yesterday afternoon, binutils 2.16.1 and
newlib 1.13.0.
I can file a PR but this is definitely a recent breakage.
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
Re: Link-time optimzation
hi, Daniel Berlin wrote: I discovered this when deep hacking into the symbol code of GDB a while ago. Apparently, some people enjoy breakpointing symbols by using the fully mangled name, which appears (nowadays) mainly in the minsym table. This sort of hack is often used to work around what appears to be the inability of gdb to put breakpoints in c++ constructors (or maybe it is bad dwarf2 debugging output by gcc, I don't know). regards, Mathieu
Re: m68k does not build on head
> ../../../gcc-head-test/libiberty/regex.c: In function
> 'byte_common_op_match_null_string_p':
>
> ../../../gcc-head-test/libiberty/regex.c:7724: error: insn does not
> satisfy its constraints:
> (insn 158 85 159 8
> ../../../gcc-head-test/libiberty/regex.c:7699 (set (reg:SI 2 %d2)
>
>(sign_extend:SI (reg:HI 1 %d1 [59]))) 65 {*68k_extendhisi2} (nil)
>(nil))
> ../../../gcc-head-test/libiberty/regex.c:7724: internal
> compiler error: in reload_cse_simplify_operands, at postreload.c:393
I'm also seeing this on m68-elf.
It appears to have been caused by the following patch (r106804)
2005-11-12 Hans-Peter Nilsson <[EMAIL PROTECTED]>
PR middle-end/24750
* reload.c (find_reloads_address_1) : New cases.
Re: m68k does not build on head
> From: Paul Brook <[EMAIL PROTECTED]>
> Date: Thu, 17 Nov 2005 15:12:50 +
> > ../../../gcc-head-test/libiberty/regex.c:7699 (set (reg:SI 2 %d2)
> >
> >(sign_extend:SI (reg:HI 1 %d1 [59]))) 65 {*68k_extendhisi2} (nil)
> >(nil))
> > ../../../gcc-head-test/libiberty/regex.c:7724: internal
> > compiler error: in reload_cse_simplify_operands, at postreload.c:393
>
> I'm also seeing this on m68-elf.
>
> It appears to have been caused by the following patch (r106804)
Or perhaps the patch that tightened operand checks for "g".
Please open a PR with preprocessed source attached and assign it
to me.
brgds, H-P
Re: m68k does not build on head
On Thursday 17 November 2005 15:20, Hans-Peter Nilsson wrote:
> > From: Paul Brook <[EMAIL PROTECTED]>
> > Date: Thu, 17 Nov 2005 15:12:50 +
> >
> > > ../../../gcc-head-test/libiberty/regex.c:7699 (set (reg:SI 2 %d2)
> > >
> > >(sign_extend:SI (reg:HI 1 %d1 [59]))) 65 {*68k_extendhisi2}
> > > (nil) (nil))
> > > ../../../gcc-head-test/libiberty/regex.c:7724: internal
> > > compiler error: in reload_cse_simplify_operands, at postreload.c:393
> >
> > I'm also seeing this on m68-elf.
> >
> > It appears to have been caused by the following patch (r106804)
>
> Or perhaps the patch that tightened operand checks for "g".
Maybe. Reverting r106804 seems to fix the problem.
> Please open a PR with preprocessed source attached and assign it
> to me.
This is now PR24912
Paul
specific instantiation of static members from template class
hello, I have a problem when I try to instantiate static members. this code
works with gcc-3.4.5 but not with gcc-4.0.2 (debian sid).
here a test case with 3 files :
/ main.cpp
#include
#include "Test.h"
int main(int argc, char **argv)
{
std::cout << TestInt::member << std::endl;
return 0;
}
/ test.h
template
class Test
{
public:
static T member;
};
typedef Test TestInt;
/ test.cpp
#include "Test.h"
template class Test;
template<> int Test::member;
I got an error at link because it cannot find the symbol Test::member
used in "main.o"
If I use only one file, it works.
If I give an initial value to Test::member in test.cpp, it works.
It works with gcc-3.4.5.
I did some research and see that it could works even without the member
declaration, the class instantiation should be enough here :
http://gcc.gnu.org/ml/gcc/2004-05/msg01393.html
Is this a bug or a behavour change from gcc ?
Re: [rfc] new tree-codes/optabs for vectorization of non-unit-stride accesses
Steven Bosscher <[EMAIL PROTECTED]> wrote on 11/16/2005 10:39:24 PM: > On Wednesday 16 November 2005 15:35, Dorit Naishlos wrote: > > We'd like to suggest a few new tree-codes/optabs in order to express the > > extraction and merging of elements from/to vectors. > > Watch out for tree code starvation: > > $ ~/devel/gomp-branch/gcc> grep ^DEFTREECODE *.def | wc > 181 908 12483 > $ ~/devel/gomp-branch/gcc> cd cp > $ ~/devel/gomp-branch/gcc/cp> grep ^DEFTREECODE *.def | wc > 58 2884262 > $ ~/devel/gomp-branch/gcc/cp> > > So for C++ on the GOMP-branch, we currently have 239 tree codes. > There can be at nost 256 tree codes, because tree_common.code only > can hold that many... > only thing I can suggest in the context of the vectorizer is to use an extra argument to save a few tree-codes: i.e. instead of: VEC_EXTRACT_EVEN(v1,v2), VEC_EXTRACT_ODD(v1,v2) VEC_INTERLEAVE_HIGH(v1,v2), VEC_INTERLEAVE_LOW(v1,v2) have: VEC_EXTRACT(even_odd_bool,v1,v2) VEC_INTERLEAVE(high_low_bool,v1,v2) if that's preferable (I don't like it so much...). dorit > Gr. > Steven >
Re: [rfc] new tree-codes/optabs for vectorization of non-unit-stride accesses
Paul Brook <[EMAIL PROTECTED]> wrote on 11/16/2005 05:03:47 PM:
> On Wednesday 16 November 2005 14:35, Dorit Naishlos wrote:
> > We're going to commit to autovect-branch vectorization support for
> > non-unit-stride accesses.
> > We'd like to suggest a few new tree-codes/optabs in order to express
the
> > extraction and merging of elements from/to vectors.
>
> > Background:
> > The new functionality is going to allow us to vectorize
computations
> > with strides that are a power-of-2, like in the example below, in which
the
> > real and imaginary parts are interleaved, and therefore each of the
> > data-refs accesses data with stride 2:
> >
> > for (i = 0; i < n; i++) {
> > tmp_re = in[2*i] * coefs[2*i] - in[2*i+1] * coefs[2*i+1];
> > tmp_im = in[2*i] * coefs[2*i+1] + in[2*i+1] * coefs[2*i];
> > out[2*i] = tmp_re;
> > out[2*i+1] = temp_im;
> > }
> >
> > What is generally going to happen is that, for a VF=4, we're going to:
> >
> > (1) load this data from memory:
> > vec_in1 = [re0,im0,re1,im1] = vload &in
> > vec_in2 = [re2,im2,re3,im3] = vload &in[VF]
> > (and similarly for the coefs array)
> >
> > and then, because we're doing different operations on the odd and even
> > elements, we need to
> > (2) arrange them into separate vectors:
> > vec_in_re = [re0,re1,re2,re3] = extract_even (vec_in1, vec_in2)
> > vec_in_im = [im0,im1,im2,im3] = extract_odd (vec_in1, vec_in2)
> > (and similarly for the coefs array)
>
> Have you considered targets that support interleaved load/store
instructions?
> I'm not sure if this is supported by existing targets, but in the next
year
> there will be targets that can perform steps 1+2 in a single
load-interleaved
> instruction.
>
I don't know of existing targets that have this capability - it usually
requires explicit reordering.
Anyhow, when such a time comes, we can consider either adding a new
tree-code for that (but sounds like we're running short of tree-codes...)
or detect later on (combine?) that a {load,load,extract_even,extract_odd}
sequence can be replaced by an "interleaved_load". (I assume this
specialized load exists only for stride 2?)
thanks,
dorit
> Paul
Re: Link-time optimzation
On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote: > > http://gcc.gnu.org/projects/lto/lto.pdf > > Section 4.2 > > What is the rationale for using a stack-based representation rather > than a register-based representation? A infinite register based > solution would seem to map better onto gimple, making it easier to > understand the conversion into and out of. The required stacking > and unstacking operations would seem to get in the way. > > C.f. plan9's inferno, rather than jvm or cil. What we wanted was something that was portable and easy to specify but also easily exported from and imported into GCC. With respect to those constraints, JVM, CIL and LLVM do not make the cut because they are different enough from the tree-gimple code that we have to make the translation into and/or out of gcc difficult. This is not NIH, just being pragmatic about not wanting to have to commit resources into things that are not important. A stack machine representation was chosen for the same reason. Tree gimple is a series of statements each statement being a tree. Smashing the trees and introducing temps is easy on the output side but requires a lot of work on the input side. I am not a fan of our tree representations, but I did not believe that changing them should be a necessary to get to link time optimization. If we decide we want to get rid if trees as an intermediate form, this decision should change. A well designed stack machine also provides for a very tight encoding. It is very desirable from a size of portable code point of view to minimize the number of temps that you create. You can do this in several ways: 1) Do some register allocation of the temps so that they are reused. This is non trivial to undo (but truely doable), especially where you wish to not adversely impact debugging. 2) Just generate a lot of temps and hope that some other form of compression will save the day. 3) Use a stack to represent the intermediate nodes of the tree. This is what we chose to do. It is trivial to generate the stack code from a single walk of the tree. It is trivial to regenerate the tree from a single pass over the stack code. The stack machine that we have in mind will be as stripped down as possible. The idea is just to get the trees in and get them back out. Kenny
Re: [rfc] new tree-codes/optabs for vectorization of non-unit-stride accesses
On Thursday 17 November 2005 16:51, Dorit Naishlos wrote: > only thing I can suggest in the context of the vectorizer is to use an > extra argument to save a few tree-codes: I don't think that this is a good idea. If we are going to need more tree codes, we're just going to have to figure out a way to make it possible to have more tree codes, e.g. by cleaning up 8 of the 24 bits reserved for various flags, and make the field for the tree code 16 bits. Gr. Steven
Re: Link-time optimzation
Mark Mitchell <[EMAIL PROTECTED]> writes: > http://gcc.gnu.org/projects/lto/lto.pdf > > Section 4.2 (Executable Representation) describes the GVM as a stack > machine, and mentions load, store, duplicate, and swap operations. > But it also discusses having registers which correspond to GIMPLE > local variables. The way I put this together is that a MODIFY_EXPR > which sets a local variable, say, will be converted to something that > computes the expression using a stack and then assigns the value to a > register. It's easy to see how to convert such a MODIFY_EXPR into a > stack machine and back. But it's not easy to see why that stack > machine is going to need, e.g, a swap operation. There is no GIMPLE > swap operator. So I may still be confused about something. You are most likely correct. We either do not need a swap or do not want to encourage people to try to optimize the trees so much that they need a swap. > > Ian
Re: Link-time optimzation
> >> Thanks for woking on this. Any specific reason why using the LLVM > >> bytecode wasn't taken into account? > > > > It was. > > A large number of alternatives were explored, including CIL, the JVM, > > LLVM, etc. > > > >> It is proven to be stable, high-level enough to > >> perform any kind of needed optimization, > > > > This is not true, unfortunately. > > That's why it is called "low level virtual machine". > > It doesn't have things we'd like to do high level optimizations on, > > like dynamic_cast removal, etc. > > > Anyway, *slightly* extending an existing VM which already exists, is > production-ready, is GPL compatible, is supported by a full toolchain > (including interpreters, disassemblers, jitters, loaders, optimizers...) looks > like a much better deal. Also, I'm sure Chris would be willing to provide us > with all the needed help. > > I also think CIL would have egregiously worked. I'm sure the reasons to refuse > it are more political than tecnical, so it's useless to go into further > details > I presume. I do not think that CIL really would have worked. CIL has been carefully crafted to support what Microsoft wants it to support and unrestricted C, C++, and Fortran are not in that mix. Remember that Microsoft wants to be able to take a CIL program produced on one (?Microsoft?) platform and run it on another (?Microsoft?) platform. By the time we get to where we want to produce the iterchangable code, the il has a lot of platform knowledge (for instance generated by the C preprocessor) that cannot be easily accounted for. > > Giovanni Bajo
Re: Link-time optimzation
> On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote: > > > http://gcc.gnu.org/projects/lto/lto.pdf > > > > Section 4.2 > > > > What is the rationale for using a stack-based representation rather > > than a register-based representation? A infinite register based > > solution would seem to map better onto gimple, making it easier to > > understand the conversion into and out of. The required stacking > > and unstacking operations would seem to get in the way. > > > > C.f. plan9's inferno, rather than jvm or cil. > > A stack machine representation was chosen for the same reason. Tree > gimple is a series of statements each statement being a tree. > Smashing the trees and introducing temps is easy on the output side > but requires a lot of work on the input side. I am not a fan of our > tree representations, but I did not believe that changing them should > be a necessary to get to link time optimization. If we decide we want > to get rid if trees as an intermediate form, this decision should > change. Actually I also tend to think that using stack based IL would be mistake here. Gimple is represented as tree in low level, but basically it is flat IL with registers, so having the representation close to such language would actually make translation more direct, I would expect. I think we can gradually move away from the nested tree representation of gimple and thus it would be better to not push it deeper into our design decisions. > > A well designed stack machine also provides for a very tight encoding. > It is very desirable from a size of portable code point of view to > minimize the number of temps that you create. You can do this in > several ways: > > 1) Do some register allocation of the temps so that they are reused. >This is non trivial to undo (but truely doable), especially where >you wish to not adversely impact debugging. > > 2) Just generate a lot of temps and hope that some other form of >compression will save the day. > > 3) Use a stack to represent the intermediate nodes of the tree. This >is what we chose to do. > > It is trivial to generate the stack code from a single walk of the > tree. It is trivial to regenerate the tree from a single pass over > the stack code. > > The stack machine that we have in mind will be as stripped down as > possible. The idea is just to get the trees in and get them back out. I have a feeling that going in/out of stack representation will cause some extra garbage to be produced (pretty much like we do with reg-stack that solve sort of similar problem), making it bit more challenging to optimize code at compilation time and save work by not re-doing it all at link time. It seems important to me that saving/restoring pair don't actually introduce any non-trivial suboptimalities. I would probably preffer if it was possible to save IL in SSA form unless this is really seen as overkill file size wise. Compactness is important here, but since we are going to expand everything into temporary form in memory anyway we are not going to win that much I would say. My preferences here (at this very moment) would be to hope for 2) to save day ;)) I am on the vacation now, so I won't comment much before I have chance to look closer into the proposal at monday, so these are just my 2 cents... But thanks for all the work, Honza
Register Allocation
It must be the season for this sort of thing :-) I have been contemplating building a GCC register allocator from scratch for some time. To that end, I have put together a bit of a document given a high level overview of the various components I think would benefit GCC, and a rough description of how they would work together. It is my intention over the next few months to do some of the initial underlying infrastructure bits upon which the entire document is based. Presuming that proceeds OK and I can build up the data structures I am looking for, I'll move on from there. If anyone wants to help, I'm sure there will be some juicy things to do. Anyone who wishes to provide constructive comments about what is in the write up, feel free to send them to me. I also know there are other projects ongoing which could be related to this work in some fashion. Anyone reading this document who is involved with those projects and sees something useful here or in those projects that could be combined in some way is encouraged to let me know their thoughts and ideas as well. The document is intended as a starting point and consists mostly of my thoughts at the moment. By the time the underlying RTL bits are done, I would like it to have evolved to include input from others. The more useful comments there are, the better the chance of us getting a decent allocator. The .pdf file is currently available at: http://people.redhat.com/dnovillo/rable.pdf (Thanks dnovillo :-) Andrew
Re: Cirrus arm Maverick Crunch fixes
Ok. I've just checked the gcc-4_0-branch but trying to compile with --with-cpu=ep9312 and --with-fpu=maverick still fails (but this is a different problem). I've reported this bug here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24914
Re: apps built w/ -fstack-protector-all segfault
On Thu, Nov 17, 2005 at 08:17:07AM +0100, Peter S. Mazinger wrote: > -fstack-protector-all (all protection) being superset of -fstack-protector > (random protection) it should also define __SSP__ 1 The IBM patch that I followed did exactly what I implemented. I see no compelling reason to change it. r~
Re: Is there a GIMPLE equivalent of UNSPEC?
On Thu, Nov 17, 2005 at 01:11:08PM +0100, Unruh, Erwin wrote: > So my question: is there some equivalent. A builtin function. r~
Re: specific instantiation of static members from template class
cedric wrote:
>
> hello, I have a problem when I try to instantiate static members. this code
> works with gcc-3.4.5 but not with gcc-4.0.2 (debian sid).
> here a test case with 3 files :
>
>
> / main.cpp
> #include
> #include "Test.h"
>
> int main(int argc, char **argv)
> {
> std::cout << TestInt::member << std::endl;
> return 0;
> }
>
> / test.h
> template
> class Test
> {
> public:
>
> static T member;
> };
add this line here:
template T Test::member;
> typedef Test TestInt;
>
> / test.cpp
> #include "Test.h"
>
> template class Test;
Either remove this line or place it before the explicit instantiation:
> template<> int Test::member;
I think GCC is right here.
jon
--
"God is as real as I am," the old man said. My faith was restored, for
I knew that Santa would never lie.
[RFC] PR/24900: computed but not used cast values
Hi folks.
In this PR we are emitting a "value computed is not used" warning for the
following code (via some fancy macro expansion in the Linux kernel):
unsigned long t(void);
void apic_write_atomic(unsigned long reg, unsigned int v)
{
((__typeof__(*((volatile unsigned int *)((t())+regt());
}
this reduces to:
int f(void);
void g(void)
{ (unsigned) f(); }
Which was made to deliberately warn by Joseph's patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00275.html
I closed the bug as a WONTFIX, but Ian suggested I bring this up on the
list, as he believes the choice to warn on this, isn't a good one.
Joseph, Ian?
Successfull build of gcc-4.0.2 on MacOS-X 10.3.9
Hi all, on PowerPC G4 with MacOS-X 10.3.9 (powerpc-apple-darwin7.9.0 ) build from : Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20040913 (GNAT for Mac OS X build 1650) with Apple's cctools 525 New 4.0.2 gcc -v output : Using built-in specs. Target: powerpc-apple-darwin7.9.0 Configured with: ../gcc-4.0.2/configure --prefix=/users/William/develop/gcc/install --enable-languages=c,ada --disable-nls --enable-threads=posix --disable-multilib Thread model: posix gcc version 4.0.2 GNAT ACATS === acats Summary === # of expected passes2317 # of unexpected failures3 *** FAILURES: c250002 cc3125c cxaca01 William
Re: Link-time optimzation
Richard Earnshaw <[EMAIL PROTECTED]> writes: > We spend a lot of time printing out the results of compilation as > assembly language, only to have to parse it all again in the assembler. > Given some of the problems this proposal throws up I think we should > seriously look at bypassing as much of this step as possible, and of > generating object files from directly in the compiler. Ultimately we'd > only need to parse assembly statements for inline asm constructs. I certainly think that is a good idea, and it is one which has been discussed before. But I think this is really a separate issue which should not be confused with the link time optimization proposal. I think the symbol table issues are a red herring. The only troublesome case is when using both a non-GNU assembler and a non-GNU debugger, and even then the worst case is some difficulty with naming static functions and variables (we can rename them using a suitable mangled source file name as a suffix so that it is still possible to find them, albeit awkward). I think that if we lay down an appropriate trail, other tool developers will follow soon enough. Ian
Re: Link-time optimzation
Ulrich Weigand <[EMAIL PROTECTED]> writes: > > Conversely, I don't know much we are going to care about speed here, > > but I assume that we are going to care a bit. For the linker to > > determine which files to pull in from an archive, it is going to have > > to read the symbol tables of all the input objects, and it is going to > > have to read the archive symbol table, and it is going to have to read > > the symbols table of each object included from an archive. It will > > have to build a symbol hash table as it goes along. This isn't fast; > > it's a significant component of link time. Since the compiler is also > > going to have to build a symbol hash table, it is going to be faster > > to have the compiler search the archive symbol table and decide which > > objects to pull in. Searching an archive symbol table isn't hard; the > > target dependencies come in when deciding which objects to include. > > I'm wondering whether we can't simply employ the linker to handle > all those issues: Have the driver always (not just as fall-back) > call "ld -r" and the linker will pull together all input files, > including those from archives, and combine them into one single > object file. Then invoke the new "link-optimizer" on that single > object file, resulting in an optimized object file. > > Any reasons why this cannot work? Well, it means having the linker do a fair amount of work and then throwing it all away. And there might be some effort involved in teasing out the debug information again, although I'm sure that could be handled. I tend to think the extra disk I/O and computation would make this idea a non-starter, but I could certainly be wrong. It does seem like a viable fallback position. Ian
Re: [RFC] PR/24900: computed but not used cast values
Aldy Hernandez <[EMAIL PROTECTED]> writes:
> this reduces to:
>
> int f(void);
> void g(void)
> { (unsigned) f(); }
>
> Which was made to deliberately warn by Joseph's patch here:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00275.html
>
> I closed the bug as a WONTFIX, but Ian suggested I bring this up on the
> list, as he believes the choice to warn on this, isn't a good one.
Basically, I don't think it helps anybody to issue a "value computed
is not used" warning for:
(unsigned) f();
We traditionally do not warn about not using the value returned by a
function. And I don't see why adding a cast should change that.
Intuitively, a cast by itself is not a computation.
Ian
pruning unused debugging types (enums/PR23336)
On a similar note than PR debug/21391...
In PR23336 we have the same thing happen with enums:
enum something { JTI_PROMOTED_BYTE_TYPE_NODE, etc };
use JTI_PROMOTED_BYTE_TYPE_NODE
JTI_PROMOTED_BYTE_TYPE_NODE and "something" get pruned even though we
use it. I see two alternatives:
1. Don't prune enumeration types.
2. Similar solution to PR21391: mark all enum types we use as
un-prunable in the front-end.
Thoughts?
Aldy
p.s. PING: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01227.html
Re: Ada Broken with h_errno change
* Joel Sherrill <[EMAIL PROTECTED]>, 2005-11-16 : > RTEMS has networking functions but they are not available at this stage > during the build. I am not sure I understand how this can happen (I am not familiar at all with the RTEMS build process). If the network functions are available on RTEMS, isn't it the case that corresponding header files should be present as well? If so why aren't they available when you build the Ada runtime library? If not how are these functions made available to applications? > this patch is needed to make *-rtems compile again. OK to commit? I'd first like to understand what exactly the situation is. -- Thomas Quinot, Ph.D. ** [EMAIL PROTECTED] ** Senior Software Engineer AdaCore -- Paris, France -- New York, USA
Re: Ada Broken with h_errno change
Thomas Quinot wrote: * Joel Sherrill <[EMAIL PROTECTED]>, 2005-11-16 : RTEMS has networking functions but they are not available at this stage during the build. I am not sure I understand how this can happen (I am not familiar at all with the RTEMS build process). If the network functions are available on RTEMS, isn't it the case that corresponding header files should be present as well? If so why aren't they available when you build the Ada runtime library? If not how are these functions made available to applications? You build RTEMS proper after you build the toolset with which you will build it. So when you gcc, you only have access to .h files which are properly associated with libc or libm. Those are provided by newlib. Headers files for networking, most tasking, and other functionality is only available later when you build the OS. To look at it another way, RTEMS doesn't use prebuilt binaries for the run-time libraries when building the tools. We start with a fresh slate every time we build gcc and bootstrap our way up. That way every object on the target is compiled by the same gcc. This lets us get the full benefit of a newer and better gcc every time we update. this patch is needed to make *-rtems compile again. OK to commit? I'd first like to understand what exactly the situation is. I hope the explanation above helps make it clearer. FWIW the extern might be better stylistically outside the function. The function already has more than enough conditional compilation going on. --joel
gcc-4.0-20051117 is now available
Snapshot gcc-4.0-20051117 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20051117/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 107140 You'll find: gcc-4.0-20051117.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20051117.tar.bz2 C front end and core compiler gcc-ada-4.0-20051117.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20051117.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20051117.tar.bz2 C++ front end and runtime gcc-java-4.0-20051117.tar.bz2 Java front end and runtime gcc-objc-4.0-20051117.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20051117.tar.bz2The GCC testsuite Diffs from 4.0-20051110 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.
Re: [RFC] PR/24900: computed but not used cast values
On Thu, Nov 17, 2005 at 02:01:56PM -0800, Ian Lance Taylor wrote: > We traditionally do not warn about not using the value returned by a > function. And I don't see why adding a cast should change that. > Intuitively, a cast by itself is not a computation. In many cases is certainly is -- it's a value transformation; zero extension, floating-point conversion, etc. My opinion is: why is the user asking for a value to be transformed if they're not going to use the result? r~
Re: [RFC] PR/24900: computed but not used cast values
On Thu, Nov 17, 2005 at 02:54:48PM -0800, Richard Henderson wrote: > On Thu, Nov 17, 2005 at 02:01:56PM -0800, Ian Lance Taylor wrote: > > We traditionally do not warn about not using the value returned by a > > function. And I don't see why adding a cast should change that. > > Intuitively, a cast by itself is not a computation. > > In many cases is certainly is -- it's a value transformation; > zero extension, floating-point conversion, etc. > > My opinion is: why is the user asking for a value to be > transformed if they're not going to use the result? As in the example, these cases will usually arise in macros, where under some circumstances some computation will be wasted.
question about gcc
Is there some reason gcc hasn't been or can't be enhanced to provide output for a cross-referencing programs? Paul Albrecht
Re: pruning unused debugging types (enums/PR23336)
On Thu, Nov 17, 2005 at 06:08:35PM -0400, Aldy Hernandez wrote:
> On a similar note than PR debug/21391...
>
> In PR23336 we have the same thing happen with enums:
>
> enum something { JTI_PROMOTED_BYTE_TYPE_NODE, etc };
>
> use JTI_PROMOTED_BYTE_TYPE_NODE
>
> JTI_PROMOTED_BYTE_TYPE_NODE and "something" get pruned even though we
> use it. I see two alternatives:
>
> 1. Don't prune enumeration types.
> 2. Similar solution to PR21391: mark all enum types we use as
> un-prunable in the front-end.
>
> Thoughts?
>
> Aldy
>
> p.s. PING: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01227.html
I'm not altogether fond of either of these. The problem, as I
see it, is that we don't actually know if either the case type
or the enum type is used in any of the code that actually makes
it into the object file.
If we're going to devolve into marking everything that's ever
used once, we might as well rely on the TREE_USED bit on the type;
in the end it isn't going to make a difference, seeing as how we
will tend to pull in all of the types anyway. Which would seem to
defeat the purpose of eliminating unused types in the first place.
If we're going to keep elimination of unused types, we're going to
have to come up with something new to associate used types with
the code that uses them. So that if the code is eliminated, the
used type will be as well.
If we set the granularity of this elimination to be the function,
we could add something to the function's debug data that could be
seen by the debug generator, and thus wouldn't be seen if the
entire function is eliminated.
A solution that comes to mind is to have the front-end add dummy
TYPE_DECL nodes to the BLOCK_VARS list of the function's outer-most
BLOCK. If the TYPE_DECL node were marked DECL_ARTIFICIAL and had
no DECL_NAME, it'd be easy for us to notice that we shouldn't
actually emit debug info for the TYPE_DECL itself, but that we
should consider its TREE_TYPE to be used.
I'm open to better schemes. Perhaps a used-type hash table in
the struct function.
r~
Re: Link-time optimzation
Ian Lance Taylor wrote: We spend a lot of time printing out the results of compilation as assembly language, only to have to parse it all again in the assembler. I never like arguments which have loaded words like "lot" without quantification. Just how long *is* spent in this step, is it really significant?
Re: [RFC] PR/24900: computed but not used cast values
Richard Henderson <[EMAIL PROTECTED]> writes:
> On Thu, Nov 17, 2005 at 02:01:56PM -0800, Ian Lance Taylor wrote:
> > We traditionally do not warn about not using the value returned by a
> > function. And I don't see why adding a cast should change that.
> > Intuitively, a cast by itself is not a computation.
>
> In many cases is certainly is -- it's a value transformation;
> zero extension, floating-point conversion, etc.
Granted, although in this case the result is being thrown away
anyhow.
> My opinion is: why is the user asking for a value to be
> transformed if they're not going to use the result?
It's PR 24900.
>From linux/include/asm-i386/apic.h:
static __inline void apic_write_atomic(unsigned long reg, unsigned long v)
{
xchg((volatile unsigned long *)(APIC_BASE+reg), v);
}
>From system.h:
#define xchg(ptr,v) ((__typeof__(*(ptr)))__xchg((unsigned
long)(v),(ptr),sizeof(*(ptr
So the cast is there becaue __xchg returns a value, and the code wants
to get that value into the right type. And presumably in some cases
the caller uses the value (or maybe not, I don't know). But in this
particular case, the code does not use the value.
To me it seems that every step is reasonable: function returns value,
macro casts value to appropriate type, caller discards value. What is
unreasonable is getting a -Wunused warning in this case. I don't
think you should get a warning for not using the return value of a
function, at least not under -Wunused.
Ian
Re: [RFC] PR/24900: computed but not used cast values
On Thu, Nov 17, 2005 at 03:00:42PM -0800, Joe Buck wrote: > As in the example, these cases will usually arise in macros, where under > some circumstances some computation will be wasted. Which is no different from f()+1, for which no one is arguing that the warning we give is incorrect. If you've got such cases, you simply should be asking for this warning, IMO. r~
Re: question about gcc
Paul Albrecht wrote: Is there some reason gcc hasn't been or can't be enhanced to provide output for a cross-referencing programs? Paul Albrecht No reason why it can't be, and the reason it hasn't is that no one has done it. Actually strictly you don't mean gcc here, you are referring to particular front ends, since the notion of referencing is somewhat language dependent. So probably you are thinking of C and/or C++. Note that GNAT, the Ada front end, does indeed output full information for xref purposes, in the form of ali files (it would indeed be nice if the C++ compiler would generate something similar!)
Re: [RFC] PR/24900: computed but not used cast values
On Thu, Nov 17, 2005 at 03:18:00PM -0800, Ian Lance Taylor wrote: > I don't think you should get a warning for not using the return value of a > function, at least not under -Wunused. For this, I agree. Except that we're not talking about the return value of the function directly, we're talking about the return value of a cast. Given that one can always cast any value to void to suppress this warning, I'm unconcerned about getting every single edge case "correct". Especially for edge cases for which one can reasonably disagree as to what is correct. A stronger case for changing this would be that gcc version n-1 didn't warn. As discussed elsewhere, some modicum of stability in warnings is desirable from the user's perspective. I don't know whether or not this applies in this case. r~
Re: Link-time optimzation
Robert Dewar <[EMAIL PROTECTED]> writes: > Ian Lance Taylor wrote: > > >>We spend a lot of time printing out the results of compilation as > >> assembly language, only to have to parse it all again in the > >> assembler. > > I never like arguments which have loaded words like "lot" without > quantification. Just how long *is* spent in this step, is it really > significant? [ It wasn't me that said the above, it was Richard Earnshaw. ] I haven't measured it for a long time, and I never measured it properly. And I don't know how significant it has to be to care about. I would expect that it is on the order of 1% of the time of a typical unoptimized compile+assembly, but I can't prove it today. A proper measurement is the amount of time spent formatting the output in the compiler, the amount of time spent making system calls to write out the output, the amount of time the assembler spends making system calls reading the input, and the amount of time the assembler spends preprocessing the assembler file, interpreting the strings, looking up instructions in hash tables, and parsing the operands. Profiling will show that the assembler stuff is a significant chunk of time taken by the assembler, so the questions are: how much time does gcc spend formatting and how much time do the system calls take? I just tried a simple unoptimized compile. -ftime-report said that final took 5% of the time (obviously final does more than formatting), and the assembler took 4% of the total user time, and system time took 16% of wall clock time. Cutting those numbers in half makes 1% seem not implausible to me, maybe even low. I'm considering an unoptimized compile because that is where the assembler makes the most difference--the compiler is faster and the assembler output probably tends to be longer, and also an unoptimized compile is when people care most about speed. For an optimizing compile, the assembler is obviously going to be less of a factor. Ian
Build failed gcc-4.1.0-20051112 on MacOS-X 10.3.9
Hi all, on PowerPC G4 with MacOS-X 10.3.9 (powerpc-apple-darwin7.9.0 ) build from : Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20040913 (GNAT for Mac OS X build 1650) with gcc cctools 576 same test with gcc cctools 590.12 $ ../gcc-20051112/configure --prefix=/users/william/develop/gcc/ppc_darwin/4.1-20051112/install --program-suffix=-4.1 --enable-languages=c,ada,c++ --enable-libada --disable-nls --enable-threads=posix --disable-multilib $ make bootstrap $ make Make failed on : (...) stage1/xgcc -Bstage1/ -B/users/william/develop/gcc/ppc_darwin/4.1-20051112/install/powerpc- apple-darwin7.9.0/bin/ -c -g -O2 -mdynamic-no-pic -gnatpg -gnata -g -O1 -fno-inline \ -I- -I. -Iada -I/users/william/develop/gcc/gcc-4.1-20051112/gcc/ada /users/william/develop/gcc/gcc-4.1-20051112/gcc/ada/a-except.adb -o ada/a-except.o +===GNAT BUG DETECTED==+ | 4.1.0 20051112 (experimental) (powerpc-apple-darwin7.9.0) GCC error: | | tree check: expected class expression, have exceptional | |(constructor) in get_base_var, at ipa-utils.c:224 | | Error detected at a-except.adb:1387:1 | (...) If this can help... William
Re: [rfc] new tree-codes/optabs for vectorization of non-unit-stride accesses
On Thursday 17 November 2005 16:55, Steven Bosscher wrote: > On Thursday 17 November 2005 16:51, Dorit Naishlos wrote: > > only thing I can suggest in the context of the vectorizer is to use an > > extra argument to save a few tree-codes: > > I don't think that this is a good idea. If we are going to need > more tree codes, we're just going to have to figure out a way to > make it possible to have more tree codes, e.g. by cleaning up 8 > of the 24 bits reserved for various flags, and make the field for > the tree code 16 bits. BTW the gomp-branch adds 22 (!) new tree codes, just like that, for all languages. This is IMHO very unfair to other projects in need of extra tree codes. Gr. Steven
Re: question about gcc
From: "Robert Dewar" <[EMAIL PROTECTED]> > Paul Albrecht wrote: > > Is there some reason gcc hasn't been or can't be enhanced to provide output > > for a > > cross-referencing programs? > > > > No reason why it can't be, and the reason it hasn't is that no one has done > it. Actually strictly you don't mean gcc > here, you are referring to particular front ends, since the notion of > referencing is somewhat language dependent. > So probably you are thinking of C and/or C++. Note that GNAT, the Ada front > end, does indeed output full > information for xref purposes, in the form of alibfiles (it would indeed be > nice if the C++ compiler > would generate something similar!) > > I took a swipe at the c front end and have cross-referenced linux and gcc using my hacked gcc. I'd like to get some feedback from the gcc community. You can check out my results at my web site www.pjalbrecht.com. Paul Albrecht
Re: question about gcc
Paul Albrecht wrote: Is there some reason gcc hasn't been or can't be enhanced to provide output for a cross-referencing programs? FYI, there are a number of tools available for producing cross-referencing info. See for instance http://www.gnu.org/software/global/links.html and try looking at the up-link to global itself also. I found this by searching on the GNU web site. I've never used global myself. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: [RFC] PR/24900: computed but not used cast values
> A stronger case for changing this would be that gcc version > n-1 didn't warn. As discussed elsewhere, some modicum of > stability in warnings is desirable from the user's perspective. > I don't know whether or not this applies in this case. Well, as I mentioned in the PR, macro writers can wrap the whole thing in a statement expression and avoid the warning. Can't we suggest this and keep (almost) everybody happy?
Re: question about gcc
From: "Jim Wilson" <[EMAIL PROTECTED]> > Paul Albrecht wrote: > > Is there some reason gcc hasn't been or can't be enhanced to provide output > > for > > cross-referencing programs? > > FYI, there are a number of tools available for producing > cross-referencing info. See for instance > http://www.gnu.org/software/global/links.html > and try looking at the up-link to global itself also. I found this by > searching on the GNU web site. I've never used global myself. > I'm not really so much interested in particular cross-referencing programs as I am interested in whether the gcc community has considered providing compiler output to cross-referencing programs via a front end option. Paul Albrecht
Re: [RFC] PR/24900: computed but not used cast values
On Thu, Nov 17, 2005 at 08:42:19PM -0400, Aldy Hernandez wrote: > Well, as I mentioned in the PR, macro writers can wrap the whole thing > in a statement expression and avoid the warning. Can't we suggest this > and keep (almost) everybody happy? I think so. r~
Re: [rfc] new tree-codes/optabs for vectorization of non-unit-stride accesses
On Fri, Nov 18, 2005 at 01:19:14AM +0100, Steven Bosscher wrote: > BTW the gomp-branch adds 22 (!) new tree codes, just like that, > for all languages. This is IMHO very unfair to other projects > in need of extra tree codes. Yeah, well, I don't see any way around it. We'll have to solve the bit field size problem sooner or later. r~
Re: can DECL_RESULT be 0?
Rafael Ávila de Espíndola wrote: Thank you very much for showing that the problem was in the comment. I've checked in a patch to fix the comment typo. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Undelivered Mail Returned to Sender
Gabriel Dos Reis wrote: This is the fifth or so message from me, within the last few days, that gets rejected. What is up? Hmm, I don't see this in the overseers archive. I don't think it reached them. Maybe it triggered the spam filter for having too many capital letters in the subject line. Anyways, the overseers aren't sure what the problem is, but they are testing a newer version of the mailer software in the hope that it will fix the problem. You aren't the only person seeing this problem. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Link-time optimzation
On Thu, Nov 17, 2005 at 03:42:29PM -0800, Ian Lance Taylor wrote: > I just tried a simple unoptimized compile. -ftime-report said that > final took 5% of the time (obviously final does more than formatting), > and the assembler took 4% of the total user time, and system time took > 16% of wall clock time. Cutting those numbers in half makes 1% seem > not implausible to me, maybe even low. > > I'm considering an unoptimized compile because that is where the > assembler makes the most difference--the compiler is faster and the > assembler output probably tends to be longer, and also an unoptimized > compile is when people care most about speed. For an optimizing > compile, the assembler is obviously going to be less of a factor. Also, please keep in mind that generating and then assembling debug info takes a huge amount of I/O relative to code size. I'd expect much more than 1% saving the write-out and write-in on -g. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Link-time optimzation
On Nov 17, 2005, at 3:09 PM, Robert Dewar wrote: Richard Earnshaw wrote: We spend a lot of time printing out the results of compilation as assembly language, only to have to parse it all again in the assembler. I never like arguments which have loaded words like "lot" without quantification. Just how long *is* spent in this step, is it really significant? When I arrived at Apple around 5 years ago, I was told of some recent measurements that showed the assembler took around 5% of the time. Don't know if that's still accurate. Of course the speed of the assembler is also relevant, and our stubs and lazy pointers probably mean Apple's .s files are bigger than other people's.
Re: Undelivered Mail Returned to Sender
Jim Wilson wrote: Gabriel Dos Reis wrote: This is the fifth or so message from me, within the last few days, that gets rejected. What is up? Hmm, I don't see this in the overseers archive. Because it is sourceware.org not sourceware.com. I should have noticed that before I made the same mistake. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Register Allocation
Andrew MacLeod wrote: > It must be the season for this sort of thing :-) I have not yet read the entire document, but I would very much like to applaud both the goal of improving register allocation, and the spirit in which you've approached it: in particular, posting a design and getting comments before starting implementation. I'm glad to see that strategy taking hold as a general approach for major development initiatives. :-) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Link-time optimzation
On Nov 17, 2005, at 21:33, Dale Johannesen wrote: When I arrived at Apple around 5 years ago, I was told of some recent measurements that showed the assembler took around 5% of the time. Don't know if that's still accurate. Of course the speed of the assembler is also relevant, and our stubs and lazy pointers probably mean Apple's .s files are bigger than other people's. Of course, there is a reason why almost any commercial compiler writes object files directly. If you start feeding serious GCC output through IAS (the Intel assembler) on a platform like IA64, you'll find that this really doesn't work. A file that takes seconds to compile can take over an hour to assemble. GCC tries to write out assembly in a way that is unambiguous, so the exact instructions being used are known. Any platform with a "smart optimizing", assembler will run into all kinds of issues. (Think MIPS.) Many assembler features, such as decimal floating-point number conversion, are so poorly implemented that they should be avoided at all cost. Some assemblers like to do their own instruction splitting, NOP insertion and dependency detection, completely throwing off choices made by the compiler's scheduler. Then there is alignment of code labels. If there even is the slightest doubt about what exact instruction encoding the assembler will use, all bets are off here too. If you'd start from scratch and want to get everything exactly right, it seems clear that the assembly output path is far harder to implement than writing object code directly. When you know exactly what bits you want, just go and write them. However, given that all ports are implemented based on assembly output, and that many users depend on assembly output being available, changing GCC's ways will be very labor intensive unfortunately. -Geert
Re: Register Allocation
On Thu, Nov 17, 2005 at 11:53:31AM -0500, Andrew MacLeod wrote: > The document is intended as a starting point and consists mostly of my > thoughts at the moment. By the time the underlying RTL bits are done, I > would like it to have evolved to include input from others. The more > useful comments there are, the better the chance of us getting a decent > allocator. I don't have any useful comments, but I want to thank you for doing this: it seems like a sound design, and a decent strategy to get GCC moving in an area where it has been stuck in a ditch for a while now. -- Daniel Jacobowitz CodeSourcery, LLC
Re: [RFC] PR/24900: computed but not used cast values
Richard Henderson wrote: > On Thu, Nov 17, 2005 at 08:42:19PM -0400, Aldy Hernandez wrote: > >>Well, as I mentioned in the PR, macro writers can wrap the whole thing >>in a statement expression and avoid the warning. Can't we suggest this >>and keep (almost) everybody happy? > > I think so. FWIW, I agree with all of RTH's comments in this thread. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: pruning unused debugging types (enums/PR23336)
Richard Henderson wrote: > A solution that comes to mind is to have the front-end add dummy > TYPE_DECL nodes to the BLOCK_VARS list of the function's outer-most > BLOCK. If the TYPE_DECL node were marked DECL_ARTIFICIAL and had > no DECL_NAME, it'd be easy for us to notice that we shouldn't > actually emit debug info for the TYPE_DECL itself, but that we > should consider its TREE_TYPE to be used. > > I'm open to better schemes. Perhaps a used-type hash table in > the struct function. I like the idea, but I think a hash table would be better. In fact, I think the best choice would be a hash table during compilation of the function, transformed into a vector after the closing brace of the function, so that we do not have the wasted memory associated with either dummy TYPE_DECLs or hash table entries. Also, we should do this only for the kinds of types we tend to lose (maybe casts and enums?), to keep the extra memory cost to a minimum. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
