https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #107 from Oleg Endo ---
> > The serious one would be
> >
> > Running target sh-sim/-m2/-mb
> > FAIL: gcc.c-torture/execute/20040709-2.c -Os execution test
>
I have tried compiling that test case outside of the testsuite with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #104 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #103)
> I did nothing. Looks simply fragile like as other reload ICEs.
> libstdc++-v3 conftest catches it, (un)fortunately.
Ah, I understand. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61930
--- Comment #1 from Oleg Endo ---
I think this is related to PR 29969.
In some cases it might make sense to do mem copy like insns either in SImode
(if displacement addressing is better) or in SFmode (to reduce GP reg
pressure). This is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #109 from Oleg Endo ---
(In reply to Oleg Endo from comment #108)
>
> It seems I should really fix PR 67061, which
> looks like the same issue (and the other issue with sh_find_set_of_reg which
> was fixed with a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67061
--- Comment #5 from Oleg Endo ---
Created attachment 36331
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36331=edit
Proposed patch
The issue with the function 'sh_find_set_of_reg' has also popped up when
enabling LRA by default on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67061
--- Comment #6 from Oleg Endo ---
(In reply to Oleg Endo from comment #5)
> Created attachment 36331 [details]
> Proposed patch
>
> The issue with the function 'sh_find_set_of_reg' has also popped up when
> enabling LRA by default on trunk (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #102 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #101)
>
> I've forgotten that some atomic builtins fail with spill_failure
> in class 'R0_REGS' for old RA. So libstdc++-v3 was configured
> so to undefine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #97 from Oleg Endo ---
(In reply to Oleg Endo from comment #96)
>
> I haven't tried yet. I will do a full toolchain rebuild and test with -mlra
> enabled by default.
I've compared the results of r227512 without LRA and r227682
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506
--- Comment #10 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #9)
>
> Thanks for the quick bug fix! Matthias already uploaded a new gcc-5 snapshot
> today which contains the fix :).
I guess it will take a while until
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517
--- Comment #7 from Oleg Endo ---
(In reply to ktkachov from comment #6)
> Huh, I wasn't aware of this BZ.
> This looks eerily similar to what I think is the root cause of PR 67481,
> which I'm working on now.
>
> After I'm done with PR 67481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59478
--- Comment #1 from Oleg Endo ---
(In reply to Oleg Endo from comment #0)
> This happens at least on SH with trunk rev 205905 (4.9).
> I'm not sure whether these are target specific or not.
>
> Accessing float values as integers can be done in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #96 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #95)
>
> I think that it's OK to make LRA default on trunk, even if it's
> better with your R0 pre-allocating pass.
The R0 pre-alloc pass could be a further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517
Oleg Endo changed:
What|Removed |Added
CC||kyrylo.tkachov at arm dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #94 from Oleg Endo ---
Kaz, do you think we can enable LRA by default for GCC 6?
Some early results from the AMS optimization show new R0 spill failures. For
example, AMS uses @(R0,Rn) address modes more often. Although I still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #99 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #98)
> I guess that these pr64661-x.c regressions are not so problem, though.
I agree.
> I'm not sure whether hiconst.c regression is serious or not.
I think we can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506
--- Comment #6 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #5)
> (In reply to Oleg Endo from comment #4)
> > Could you please test it?
>
> It fixes all test cases for the cross trunk sh4-unknown-linux-gnu compiler.
> There is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506
--- Comment #8 from Oleg Endo ---
Author: olegendo
Date: Thu Sep 10 15:07:02 2015
New Revision: 227647
URL: https://gcc.gnu.org/viewcvs?rev=227647=gcc=rev
Log:
gcc/
Backport from mainline
2015-09-10 Oleg Endo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506
--- Comment #7 from Oleg Endo ---
Author: olegendo
Date: Thu Sep 10 14:53:48 2015
New Revision: 227646
URL: https://gcc.gnu.org/viewcvs?rev=227646=gcc=rev
Log:
gcc/
PR target/67506
* config/sh/sh.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53987
--- Comment #13 from Oleg Endo ---
attachment 36309 of PR 67506 is another example. It contains the following
code sequence:
mov.b @r2,r0 <<
extu.b r0,r0<<
tst #128,r0
bt/s.L11
extu.w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506
--- Comment #3 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #2)
> Created attachment 36309 [details]
> reduced test case
>
> [...]
>
> Oleg, could you please look at this?
Thanks for reducing it. I will have a look.
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
The following should be verified.
Currently there is no problem because nothing in GCC understands or uses the
exact T reg values. However
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65250
--- Comment #1 from Oleg Endo ---
The patch attachment 36012 for PR 54236 improves the treg_set_expr machinery by
doing proper comparison inversion, instead of trying only EQ <-> NE. This will
be the prerequisite to match a
(set (reg:SI 168)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312
--- Comment #17 from Oleg Endo ---
Adrian, the recent GCC 5 build/bootstrap on SH included D, didn't it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312
--- Comment #19 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #18)
> (In reply to Oleg Endo from comment #17)
> > Adrian, the recent GCC 5 build/bootstrap on SH included D, didn't it?
>
> If you mean that gdc is built
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312
--- Comment #20 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #12)
> Created attachment 36224 [details]
> Stage 3 compiled version of ctfeexpr.dmd.o (unstripped)
(In reply to John Paul Adrian Glaubitz from comment #11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
--- Comment #14 from Oleg Endo ---
(In reply to Oleg Endo from comment #13)
>
> I think it would be easier to leave DOUBLE_TYPE_SIZE == 64 in all cases and
> use software fp if the hardware can't do double precision. If users insist
> on
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Looking through bzip2 compress.c of the CSiBE set, I've spotted sequences such
as:
mov r15,r4
add #64,r4
mov.l @(44,r4),r2
mov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67126
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002
--- Comment #26 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to John Paul Adrian Glaubitz from comment #25)
Ok, this seems to have been fixed:
Although this PR could be marked as fixed, I'd like to keep it open. It will
remind me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #40 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Rich Felker from comment #39)
Oleg, do you have rights under your copyright assignment agreement to
dual-license the libgcc part of the patch under GPLv2 so it could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58219
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
The same applies to FP loads/stores, as this example shows:
float*
test_func_00 (float* p, float* x)
{
float r = 0;
r += *p++;
r += *p++;
*x = r;
return p;
}
fmov.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #42 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #41)
On the other hand, there are quite a few archs (more modern ones
mostly) where the Linux kernel uses the real libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65151
--- Comment #14 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Thomas Petazzoni from comment #11)
(In reply to Jakub Jelinek from comment #10)
GCC 4.9.3 has been released.
This problem still occurs with GCC 4.9.3, as far as I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002
--- Comment #22 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #21)
Yes, it works. I'm uncomfortable with it because the current use of
crtl-emit.x_cur_insn_uid aka cur_insn_uid is limitted to emit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002
--- Comment #20 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #19)
(In reply to Kazumoto Kojima from comment #18)
In the problematic situation, get_max_insn_count returns the false
value after
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
There are two new failures:
FAIL: gcc.target/sh/pr51244-12.c scan-assembler-times negc 15
FAIL: gcc.target/sh/pr51244-12.c scan-assembler-times addc 3
which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67126
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
Probably related to PR67103.
Yep, I've been following the discussion on the patches ML. I was expecting
something to break for SH, too :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002
--- Comment #17 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Michael Karcher from comment #16)
PR 61904 has been marked as a dup of PR 61801, which has been marked as fixed.
So this must be some other bug.
When compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312
--- Comment #9 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to John Paul Adrian Glaubitz from comment #8)
Would it be helpful to have a diff of the disassembly attached to this bug
report as in PR target/67002?
Yes, maybe. Please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53987
--- Comment #12 from Oleg Endo olegendo at gcc dot gnu.org ---
The following case:
int
fun_01 (char* x, char* y, int z)
{
return ((x[1] x[2] x[3]) == 0) + z;
}
results in:
add #1,r4
mov.b @r4+,r2
mov #0,r0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67061
--- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #2)
where reg is r2 and curr_insn is the insn 31. sh_find_set_of_reg is
stepping backward from the insn 31 but the call_insn 29 is missed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002
--- Comment #11 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to John Paul Adrian Glaubitz from comment #10)
Looking at the build log, it's only gcc/real.o where the comparison fails,
all the others (except for the checksum files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67061
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
CC||kkojima at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002
--- Comment #9 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to John Paul Adrian Glaubitz from comment #8)
Maybe we can add gcc/real.o to the ignore list for the time being?
Not sure if this is a good idea.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67057
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #0)
Combine is looking for a pattern:
Failed to match this instruction:
(set (reg:SI 162 [ D.1652 ])
(plus:SI (zero_extract:SI (reg:SI 4
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
The following
int foo (int a, int b)
{
return ((a (1 25)) ? 5 : 4);
}
compiled with -O2 results in:
mov.l .L4,r1
mov #-1,r0
tst r1,r4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67057
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
For some cases where T+const_int is calculated, like ...
int foo (int a, int b)
{
return a == b ? 5 : 4;
}
comiled with -O2:
cmp/eq r5,r4
movtr0
rts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63321
--- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org ---
Another example:
unsigned int
count_trailing_nonzero_bits (unsigned int v, unsigned int c)
{
c += v 1;
v = 1;
c += v 1;
v = 1;
c += v 1;
v = 1;
c += v 1;
v = 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #48 from Oleg Endo olegendo at gcc dot gnu.org ---
Can we close this as fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #55 from Oleg Endo olegendo at gcc dot gnu.org ---
Can we close this as fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66930
--- Comment #17 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Sat Jul 25 14:07:17 2015
New Revision: 226218
URL: https://gcc.gnu.org/viewcvs?rev=226218root=gccview=rev
Log:
gcc/
PR target/66930
* config/sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66930
--- Comment #18 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Sat Jul 25 14:13:48 2015
New Revision: 226219
URL: https://gcc.gnu.org/viewcvs?rev=226219root=gccview=rev
Log:
gcc/
Backport from mainline
2015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
That came out of a GCC version with has a known wrong-code bug (PR 66930)
Please try again with the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66930#c10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66930
--- Comment #16 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #14)
(In reply to Kazumoto Kojima from comment #12)
The toplevel make -k check on sh4-unknown-linux-gnu is running.
I'll report back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64036
--- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org ---
For this test case
static volatile int* const g_0 = (volatile int*)0x1240;
static volatile int* const g_1 = (volatile int*)0x1244;
static volatile int* const g_2 = (volatile int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65265
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
Actually, this can be also used for xor or and-not etc combinations. E.g. an
and-not sequence:
mov #-1,r12
tst r0,r0 T1
negcr12,r12 !T1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66930
--- Comment #10 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #6)
Created attachment 36040 [details]
.i file for gengtype.c
I've confirmed a miscompile for gengtype.c with -O1 on my 5/6
compilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66930
--- Comment #13 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #12)
--- a/config/sh/sh-protos.h
+++ b/config/sh/sh-protos.h
@@ -198,7 +198,7 @@ sh_find_set_of_reg (rtx reg, rtx_insn* insn, F stepfunc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66930
--- Comment #11 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #10)
I've added this code as part of PR 63986. I've checked with make -k
...
Sorry, by this code I didn't mean the patch in c#10 of this PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64345
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
A recent change in the middle end has triggered this:
FAIL: gcc.target/sh/pr54236-1.c scan-assembler-times negc 2
The test
int
test_07 (int *vec)
{
/* Must not see a 'sett
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54236
--- Comment #16 from Oleg Endo olegendo at gcc dot gnu.org ---
Created attachment 36012
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36012action=edit
addsicc pattern
(In reply to Oleg Endo from comment #9)
The following function compiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64345
--- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #2)
The following pattern seems to fix the test case.
===
--- gcc/config/sh/sh.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54236
--- Comment #15 from Oleg Endo olegendo at gcc dot gnu.org ---
The following shows missed subc cases when there are constants involved. Addc
cases can be constructed in the same way.
int fun (int x)
{
return x - 1 - (x 100);
}
-O2 -m4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66930
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to John Paul Adrian Glaubitz from comment #0)
As previously discussed in private mail, I am now filing a bug report for
the regression in gcc-5 that was introduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249
--- Comment #20 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #19)
Just for my understanding ... at which time does the modified expand pattern
kick in? Before RA, during RA or after RA? It's a bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65249
--- Comment #22 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #21)
Before RA, during expand phase. It's generated by function.c:
expand_function_end with
emit_move_insn (crtl-return_rtx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64036
--- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #2)
An example function, compiling with -O2 -m4:
int test_0 (unsigned short* x, int y, int z)
{
return
(x[0] + x[1] + x[2] + x[3] + x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64036
--- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org ---
I've just tried the following example on the AMS branch:
float fun (float* x)
{
return x[0] + x[1] + x[2] + x[3];
}
no AMS:
mov r4,r1
add #4,r1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833
--- Comment #14 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #12)
diff --git a/config/sh/sh.c b/config/sh/sh.c
index 0139095..86cbea7 100644
--- a/config/sh/sh.c
+++ b/config/sh/sh.c
@@ -5261,6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #39 from Oleg Endo olegendo at gcc dot gnu.org ---
Can we close this PR as fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833
--- Comment #18 from Oleg Endo olegendo at gcc dot gnu.org ---
BTW, in sh_reorg there is...
label_ref_list_d::pool.release ();
for (insn = first; insn; insn = NEXT_INSN (insn))
PUT_MODE (insn, VOIDmode);
mdep_reorg_phase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833
--- Comment #17 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #15)
sh_reorg calls shorten_branches after the loop which includes
find_barrier call and get_attr_length will return correct value
after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833
--- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org ---
Is there any update regarding this issue? Adrian, were you able to get a
preprocessed source file which reproduces the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833
--- Comment #11 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to John Paul Adrian Glaubitz from comment #9)
Created attachment 35870 [details]
Pre-processed source Magick.i
I've tried compiling that file with '-x c -std=gnu99 -O2 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #47 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Sat Jun 27 00:46:58 2015
New Revision: 225094
URL: https://gcc.gnu.org/viewcvs?rev=225094root=gccview=rev
Log:
gcc/
Backport from mainline
2015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66611
--- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Sat Jun 27 00:46:58 2015
New Revision: 225094
URL: https://gcc.gnu.org/viewcvs?rev=225094root=gccview=rev
Log:
gcc/
Backport from mainline
2015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66611
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #44 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Thu Jun 25 23:12:07 2015
New Revision: 224988
URL: https://gcc.gnu.org/viewcvs?rev=224988root=gccview=rev
Log:
gcc/
PR target/65979
PR target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66611
--- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Thu Jun 25 23:12:07 2015
New Revision: 224988
URL: https://gcc.gnu.org/viewcvs?rev=224988root=gccview=rev
Log:
gcc/
PR target/65979
PR target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #45 from Oleg Endo olegendo at gcc dot gnu.org ---
Kaz, I wanted to backport the patch to GCC 5. It doesn't apply because on
trunk gen_rtx_SET doesn't take a machine_mode arg. Since SET rtx is always
VOIDmode, it has been removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #36 from Oleg Endo olegendo at gcc dot gnu.org ---
It seems the tstsi peephole is still wrong. While working on AMS the following
example:
int test (char* x, char* y, int z)
{
return ((x[2] x[3]) == 0) + z;
}
silently produced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66611
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65979
--- Comment #37 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #36)
It seems the tstsi peephole is still wrong. While working on AMS the
following example:
int test (char* x, char* y, int z)
{
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #33 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #32)
I see, thanks. In this case, could you please add a comment e.g.:
;; Loads of the GOTPC relocation values must not be optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #31 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #29)
Unfortunately, 4.9 and later compilers 'optimize' the above code
to the code like
Just for my understanding ...
In the pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #25 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to John Paul Adrian Glaubitz from comment #22)
Provided that you're right, how would a bug in strlen this explain that gcc
always segfaults when it needs to do float
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66611
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
CC||kkojima at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #20 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to John Paul Adrian Glaubitz from comment #16)
...
763a3c: 03 61 mov r0,r1
763a3e: 00 e3 mov #0,r3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66358
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66358
--- Comment #14 from Oleg Endo olegendo at gcc dot gnu.org ---
It seems the problem is adjacent insns that need R0:
(insn 10503 2627 2628 402 (set (reg:SI 2424)
(sign_extend:SI (mem:QI (plus:SI (reg/v/f:SI 243 [ p2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65317
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #0)
It seems that it's better to allow any constant for the *andsi_compact
pattern and split out the constant load if it doesn't fit into K08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66358
--- Comment #12 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to John Paul Adrian Glaubitz from comment #11)
Any news on this issue? The sh4 buildds in Debian are currently building a
snapshot as of 2015-06-13 (r224454), let's see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66312
--- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to John Paul Adrian Glaubitz from comment #5)
Just as a heads up: This particular problem did not occur with the snapshot
as of 2014-12-20 (r218987) and we actually always
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66358
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
CC||glaubitz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66395
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66358
--- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #7)
(In reply to Oleg Endo from comment #6)
There could be some negative side effects with the patch above, because it
forces the R0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66358
--- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Kazumoto Kojima from comment #3)
(In reply to Oleg Endo from comment #2)
Defaulting -mlra might be reasonable for gcc 6.
For gcc 5, I thought the patch
601 - 700 of 1820 matches
Mail list logo
