Hi,
Out of the expand I get the following pattern:
(set (reg:SI 203)
(subreg:SI (mem/c:DI (plus:SI (reg/f:SI 147 virtual-stack-vars)
(const_int -320 [0xfec0])) [4 buf1.state+0 S8
A32]) 4))
which it looks too complex to be handled by the VREGS pass. I.e.,
To close the loop on this thread, although there was mild support
for both of these conventions there were also objections to both,
including a suggestion for an alternative to the "/*foo_p=*/" style
that would be preferred by most people who responded.
With that I don't have the sense that there
Sorry for the noise, I've remember I had a similar issue in the past.
Thanks,
Claudiu
On Tue, Oct 11, 2016 at 4:48 PM, Claudiu Zissulescu
wrote:
> Hi,
>
> Out of the expand I get the following pattern:
>
> (set (reg:SI 203)
> (subreg:SI (mem/c:DI (plus:SI (reg/f:SI 147 virtual-stack-var
On 10/11/2016 08:48 AM, Claudiu Zissulescu wrote:
Hi,
Out of the expand I get the following pattern:
(set (reg:SI 203)
(subreg:SI (mem/c:DI (plus:SI (reg/f:SI 147 virtual-stack-vars)
(const_int -320 [0xfec0])) [4 buf1.state+0 S8
A32]) 4))
which it look
Hi Jeff,
> IIRC you're not supposed to have (subreg (mem)) expressions at this point.
>
> Any (subreg (mem)) at this point can be trivially turned into a simple
> memory load.
>
The issue is that the mode_dependent_address_p hook returns true, thus the
simplify_subreg() will not simplify the su
On Tue, Oct 11, 2016 at 10:54 AM, Martin Sebor wrote:
> To close the loop on this thread, although there was mild support
> for both of these conventions there were also objections to both,
> including a suggestion for an alternative to the "/*foo_p=*/" style
> that would be preferred by most peop
There was a breakage in Fortran that has now been fixed.
In case anyone runs into it. Resolved by:
M gcc/fortran/ChangeLog
M gcc/fortran/iresolve.c
M gcc/fortran/simplify.c
r241000 = 7b8ebc39f2db57dcadd8b8f22b6b7561d187c279 (refs/remotes/svn/trunk)
Rela
On 10/11/2016 11:24 AM, Jason Merrill wrote:
On Tue, Oct 11, 2016 at 10:54 AM, Martin Sebor wrote:
To close the loop on this thread, although there was mild support
for both of these conventions there were also objections to both,
including a suggestion for an alternative to the "/*foo_p=*/" st
Snapshot gcc-5-20161011 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20161011/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
