> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Jiangning Liu
> Sent: Tuesday, February 28, 2012 11:19 AM
> To: 'William J. Schmidt'
> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> Subject: RE: A question about redundant PHI expression stmt
>
> -Original Message-
> From: Jiangning Liu
> Sent: Tuesday, February 28, 2012 4:07 PM
> To: Jiangning Liu; 'William J. Schmidt'
> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
> Subject: RE: A question about redundant PHI expression stmt
>
>
>
> > -Original Message-
> > From: gcc-o
On Tue, Feb 28, 2012 at 9:33 AM, Jiangning Liu wrote:
>
>
>> -Original Message-
>> From: Jiangning Liu
>> Sent: Tuesday, February 28, 2012 4:07 PM
>> To: Jiangning Liu; 'William J. Schmidt'
>> Cc: gcc@gcc.gnu.org; wschm...@gcc.gnu.org
>> Subject: RE: A question about redundant PHI expressi
Richard Guenther wrote:
> On Mon, Feb 20, 2012 at 11:19 PM, Ulrich Weigand wrote:
> > we've noticed that the loop optimizer sometimes inserts weirdly
> > inefficient code to compute the value of an induction variable
> > at the end of the loop.
[snip]
> The issue is that (start + 1) + 1 * (int) .
On Tue, Feb 28, 2012 at 4:10 PM, Ulrich Weigand wrote:
> Richard Guenther wrote:
>> On Mon, Feb 20, 2012 at 11:19 PM, Ulrich Weigand wrote:
>> > we've noticed that the loop optimizer sometimes inserts weirdly
>> > inefficient code to compute the value of an induction variable
>> > at the end of t
On 02/27/2012 10:33 PM, Daniel Jacobowitz wrote:
Sorry for being late to the party.
On Wed, Feb 15, 2012 at 9:55 AM, Ian Lance Taylor wrote:
Ouch, I did not know that the EABI left this open. That seems like a
bug, because it prevents code from being interoperable. This is
precisely the kind
On Tue, 2012-02-28 at 11:21 +0100, Richard Guenther wrote:
> On Tue, Feb 28, 2012 at 9:33 AM, Jiangning Liu wrote:
> >
> >
> >> -Original Message-
> >> From: Jiangning Liu
> >> Sent: Tuesday, February 28, 2012 4:07 PM
> >> To: Jiangning Liu; 'William J. Schmidt'
> >> Cc: gcc@gcc.gnu.org; w
On Tue, 2012-02-28 at 11:03 -0600, William J. Schmidt wrote:
> I think this is probably a problem with how cprop_into_successor_phis
> works. It only propagates into immediate successors of a block. In
> this case copies are propagated from bb12 into phis in bb13 and bb14 (of
> which there are n
"Jay Freeman (saurik)" writes:
> As demonstrated by these snippets, __morestack_segments is a pointer
> to a stack_segment; it is being stored in the context as a void *, but
> is being removed from the context and being passed directly to
> __morestack_release_segments, which in turn expects a p
On Tue, 2012-02-28 at 11:52 -0600, William J. Schmidt wrote:
> On Tue, 2012-02-28 at 11:03 -0600, William J. Schmidt wrote:
>
> > I think this is probably a problem with how cprop_into_successor_phis
> > works. It only propagates into immediate successors of a block. In
> > this case copies ar
> > "Jay Freeman (saurik)"
> "Ian Lance Taylor"
> Thanks for the bug report and the analysis. I think it does simply
> require an '&'. That makes it analogous to the way
> __morestack_release_segments is used in generic-morestack-thread.c.
The only reason I hesitated on that is that it might
Snapshot gcc-4.4-20120228 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20120228/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
12 matches
Mail list logo
