On Mon, Nov 12, 2018 at 11:54:37AM +, Sam Tebbs wrote:
> On 11/08/2018 08:34 PM, Segher Boessenkool wrote:
>
> > On Thu, Nov 08, 2018 at 03:44:44PM +, Sam Tebbs wrote:
> >> Does your patch fix the incorrect generation of "scvtf s1, s1"? I was
> >> looking at the issue as well and don't wan
On 11/08/2018 08:34 PM, Segher Boessenkool wrote:
> On Thu, Nov 08, 2018 at 03:44:44PM +, Sam Tebbs wrote:
>> Does your patch fix the incorrect generation of "scvtf s1, s1"? I was
>> looking at the issue as well and don't want to do any overlapping work.
> I don't know. Well, there are no in
On 11/9/18 9:50 PM, Segher Boessenkool wrote:
> On Fri, Nov 09, 2018 at 02:12:22PM -0700, Jeff Law wrote:
>> On 11/8/18 1:34 PM, Segher Boessenkool wrote:
>>> On Thu, Nov 08, 2018 at 03:44:44PM +, Sam Tebbs wrote:
Does your patch fix the incorrect generation of "scvtf s1, s1"? I was
l
On Fri, Nov 09, 2018 at 02:12:22PM -0700, Jeff Law wrote:
> On 11/8/18 1:34 PM, Segher Boessenkool wrote:
> > On Thu, Nov 08, 2018 at 03:44:44PM +, Sam Tebbs wrote:
> >> Does your patch fix the incorrect generation of "scvtf s1, s1"? I was
> >> looking at the issue as well and don't want to do
On 11/8/18 1:34 PM, Segher Boessenkool wrote:
> On Thu, Nov 08, 2018 at 03:44:44PM +, Sam Tebbs wrote:
>> Does your patch fix the incorrect generation of "scvtf s1, s1"? I was
>> looking at the issue as well and don't want to do any overlapping work.
>
> I don't know. Well, there are no incor
On 07/11/2018 23:02, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Nov 05, 2018 at 06:16:16PM +, Renlin Li wrote:
>> Sorry, this is not correct. Instructions scheduled between x and x+1
>> directly use hard register r1.
>> It is not IRA/LRA assigning r1 to the operands.
>>
>>
>> To reproduce th
On Thu, Nov 08, 2018 at 03:44:44PM +, Sam Tebbs wrote:
> Does your patch fix the incorrect generation of "scvtf s1, s1"? I was
> looking at the issue as well and don't want to do any overlapping work.
I don't know. Well, there are no incorrect code issues I know of at all
now; but you mean th
Hi!
On Mon, Nov 05, 2018 at 06:16:16PM +, Renlin Li wrote:
> Sorry, this is not correct. Instructions scheduled between x and x+1
> directly use hard register r1.
> It is not IRA/LRA assigning r1 to the operands.
>
>
> To reproduce this particular case, you could use:
> cc1 -O3 -marm -marc
Hi!
On Mon, Nov 05, 2018 at 12:35:24PM +, Renlin Li wrote:
> >>--- a/gcc/combine.c
> >>+++ b/gcc/combine.c
> >>@@ -14998,6 +14998,8 @@ make_more_copies (void)
> >>continue;
> >> if (TEST_HARD_REG_BIT (fixed_reg_set, REGNO (src)))
> >>continue;
> >>+ if (REG_P (dest) &&
On 11/05/2018 12:35 PM, Renlin Li wrote:
Hi Segher,
On 11/03/2018 02:34 AM, Jeff Law wrote:
On 11/2/18 5:54 PM, Segher Boessenkool wrote:
On Fri, Nov 02, 2018 at 06:03:20PM -0500, Segher Boessenkool wrote:
The original rtx is generated by expand_builtin_setjmp_receiver to adjust
the frame
Hi Segher,
On 11/03/2018 02:34 AM, Jeff Law wrote:
On 11/2/18 5:54 PM, Segher Boessenkool wrote:
On Fri, Nov 02, 2018 at 06:03:20PM -0500, Segher Boessenkool wrote:
The original rtx is generated by expand_builtin_setjmp_receiver to adjust
the frame pointer.
And later in LRA, it will try to el
On 11/2/18 5:54 PM, Segher Boessenkool wrote:
> On Fri, Nov 02, 2018 at 06:03:20PM -0500, Segher Boessenkool wrote:
>>> The original rtx is generated by expand_builtin_setjmp_receiver to adjust
>>> the frame pointer.
>>>
>>> And later in LRA, it will try to eliminate frame_pointer with hard frame
On Fri, Nov 02, 2018 at 06:03:20PM -0500, Segher Boessenkool wrote:
> > The original rtx is generated by expand_builtin_setjmp_receiver to adjust
> > the frame pointer.
> >
> > And later in LRA, it will try to eliminate frame_pointer with hard frame
> > pointer which is
> > defined the ELIMINABL
Hi!
On Fri, Nov 02, 2018 at 10:19:01PM +, Renlin Li wrote:
> I find a problem with your change to add make_more_copies.
> I am investigating those regressions, a big amount of them are wrong code
> generation.
>
> One problem is that, make_more_copies will split the assignment of fp to
> sf
Hi Segher,
I find a problem with your change to add make_more_copies.
I am investigating those regressions, a big amount of them are wrong code
generation.
One problem is that, make_more_copies will split the assignment of fp to sfp.
From:
(insn 48 26 28 5 (set (reg/f:SI 102 sfp)
(reg/
On Fri, Oct 26, 2018 at 04:39:06PM +, Steve Ellcey wrote:
> What is the status of this patch? I see PR 87708, which is for the
> regression to ira-shrinkwrap-prep-[12].c but what about all the
> other regressions? I see 27 of them on my aarch64 build and when
> I looked at one of them (gcc.ta
What is the status of this patch? I see PR 87708, which is for the
regression to ira-shrinkwrap-prep-[12].c but what about all the
other regressions? I see 27 of them on my aarch64 build and when
I looked at one of them (gcc.target/aarch64/cvtf_1.c) the code looks
worse than before, generating an
It's the test case that is miscompiled.
$ cat nested_struct.c
#include
typedef struct cls_struct_16byte1 {
double a;
float b;
int c;
} cls_struct_16byte1;
typedef struct cls_struct_16byte2 {
int ii;
double dd;
float ff;
} cls_struct_16byte2;
typedef struct cls_struct_combined {
c
On Wed, 24 Oct 2018 at 00:26, Segher Boessenkool
wrote:
>
> Hi Christophe,
>
> On Tue, Oct 23, 2018 at 03:25:55PM +0200, Christophe Lyon wrote:
> > On Tue, 23 Oct 2018 at 14:29, Segher Boessenkool
> > wrote:
> > > On Tue, Oct 23, 2018 at 12:14:27PM +0200, Christophe Lyon wrote:
> > > > I have not
Hi:
>
> I have noticed many regressions on arm and aarch64 between 265366 and
> 265408 (this commit is 265398).
>
There are many regressions on mips64el between 265378 and 265420.
r265378 testresults:
https://gcc.gnu.org/ml/gcc-testresults/2018-10/msg02935.html
r265420 testresults:
https://gcc.gn
Hi Christophe,
On Tue, Oct 23, 2018 at 03:25:55PM +0200, Christophe Lyon wrote:
> On Tue, 23 Oct 2018 at 14:29, Segher Boessenkool
> wrote:
> > On Tue, Oct 23, 2018 at 12:14:27PM +0200, Christophe Lyon wrote:
> > > I have noticed many regressions on arm and aarch64 between 265366 and
> > > 265408
On Tue, Oct 23, 2018 at 05:16:38PM +0200, Andreas Schwab wrote:
> This miscompiles libffi and libgo on ia64.
Ouch. I cannot read ia64 machine code without a lot of handholding...
Any hints what is wrong?
Segher
This miscompiles libffi and libgo on ia64.
The following libffi tests fail:
libffi.call/nested_struct.c -W -Wall -Wno-psabi -O2 -fomit-frame-pointer
execution test
libffi.call/nested_struct.c -W -Wall -Wno-psabi -O2 execution test
libffi.call/nested_struct.c -W -Wall -Wno-psabi -Os execution tes
On Tue, 23 Oct 2018 at 14:29, Segher Boessenkool
wrote:
>
> On Tue, Oct 23, 2018 at 12:14:27PM +0200, Christophe Lyon wrote:
> > I have noticed many regressions on arm and aarch64 between 265366 and
> > 265408 (this commit is 265398).
> >
> > I bisected at least one to this commit on aarch64:
> >
On Tue, 23 Oct 2018 at 14:34, Segher Boessenkool
wrote:
>
> On Tue, Oct 23, 2018 at 02:02:35PM +0200, Christophe Lyon wrote:
> > I also bisected regressions on arm:
> > gcc.c-torture/execute/920428-2.c
> > gfortran.dg/actual_array_substr_2.f90
> > both point to this commit too.
>
> And what are th
On Tue, Oct 23, 2018 at 02:02:35PM +0200, Christophe Lyon wrote:
> I also bisected regressions on arm:
> gcc.c-torture/execute/920428-2.c
> gfortran.dg/actual_array_substr_2.f90
> both point to this commit too.
And what are the errors for those?
Segher
On Tue, Oct 23, 2018 at 12:14:27PM +0200, Christophe Lyon wrote:
> I have noticed many regressions on arm and aarch64 between 265366 and
> 265408 (this commit is 265398).
>
> I bisected at least one to this commit on aarch64:
> FAIL: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump ira "Split
> live-r
On Tue, 23 Oct 2018 at 12:14, Christophe Lyon
wrote:
>
> On Mon, 22 Oct 2018 at 22:17, Segher Boessenkool
> wrote:
> >
> > On most targets every function starts with moves from the parameter
> > passing (hard) registers into pseudos. Similarly, after every call
> > there is a move from the retur
On Mon, 22 Oct 2018 at 22:17, Segher Boessenkool
wrote:
>
> On most targets every function starts with moves from the parameter
> passing (hard) registers into pseudos. Similarly, after every call
> there is a move from the return register into a pseudo. These moves
> usually combine with later
Hi Jeff,
On Mon, Oct 22, 2018 at 02:52:12PM -0600, Jeff Law wrote:
> I know we've gone back and forth on this stuff through the years,
> particularly for targets with likely-to-spilled classes that are used
> for register passing/return values.
Right, there already was code to not copy to a pseud
On 10/22/18 2:17 PM, Segher Boessenkool wrote:
> On most targets every function starts with moves from the parameter
> passing (hard) registers into pseudos. Similarly, after every call
> there is a move from the return register into a pseudo. These moves
> usually combine with later instructions
On most targets every function starts with moves from the parameter
passing (hard) registers into pseudos. Similarly, after every call
there is a move from the return register into a pseudo. These moves
usually combine with later instructions (leaving pretty much the same
instruction, just with a
32 matches
Mail list logo
