dejagnu: timeout?
I just noticed a slight change in behaviour... on my system, I have edited dejagnu's remote.exp such that it defaults its timeout to 1800 instead of 300. However, on gcc trunk, I see that, for example, in the libstdc++ testsuite log, the timeout is set to 600, while in, e.g., gcc's log file, its 1800, as I expect. Now, is there some change that has been made to gcc trunk lately, meaning the last year, that have this effect? Any suggestions on how I could get gcc trunk testsuite to once again use dejagnu timeout to 1800? -- Cheers, /ChJ
Re: dejagnu: timeout?
On 8/21/06, Christian Joensson <[EMAIL PROTECTED]> wrote: I just noticed a slight change in behaviour... on my system, I have edited dejagnu's remote.exp such that it defaults its timeout to 1800 instead of 300. However, on gcc trunk, I see that, for example, in the libstdc++ testsuite log, the timeout is set to 600, while in, e.g., gcc's log file, its 1800, as I expect. Now, is there some change that has been made to gcc trunk lately, meaning the last year, that have this effect? sorry, too early, it's http://gcc.gnu.org/ml/gcc-cvs/2006-06/msg00792.html ... Any suggestions on how I could get gcc trunk testsuite to once again use dejagnu timeout to 1800? so, basically, how would I override http://gcc.gnu.org/ml/gcc-cvs/2006-06/msg00792.html , without having a local change in my source tree, such that I get my old behaviour? -- Cheers, /ChJ
Re: Use gcc front-end for metrics
In order to build a metrication tool I need a frontend that can provide me with an abstract syntax tree containing information on all actual language constructs in the code and also a CFG representation. I reckon GCC has these capabilities and I was wondering if any of you could tell me if it is possible to use just GCC's frontend. Furthermore, where should I start, how do I extract the frontend from GCC, which of the intermediate GCC representation could I use, are they documented? I would like to thank you in advance for any help you can give me. Before you are to familiarized with GCC I want to give you a hint to another project from Berkley. It is called Elsa/Elkhound parser (www.cs.berkeley.edu/~smcpeak/elkhound/). It is a C and C++ parser written in C++ with a cleaner internal structure as the GCC parser. Additionally, there is another projects, called OINK (funny name), which provides different back-ends for Elsa as well printing a CFG. I started like you with implementing my own code inside GCC, then I found these two projects and this saves me a lot of time. HTH Christian
TTCN-3 frontend
Hi, I would like to ask whose approval is needed to start developing a GCC front-end for the abstract test language TTCN-3. More information about the language can be found here: http://www.ttcn-3.org/ Thanks, Cosmin -- --- Dipl.Ing. Cosmin Rentea web:http://www.fokus.fraunhofer.de/motion Fraunhofer FOKUS email: [EMAIL PROTECTED] Kaiserin-Augusta-Allee 31tel:++49-30-3463-7175 D-10589 Berlin fax:++49-30-3463-8243 ---
Re: TTCN-3 frontend
On 8/21/06, Cosmin Rentea <[EMAIL PROTECTED]> wrote: Hi, I would like to ask whose approval is needed to start developing a GCC front-end for the abstract test language TTCN-3. You don't need an approval for that. See the COPYING file distributed with GCC for the details. More information about the language can be found here: http://www.ttcn-3.org/ Thanks, Cosmin Best Regards, Rafael
Re: Darwin -m64 results
Mike, As I mentioned before, the simple test case of... program test integer i end shows the following change in its .s file when the "common i" is added... --- assign.s.nocommon 2006-08-19 10:45:59.0 -0400 +++ assign.s2006-08-19 10:46:19.0 -0400 @@ -18,6 +18,11 @@ .stabs "void:t(0,1)",128,0,0,0 Lscope1: .stabs "",36,0,0,Lscope1-LFBB1 +.comm ___BLNK__,4 + .stabs "__BLNK__:G(0,2)=s4i:(0,3)=r(0,3);-2147483648;2147483647;,0,32;;",32,0,3,0 + .stabs "int4:t(0,3)",128,0,0,0 + .stabs "__BLNK__:G(0,2)",32,0,3,0 + .stabs "i:G(0,3)",32,0,4,0 .stabs "",100,0,0,Letext0 Letext0: .section __TEXT,__picsymbolstub1,symbol_stubs,pure_instructions,32 I just wanted to be clear that you believe only the line... + .stabs "i:G(0,3)",32,0,4,0 in that .s file is incorrect and it would be sufficient just to have that suppressed by the gfortran compiler. Or do you believe it should be replaced by something else for "i" as a COMMON block? Jack
mismatched parentheses in reload1.c
This patch: r116277 | hubicka | 2006-08-21 02:00:14 +0200 (Mon, 21 Aug 2006) | 6 lines PR rtl-optimization/28071 * reload1.c (reg_has_output_reload): Turn into regset. (reload_as_needed, forget_old_reloads_1, forget_marked_reloads, choose_reload_regs, emit_reload_insns): Update to new reg_has_output_reload. introduced changes in these lines of code (around line 7390 of reload1.c): else if (rld[r].out_reg == 0 && rld[r].in != 0 && ((REG_P (rld[r].in) && REGNO (rld[r].in) >= FIRST_PSEUDO_REGISTER && !REGNO_REG_SET_P (®_has_output_reload, REGNO (rld[r].in)) || (REG_P (rld[r].in_reg) && !REGNO_REG_SET_P (®_has_output_reload, REGNO (rld[r].in) && ! reg_set_p (rld[r].reg_rtx, PATTERN (insn))) Notice how the OR is aligned with the parentheses, but in fact the closing parentheses on the previous line do *not* close up to the REG_P (only up to the REGNO_REG_SET_P). I think something like this patch would be necessary: && !REGNO_REG_SET_P (®_has_output_reload, -REGNO (rld[r].in)) +REGNO (rld[r].in))) || (REG_P (rld[r].in_reg) && !REGNO_REG_SET_P (®_has_output_reload, - REGNO (rld[r].in) + REGNO (rld[r].in Honza, do you agree? Paolo
Re: mismatched parentheses in reload1.c
> This patch: > > > r116277 | hubicka | 2006-08-21 02:00:14 +0200 (Mon, 21 Aug 2006) | 6 lines > > PR rtl-optimization/28071 > * reload1.c (reg_has_output_reload): Turn into regset. > (reload_as_needed, forget_old_reloads_1, forget_marked_reloads, > choose_reload_regs, emit_reload_insns): Update to new > reg_has_output_reload. > > > > introduced changes in these lines of code (around line 7390 of reload1.c): > > else if (rld[r].out_reg == 0 >&& rld[r].in != 0 >&& ((REG_P (rld[r].in) > && REGNO (rld[r].in) >= FIRST_PSEUDO_REGISTER > && !REGNO_REG_SET_P (®_has_output_reload, > REGNO (rld[r].in)) >|| (REG_P (rld[r].in_reg) >&& !REGNO_REG_SET_P (®_has_output_reload, > REGNO (rld[r].in) >&& ! reg_set_p (rld[r].reg_rtx, PATTERN (insn))) > > Notice how the OR is aligned with the parentheses, but in fact the > closing parentheses on the previous line do *not* close up to the REG_P > (only up to the REGNO_REG_SET_P). I think something like this patch > would be necessary: > > && !REGNO_REG_SET_P (®_has_output_reload, > -REGNO (rld[r].in)) > +REGNO (rld[r].in))) >|| (REG_P (rld[r].in_reg) >&& !REGNO_REG_SET_P (®_has_output_reload, > - REGNO (rld[r].in) > + REGNO (rld[r].in > > > Honza, do you agree? Yes, thanks for noticing the problem and my apologizes for the screwup. The conditionals are easy to misread :( Honza
Re: dejagnu: timeout?
On Aug 21, 2006, at 12:00 AM, Christian Joensson wrote: I just noticed a slight change in behaviour... on my system, I have edited dejagnu's remote.exp such that it defaults its timeout to 1800 instead of 300. However, on gcc trunk, I see that, for example, in the libstdc++ testsuite log, the timeout is set to 600, while in, e.g., gcc's log file, its 1800, as I expect. Maybe libstdc++ should do timeout = timeout*2 and then use it, or play games with saving/restoring the other value. I'd suggest doing up that type of patch and seeing if it works. If it does, feel free to contribute it. BTW, the usual way to set a timeout would be in a board file, or .dejagnurc.
Re: Incorrect application of loop exit heuristic?
Jan Hubicka <[EMAIL PROTECTED]> wrote on 08/19/2006 07:51:42 PM: > > > > Hi, > > thepatch limiting minimal probability to 2% seems to make sense to me, > > so please submit it for review. It would be nice to have the code to > > compute maximal number of exits from loop too, but if it is really 9, we > > would end up with 1% (it might however make difference elsewhere). > > If you would feed motivated to do so, please just do ;) Otheriwse I will > > add it to my ever growing TODO list. > > Hi, > this patch at least hides the ugly details within some abstraction so we > can eventally go for propagating reliability information across CFG if > we conclude it is important. How does it work for you? > I like your approach, thanks. I've confirmed that the generated code no longer contains the mis-predicted branch hints. Will follow up with results from SPEC run once I get them (hosed things up for myself, so restarting from scratch) :-( -Pat
Re: Darwin -m64 results
On Aug 21, 2006, at 6:34 AM, Jack Howarth wrote: I just wanted to be clear that you believe only the line... + .stabs "i:G(0,3)",32,0,4,0 in that .s file is incorrect I never said that, let me refer you to my previous email for what I said. I did say that it was causing the problem. There is a subtle difference between the two, that when deciding what to fix, is important. and it would be sufficient just to have that suppressed by the gfortran compiler. I never said that either. Or do you believe it should be replaced by something else for "i" as a COMMON block? The reason why you're having a hard time pulling a definitive way of how to fix it out of me is because I don't have a definitive idea, I just don't know. I would have to research it, review the code, check the stabs document, maybe even ask a gdb person about it and then maybe talk to the person that added common support to fortran.
Re: Darwin -m64 results
Trunk bootstrap failure on Linux/x86_64 in reload1.c
Trunk fails to build for me with: /cvs/gcc-svn/trunk/gcc/libgcov.c: In function ‘gcov_exit’: /cvs/gcc-svn/trunk/gcc/libgcov.c:532: internal compiler error: RTL check: expected code 'reg', have 'symbol_ref' in emit_reload_insns, at reload1.c:7397 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[4]: *** [libgcc/./_gcov.o] Error 1 I configured with: /cvs/gcc-svn/trunk/configure --prefix=/opt/gcc/4.2-devel --enable-checking=yes,rtl --enable-threads=posix --enable-clocale=gnu --enable-__cxa_atexit --enable-shared --with-system-zlib x86_64-suse-linux-gnu --enable-languages=c,ada,c++,fortran,java,objc,treelang Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpfXCPJK9FKh.pgp Description: PGP signature
Re: How do I teach GCC about automatic vec_concat and vec_select?
Erich Plondke wrote: As it turns out this is very handy when I'm writing code by hand, but I haven't figured out a good way to teach GCC about it. So my question is: what strategy should I use to teach GCC about this? There are several issues you are asking about here. One of them is general representation of vector operations. Unfortunately, in GCC, the vector RTL representation hasn't been very well specified yet. There are overlapping meanings between operators, and some ambiguous operators. Also, there are very few rtl optimizations on vectors. To a first degree approximation, the rtl optimizers will only see what the middle end generated. So you don't need to worry about all of the possible representation forms. Just pick one and use it. Generate it in an exander, and match it in a pattern, and don't worry about the other forms. Ideally, we would have a canonical form defined for each vector operation. The combiner only accepts canonical form, and emits canonical form, so there is no need to define RTL that matches every possible representation of every arithmetic operation. You only need to match the canonical forms. Unfortunately, we don't have canonical forms for vector operations yet. If we did, then you would only have to worry about matching the canonical form. But since we also lack much RTL vector optimization, this is mostly a moot issue at the moment. Also, we lack C syntax for extracting elements from a vector. It has been suggested that array syntax could be overloaded for this, but at the moment there is no useful syntax unless you define your own built in functions. Since you have to have your own builtins anyways, you just emit RTL of your choice for extracting an element, and no other RTL will be generated than the one you choose. I'd use vec_select myself. One of the other issues you mentioned is register allocation related. Getting pseudo-regs in the right place to avoid movement. Ideally, this should be handled invisibly by the register allocator. There isn't really much you can do to help this. There is the macro MODES_TIEABLE_P which should be defined correctly, but this doesn't guarantee optimal placement. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Trunk bootstrap failure on Linux/x86_64 in reload1.c
On Aug 21, 2006, at 11:59 AM, Andreas Jaeger wrote: Trunk fails to build for me with: Maybe related (from http://gcc.gnu.org/regtest/HEAD/): 2006-08-16T23:25:59Z 2006-08-17T14:40:57Z pass native 116195 2006-08-17T14:43:02Z 2006-08-17T15:38:47Z build native 116224 2006-08-17T17:16:01Z 2006-08-17T18:11:20Z build native 116228 2006-08-17T19:15:58Z 2006-08-17T20:11:18Z build native 116230 2006-08-18T00:30:59Z 2006-08-18T01:26:07Z build native 116236 2006-08-18T06:00:59Z 2006-08-18T06:56:35Z build native 116237 2006-08-18T15:45:57Z 2006-08-18T16:41:20Z build native 116241 2006-08-18T17:30:57Z 2006-08-18T18:26:18Z build native 116247 2006-08-18T19:30:56Z 2006-08-18T20:26:17Z build native 116250 2006-08-18T20:27:22Z 2006-08-18T21:22:55Z build native 116251 2006-08-19T00:30:57Z 2006-08-19T01:26:18Z build native 116256 2006-08-19T15:45:57Z 2006-08-19T16:41:03Z build native 116258 2006-08-19T21:15:56Z 2006-08-19T22:11:06Z build native 116261 2006-08-20T00:30:58Z 2006-08-20T01:26:12Z build native 116267 2006-08-20T06:00:56Z 2006-08-20T06:56:25Z build native 116268 2006-08-20T09:00:58Z 2006-08-20T09:56:06Z build native 116270 2006-08-20T09:57:19Z 2006-08-20T10:52:47Z build native 116271 2006-08-20T16:15:57Z 2006-08-20T17:11:01Z build native 116273 2006-08-20T19:00:56Z 2006-08-20T19:56:36Z build native 116274 2006-08-21T00:00:59Z 2006-08-21T00:56:30Z build native 116276 2006-08-21T00:57:30Z 2006-08-21T01:52:53Z build native 116283 2006-08-21T01:54:02Z 2006-08-21T02:49:56Z build native 116284 2006-08-21T02:51:02Z 2006-08-21T03:47:00Z build native 116285 2006-08-21T10:15:58Z 2006-08-21T11:12:00Z build native 116291 2006-08-21T12:45:58Z 2006-08-21T13:41:59Z build native 116296 2006-08-21T16:15:58Z 2006-08-21T17:12:16Z build native 116300 You should be able to update to 116195 and continue developing there if things don't improve.
Re: Trunk bootstrap failure on Linux/x86_64 in reload1.c
> > On Aug 21, 2006, at 11:59 AM, Andreas Jaeger wrote: > > Trunk fails to build for me with: > > Maybe related (from http://gcc.gnu.org/regtest/HEAD/): > > 2006-08-16T23:25:59Z 2006-08-17T14:40:57Z pass native 116195 > 2006-08-17T14:43:02Z 2006-08-17T15:38:47Z build native 116224 This is unrelated. Mike it is not hard to see they are unrelated. Anyways the Darwin bootstrap failure is PR 28776. The ia64 bootstrap failure with RTL checking turned on does not have a bug report yet. -- Pinski
Re: Trunk bootstrap failure on Linux/x86_64 in reload1.c
On Mon, Aug 21, 2006 at 05:25:09PM -0400, Andrew Pinski wrote: > > > > On Aug 21, 2006, at 11:59 AM, Andreas Jaeger wrote: > > > Trunk fails to build for me with: > > > > Maybe related (from http://gcc.gnu.org/regtest/HEAD/): > > > > 2006-08-16T23:25:59Z 2006-08-17T14:40:57Z pass native 116195 > > 2006-08-17T14:43:02Z 2006-08-17T15:38:47Z build native 116224 > > This is unrelated. Mike it is not hard to see they are unrelated. > Anyways the Darwin bootstrap failure is PR 28776. The ia64 bootstrap > failure with RTL checking turned on does not have a bug report yet. Is that related to http://gcc.gnu.org/ml/gcc/2006-08/msg00377.html H.J.
Re: Trunk bootstrap failure on Linux/x86_64 in reload1.c
> On Mon, Aug 21, 2006 at 05:25:09PM -0400, Andrew Pinski wrote: > > > > > > On Aug 21, 2006, at 11:59 AM, Andreas Jaeger wrote: > > > > Trunk fails to build for me with: > > > > > > Maybe related (from http://gcc.gnu.org/regtest/HEAD/): > > > > > > 2006-08-16T23:25:59Z 2006-08-17T14:40:57Z pass native 116195 > > > 2006-08-17T14:43:02Z 2006-08-17T15:38:47Z build native 116224 > > > > This is unrelated. Mike it is not hard to see they are unrelated. > > Anyways the Darwin bootstrap failure is PR 28776. The ia64 bootstrap > > failure with RTL checking turned on does not have a bug report yet. > > Is that related to > > http://gcc.gnu.org/ml/gcc/2006-08/msg00377.html I have honestly no idea what that typo can cause. I am testing Paolo's patch and will commit it as obvious once it finish. Hopefully the problems will go away then... Honza > > > H.J.
Unnecessary call to mark_temp_addr_taken in calls.c (related to pr25505)?
All - I've been investigating the cause of pr25505, where the amount of stack space being used for a particular C++ function went from <1K to ~20K between gcc 3.3 and 4.0. One of the issues I ran into was that the stack slot allocated to hold the result of a function returning a structure was never being reused (see comment #5 in the PR for a simple example). The code in calls.c that allocates the location for storing the result marks its address as being taken, which prevents it from being reused for other function calls in the same scope: /* For variable-sized objects, we must be called with a target specified. If we were to allocate space on the stack here, we would have no way of knowing when to free it. */ rtx d = assign_temp (TREE_TYPE (exp), 1, 1, 1); mark_temp_addr_taken (d); structure_value_addr = XEXP (d, 0); target = 0; So, my question is: is it really necessary to mark this location as having its address taken? Yes, the address of the slot is passed to a function, however I can't imagine any instances where the function retaining that address after the call would be valid. Stepping through the code with a debugger showed that the location is preserved until after its value is copied out, so I don't believe that the value will ever be overwritten too early. In an effort to help understand whether this call was necessary, I ran the test suite against 4.1 and mainline for both i686-pc-linux-gnu and powerpc-apple-darwin8 (with all default languages enabled), but there were no regressions. I also tried to track down the origins of this code, but the original email discussions were somewhat nebulous. Here is a link to the original patch: http://gcc.gnu.org/ml/gcc-patches/1999-10n/msg00856.html I also investigated where the other calls to mark_temp_addr_taken were removed, which happened here: http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00813.html These appeared to me to be related to a patch that was introduced shortly before which performed alias analysis on MEM locations (IIUC): http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00643.html Before submitting a patch to remove this call, and the resultant dead code, I thought I would see if anyone had some background knowledge as to why this was present, and why I shouldn't remove it. Thanks in advance for any advice. - Josh
Re: unwind, x86, DW_CFA_GNU_args_size
On 18/08/2006, at 6:39 PM, Ian Lance Taylor wrote: Geoffrey Keating <[EMAIL PROTECTED]> writes: On 18/08/2006, at 5:42 PM, Ian Lance Taylor wrote: ... We could change CSA so that when it combines a prologue instruction with a non-prologue instruction it sets a new flag on the instruction, and uses a table on the side to record the original values in the instruction. I guess that would work; but wouldn't it be easier to just have calls.c tell the dwarf output code what the right offset is? Would that actually work correctly when the stack adjustments are combined? Wouldn't we get the wrong number when different stack adjustments were combined? I'm not sure what you mean by 'combined' here. At present, calls.c puts the size of the arguments for that call in each CALL. What we could do is change it to put the size of the total arguments pushed so far in each CALL, even if some of those arguments will be used by a later call. smime.p7s Description: S/MIME cryptographic signature
Re: Unnecessary call to mark_temp_addr_taken in calls.c (related to pr25505)?
> So, my question is: is it really necessary to mark this location as > having its address taken? Yes, the address of the slot is passed to a > function, however I can't imagine any instances where the function > retaining that address after the call would be valid. Your tracing below confirms my recollection that I was the one who added that code. Unfortunately, it came in as a merge from another tree, so it's going to be hard to do the archeology to figure out what it was added for, but the history certainly suggests to me that there *was* some test case when it did have a longer life and that's why it was added. Remember that all this stuff is very sensitive to calling sequences so you may not be able to find it on one or two machines (e.g., try Sparc). I suspect the test case involved something like two calls to the same function (that returns a structure) within the parameter list to a third function. My strong suggestion is to leave this alone. The benefits in terms of increased optimization opportunities is small and the costs if it *does* cause wrong code to be generated is large because we know it'll be an obscure and hard-to-find case.
Re: Unnecessary call to mark_temp_addr_taken in calls.c (related to pr25505)?
Richard Kenner wrote:
>> So, my question is: is it really necessary to mark this location as
>> having its address taken? Yes, the address of the slot is passed to a
>> function, however I can't imagine any instances where the function
>> retaining that address after the call would be valid.
>
> Your tracing below confirms my recollection that I was the one who added that
> code. Unfortunately, it came in as a merge from another tree, so it's going
> to be hard to do the archeology to figure out what it was added for, but the
> history certainly suggests to me that there *was* some test case when it did
> have a longer life and that's why it was added. Remember that all this stuff
> is very sensitive to calling sequences so you may not be able to find it on
> one or two machines (e.g., try Sparc). I suspect the test case involved
> something like two calls to the same function (that returns a structure)
> within the parameter list to a third function.
>
> My strong suggestion is to leave this alone. The benefits in terms of
> increased optimization opportunities is small and the costs if it
> *does* cause wrong code to be generated is large because we know it'll
> be an obscure and hard-to-find case.
Richard -
Thanks for looking at this and the advice. I can understand the concern
about introducing a subtle bug for negligible benefit, although in my
case the benefit is somewhat more meaningful (~6k stack regained on a
single function).
Might you be able to provide any insight as to why you were able to
remove the other calls to mark_temp_addr_taken? Was it indeed because
of improved alias analysis of MEM locations? I wasn't, unfortunately,
able to derive this from the email traffic. Here's the link again, in
case it's helpful:
http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00813.html
I did investigate the case you described, where two function parameters
are calls to the same function returning a structure. The front-end
generates temporaries to handle this, and so the middle-end-generated
temporaries are still restricted to a lifetime of a single statement.
Here's the tree dump:
baz ()
{
struct S D.1105;
struct S D.1104;
:
D.1104 = foo ();
D.1105 = foo ();
bar (D.1104, D.1105) [tail call];
return;
}
Note that we will get 4 instances of struct S generated on the stack:
two for D.110[45], and two more for holding the return values from the
two calls to foo.
Thanks again, and I appreciate any additional context you might be able
to offer.
- Josh
Re: Unnecessary call to mark_temp_addr_taken in calls.c (related to pr25505)?
> Might you be able to provide any insight as to why you were able to > remove the other calls to mark_temp_addr_taken? Was it indeed because > of improved alias analysis of MEM locations? I wasn't, unfortunately, > able to derive this from the email traffic. My *guess*, and it's just that, is that putting them in such central places weren't needed since they were in higher-level places (such as in the cited place in calls.c). But this was *very* long ago. I strongly doubt this had to do with alias analysis issues. > I did investigate the case you described, where two function parameters > are calls to the same function returning a structure. The front-end > generates temporaries to handle this, and so the middle-end-generated > temporaries are still restricted to a lifetime of a single statement. That's C. Have you verified that all the other front ends do this? Is this really the most efficient approach? Etc. Neverthless, it may be that gimplification renders this OBE. If so, then I suspect a that *a lot* of the temporary lifetime tracking code is also no longer needed. But I wouldn't want to jump to any of these conclusions too quickly: this stuff is very complex.
Re: Unnecessary call to mark_temp_addr_taken in calls.c (related to pr25505)?
Richard Kenner wrote: >> I did investigate the case you described, where two function parameters >> are calls to the same function returning a structure. The front-end >> generates temporaries to handle this, and so the middle-end-generated >> temporaries are still restricted to a lifetime of a single statement. > Neverthless, it may be that gimplification renders this OBE. If so, > then I suspect a that *a lot* of the temporary lifetime tracking code is > also no longer needed. But I wouldn't want to jump to any of these > conclusions too quickly: this stuff is very complex. OK, thanks. If you have any suggestions on other approaches to verifying this, I'd certainly appreciate it. - Josh
Re: Darwin -m64 results
Mike, Actually, while building tonight's svn pull, I noticed that the linker warnings have actually been present during the linkage of libgfortran.dylib for the -m64 part of the multilib build... /bin/sh ./libtool --mode=link /sw/src/fink.build/gcc4-4.1.999-20060821/darwin_objdir/./gcc/gfortran -B/sw/src/fink.build/gcc4-4.1.999-20060821/darwin_objdir/./gcc/ -B/sw/lib/gcc4/powerpc-apple-darwin8/bin/ -B/sw/lib/gcc4/powerpc-apple-darwin8/lib/ -isystem /sw/lib/gcc4/powerpc-apple-darwin8/include -isystem /sw/lib/gcc4/powerpc-apple-darwin8/sys-include -m64 -I . -Wall -fno-repack-arrays -fno-underscoring -g -O2 -m64 -m64 -o libgfortran.la -rpath /sw/lib/gcc4/lib/ppc64 -version-info `grep -v '^#' ../../../../gcc-4.2-20060821/libgfortran/libtool-version` -lm -Wl,-single_module compile_options.lo environ.lo error.lo fpu.lo main.lo memory.lo pause.lo stop.lo string.lo select.lo all_l4.lo all_l8.lo all_l16.lo any_l4.lo any_l8.lo any_l16.lo count_4_l4.lo count_8_l4.lo count_16_l4.lo count_4_l8.lo count_8_l8.lo count_16_l8.lo count_4_l16.lo count_8_l16.lo count_16_l16.lo maxloc0_4_i4.lo maxloc0_8_i4.lo maxloc0_16_i4.lo maxloc0_4_i8.lo maxloc0_8_i8.lo maxloc0_16_i8.lo maxloc0_4_i 16.lo maxloc0_8_i16.lo maxloc0_16_i16.lo maxloc0_4_r4.lo maxloc0_8_r4.lo maxloc0_16_r4.lo maxloc0_4_r8.lo maxloc0_8_r8.lo maxloc0_16_r8.lo maxloc0_4_r10.lo maxloc0_8_r10.lo maxloc0_16_r10.lo maxloc0_4_r16.lo maxloc0_8_r16.lo maxloc0_16_r16.lo maxloc1_4_i4.lo maxloc1_8_i4.lo maxloc1_16_i4.lo maxloc1_4_i8.lo maxloc1_8_i8.lo maxloc1_16_i8.lo maxloc1_4_i16.lo maxloc1_8_i16.lo maxloc1_16_i16.lo maxloc1_4_r4.lo maxloc1_8_r4.lo maxloc1_16_r4.lo maxloc1_4_r8.lo maxloc1_8_r8.lo maxloc1_16_r8.lo maxloc1_4_r10.lo maxloc1_8_r10.lo maxloc1_16_r10.lo maxloc1_4_r16.lo maxloc1_8_r16.lo maxloc1_16_r16.lo maxval_i4.lo maxval_i8.lo maxval_i16.lo maxval_r4.lo maxval_r8.lo maxval_r10.lo maxval_r16.lo minloc0_4_i4.lo minloc0_8_i4.lo minloc0_16_i4.lo minloc0_4_i8.lo minloc0_8_i8.lo minloc0_16_i8.lo minloc0_4_i16.lo minloc0_8_i16.lo minloc0_16_i16.lo minloc0_4_r4.lo minloc0_8_r4.lo minloc0_16_r4.lo minloc0_4_r8.lo minloc0_8_r8.lo minloc0_16_r8.lo minloc0_4_r10.lo minloc0_8_r10.lo minloc0_16_r10.lo minloc0_4_r16.lo minloc0_8_r16.lo minloc0_16_r16.lo minloc1_4_i4.lo minloc1_8_i4.lo minloc1_16_i4.lo minloc1_4_i8.lo minloc1_8_i8.lo minloc1_16_i8.lo minloc1_4_i16.lo minloc1_8_i16.lo minloc1_16_i16.lo minloc1_4_r4.lo minloc1_8_r4.lo minloc1_16_r4.lo minloc1_4_r8.lo minloc1_8_r8.lo minloc1_16_r8.lo minloc1_4_r10.lo minloc1_8_r10.lo minloc1_16_r10.lo minloc1_4_r16.lo minloc1_8_r16.lo minloc1_16_r16.lo minval_i4.lo minval_i8.lo minval_i16.lo minval_r4.lo minval_r8.lo minval_r10.lo minval_r16.lo product_i4.lo product_i8.lo product_i16.lo product_r4.lo product_r8.lo product_r10.lo product_r16.lo product_c4.lo product_c8.lo product_c10.lo product_c16.lo sum_i4.lo sum_i8.lo sum_i16.lo sum_r4.lo sum_r8.lo sum_r10.lo sum_r16.lo sum_c4.lo sum_c8.lo sum_c10.lo sum_c16.lo matmul_i4.lo matmul_i8.lo matmul_i16.lo matmul_r4.lo matmul_r8.lo matmul_r10.lo matmul_r16.lo matmul_c4.lo matmul_c8.lo matmul_c10.lo matmul_c16.lo matmul_l4.lo matmul_l8.lo matmul_l16.lo transpose_i4.lo transpose_i8. lo transpose_i16.lo transpose_r4.lo transpose_r8.lo transpose_r10.lo transpose_r16.lo transpose_c4.lo transpose_c8.lo transpose_c10.lo transpose_c16.lo shape_i4.lo shape_i8.lo shape_i16.lo eoshift1_4.lo eoshift1_8.lo eoshift1_16.lo eoshift3_4.lo eoshift3_8.lo eoshift3_16.lo cshift1_4.lo cshift1_8.lo cshift1_16.lo reshape_i4.lo reshape_i8.lo reshape_i16.lo reshape_r4.lo reshape_r8.lo reshape_r10.lo reshape_r16.lo reshape_c4.lo reshape_c8.lo reshape_c10.lo reshape_c16.lo in_pack_i4.lo in_pack_i8.lo in_pack_i16.lo in_pack_c4.lo in_pack_c8.lo in_pack_c10.lo in_pack_c16.lo in_unpack_i4.lo in_unpack_i8.lo in_unpack_i16.lo in_unpack_c4.lo in_unpack_c8.lo in_unpack_c10.lo in_unpack_c16.lo exponent_r4.lo exponent_r8.lo exponent_r10.lo exponent_r16.lo fraction_r4.lo fraction_r8.lo fraction_r10.lo fraction_r16.lo nearest_r4.lo nearest_r8.lo nearest_r10.lo nearest_r16.lo set_exponent_r4.lo set_exponent_r8.lo set_exponent_r10.lo set_exponent_r16.lo pow_i4_i4.lo pow_i8_i4.lo pow_i16_i4.lo pow_r4_i4.lo pow_r8_i4.lo pow_r10_i4.lo pow_r16_i4.lo pow_c4_i4.lo pow_c8_i4.lo pow_c10_i4.lo pow_c16_i4.lo pow_i4_i8.lo pow_i8_i8.lo pow /sw/src/fink.build/gcc4-4.1.999-20060821/darwin_objdir/./gcc/xgcc -B/sw/src/fink.build/gcc4-4.1.999-20060821/darwin_objdir/./gcc/ -B/sw/lib/gcc4/powerpc-apple-darwin8/bin/ -B/sw/lib/gcc4/powerpc-apple-darwin8/lib/ -isystem /sw/lib/gcc4/powerpc-apple-darwin8/include -isystem /sw/lib/gcc4/powerpc-apple-darwin8/sys-include -m64 -dynamiclib -undefined dynamic_lookup -o .libs/libgfortran.2.0.0.dylib .libs/compile_options.o .libs/environ.o .libs/error.o .libs/fpu.o .libs/main.o .libs/memory.o .libs/pause.o .libs/stop.o .libs/string.o .libs/select.o .libs/all_l4.o .libs/all_l8.o .libs/all_l16.o .libs/any_l4.o
