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
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
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 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
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 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
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
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
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.,