On Wed, Jun 15, 2016 at 7:06 AM, Bernd Schmidt wrote:
>
>
> On 06/15/2016 04:03 PM, Alan Modra wrote:
>>
>> On Wed, Jun 15, 2016 at 11:49:50AM +0200, Bernd Schmidt wrote:
>>>
>>> On 06/15/2016 03:30 AM, Alan Modra wrote:
Between these two calls to
On 06/15/2016 04:03 PM, Alan Modra wrote:
On Wed, Jun 15, 2016 at 11:49:50AM +0200, Bernd Schmidt wrote:
On 06/15/2016 03:30 AM, Alan Modra wrote:
Between these two calls to _gfortran_string_verify,
if (verify(c4, "A", back = .true.) .ne. 3) call abort
if (verify(c4, "AB") .ne. 0) call
On Wed, Jun 15, 2016 at 11:49:50AM +0200, Bernd Schmidt wrote:
> On 06/15/2016 03:30 AM, Alan Modra wrote:
> >Between these two calls to _gfortran_string_verify,
> > if (verify(c4, "A", back = .true.) .ne. 3) call abort
> > if (verify(c4, "AB") .ne. 0) call abort
> >it seems that gfortran is
On Wed, Jun 15, 2016 at 2:49 AM, Bernd Schmidt wrote:
> On 06/15/2016 03:30 AM, Alan Modra wrote:
>>
>> Between these two calls to _gfortran_string_verify,
>> if (verify(c4, "A", back = .true.) .ne. 3) call abort
>> if (verify(c4, "AB") .ne. 0) call abort
>> it seems that
On 06/15/2016 03:30 AM, Alan Modra wrote:
Between these two calls to _gfortran_string_verify,
if (verify(c4, "A", back = .true.) .ne. 3) call abort
if (verify(c4, "AB") .ne. 0) call abort
it seems that gfortran is assuming that parameters passed on the stack
are unchanged.
How? Is this
On Wed, Jun 15, 2016 at 11:00:22AM +0930, Alan Modra wrote:
> On Tue, Jun 14, 2016 at 09:26:19AM -0700, H.J. Lu wrote:
> > On Thu, May 26, 2016 at 4:02 AM, Alan Modra wrote:
> > > This fixes lack of bb_loop_depth info in some of the early parts of
> > > ira, which has been the
On Tue, Jun 14, 2016 at 09:26:19AM -0700, H.J. Lu wrote:
> On Thu, May 26, 2016 at 4:02 AM, Alan Modra wrote:
> > This fixes lack of bb_loop_depth info in some of the early parts of
> > ira, which has been the case for quite some time. All active branches
> > return 0 from
On Thu, May 26, 2016 at 4:02 AM, Alan Modra wrote:
> This fixes lack of bb_loop_depth info in some of the early parts of
> ira, which has been the case for quite some time. All active branches
> return 0 from bb_loop_depth() in update_equiv_regs, but whether that
> actually
On Thu, May 26, 2016 at 11:04:41PM -0400, Vladimir Makarov wrote:
> On 05/26/2016 10:14 PM, Alan Modra wrote:
> >On Thu, May 26, 2016 at 10:12:14AM -0400, Vladimir Makarov wrote:
> >>On 05/26/2016 07:02 AM, Alan Modra wrote:
> >>>This fixes lack of bb_loop_depth info in some of the early parts of
On 05/26/2016 10:14 PM, Alan Modra wrote:
On Thu, May 26, 2016 at 10:12:14AM -0400, Vladimir Makarov wrote:
On 05/26/2016 07:02 AM, Alan Modra wrote:
This fixes lack of bb_loop_depth info in some of the early parts of
ira, which has been the case for quite some time. All active branches
On Thu, May 26, 2016 at 10:12:14AM -0400, Vladimir Makarov wrote:
> On 05/26/2016 07:02 AM, Alan Modra wrote:
> >This fixes lack of bb_loop_depth info in some of the early parts of
> >ira, which has been the case for quite some time. All active branches
> >return 0 from bb_loop_depth() in
On 05/26/2016 07:02 AM, Alan Modra wrote:
This fixes lack of bb_loop_depth info in some of the early parts of
ira, which has been the case for quite some time. All active branches
return 0 from bb_loop_depth() in update_equiv_regs, but whether that
actually causes mis-optimization anywhere but
This fixes lack of bb_loop_depth info in some of the early parts of
ira, which has been the case for quite some time. All active branches
return 0 from bb_loop_depth() in update_equiv_regs, but whether that
actually causes mis-optimization anywhere but trunk is yet to be
determined.
I played a
13 matches
Mail list logo