GCJ Interpreter Aborts (2005-08-24 IST)
Hi,
In the last 24 hours, something has gone in which makes
the GCJ interpreter "gij" abort on even simple "Hello World"
classes. For example, the "RuntimeCheck" program in
the Jacks testsuite:
8<
public class RuntimeCheck {
private RuntimeCheck() {}
public static void main(String[] argv) {
System.out.print("1");
}
}
8<
Unfortunately, I didn't have time to debug this properly.
Ranjit.
--
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/
Re: Searching for a branch for the see optimization.
> > Why not just maintain it in a local tree and post refined > > versions every now and then, until stage 1 for GCC 4.2 opens? > > Branches are for major work and a new pass is not that major. > > It's also fine to create a new branch for this work. That let's other > people see what you're working on. That was my original purpose of searching for a brunch. I thought that if there is a related branch open I could join in. I don't think that it will disturb other people work. Leehod.
Warnung & Error Messages
Hi there, is there any reference about the warning- and error-messages gcc (e.g. 4.0.1) produces when compiling a C-source code ? What I'm looking for is a summary with some explanations. I tried hard, but couldn't find something suitable. Thanks and kind regards Ralf Schubert PASStec GmbH Germany
ia32: clearing a 7116 bytes struct inserted as "C.171.8759: .zero 7116 ... memcpy()" with gcc-4.0.2
Hello,
Investigated again a big increase of size going from GCC-3.4 to 4.x
(gcc (GCC) 4.0.2 20050811 (prerelease)) on my Gujin-v1.2, quickly way
to reproduce:
Download and untar gujin, then build "fs.s" :
url_get http://prdownloads.sourceforge.net/gujin/gujin-1.2.tar.gz?download
tar -xvzf gujin-1.2.tar.gz
cd gujin
make dep fs.s CC=/home/etienne/projet/toolchain/bin/gcc
Then edit fs.s and search the header of function "system_file_load":
.section.rodata
.type C.171.8759, @object
.size C.171.8759, 7116
C.171.8759:
.zero 7116
.section.xcode.system_file_load,"ax",@progbits
.p2align 1,,1
.globl system_file_load
.type system_file_load, @function
system_file_load:
pushl %ebp#
pushl %edi#
pushl %esi#
pushl %ebx#
subl$7488, %esp #, saved_stack.113
movl$0, 24(%esp)#, ax
movl$0, 20(%esp)#, ax
movl$0, 16(%esp)#, ax
movl$0, 12(%esp)#, ax
movl$0, 8(%esp) #, ax
#APP
bound %esp,STATE+48# STATE.stack_limit
#NO_APP
leal44(%esp), %edi #, tmp94
movl$C.171.8759, %esi #, tmp95
cld
movl$1779, %ecx #, tmp96
rep
movsl
That is the result of compiling (INIT is an enum of value 0):
unsigned system_file_load (struct desc_str *elem)
{bound_stack();{
z_stream gzlib = { .mode = INIT }; /* everything is null */
unsigned returned;
Thanks,
Etienne.
___
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger
Téléchargez cette version sur http://fr.messenger.yahoo.com
Problem with peephole to peephole2 conversion
I am converting peepholes to peephole2's. However, after compiling the kernel with the patched build, I get size regressions. Although the obj-dump shows that the peephole should have matched, it is actually not getting matched. This is because the pattern to be matched is not present at the time of peephole2 pass (it is a 3 insn pattern, out of which 2 are together, but the third one is put in later by the scheduler) The pattern matches in the original peephole pass because the peephole pass happens just before assembly generation, when the 3 insns are present together. Has anybody encountered a similar problem? Does this mean that peephole2 and peephole both should be kept on. Secondly, after taking a look at other ports, i realised that all are using peep2_dead_reg_p instead of dead_or_set_p to check if a register is dead. The former is smarter than the later in the sense that it also checks if the current insn "sets" the register which is to be verified as dead. So, why do other ports use peep2_reg_dead_p instead of dead_or_set_p. Pls help me to find the advantages of using peep2_reg_dead_p over its counterpart.
Re: Problem with the special live analyzer in global alloc
On Wed, 2005-08-24 at 00:07 -0400, Daniel Berlin wrote: > I imagine if you have 300k bb's or 1.5 million live pseudos to consider, > it probably makes a real difference, but that's not *too* common in our > supported languages (30k bb's/150k pseudos is probably the practical > upper limit of what we see, though i'm sure someone is going to say > they've seen larger :P) I wasn't trying to argue that it's the right answer for GCC, just that is was useful for the iSeries compiler. But like you alluded to and I mentioned, if you go this route, you really need to handle these new definitions specially otherwise you'll lose optimization opportunities. Peter
Re: SSE builtins for ia32
> "Richard" == Richard Henderson <[EMAIL PROTECTED]> writes: Richard> On Tue, Aug 23, 2005 at 04:32:42PM -0400, Paul Koning wrote: >> 1. Why do _builtin_ia32_paddusb and similar functions take signed >> vector arguments, when the hardware primitive is defined to >> operate on unsigned vectors? Richard> Because the interface you're actually supposed to be using Richard> is _mm_adds_pu8, which uses an opaque type. The underlying Richard> builtins all use signed vectors because it was simple to Richard> make them all the same. >> 2. Why are there no sse equivalents of those functions, ones that >> operate on 128 bit values (i.e., paddusb for v16qi vectors)? Richard> There are. See _mm_adds_epu8 in emmintrin.h. Thanks. The puzzler is that this isn't in the gcc docs. At least not in a place I could find. Not that the MMX builtins are easy to find, either... paul
Re: Problem with the special live analyzer in global alloc
On Wed, 2005-08-24 at 08:47 -0500, Peter Bergner wrote: > On Wed, 2005-08-24 at 00:07 -0400, Daniel Berlin wrote: > > I imagine if you have 300k bb's or 1.5 million live pseudos to consider, > > it probably makes a real difference, but that's not *too* common in our > > supported languages (30k bb's/150k pseudos is probably the practical > > upper limit of what we see, though i'm sure someone is going to say > > they've seen larger :P) > > I wasn't trying to argue that it's the right answer for GCC, just that > is was useful for the iSeries compiler. Sure. I was actually genuinely curious if you thought it would be useful for other languages that weren't like RPG :) You do, after all, know a little bit about this stuff :)
gcc newbie and open projects
Hello all! I would very much like to contribute to the gcc project and as such have been monitoring the gcc list and perusing the documentation. One project in particular looks interesting. Make insn-recog.c use a byte-coded DFA. Richard Henderson and I started this back in 1999 but never finished. I may still be able to find the code. It produces an order of magnitude size reduction in insn-recog.o, which is huge (432KB on i386). Is this still an open project? and if so can anyone give me more information on what is needed? I am an experienced c/c++ programmer but will obviously need to come up to speed on the gcc compiler internals. If anyone is feeling generous please let me know of projects which I could start with. hope to be talking with you all alot more, regards, Brian N. Makin __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: GCJ Interpreter Aborts (2005-08-24 IST)
> In the last 24 hours, something has gone in which makes > the GCJ interpreter "gij" abort on even simple "Hello World" > classes. For example, the "RuntimeCheck" program in > the Jacks testsuite: I had (probably) the same thing yesterday. Here's a backtrace: (gdb) bt #0 0x412d6ca1 in kill () from /lib/i686/libc.so.6 #1 0x412523a1 in pthread_kill () from /lib/i686/libpthread.so.0 #2 0x4125271b in raise () from /lib/i686/libpthread.so.0 #3 0x412d6908 in raise () from /lib/i686/libc.so.6 #4 0x412d7f70 in abort () from /lib/i686/libc.so.6 #5 0x4068eed1 in _Jv_Throw (value=0x4daf8) at ../../../gcc/libjava/exception.cc:111 #6 0x406bbb7e in java::lang::Thread::start (this=0x6dfc0) at ../../../gcc/libjava/java/lang/natThread.cc:322 #7 0x4087af40 in java.lang.ConcreteProcess.ConcreteProcess(java.lang.String[], java.lang.String[], java.io.File) (this=0x47f10, progarray=0x56258, envp=0x0, dir=0x0) at ConcreteProcess.java:377 #8 0x406b8e2b in java::lang::Runtime::execInternal (this=0x4db28, cmd=0x56258, env=0x0, dir=0x0) at ../../../gcc/libjava/java/lang/natRuntime.cc:287 #9 0x40868c90 in java.lang.Runtime.exec(java.lang.String[], java.lang.String[], java.io.File) ( this=0x4db28, cmd=0x56258, env=0x0, dir=0x0) at Runtime.java:492 #10 0x408622ed in java.lang.Runtime.exec(java.lang.String[]) (this=0x4db28, cmd=0x56258) at Runtime.java:444 #11 0x406cdf71 in gnu.gcj.runtime.NameFinder$Addr2Line.NameFinder$Addr2Line(gnu.gcj.runtime.Na meFin er, java.lang.String) (this=0x411d246c, this$0=0x0, binaryFile=0x0) at NameFinder.java:72 #12 0x406ce213 in gnu.gcj.runtime.NameFinder.lookup(java.lang.String, long) (this=0x411d246c, file=0x44a10, addr=4642331877099981328) at NameFinder.java:143 #13 0x4068f51b in _Jv_StackTrace::getLineNumberForFrame (frame=0x64f58, finder=0x4db58, sourceFileName=0xb350, lineNum=0xb34c) at ../../../gcc/libjava/stacktrace.cc:218 #14 0x4068f94b in _Jv_StackTrace::GetStackTraceElements (trace=0x64ea0, throwable=0x4dc60) at ../../../gcc/libjava/stacktrace.cc:342 #15 0x406bca41 in java::lang::VMThrowable::getStackTrace (this=0x47f30, throwable=0x4dc60) at ../../../gcc/libjava/java/lang/natVMThrowable.cc:44 #16 0x40870149 in java.lang.Throwable.getStackTrace() (this=0x4dc60) at Throwable.java:522 #17 0x0004dc60 in ?? () #18 0x40873722 in java.lang.Throwable.stackTraceString() (this=0x4dc60) at Throwable.java:417 #19 0x40873942 in java.lang.Throwable.printStackTrace(java.io.PrintStream) (this=0x411d246c, s=0x4dc60) at Throwable.java:363 #20 0x40864224 in java.lang.Throwable.printStackTrace() (this=0x411d246c) at Throwable.java:352 #21 0x40685060 in _Jv_RunMain (vm_args=0x0, klass=0x8050480, name=0x0, argc=1, argv=0xb564, is_jar=false) at ../../../gcc/libjava/prims.cc:1378 #22 0x406850b3 in _Jv_RunMain (klass=0x8050480, name=0x0, argc=1, argv=0xb564, is_jar=false) at ../../../gcc/libjava/prims.cc:1397 #23 0x406850e1 in JvRunMain (klass=0x8050480, argc=1, argv=0xb564) at ../../../gcc/libjava/prims.cc:1403 #24 0x0804e1ad in main (argc=1, argv=0xb564) at /root/tmp/ccJzdxFk.i:12
Re: gcc newbie and open projects
Is this still an open project? and if so can anyone
give me more information on what is needed?
Yes, it is.
Basically, insn-recog.c is a huge decision tree. genrecog.c builds it
and outputs it as C code. It uses variables like "x0, x1, x2, ..., xn"
which would become the virtual machine's registers. It should be
possible to linearize into something like bytecodes (more likely an
array of structs).
Some of the bytecodes are already visible from the "decision_type" enum
in genrecog.c:
DT_mode, DT_code, DT_veclen,
DT_elt_zero_int, DT_elt_one_int, DT_elt_zero_wide,
DT_elt_zero_wide_safe,
DT_const_int,
DT_veclen_ge, DT_dup, DT_pred, DT_c_test,
DT_accept_op, DT_accept_insn
To these, you should add some for control flow. In the end you may have
something like
- one bytecode for each of DT_mode ... DT_dup
- if ... goto ...
- switch (maybe more than one bytecode, see later)
- xK = PATTERN (peep2_next_insn (N))
- if peep2_next_insn (N) == NULL_RTX goto ... else same as above
- xK = XVECEXP (xJ, 0, N)
- xK = XEXP (xJ, N)
- operands[K] = N (this is DT_accept_op
- at least three bytecodes for DT_accept_insn, depending on
subroutine_type (see write_action in genrecog.c)
- one bytecode per predicate (not sure about this)
The moderately complex part of it should be:
- the switch statements, where it is mostly a matter of efficiently
encoding them. Most of them have a handful of cases, but few have 20 or so.
- the labels, where genrecog can already associate each decision tree
node with a C label. I guess you can do two compilation passes, one to
linearize the tree, and one to put in the "virtual program counter"
values and actually output the bytecoded description.
- DT_c_test: these are embedded C predicates. You can also have one
bytecode per test there. Anyway, you're already going to write at least
"part" of the virtual machine interpreter in your rewritten genrecog, if
you have one bytecode per predicate. Luckily, if the host compiler is
3.0.1 or later, insn-conditions.c has most of the work already done!
gensupport.c has this code
int
maybe_eval_c_test (const char *expr)
{
const struct c_test *test;
struct c_test dummy;
if (expr[0] == 0)
return 1;
if (insn_elision_unavailable)
return -1;
dummy.expr = expr;
test = (const struct c_test *)htab_find (condition_table, &dummy);
gcc_assert (test);
return test->value;
}
which gives this function
int
c_test_id (const char *expr)
{
const struct c_test *test;
struct c_test dummy;
if (expr[0] == 0)
return -1;
dummy.expr = expr;
test = (const struct c_test *)htab_find (condition_table, &dummy);
gcc_assert (test);
return test - insn_conditions;
}
With a GCC earlier than 3.0.1, dummy-conditions.c is used instead, but
you can ditch this. You'll have to modify write_one_condition in
genconditions.c, so that instead of
{ "! optimize_size && ! TARGET_READ_MODIFY",
__builtin_constant_p (! optimize_size && ! TARGET_READ_MODIFY)
? (int) (! optimize_size && ! TARGET_READ_MODIFY)
: -1) },
it outputs something like
{ "! optimize_size && ! TARGET_READ_MODIFY",
#if GCC_VERSION < 3001
__builtin_constant_p (! optimize_size && ! TARGET_READ_MODIFY)
? (int) (! optimize_size && ! TARGET_READ_MODIFY) :
#endif
-1) },
Similarly in write_conditions, instead of
const int insn_elision_unavailable = 0;
you can output
#if GCC_VERSION < 3001
const int insn_elision_unavailable = 1;
#else
const int insn_elision_unavailable = 0;
#endif
I guess the only complicated part is really the switch statements.
Paolo
Wiki Broken?
Attempting to edit the Wiki or otherwise login seems to generate an
error. This may be because I don't have an account. Error text below.
Niko
Fatal Error:
lib/WikiDB/adodb/adodb-errorhandler.inc.php:76: Error: mysql error:
[1065: Query was empty] in EXECUTE("")
lib/WikiUser/AdoDb.php:113: Notice: Object to string conversion
lib/WikiUser/AdoDb.php:113: Warning: Object
lib/WikiUser/AdoDb.php:127: Notice: Object to string conversion
lib/WikiUser/AdoDb.php:127: Warning: Object
lib/WikiUserNew.php:1055: Warning: DbAuthParams: Old statement
quoting style in
Fatal PhpWiki Error
lib/WikiDB/adodb/adodb-errorhandler.inc.php:76: Error: mysql error:
[1065: Query was empty] in EXECUTE("")
Notice: Undefined property: _user in /sourceware/www/gcc/wikidata/lib/
main.php on line 720
Notice: Use of undefined constant USE_SAFE_DBSESSION - assumed
'USE_SAFE_DBSESSION' in /sourceware/www/gcc/wikidata/lib/
DbSession.php on line 430
Re: Wiki Broken?
Niko Matsakis wrote: Attempting to edit the Wiki or otherwise login seems to generate an error. This may be because I don't have an account. Error text below. Probably, because I can edit with "PaoloBonzini" but not with "Paolo". Using "WikiWord" literally is a workaround. Paolo
Re: Wiki Broken?
You don't need a real account, just login as any wikiword. I think you are probably trying to login with a non-wikiword as the login name. Indeed, I forgot that WikiName's must be MixedCase. Niko
Re: Problem with peephole to peephole2 conversion
On Wed, Aug 24, 2005 at 06:50:25PM +0530, Ashwin wrote: > The pattern matches in the original peephole pass because the > peephole pass happens just before assembly generation, when the 3 insns > are present together. Has anybody encountered a similar problem? No, or at least havn't looked. > Does this mean that peephole2 and peephole both should be kept on. No. It would be possible to run peep2 more than once. Noone has shown a need for it yet. > Secondly, after taking a look at other ports, i realised that all are > using peep2_dead_reg_p instead of dead_or_set_p to check if a register > is dead. The former is smarter than the later in the sense that it also > checks if the current insn "sets" the register which is to be verified > as dead. So, why do other ports use peep2_reg_dead_p instead of > dead_or_set_p. Pls help me to find the advantages of using > peep2_reg_dead_p over its counterpart. My guess is that your misunderstanding is that you're not realizing that you can ask peep2_dead_reg_p about the state of a register at the beginning of the N+1 insn in the sequence. That is, after the entire sequence is over. peep2_dead_reg_p *is* smarter than dead_or_set_p. r~
Removing operand normalizaiton in get_expr_operands
Currently, get_expr_operands "renormalizes" the actual tree operands on it's own whim , such that if you call update_stmt on something like "a + c", it may be "c + a" after the call to update_stmt. This is not the same as sorting the use operands, vuses, etc, which is fine. This is actually modifying the expression, so that TREE_OPERAND (rhs, 0) before the call is not necessarily TREE_OPERAND (rhs, 0) after the call. In the reassociation rewrite (which rewrites the resasoc pass so that it catches all the things we've been looking for, like a & b & ~a & ~b, etc), it's very nice if we can reorder the operands temporarily so that the leaves are all to one side. We also need to keep the immediate uses up to date as we move things around, so that we have to call update_stmt. If update_stmt reorders things, then you have to keep checking whether the thing you thought was a leaf before update_stmt, is still in the same place, and reverse your operands, recurse on the correct side, etc. It's quite ugly. This ugliness happens during both linearization, and later rewriting. So I proposed to Andrew Macleod that we have an update_stmt interface that lets us choose not to resort the actual operands, and i'll just resort the expressions i touch when we are done. He went me one better and said we should just remove the code that is swapping the actual operands around. He didn't seem to remember why it was added. Here's why i agree that it should be removed entirely: 1. operand_equal_p already takes into account commutative operations. 2. iterative_hash_expr does as well. 3. None of the optimizations are trying to use simple pointer equivalence on actual binary operator arguments, AFAICT (Andrew said DOM might, but i don't see where). 4. Calling update_stmt on a statement should not actually change the statement itself. It seems completely counter-intuitive. 5. Fold will already do this, and we should be using it where necessary anyway. 6. It wastes some small amount of time to do this :) The counter arguments i can see are: 1. Auto-canonicalization is theoretically nice. Which is good and all, but it only helps if you are trying to see if the expressions are exactly the same, and 1. we use operand_equal_p for that anyway, because it knows more than we do about which operands are really equal. 2. fold will put them in the right order anyway, and things that modify or generate operations generally call fold. So my proposal is to simply remove the code that does this in tree-ssa-operands.c:get_expr_operands (search for tree_swap_operands to see it). Alternatively, i can just add the "no resort" interface. (or of course, write the ugly code to keep rechecking which operands got switched after each call to update_stmt :P)
Re: Wiki Broken?
On Wed, 2005-08-24 at 18:15 +0200, Niko Matsakis wrote: > Attempting to edit the Wiki or otherwise login seems to generate an > error. This may be because I don't have an account. Error text below. > You don't need a real account, just login as any wikiword. I think you are probably trying to login with a non-wikiword as the login name. I can't really debug this php crap anymore, which is why i really want to move to the new wiki software which is maintainable. Unfortunately, this too is waiting the new sourceware.
Re: Wiki Broken?
On Wednesday 24 August 2005 12:58 pm, Niko Matsakis wrote: > Indeed, I forgot that WikiName's must be MixedCase. Also known as BumpyCaps. Today's useless fact was brought to you by the letters A and K, and the number 47. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpjspGMxWLsx.pgp Description: PGP signature
RE: Wiki Broken?
Original Message >From: Patrick McFarland >Sent: 24 August 2005 18:27 > On Wednesday 24 August 2005 12:58 pm, Niko Matsakis wrote: >> Indeed, I forgot that WikiName's must be MixedCase. > > Also known as BumpyCaps. Today's useless fact was brought to you by the > letters A and K, and the number 47. And CamelCase. This also-useless fact was brought to you by the letters a, C, e, l, m and s. cheers, DaveK -- Can't think of a witty .sigline today
Re: Removing operand normalizaiton in get_expr_operands
On Wed, 2005-08-24 at 13:22 -0400, Daniel Berlin wrote: > Currently, get_expr_operands "renormalizes" the actual tree operands on > it's own whim , such that if you call update_stmt on something like "a + > c", it may be "c + a" after the call to update_stmt. > This is not the same as sorting the use operands, vuses, etc, which is > fine. > > This is actually modifying the expression, so that TREE_OPERAND (rhs, 0) > before the call is not necessarily TREE_OPERAND (rhs, 0) after the call. > > In the reassociation rewrite (which rewrites the resasoc pass so that it > catches all the things we've been looking for, like a & b & ~a & ~b, > etc), it's very nice if we can reorder the operands temporarily so that > the leaves are all to one side. > We also need to keep the immediate uses up to date as we move things > around, so that we have to call update_stmt. > > If update_stmt reorders things, then you have to keep checking whether > the thing you thought was a leaf before update_stmt, is still in the > same place, and reverse your operands, recurse on the correct side, etc. > It's quite ugly. This ugliness happens during both linearization, and > later rewriting. > > So I proposed to Andrew Macleod that we have an update_stmt interface > that lets us choose not to resort the actual operands, and i'll just > resort the expressions i touch when we are done. He went me one better > and said we should just remove the code that is swapping the actual > operands around. > > He didn't seem to remember why it was added. > > Here's why i agree that it should be removed entirely: > > 1. operand_equal_p already takes into account commutative operations. > 2. iterative_hash_expr does as well. > 3. None of the optimizations are trying to use simple pointer > equivalence on actual binary operator arguments, AFAICT (Andrew said DOM > might, but i don't see where). > 4. Calling update_stmt on a statement should not actually change the > statement itself. It seems completely counter-intuitive. > 5. Fold will already do this, and we should be using it where necessary > anyway. > 6. It wastes some small amount of time to do this :) > > The counter arguments i can see are: > 1. Auto-canonicalization is theoretically nice. > > Which is good and all, but it only helps if you are trying to see if the > expressions are exactly the same, and > 1. we use operand_equal_p for that anyway, because it knows more than we > do about which operands are really equal. > 2. fold will put them in the right order anyway, and things that modify > or generate operations generally call fold. > > So my proposal is to simply remove the code that does this in > tree-ssa-operands.c:get_expr_operands (search for tree_swap_operands to > see it). The auto-canonicalization does present some problems. No doubt about that. However, I was added specifically because it was allowing us to eliminate more useless crud. IIRC it was comparison elimination that primarily benefited from auto canonicalization. I don't recall any changes which would make the auto canonicalization no longer necessary, but if you can show no ill effects before/after removing auto canonicalization, then I won't object. jeff
Re: Removing operand normalizaiton in get_expr_operands
On Wed, Aug 24, 2005 at 01:22:09PM -0400, Daniel Berlin wrote: > Alternatively, i can just add the "no resort" interface. > (or of course, write the ugly code to keep rechecking which operands got > switched after each call to update_stmt :P) I'd prefer we kill it. Anything that relies on it ought to be fairly localized, and we can adjust there. But my guess is that nothing relies on it. r~
Re: Removing operand normalizaiton in get_expr_operands
> The auto-canonicalization does present some problems. No doubt about > that. However, I was added specifically because it was allowing us > to eliminate more useless crud. IIRC it was comparison elimination > that primarily benefited from auto canonicalization. I think that part may have been superseded by VRP, which uses operand_equal_p (the remainings parts of DOM, including avail_expr_eq, for example, uses operand_equal_p, which should handle that situation) > > I don't recall any changes which would make the auto canonicalization > no longer necessary, but if you can show no ill effects before/after > removing auto canonicalization, then I won't object. I'll run some numbers. > > > jeff > >
TREE_READONLY vs TREE_CONSTANT
In looking at PR23237, I ran into a bit of confusion over the difference between TREE_READONLY and TREE_CONSTANT. Andrew Pinski indicated in PR logs that I am misunderstanding their uses, so rather than bogging down the PR logs trying to clear up my confusion (which isn't really fair to Andrew), I thought I would bring up the question in a more general forum to see if there is someone willing to offer some insight. In the example from this PR, the TREE_READONLY attribute of a static variable declaration is being set in the ipa-reference pass if is determined that the variable is never modified. The problem is that when the assembly code is generated for this variable, the section flags are also set based on TREE_READONLY, so it ends up in a section inconsistent with its declaration. When I started digging into the tree flags, the descriptions in tree.h seemed to imply that TREE_CONSTANT is the appropriate attribute for a variable whose value doesn't change: /* Value of expression is constant. Always on in all ..._CST nodes. May also appear in an expression or decl where the value is constant. */ #define TREE_CONSTANT(NODE) (NON_TYPE_CHECK (NODE)- >common.constant_flag) And, based on other bits of source, TREE_READONLY seems to represent whether the variable was actually declared constant. Can someone provide a bit of insight here - what is the difference between TREE_READONLY and TREE_CONSTANT (and why is TREE_READONLY the one that ipa-reference should be setting)? Thanks for any help you can offer. - Josh
Re: V850 ABI?
Torsten Mohr wrote: > In that file i've also read about an option "ghs", does > that one switch to the Greenhills ABI? In theory, yes. In practice, I'd be skeptical. It probably hasn't been well tested. > From that file i can't really conclude everything. > For example i don't know if registers 20 and 21 hold the > values 255 and 65535 (an optimisation on V850). The startup > code in newlib assigns them, but does gcc really rely on that > and uses that (this question is just an example)? Try writing a simple example program to check. Since 20 and 21 are not fixed registers, my guess would be no. > Is there a description of the ABI or the ABIs available? Red Hat probably has a manual. If you can find a copy of a Red Hat v850 release, there may be a manual inside it that has ABI info. Otherwise, probably no. Gcc normally does not define the ABI. We just follow ABI standards produced by others. You could try checking in NEC publishes an ABI for the v850. For some embedded targets, gcc defines the ABI because there isn't an external one we can follow. In this case, gcc should document the ABI that it implements. This is done for some targets. If you look, you can see that some targets have a *ABI* or *abi* file that documents the gcc abi. Unfortunately, we don't do this for as many targets as we should. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: compile error for 990203-1.c
[EMAIL PROTECTED] wrote: > It's the mem rtx makes the difference, > but I don't know where the mem rtx comes from. > I have no idea about it. The real question here is why did purge_addressof_1 fail? You didn't provide that info. There are so many different things that could be wrong here that I can only suggest that you spend some more time debugging your port to figure out what is going on. Figure out where the REG_EQUAL note is being added (try emit_libcall_block or gen_rtx_INSN_LIST). Check to see if it was originally a reg or a mem. If it was originally a reg, figure out where and why it got changed to a mem. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: compile error for 990203-1.c
[EMAIL PROTECTED] wrote: > main.c:7: internal compiler error: in purge_addressof, at > function.c:3423 Oh, I forgot to mention, purge_addressof disappeared over a year ago, so few people are going to care about this. You are doing a port to gcc-3.4.x perhaps? It is important to include info like this, as porting problems are sometimes version dependent. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: m64
ji an wrote: > when I input the command line: >>g++ -m64 -o test test.cc > error message was output: > /tmp/ccyjpGIh.o(.text+0x900): In function `main': > : relocation truncated to fit: R_X86_64_32 This kind of question is more appropriate for gcc-help. The gcc list is intended for questions about gcc development. Please see http://gcc.gnu.org/bugs.html for info on how to report bugs. We can't do anything with the limited info that you have provided. We need a testcase, we need to know what OS you are running, etc. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: GCJ Interpreter Aborts (2005-08-24 IST)
> > > In the last 24 hours, something has gone in which makes > > the GCJ interpreter "gij" abort on even simple "Hello World" > > classes. For example, the "RuntimeCheck" program in > > the Jacks testsuite: > > I had (probably) the same thing yesterday. Here's a backtrace: It was caused by the following patch: 2005-08-23 J"orn Rennecke <[EMAIL PROTECTED]> PR middle-end/23467 * stor-layout.c (finalize_type_size): Dont override existing alignment with a smaller alignment from the mode. We now have a different layout causing the libjava to fail. -- Pinski
Re: Assembling pending decls before writing their debug info
Nick Clifton wrote: > The reason for this behaviour is that the debug information is being > written out before the variables have been fully resolved. In > particular DECL_SET() for the second and third observer functions is > NULL when the debug info is generated, which is why they are being > given the DW_AT_const_value attribute. See PR 21828 where some possible solutions for a related problem got discussed. Eventually, PR 21828 was fixed when Richard Henderson fixed something else and Mark Mitchell's patch for PR 18556 got reverted. This is discussed in the log. Meanwhile, there have been reports of some other related problems. There is a report from Apple near the end of PR 21828 that mentions stabs is still broken. This got rereported as PR 23190 and contains a patch similar to ones discussed in PR 21828. The interface between the front ends and cgraph really needs to be worked out here. Currently, the C and C++ front ends are calling some cgraph functions in different orders, and we are having lots of debug related problems. Maybe we need to move the calls to the debugging hooks from toplev into cgraph, so that they are only called when a variable is finalized? The right place to do this seems to be cgraph_varpool_assemble_pending_decls where it calls assemble_variable. And there is already a debug info hook there, but it is only used for static variables. So we need to get debug info for global variables emitted here, rather than in check_global_decls in toplev.c. You will need some magic variable to test in check_global_decls to prevent duplicate debug info, perhaps making the debug hook call here dependent on !flag_unit_at_a_time will work? -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: TREE_READONLY vs TREE_CONSTANT
On Wed, Aug 24, 2005 at 11:10:38AM -0700, Josh Conner wrote: > Can someone provide a bit of insight here - what is the difference > between TREE_READONLY and TREE_CONSTANT (and why is TREE_READONLY the > one that ipa-reference should be setting)? It depends on what property IPA is computing. And they aren't terribly differentiated. TREE_CONSTANT corresponds to the C++ "const int i = 1". That is, the variable may be immediately replaced in context with the immediate value, and unless the address of I is taken, its symbol will not appear in the assembly file. We probably could set TREE_CONSTANT for C "static const int i = 1", but to-date the optimizations that would enable are already taken care of by other means. TREE_READONLY means that the decl is not modifyable. It is interpreted, then, that the variable ought to go into read-only storage. The problem demonstrated in this PR comes when we combine this with variables in user defined sections. We take TREE_READONLY to infer the flags that should be applied to the section. Since a section can only have one set of flags, we define that the user must use the same set of flags for all variables in the section. The IPA pass indiscriminately setting TREE_READONLY breaks this. It's clear that we want IPA to set TREE_READONLY when the variable isn't in a user-defined section, so that if there is something that truely forces the variable into memory, that we put it in read-only storage. Which leaves the question of what IPA should do with variables that are in user-defined sections, and still gain the benefit of the IPA analysis? My suggestion is that IPA sets TREE_CONSTANT for all variables that it determines are unchanged, and TREE_READONLY as constrained by DECL_SECTION_NAME. We'll then have to modify a couple of places in the optimizers to check TREE_CONSTANT or TREE_READONLY. Finally, modify the front ends to set TREE_CONSTANT right away when it makes sense, and then we can remove the duplicated check in the optimizers. I'm not sure how much of this will be possible before 4.1 is released. At minimum we have to change IPA to stop setting TREE_READONLY when DECL_SECTION_NAME is set; if we have to live with reduced optimization so be it. r~
Re: Assembling pending decls before writing their debug info
On Wed, 2005-08-24 at 12:33 -0700, James E Wilson wrote: > Nick Clifton wrote: > > The reason for this behaviour is that the debug information is being > > written out before the variables have been fully resolved. In > > particular DECL_SET() for the second and third observer functions is > > NULL when the debug info is generated, which is why they are being > > given the DW_AT_const_value attribute. > > See PR 21828 where some possible solutions for a related problem got > discussed. Eventually, PR 21828 was fixed when Richard Henderson fixed > something else and Mark Mitchell's patch for PR 18556 got reverted. > This is discussed in the log. > > Meanwhile, there have been reports of some other related problems. > There is a report from Apple near the end of PR 21828 that mentions > stabs is still broken. This got rereported as PR 23190 and contains a > patch similar to ones discussed in PR 21828. > > The interface between the front ends and cgraph really needs to be > worked out here. Currently, the C and C++ front ends are calling some > cgraph functions in different orders, and we are having lots of debug > related problems. > > Maybe we need to move the calls to the debugging hooks from toplev into > cgraph, so that they are only called when a variable is finalized? This is something i meant to do for 4.1, but didn't get to :( At this point, cgraph should definitely be driving the debug output, at least for the variables it knows about. IMHO. :) The blocker last time i looked was that we had to support non-unit-at-a-time, and thus, it wasn't at all clear to me what logic i could remove completely, and what logic needed to be ! flag_unit_at_a_time.
Re: TREE_READONLY vs TREE_CONSTANT
On Aug 24, 2005, at 12:33 PM, Richard Henderson wrote: On Wed, Aug 24, 2005 at 11:10:38AM -0700, Josh Conner wrote: Can someone provide a bit of insight here - what is the difference between TREE_READONLY and TREE_CONSTANT (and why is TREE_READONLY the one that ipa-reference should be setting)? It depends on what property IPA is computing. And they aren't terribly differentiated. ... Thanks very much for the thorough description. I think I understand the distinction now. I'm not sure how much of this will be possible before 4.1 is released. At minimum we have to change IPA to stop setting TREE_READONLY when DECL_SECTION_NAME is set; if we have to live with reduced optimization so be it. I'd be glad to create and test a patch for this, if it would be welcomed. - Josh
SSA_NAMEs not always released
I am writing a "quick and dirty" DCE pass which is faster the current
DCE and
does not do anything with stores/loads. It passes over all the live
SSA_NAMEs
by looping over ssa_name. But I am running into places where SSA_NAMEs
not
released when they become dead. I have a fix for some of these places,
we
call bsi_remove and don't call release_defs (I will submit those later,
I already tested it last night) but there are still other places where
the
SSA_NAME becomes not alive but does not get released.
On example is:
int f(void)
{
int i;
int *j = &i;
i = 1;
return *j;
}
With the attached patch, I get the following error:
t1.c: In function 'f':
t1.c:2: error: SSA_NAME_DEF_STMT does not define the correct SSA_NAME
while verifying SSA_NAME i_3 in statement
i_1 = 1;
i_3 no longer exists (can be seen by looking at the tree dumps
and at the BasicBlock at the time of checking) but it has not been
released
so it is still in the ssa_name VEC and refers to the "i_1 = 1;"
statement.
If we take this after DCE, we still refer to a statement which no longer
exists which we don't collect in the GC.
Could someone look into this and see what they can do? This will
improve
memory usage in GCC and also there will be more SSA_NAME reuse which is
good.
Thanks,
Andrew Pinsk
Index: tree-ssa.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa.c,v
retrieving revision 2.106
diff -u -p -r2.106 tree-ssa.c
--- tree-ssa.c 19 Jul 2005 20:20:40 - 2.106
+++ tree-ssa.c 24 Aug 2005 21:23:51 -
@@ -184,6 +184,27 @@ verify_def (basic_block bb, basic_block
print_generic_stmt (stderr, stmt, TDF_VOPS);
goto err;
}
+
+ if (!is_virtual)
+{
+ if (TREE_CODE (stmt) == RETURN_EXPR)
+stmt = TREE_OPERAND (stmt, 0);
+ if (TREE_CODE (stmt) != MODIFY_EXPR && TREE_CODE (stmt) != PHI_NODE)
+{
+ error ("SSA_NAME_DEF_STMT is not a MODIFY_EXPR or a PHI_NODE");
+ goto err;
+ }
+ if (TREE_CODE (stmt) == MODIFY_EXPR && TREE_OPERAND (stmt, 0) !=
ssa_name)
+{
+ error ("SSA_NAME_DEF_STMT does not define the correct SSA_NAME");
+ goto err;
+ }
+ if (TREE_CODE (stmt) == PHI_NODE && PHI_RESULT_TREE (stmt) != ssa_name)
+{
+ error ("SSA_NAME_DEF_STMT does not define the correct SSA_NAME");
+ goto err;
+ }
+}
return false;
@@ -659,8 +680,9 @@ verify_ssa (bool check_modified_stmt)
if (!IS_EMPTY_STMT (stmt))
{
basic_block bb = bb_for_stmt (stmt);
- verify_def (bb, definition_block,
- name, stmt, !is_gimple_reg (name));
+ if (verify_def (bb, definition_block,
+ name, stmt, !is_gimple_reg (name)))
+ goto err;
}
}
Index: tree-cfg.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-cfg.c,v
retrieving revision 2.216
diff -u -p -r2.216 tree-cfg.c
--- tree-cfg.c 13 Aug 2005 17:28:36 - 2.216
+++ tree-cfg.c 24 Aug 2005 21:23:52 -
@@ -3140,6 +3140,21 @@ verify_expr (tree *tp, int *walk_subtree
error ("GIMPLE register modified with BIT_FIELD_REF");
return t;
}
+ if (TREE_CODE (x) == SSA_NAME)
+{
+ tree t1 = SSA_NAME_DEF_STMT (x);
+ if (TREE_CODE (t1) == RETURN_EXPR)
+ t1 = TREE_OPERAND (t1, 0);
+ if (t1 != t)
+ {
+ fprintf (stderr, "SSA_NAME ");
+ print_generic_expr (stderr, x, 0);
+ fprintf (stderr, "points to the wrong statement\n");
+ print_generic_stmt (stderr, SSA_NAME_DEF_STMT (x), TDF_VOPS);
+ print_generic_stmt (stderr, t, TDF_VOPS);
+ return t;
+ }
+ }
break;
case ADDR_EXPR:
Re: SSA_NAMEs not always released
> If we take this after DCE, we still refer to a statement which no longer > exists which we don't collect in the GC. As i said when i pointed this out to you, we should probably skip walking common.chain on SSA_NAME. But that's non-trivial hard because it's a reused field :( > > Could someone look into this and see what they can do? You should probably ask Diego or Andrew directly whether they'd like us to do this in bsi_remove (which requires adding an argument) and remove_phi_node(ditto) so that a lot less has to worry about releasing defs. > This will > improve > memory usage in GCC and also there will be more SSA_NAME reuse which is > good. > > Thanks, > Andrew Pinsk > > > >
help on compile error (4.0.1)
Hello, I am compiling GCC-4.0.1 with the following : ../gcc-4.0.1/configure --enable-tree-browser=yes --prefix=/home/jiang/DEV/gcc-dev/trunk/install --enable-languages=c,c++ --enable-maintainer-mode=yes After a while I got the following errors with : Adding multilib support to Makefile in ../../../gcc-4.0.1/libmudflap multidirs= with_multisubdir= config.status: executing depfiles commands make[1]: Entering directory `/home/jiang/DEV/gcc-dev/trunk/obj/i686-pc-linux-gnu /libmudflap' cd ../../../gcc-4.0.1/libmudflap && /bin/sh /home/jiang/DEV/gcc-dev/trunk/gcc-4. 0.1/missing --run aclocal-1.9 -I .. -I ../config cd ../../../gcc-4.0.1/libmudflap && /bin/sh /home/jiang/DEV/gcc-dev/trunk/gcc-4 .0.1/missing --run automake-1.9 --foreign cd ../../../gcc-4.0.1/libmudflap && /bin/sh /home/jiang/DEV/gcc-dev/trunk/gcc-4. 0.1/missing --run autoconf /bin/sh ./config.status --recheck running /bin/sh /home/jiang/DEV/gcc-dev/trunk/gcc-4.0.1/libmudflap/configure -- cache-file=./config.cache --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --e nable-multilib --enable-tree-browser=yes --prefix=/home/jiang/DEV/gcc-dev/trunk/ install --with-cflags=-g3 -O0 --enable-maintainer-mode=yes --with-gcc-version-tr igger=/home/jiang/DEV/gcc-dev/trunk/gcc-4.0.1/gcc/version.c --enable-languages=c ,c++ --program-transform-name=s,y,y, --srcdir=../../../gcc-4.0.1/libmudflap --wi th-target-subdir=i686-pc-linux-gnu CPPFLAGS= build_alias=i686-pc-linux-gnu host_ alias=i686-pc-linux-gnu --no-create --no-recursion configure: loading cache ./config.cache configure: error: `target_alias' was not set in the previous run configure: error: changes in the environment can compromise the build configure: error: run `make distclean' and/or `rm ./config.cache' and start over make[1]: *** [config.status] Error 1 make[1]: Leaving directory `/home/jiang/DEV/gcc-dev/trunk/obj/i686-pc-linux-gnu/ libmudflap' make: *** [all-target-libmudflap] Error 2 Any suggestions? -Jiang
Re: SSA_NAMEs not always released
On Wed, 2005-08-24 at 18:28 -0400, Daniel Berlin wrote: > > Could someone look into this and see what they can do? > > You should probably ask Diego or Andrew directly whether they'd like us > to do this in bsi_remove (which requires adding an argument) and > remove_phi_node(ditto) so that a lot less has to worry about releasing > defs. removing a stmt doesn't mean that the def is no longer needed. there could still be uses and a replacement def inserted later. Even if there are currently no uses, that still doesn't mean that the stmt being removed isn't going to be inserted again somewhere else... Then the def on the stmt would not be valid. bsi_remove is simply a wrapper around stmt delinking, it shouldn't have other effects like deciding an SSA_NAME is now unused. Ive never been a big fan of having to call something to release ssa_names, its too bug prone. I would much prefer to see something like a cleanup pass done every once in a while... an ssa-name garbage collector if you will :-). It seems to me that between major optimization passes, any SSA_NAME with no defining stmt, no uses, and isn't a default def of some sort can simply be released. Or at least some similar set of criteria. I suspect immediate uses were not available when release_defs was invented, so this was not easily done. Andrew
Re: Wiki Broken?
On Wed, Aug 24, 2005 at 06:30:17PM +0100, Dave Korn took 20 lines to write: > Original Message > >From: Patrick McFarland > >Sent: 24 August 2005 18:27 > > > On Wednesday 24 August 2005 12:58 pm, Niko Matsakis wrote: > >> Indeed, I forgot that WikiName's must be MixedCase. > > > > Also known as BumpyCaps. Today's useless fact was brought to you by the > > letters A and K, and the number 47. > > > And CamelCase. This also-useless fact was brought to you by the letters > a, C, e, l, m and s. And StudlyCaps. Yet another useless fact brought you by the SMTP, TCP, and Ethernet protocols. Kurt -- Ask your boss to reconsider -- it's so difficult to take "Go to hell" for an answer.
Re: SSA_NAMEs not always released
On Wed, 2005-08-24 at 19:19 -0400, Andrew MacLeod wrote: > On Wed, 2005-08-24 at 18:28 -0400, Daniel Berlin wrote: > > > Could someone look into this and see what they can do? > > > > You should probably ask Diego or Andrew directly whether they'd like us > > to do this in bsi_remove (which requires adding an argument) and > > remove_phi_node(ditto) so that a lot less has to worry about releasing > > defs. > > removing a stmt doesn't mean that the def is no longer needed. That ws the goal of the extra argument, however > Ive never been a big fan of having to call something to release > ssa_names, its too bug prone. I would much prefer to see something like > a cleanup pass done every once in a while... an ssa-name garbage > collector if you will :-). It seems to me that between major > optimization passes, any SSA_NAME with no defining stmt, no uses, and > isn't a default def of some sort can simply be released. Or at least > some similar set of criteria. I suspect immediate uses were not > available when release_defs was invented, so this was not easily done. I like this idea much better :)
4.2 Project: "@file" support
I've created a new 4.2 Project page for "response files", which is
what Microsoft calls files that contain command-line options.
Conventionally, if you pass "@file" as an argument to a program, the
file is read, and the contents are treated as command-line options.
On systems with small command-line buffers, this is a must-have
feature.
This is clearly not Stage 3 material. I'm posting it now in the hopes
that any issues can be resolved in advance of 4.2 Stage 1. Also,
because this patch comes from a 3.4 toolchain, I know there are a few
updates (like using XRESIZEVEC) that should be made before committing
to mainline.
And, as penance for posting new features in Stage 3, I'm committing to
fixing some C++ bugs before bedtime.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
2005-08-24 Mark Mitchell <[EMAIL PROTECTED]>
* include/libiberty.h (expandargv): New function.
* libiberty/argv.c (safe-ctype.h): Include it.
(ISBLANK): Remove.
(stdio.h): Include.
(expandargv): New function.
* libiberty/Makefile.in: Regenerated.
* gcc/gcc.c (main): Use expandargv.
* gcc/doc/invoke.texi: Describe "@file" option.
Index: include/libiberty.h
===
RCS file: /cvs/gcc/gcc/include/libiberty.h,v
retrieving revision 1.35.10.1
diff -c -5 -p -r1.35.10.1 libiberty.h
*** include/libiberty.h 23 Dec 2003 17:25:29 - 1.35.10.1
--- include/libiberty.h 25 Aug 2005 03:31:49 -
*** extern void freeargv PARAMS ((char **));
*** 60,69
--- 60,72
/* Duplicate an argument vector. Allocates memory using malloc. Use
freeargv to free the vector. */
extern char **dupargv PARAMS ((char **)) ATTRIBUTE_MALLOC;
+ /* Expand "@file" arguments in argv. */
+
+ extern const char *expandargv PARAMS ((int *, char ***));
/* Return the last component of a path name. Note that we can't use a
prototype here because the parameter is declared inconsistently
across different systems, sometimes as "char *" and sometimes as
"const char *" */
Index: libiberty/argv.c
===
RCS file: /cvs/gcc/gcc/libiberty/argv.c,v
retrieving revision 1.13
diff -c -5 -p -r1.13 argv.c
*** libiberty/argv.c15 Apr 2003 20:36:33 - 1.13
--- libiberty/argv.c25 Aug 2005 03:31:49 -
*** Boston, MA 02111-1307, USA. */
*** 22,33
/* Create and destroy argument vectors. An argument vector is simply an
array of string pointers, terminated by a NULL pointer. */
#include "ansidecl.h"
#include "libiberty.h"
! #define ISBLANK(ch) ((ch) == ' ' || (ch) == '\t')
/* Routines imported from standard C runtime libraries. */
#ifdef ANSI_PROTOTYPES
--- 22,34
/* Create and destroy argument vectors. An argument vector is simply an
array of string pointers, terminated by a NULL pointer. */
#include "ansidecl.h"
#include "libiberty.h"
+ #include "safe-ctype.h"
! #include
/* Routines imported from standard C runtime libraries. */
#ifdef ANSI_PROTOTYPES
*** char **buildargv (input)
*** 302,311
--- 303,457
while (*input != EOS);
}
return (argv);
}
+ /*
+
+ @deftypefn Extension const char* expandargv (int [EMAIL PROTECTED], char
[EMAIL PROTECTED])
+
+ The @var{argcp} and @code{argvp} arguments are pointers to the usual
+ @code{argc} and @code{argv} arguments to @code{main}. This function
+ looks for arguments that begin with the character @samp{@@}. Any such
+ arguments are interpreted as ``response files''. The contents of the
+ response file are interpreted as additional command line options. In
+ particular, the file is separated into whitespace-separated strings;
+ each such string is taken as a command-line option. The new options
+ are inserted in place of the option naming the response file, and
+ @code{*argcp} and @code{*argvp} will be updated. If the value of
+ @code{*argvp} is modified by this function, then the new value has
+ been dynamically allocated and should be deallocated by the caller
+ with @code{freeargv}.
+
+ If the value returned is not @code{NULL}, then it is the name of a
+ response file that could not be read.
+
+ @end deftypefn
+
+ */
+
+ const char *
+ expandargv (argcp, argvp)
+ int *argcp;
+ char ***argvp;
+ {
+ /* A dynamically allocated buffer used to hold options read from a
+ response file. NULL until needed. */
+ char *buffer = NULL;
+ /* The number of bytes in BUFFER. */
+ size_t buffer_len = 0;
+ /* Dynamically allocated storage for the options read from the
+ response file. NULL until needed. */
+ char **file_options = NULL;
+ /* The number of slots in the FILE_OPTIONS array. */
+ size_t file_options_len = 0;
+ /* If non-NULL, the name of the response file that caused a
+ failure. */
+ const char
Re: 4.2 Project: "@file" support
On Wed, Aug 24, 2005 at 09:50:32PM -0700, Mark Mitchell wrote: > > I've created a new 4.2 Project page for "response files", which is > what Microsoft calls files that contain command-line options. > Conventionally, if you pass "@file" as an argument to a program, the > file is read, and the contents are treated as command-line options. Huh? That should certainly be a feature of the shell, not the OS. > On systems with small command-line buffers, this is a must-have > feature. Do you really want every application to work around a broken propritary system? Looks like gcc is really heading down the wrong way..
Re: 4.2 Project: "@file" support
Christoph Hellwig wrote: On Wed, Aug 24, 2005 at 09:50:32PM -0700, Mark Mitchell wrote: I've created a new 4.2 Project page for "response files", which is what Microsoft calls files that contain command-line options. Conventionally, if you pass "@file" as an argument to a program, the file is read, and the contents are treated as command-line options. Huh? That should certainly be a feature of the shell, not the OS. I'm not sure what you're saying. The limitation on command-line length can be in either the shell, or the OS. In Windows 2000, the limitation comes primarily from the Windows command shell. On systems with small command-line buffers, this is a must-have feature. Do you really want every application to work around a broken propritary system? I want GCC to work well for people, no matter what operating system they are using. This is a feature that everyone who produces Windows-hosted versions of GCC ends up implementing; I'd like to keep us all from having to keep reinventing the wheel. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: 4.2 Project: "@file" support
Mark Mitchell <[EMAIL PROTECTED]> writes: > I've created a new 4.2 Project page for "response files", which is > what Microsoft calls files that contain command-line options. > Conventionally, if you pass "@file" as an argument to a program, the > file is read, and the contents are treated as command-line options. > On systems with small command-line buffers, this is a must-have > feature. DJGPP and Cygwin already implement these at the OS level, for *all* applications, and have for quite some time now. Please don't interfere with this; it will only confuse DJGPP and Cygwin users, especially since your implementation is already different than existing implementations. Also, both DJGPP and Cygwin programs have essentially unlimited command line buffers when invoked from other DJGPP or Cygwin programs (like "make"); they use an internal interface to bypass the OS limitations. It sounds like you're interested in MinGW. If you really wanted to help MinGW users, you'd fix MinGW so that it supported these the same way that DJGPP and Cygwin do, for *all* MinGW applications, not just gcc. I'd have to have to manually add this function call to each of the programs in binutils, gdb, sid, fileutils, coreutils, make, etc. That sounds like the wrong way to solve an OS problem.
Re: 4.2 Project: "@file" support
> I'm not sure what you're saying. The limitation on command-line > length can be in either the shell, or the OS. In Windows 2000, the > limitation comes primarily from the Windows command shell. When gcc.exe invokes cc1.exe, the limitation is not the command shell.
Re: 4.2 Project: "@file" support
DJ Delorie wrote: I'm not sure what you're saying. The limitation on command-line length can be in either the shell, or the OS. In Windows 2000, the limitation comes primarily from the Windows command shell. When gcc.exe invokes cc1.exe, the limitation is not the command shell. Correct. In Windows, there is much less of a limitation there; CreateProcess has a 32K limit. However, Win2K's command shell was much more limited. Therefore, the primary problem is in getting arguments into the driver; getting things from the driver to subprocesses is much less problematic, in practice. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: 4.2 Project: "@file" support
DJ Delorie wrote: It sounds like you're interested in MinGW. Yes. I'm particularly interested in the case of applications not built with GCC invoking GCC. I can't control the invoker; only the invokee. > If you really wanted > help MinGW users, you'd fix MinGW so that it supported these the same way that DJGPP and Cygwin do, for *all* MinGW applications, not just gcc. I'd have to have to manually add this function call to each of the programs in binutils, gdb, sid, fileutils, coreutils, make, etc. That sounds like the wrong way to solve an OS problem. I'm not sure how I can "fix MinGW"; see above. Also, if a MinGW application wants to invoke some other Windows program, the behavior should be the same as if I compiled that application with Visual C, or Intel's C compiler, or whatever; if we were using magic to pass command-line arguments, we'd be breaking things. We have the same OS problem in almost every UNIX, to one degree or another. Older UNIX variants certainly had this problem in spades. But it's not a big deal to me if people don't want this for systems other than MinGW, but I think we need it for MinGW. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Dom patch
Hey,
I'm going to do more testing on this, but it seems this patch reduces the
number of DOM iterations from the number of else if statements in pr19097 to
2 DOM iterations. This is a massive savings and the savings if from
calling fold_build2 (cond_code, boolean_type_node, op0, op1) in
thread_across_edge since the folded expression is now saved for the rest of
the iteration where the folded expression wasn't before. Since this is such
a huge gain, I'm skeptical that it is truly correct. Comments?
Jim
Index: tree-ssa-dom.c
===
RCS file: /cvsroot/gcc/gcc/gcc/tree-ssa-dom.c,v
retrieving revision 2.127
diff -u -p -r2.127 tree-ssa-dom.c
--- tree-ssa-dom.c 2 Aug 2005 00:12:39 - 2.127
+++ tree-ssa-dom.c 25 Aug 2005 06:31:56 -
@@ -294,21 +294,6 @@ static void restore_nonzero_vars_to_orig
static inline bool unsafe_associative_fp_binop (tree);
-/* Local version of fold that doesn't introduce cruft. */
-
-static tree
-local_fold (tree t)
-{
- t = fold (t);
-
- /* Strip away useless type conversions. Both the NON_LVALUE_EXPR that
- may have been added by fold, and "useless" type conversions that might
- now be apparent due to propagation. */
- STRIP_USELESS_TYPE_CONVERSION (t);
-
- return t;
-}
-
/* Allocate an EDGE_INFO for edge E and attach it to E.
Return the new EDGE_INFO structure. */
@@ -795,21 +780,27 @@ thread_across_edge (struct dom_walk_data
dummy_cond = walk_data->global_data;
if (! dummy_cond)
{
- dummy_cond = build (cond_code, boolean_type_node, op0, op1);
- dummy_cond = build (COND_EXPR, void_type_node,
- dummy_cond, NULL, NULL);
+ cached_lhs = fold_build2 (cond_code, boolean_type_node, op0, op1);
+ dummy_cond = build3 (COND_EXPR, void_type_node,
+ cached_lhs, NULL, NULL);
walk_data->global_data = dummy_cond;
}
+ else if ((cached_lhs = fold_binary (cond_code, boolean_type_node,
+ op0, op1)))
+ {
+ COND_EXPR_COND (dummy_cond) = cached_lhs;
+ }
else
{
TREE_SET_CODE (COND_EXPR_COND (dummy_cond), cond_code);
TREE_OPERAND (COND_EXPR_COND (dummy_cond), 0) = op0;
TREE_OPERAND (COND_EXPR_COND (dummy_cond), 1) = op1;
+ cached_lhs = COND_EXPR_COND (dummy_cond);
}
+ STRIP_USELESS_TYPE_CONVERSION (cached_lhs);
/* If the conditional folds to an invariant, then we are done,
otherwise look it up in the hash tables. */
- cached_lhs = local_fold (COND_EXPR_COND (dummy_cond));
if (! is_gimple_min_invariant (cached_lhs))
{
cached_lhs = lookup_avail_expr (dummy_cond, false);
@@ -1813,18 +1804,22 @@ simplify_rhs_and_lookup_avail_expr (tree
if (rhs_def_code != rhs_code)
{
if (rhs_def_code == MINUS_EXPR)
- t = build (MINUS_EXPR, type, outer_const, def_stmt_op1);
+ t = fold_build2 (MINUS_EXPR, type, outer_const,
+def_stmt_op1);
else
- t = build (MINUS_EXPR, type, def_stmt_op1, outer_const);
+ t = fold_build2 (MINUS_EXPR, type, def_stmt_op1,
+outer_const);
rhs_code = PLUS_EXPR;
}
else if (rhs_def_code == MINUS_EXPR)
- t = build (PLUS_EXPR, type, def_stmt_op1, outer_const);
+ t = fold_build2 (PLUS_EXPR, type, def_stmt_op1,
+outer_const);
else
- t = build (rhs_def_code, type, def_stmt_op1, outer_const);
- t = local_fold (t);
- t = build (rhs_code, type, def_stmt_op0, t);
- t = local_fold (t);
+ t = fold_build2 (rhs_def_code, type, def_stmt_op1,
+outer_const);
+ STRIP_USELESS_TYPE_CONVERSION (t);
+ t = fold_build2 (rhs_code, type, def_stmt_op0, t);
+ STRIP_USELESS_TYPE_CONVERSION (t);
/* If the result is a suitable looking gimple expression,
then use it instead of the original for STMT. */
@@ -1928,11 +1923,11 @@ find_equivalent_equality_comparison (tre
If that is true, the build and return new equivalent
condition which uses the source of the typecast and the
new constant (which has only changed its type). */
- new = build1 (TREE_CODE (def_rhs), def_rhs_inner_type, op1);
- new = local_fold (new);
+ new = fold_build1 (TREE_CODE (def
