Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
CC: kkojima at gcc dot gnu.org, vmakarov at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
In r228176 the SH addsi3 patterns have been extended to allow more relaxed
input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #28 from Oleg Endo ---
I've created a new PR for the LRA addsi3 thing .. PR 67732.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #30 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #29)
> I think so, though we should test it on 5-branch. I'm running tests
> on 5-branch now.
No new failures on sh-elf with
make -k check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #116 from Oleg Endo ---
(In reply to Oleg Endo from comment #91)
>
> I can confirm the -1140 bytes / -0.04% on the CSiBE set.
Since r228176 this is no longer true. Now the gap of no-LRA and LRA is a bit
wider:
3345527 -> 3334351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #24 from Oleg Endo ---
Thanks!
Could you please re-run that test with attachment 36400?
(Because the problem was triggered only by this test, I think we don't need to
fully re-test it)
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org, segher at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
This is what happens on SH, but it's probably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716
--- Comment #7 from Oleg Endo ---
Created attachment 36394
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36394=edit
preprocessed C++ source for dcraw_common.cpp
The code in attachment 36389 doesn't compile with the trunk compiler because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67644
--- Comment #5 from Oleg Endo ---
Possibly related: PR 50521, PR 56997
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #16 from Oleg Endo ---
Created attachment 36396
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36396=edit
Another trail, works with LRA
(In reply to Oleg Endo from comment #15)
>
> I'm now trying to come up with something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716
--- Comment #8 from Oleg Endo ---
On sh-elf/newlib there are no threads, so -fopenmp doesn't work. I can't
reproduce it Without -fopenmp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716
--- Comment #12 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #11)
> Created attachment 36397 [details]
> patch for targetm.override_options_after_change
>
> Could you try this patch?
>
> What is going on:
>
> 1. align_jumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67723
--- Comment #1 from Oleg Endo ---
(In reply to Oleg Endo from comment #0)
> Instead they should be enabled in
> TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE
Alternatively, the insn conditions could check the flags directly via a
function instead of
ty: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
When the following code is compiled with "-m4-single -ml -O2 -mfsrra"
#pra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #18 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #17)
> (In reply to Oleg Endo from comment #16)
> > Kaz, does this patch fix the issue in c#11 ?
>
> Yep, it fixes that ICE. Thanks!
> My 36387 trial patch can cause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #19 from Oleg Endo ---
(In reply to Oleg Endo from comment #16)
> Then, there's is messy thing with 3 addsi3 patterns ... the order is very
> important. They must be in exactly this order, or else we don't get the
> code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
Oleg Endo changed:
What|Removed |Added
Attachment #36396|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65317
--- Comment #2 from Oleg Endo ---
It seems this is a general problem. Combine would sometimes synthesize and try
to introduce new constants. But because most of the SH insn patterns reject
general constants (e.g. arith_reg_operand) combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #20 from Oleg Endo ---
(In reply to Oleg Endo from comment #16)
> Created attachment 36396 [details]
> Another trail, works with LRA
>
> I've tested this patch with
> make -k check
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52628
--- Comment #2 from Oleg Endo ---
To catch cases such as
int test_01 (int a, int b, int c)
{
return c << (a > b ? 1 : 0);
}
a shift with treg_set_expr can be implemented. Combine is looking for this
pattern:
Failed to match this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716
--- Comment #14 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #13)
> (In reply to Oleg Endo from comment #12)
> > Maybe we should move some
> > more of the sh_option_override things sh_override_options_after_change? I
> > don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #15 from Oleg Endo ---
Created attachment 36393
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36393=edit
Another trail, doesn't work with LRA
(In reply to Kazumoto Kojima from comment #14)
> Created attachment 36387 [details]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67675
Oleg Endo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67675
--- Comment #3 from Oleg Endo ---
Author: olegendo
Date: Fri Sep 25 13:09:04 2015
New Revision: 228118
URL: https://gcc.gnu.org/viewcvs?rev=228118=gcc=rev
Log:
gcc/
PR target/67675
* config/sh/sh-mem.cc (sh_expand_cmpstr): Check
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
The test case from gcc.target/sh/cmpstrn.c
int
test02 (const char *s1)
{
return __builtin_strncmp (s1, "abcdefghi", 8);
}
compile
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
It seems that the following
int test_06 (const char* s1)
{
return __builtin_strncmp (s1, "abcdabc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #13 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #11)
>
> /exp/ldroot/dodes/INTEST/trunk/gcc/testsuite/gfortran.dg/matmul_6.f90:19:0:
> Error: could not split insn
> (insn 2778 2779 94 (set (reg:SI 3 r3)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #7 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #6)
> Test completed with no new failures on sh4-unknown-linux-gnu.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #10 from Oleg Endo ---
The core issue should be fixed. I'd like to keep this PR open though for a
while.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #9 from Oleg Endo ---
Author: olegendo
Date: Wed Sep 23 11:57:27 2015
New Revision: 228047
URL: https://gcc.gnu.org/viewcvs?rev=228047=gcc=rev
Log:
gcc/
Backport from mainline
2015-09-23 Oleg Endo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #8 from Oleg Endo ---
Author: olegendo
Date: Wed Sep 23 11:55:45 2015
New Revision: 228046
URL: https://gcc.gnu.org/viewcvs?rev=228046=gcc=rev
Log:
gcc/
PR target/67391
* config/sh/sh.md (addsi3, *addsi3_compact):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #12 from Oleg Endo ---
I already thought that something like this might happen. I will have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
Oleg Endo changed:
What|Removed |Added
CC||kkojima at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #4 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #3)
>
> Ugh, those checks look just wrong and I can't remind why I've
> added them. 33707 didn't do that and checked overlapping at
> the split condition only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391
--- Comment #2 from Oleg Endo ---
Created attachment 36373
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36373=edit
Proposed patch
Tested on sh-elf, LRA enabled, with make -k check
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
In CSiBE I've seen code that goes like this ...
left shift:
mov.b@(...),r0
extu.b r0,r1
||olegendo at gcc dot gnu.org
--- Comment #40 from Oleg Endo ---
Just hit this PR by accident. I wonder how many address mode related PRs are
hanging around there...
I hope that the AMS pass will help. The current branch is
https://github.com/erikvarga/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842
Bug 29842 depends on bug 28791, which changed state.
Bug 28791 Summary: sh64-elf -mdiv= options bitrot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28791
What|Removed |Added
||olegendo at gcc dot gnu.org
Resolution|--- |WONTFIX
--- Comment #2 from Oleg Endo ---
SH5/SH64 has been declared obsolete
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01516.html
||olegendo at gcc dot gnu.org
Resolution|--- |WONTFIX
--- Comment #1 from Oleg Endo ---
SH5/SH64 has been declared obsolete
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01516.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58866
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
||olegendo at gcc dot gnu.org
Resolution|--- |WONTFIX
--- Comment #17 from Oleg Endo ---
SH5/SH64 has been declared obsolete
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01516.html
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
If the alignments of both input pointers to __builtin_strcmp are not at least 4
bytes, code is emitted to do a run-time check:
int foo1 (const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #11 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #10)
> (In reply to Oleg Endo from comment #1)
> > Thanks for reporting. I was a bit confused ... the attached source is not
> > cselib.c (which is a GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #13 from Oleg Endo ---
Author: olegendo
Date: Mon Sep 21 13:14:45 2015
New Revision: 227970
URL: https://gcc.gnu.org/viewcvs?rev=227970=gcc=rev
Log:
gcc/
Backport from mainline
2015-09-21 Oleg Endo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #9 from Oleg Endo ---
(In reply to Oleg Endo from comment #7)
> Created attachment 36357 [details]
> Proposed patch
>
> Although a "mov @r2+,r2" is actually possible and valid (r2 will contain the
> value loaded from memory, AFAIR),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64345
--- Comment #5 from Oleg Endo ---
Author: olegendo
Date: Mon Sep 21 13:49:07 2015
New Revision: 227971
URL: https://gcc.gnu.org/viewcvs?rev=227971=gcc=rev
Log:
testsuite/
PR target/64345
* gcc.target/sh/pr64345-1.c: Adjust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #113 from Oleg Endo ---
Created attachment 36363
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36363=edit
CSiBE I08 const cost = 0 vs. cost = 1, no LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #114 from Oleg Endo ---
Created attachment 36364
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36364=edit
CSiBE I08 const cost = 0 vs. cost = 1, LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67675
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
I've noticed this while doing PR 67675...
On strict-alignment targets (like SH) a pointer to a struct is always assumed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67675
--- Comment #2 from Oleg Endo ---
(In reply to Oleg Endo from comment #0)
> struct S
> {
> int a, b, c;
> char s[64];// this array will be always 4 byte aligned.
> };
Currently this doesn't work, see PR 67676.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #112 from Oleg Endo ---
I had a quick look at the gcc.target/sh/hiconst.c test case:
int rab (char *pt, int *pti)
{
pt[2] = 0;
pti[3] = 0;
return 0;
}
without LRA:
mov #0,r0
mov.b r0,@(2,r4)
rts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #115 from Oleg Endo ---
It seems that it's already enough to set the cost for I08 from 0 to 1:
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c (revision 227958)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #12 from Oleg Endo ---
Author: olegendo
Date: Mon Sep 21 12:57:31 2015
New Revision: 227969
URL: https://gcc.gnu.org/viewcvs?rev=227969=gcc=rev
Log:
gcc/
PR target/67657
* config/sh/sh.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67660
--- Comment #1 from Oleg Endo ---
Just a note ...
It might also make sense to tell the compiler (via function attribute) whether
the ISR is re-entrant or not. On a single-core system, atomic ops in an ISR
can be converted into normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #8 from Oleg Endo ---
BTW, I'd recommend not specifying -ffloat-store on SH. It doesn't affect FP
precision (unlike on x86) and just creates slower code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52394
--- Comment #3 from Oleg Endo ---
(In reply to Oleg Endo from comment #2)
>
> The code should actually be something like this:
> mov.l .L2,r2
> bld #0,r5
> mov #0,r0
> bor.b #5,@(0,r2)
> bst.b
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
The following:
unsigned int test (unsigned int x)
{
return (x & 0x30) ? ~0 : 0;
}
compiled with -m4 -ml -O2 results in:
mov r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67061
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67061
--- Comment #8 from Oleg Endo ---
Author: olegendo
Date: Sun Sep 20 10:18:45 2015
New Revision: 227943
URL: https://gcc.gnu.org/viewcvs?rev=227943=gcc=rev
Log:
gcc/
Backport from mainline
2015-09-14 Oleg Endo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67126
--- Comment #4 from Oleg Endo ---
Author: olegendo
Date: Mon Sep 21 00:17:22 2015
New Revision: 227957
URL: https://gcc.gnu.org/viewcvs?rev=227957=gcc=rev
Log:
gcc/
PR target/67126
* config/sh/sh.md (*reg_lsb_t): Emit bld insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67126
Oleg Endo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506
Oleg Endo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #1 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #0)
> Created attachment 36354 [details]
> Preprocessed source for cselib.c
Thanks for reporting. I was a bit confused ... the attached source is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59478
--- Comment #2 from Oleg Endo ---
Author: olegendo
Date: Mon Sep 21 01:43:50 2015
New Revision: 227958
URL: https://gcc.gnu.org/viewcvs?rev=227958=gcc=rev
Log:
gcc/testsuite/
PR target/59478
* gcc.target/sh/pr59478.c: New.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67644
--- Comment #1 from Oleg Endo ---
I've just checked with the current GCC 4.9 branch. It happens there, too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67644
--- Comment #3 from Oleg Endo ---
It somehow makes sense ...
x->ICR0.BIT.BIT5 |= 1;
or maybe better
x->ICR0.BIT.BIT5 ^= 1;
is a bitfield read and a bitfield write.
A bitfield write implies a bitfield read-modify-write, and thus we get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67644
Oleg Endo changed:
What|Removed |Added
Target|sh*-*-* |sh*-*-* rx*-*-*
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
This has been originally mentioned here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457#c16
however
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #3 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #2)
> Created attachment 36356 [details]
> reduced test case
>
> I can reproduce it with trunk rev. 227929 but can't with 227887.
> Clearly very fragile.
> ...
> into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #7 from Oleg Endo ---
Created attachment 36357
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36357=edit
Proposed patch
Although a "mov @r2+,r2" is actually possible and valid (r2 will contain the
value loaded from memory,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457
Oleg Endo changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67644
--- Comment #4 from Oleg Endo ---
Hm, maybe it'd be good to add a warning (enabled by default, can be disabled)
if volatile bitfields are used. To me it looks like volatile bitfields have
almost no use (the way they are implemented by GCC now)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #5 from Oleg Endo ---
(In reply to Oleg Endo from comment #4)
Just for reference, those are the exact options:
-x c -std=gnu99 -m4 -ml -g -O2 -ffloat-store -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657
--- Comment #6 from Oleg Endo ---
The peephole outputs this:
(insn 2292 0 0 (set (reg/v/f:SI 2 r2 [orig:320 outptr ] [320])
(mem/f:SI (post_inc:SI (reg:SI 2 r2)) [2 MEM[base: _145, offset: 0B]+0
S4 A32])) -1
(expr_list:REG_INC
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
The following:
struct USRSTR
{
union
{
unsigned char BYTE;
struct
{
unsigned char BIT7:1;
unsigned char BIT6:1
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
Ignoring the volatile bitfield double load issue of PR 67644, there seems to be
some room for improvements w.r.t. operations on single bit
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
If the FPU is (potentially) used in ISRs, it should be brought into a
consistent state
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
The following ...
extern void foo (void);
void __attribute__((interrupt_handler))
isr2 (void)
{
foo ();
}
compiled with -m4a -ml -mfmovd -O2 results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52394
--- Comment #2 from Oleg Endo ---
The SH2A bitops seem to produce some of the insns, but it seems the generated
code is either really bad (defeating the original purpose) or broken.
For example:
volatile struct
{
union
{
unsigned char
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
CC: segher at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
The following new failure popped up a while ago.
non-SH2A:
FAIL: gcc.target/sh/pr54236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67636
--- Comment #1 from Oleg Endo ---
See also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64345#c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64345#c3
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
There are some cases, where shll or shlr insns are used to conditionally branch
on the MSB or LSB of a reg.
The shll case has been mentioned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66181
--- Comment #16 from Oleg Endo ---
Can this be closed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64345
--- Comment #4 from Oleg Endo ---
(In reply to Oleg Endo from comment #2)
> A recent change in the middle end has triggered this:
>
> FAIL: gcc.target/sh/pr54236-1.c scan-assembler-times negc 2
>
I've created a new PR 67636 for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55298
--- Comment #2 from Oleg Endo ---
Something similar has been done for ARM:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00939.html
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
When compiling the test cases pragma-isr-nosave_low_regs.c and
attr-isr-nosave_low_regs.c in gcc.target/sh there's an ICE:
attr-isr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573
--- Comment #9 from Oleg Endo ---
I think this should be backported to GCC 5. Even if it might not be triggered
often, there is a possibility for silent wrong-code bugs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66609
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #5
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
At least on SH, the following:
bool test (int a, int b, int* r)
{
return __builtin_mul_overflow (a, b, r);
}
compiled with -m4 -ml -O2 results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #23 from Oleg Endo ---
Thanks for the interesting test/use case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573
--- Comment #8 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #7)
> Fixed on trunk.
> Oleg, now we can propose to make -mlra default on trunk.
Nice, thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #21 from Oleg Endo ---
(In reply to Urja Rannikko from comment #20)
> I'll add a note here that this seems to also affect the AVR target when it
> is under register pressure and cant use Z or Y registers which can do Z+n
> /Y+n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573
--- Comment #4 from Oleg Endo ---
Maybe FPSCR_STAT_REG should be in the clobber list, too? Otherwise stores of
FP exception bits etc (get_fpscr builtin) could be wrongly CSE'd across
function calls... However, I don't know if this is a problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67061
--- Comment #7 from Oleg Endo ---
Author: olegendo
Date: Mon Sep 14 13:46:14 2015
New Revision: 227750
URL: https://gcc.gnu.org/viewcvs?rev=227750=gcc=rev
Log:
gcc/
PR target/67061
* config/sh/sh-protos.h (sh_find_set_of_reg):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #108 from Oleg Endo ---
(In reply to Oleg Endo from comment #107)
The problem is the define_split at sh.md line 893 (the part at 945). Or
actually, it's sh_find_set_of_reg. Adding this
diff --git a/gcc/config/sh/sh-protos.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #106 from Oleg Endo ---
Created attachment 36329
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36329=edit
20040709-2.s with LRA (FAIL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #105 from Oleg Endo ---
Created attachment 36328
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36328=edit
20040709-2.s without LRA (PASS)
501 - 600 of 1820 matches
Mail list logo
