On May 25, 2018 9:25:51 PM GMT+02:00, Jeff Law wrote:
>On 05/25/2018 11:54 AM, Richard Biener wrote:
>> On May 25, 2018 6:57:13 PM GMT+02:00, Jeff Law
>wrote:
>>> On 05/25/2018 03:49 AM, Bin.Cheng wrote:
On Fri, May 25, 2018 at 10:23 AM, Prathamesh Kulkarni
wrote:
> On 23 May 2018
Snapshot gcc-8-20180525 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/8-20180525/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8
On Fri, May 25, 2018 at 3:35 PM, Steve Ellcey wrote:
> I was curious if there was any reason that REG_ALLOC_ORDER is not
> defined for Aarch64. Has anyone tried this to see if it could help
> performance? It is defined for many other platforms.
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg0181
I was curious if there was any reason that REG_ALLOC_ORDER is not
defined for Aarch64. Has anyone tried this to see if it could help
performance? It is defined for many other platforms.
Steve Ellcey
sell...@cavium.com
On Fri, May 25, 2018 at 08:11:43AM +0200, Eric Botcazou wrote:
> > Is this something the back end is responsible for getting right, for example
> > via the machine description file? If so, any hints where to start?
>
> The SUBREG of MEM is invalid at this stage.
>From rtl.texi:
---
There are cu
A fix for 84851 - missing -Wclass-memaccess for a memcpy in a copy
ctor with a non-trivial member was implemented but disabled for GCC
8 but because it was late, with the expectation we would enable it
for GCC 9. The attached removes the code that guards the full fix
to enable it.
Martin
PR c++
On 05/25/2018 11:54 AM, Richard Biener wrote:
> On May 25, 2018 6:57:13 PM GMT+02:00, Jeff Law wrote:
>> On 05/25/2018 03:49 AM, Bin.Cheng wrote:
>>> On Fri, May 25, 2018 at 10:23 AM, Prathamesh Kulkarni
>>> wrote:
On 23 May 2018 at 18:37, Jeff Law wrote:
> On 05/23/2018 03:20 AM, Prath
One of my testsuite failures for the pdp11 back end is
gcc.c-torture/compile/930326-1.c which is:
struct
{
char a, b, f[3];
} s;
long i = s.f-&s.b;
It fails with "error: initializer element is not computable at load time".
I don't understand why because it seems to be a perfectly reasonable
On May 25, 2018 6:57:13 PM GMT+02:00, Jeff Law wrote:
>On 05/25/2018 03:49 AM, Bin.Cheng wrote:
>> On Fri, May 25, 2018 at 10:23 AM, Prathamesh Kulkarni
>> wrote:
>>> On 23 May 2018 at 18:37, Jeff Law wrote:
On 05/23/2018 03:20 AM, Prathamesh Kulkarni wrote:
> On 23 May 2018 at 13:58, R
On 05/25/2018 03:49 AM, Bin.Cheng wrote:
> On Fri, May 25, 2018 at 10:23 AM, Prathamesh Kulkarni
> wrote:
>> On 23 May 2018 at 18:37, Jeff Law wrote:
>>> On 05/23/2018 03:20 AM, Prathamesh Kulkarni wrote:
On 23 May 2018 at 13:58, Richard Biener wrote:
> On Wed, 23 May 2018, Prathamesh K
On Fri, 25 May 2018, Bin.Cheng wrote:
> On Fri, May 25, 2018 at 10:23 AM, Prathamesh Kulkarni
> wrote:
> > On 23 May 2018 at 18:37, Jeff Law wrote:
> >> On 05/23/2018 03:20 AM, Prathamesh Kulkarni wrote:
> >>> On 23 May 2018 at 13:58, Richard Biener wrote:
> On Wed, 23 May 2018, Prathamesh
On Fri, May 25, 2018 at 10:23 AM, Prathamesh Kulkarni
wrote:
> On 23 May 2018 at 18:37, Jeff Law wrote:
>> On 05/23/2018 03:20 AM, Prathamesh Kulkarni wrote:
>>> On 23 May 2018 at 13:58, Richard Biener wrote:
On Wed, 23 May 2018, Prathamesh Kulkarni wrote:
> Hi,
> I am trying t
On 23 May 2018 at 18:37, Jeff Law wrote:
> On 05/23/2018 03:20 AM, Prathamesh Kulkarni wrote:
>> On 23 May 2018 at 13:58, Richard Biener wrote:
>>> On Wed, 23 May 2018, Prathamesh Kulkarni wrote:
>>>
Hi,
I am trying to work on PR80155, which exposes a problem with code
hoisting and
13 matches
Mail list logo
