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/
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 s
> 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
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.
>
>
> 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
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,
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 nev
> 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
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
>
>
> 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 unrel
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-1
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
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
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.
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
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
> 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_neede
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_r
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
@@ -1
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 a
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
--
---
Di
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 p
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 t
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 1
25 matches
Mail list logo
