https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66591
--- Comment #2 from Oleg Endo ---
I have started working on the R0 issue...
An R0-pre-allocating pass might potentially break down again when reload/LRA
tries to emit mem access insns, which have an R0 constraint. Although the
pre-allocating wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71338
--- Comment #3 from Oleg Endo ---
Thanks DJ. Is it OK to backport it to 5 and 6 branches? If you're OK with it,
I can do it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30065
Oleg Endo changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842
Bug 29842 depends on bug 30065, which changed state.
Bug 30065 Summary: Could use indexed addressing to reduce const costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30065
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29366
--- Comment #10 from Oleg Endo ---
(In reply to Eric Gallager from comment #9)
>
> Did this fix things?
No, not entirely. The whole config/cpu/sh/atomicity.h header should not be
required, but because of PR 53579, it is.
Please do not close a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30065
--- Comment #7 from Oleg Endo ---
(In reply to Eric Gallager from comment #6)
>
> Can I change the status to SUSPENDED or assign them to you instead? I'm not
> so much trying to reduce the number of open PRs as I am trying to just move
> them ou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67638
--- Comment #2 from Oleg Endo ---
(In reply to Martin Liška from comment #1)
> Can't reproduce with cross compiler on trunk and gcc-5 branch. Is it
> reproducible with cross compiler? Which options do you use?
You have to use -m4 or -m4a (SH4 or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81485
Oleg Endo changed:
What|Removed |Added
Last reconfirmed|2017-08-08 00:00:00 |2017-8-10
--- Comment #2 from Oleg Endo ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81485
--- Comment #4 from Oleg Endo ---
(In reply to Martin Liška from comment #3)
>
> Good, I can confirm it works for GCC 5. Let's then bisect that..
I'm not sure whether this will reveal anything useful.
It's probably just a bug in the function sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81485
--- Comment #6 from Oleg Endo ---
And in fact, there has been a change to the function sh_find_set_of_reg. I'd
have to dig through the archives etc to find out what was going on there.
Meanwhile, it seems that the small backport patch below fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81485
--- Comment #7 from Oleg Endo ---
(In reply to Oleg Endo from comment #6)
> And in fact, there has been a change to the function sh_find_set_of_reg.
> I'd have to dig through the archives etc to find out what was going on
> there.
The change wa
: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
This error shows up when building a bigger app on RX with LTO. It is working
OK on GCC 6
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
__atomic_test_and_set is supposed to change only one byte, but on RX it wrongly
overwrites adjacent memory locations:
int test (volatile char* x)
{
return
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: rx*-*-*
There are some places which check if the target directly supports SImode atomic
compare and exchange, via the __GCC_ATOMIC_INT_LOCK_FREE macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81821
Oleg Endo changed:
What|Removed |Added
Summary|[RX] __atomic_test_and_set |[RX] xchg_mem uses
|overwr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81821
--- Comment #2 from Oleg Endo ---
A possible fix:
Index: gcc/config/rx/rx.md
===
--- gcc/config/rx/rx.md (revision 251045)
+++ gcc/config/rx/rx.md (working copy)
@@ -2167,6 +2167,7
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: rx*-*-*
Atomics that perform arithmetic are only implemented for SImode. It should be
extended to support QImode and HImode in the same way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #4 from Oleg Endo ---
(In reply to Nick Clifton from comment #2)
>
> So what I suspect is that something is missing from the rx libgcc
> configuration files (libgcc/config/rx/t-rx and/or libgcc/config/rx/rx-lib.h)
> which means that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #5 from Oleg Endo ---
I have checked with the following simplified test code:
#include
int main (void)
{
volatile float testval = 1;
// volatile double testval = 1;
testval = testval + 1;
return ((const uint8_t*)&testval)[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #6 from Oleg Endo ---
Created attachment 41980
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41980&action=edit
Disassembled SF code of comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #7 from Oleg Endo ---
Created attachment 41981
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41981&action=edit
Disassembled DF code of comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
Oleg Endo changed:
What|Removed |Added
CC||joseph at codesourcery dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #9 from Oleg Endo ---
Created attachment 41982
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41982&action=edit
Proposed patch
I'd propose to remove the FLOAT_BIT_ORDER_MISMATCH stuff altogether. It's more
portable to use shif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
Oleg Endo changed:
What|Removed |Added
CC||andrew.burgess at embecosm dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
Oleg Endo changed:
What|Removed |Added
CC||amylaar at gcc dot gnu.org
--- Comment #11 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
Oleg Endo changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #14 from Ole
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #16 from Oleg Endo ---
(In reply to Ian Lance Taylor from comment #15)
> What does this program print on rx?
12
6f883f80 0 0
>
> Overall the softfp code is newer and probably better. Converting rx to use
> the softfp code is p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #20 from Oleg Endo ---
(In reply to jos...@codesourcery.com from comment #17)
> Presumably the bit-field issue is RX defaulting to MS bit-field layout
> (rx_is_ms_bitfield_layout suggests making the structure itself packed
> should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #21 from Oleg Endo ---
(In reply to Ian Lance Taylor from comment #18)
> How could the size of that struct possibly be 12? Can you figure out what
> is causing that to happen? There are exactly 64 bits specified, and the
> fields ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #23 from Oleg Endo ---
(In reply to Ian Lance Taylor from comment #22)
> The patch to make the structs themselves attribute((packed)) is approved.
>
Thanks!
> If you want to investigate dropping the bitfield code entirely, that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67712
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
Oleg Endo changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #13 from Ole
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #14 from Oleg Endo ---
(In reply to Ian Lance Taylor from comment #25)
> I have no particular concerns with dropping the bitfield code, but clearly it
> has to be tested on a couple of little-endian platforms.
Can we try to narrow it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426
--- Comment #1 from Oleg Endo ---
Have you tried compiling the package with -mlra?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426
--- Comment #3 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #2)
>
> Not yet, I will give it a try now.
Please try. It might allow you to at least build the package. Regardless of
that, let's keep this PR open.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426
--- Comment #5 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #4)
>
> It helps, indeed. The build now passes the problematic source code file.
> However, it now bails out later with:
>
> /tmp/cck5XKuE.s: Assembler messag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62180
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633
--- Comment #5 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #1)
> Here is a trial patch
>
> diff --git a/config/sh/sh.md b/config/sh/sh.md
> index c6956a0..c83bf08 100644
> --- a/config/sh/sh.md
> +++ b/config/sh/sh.md
> @@ -858,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633
--- Comment #7 from Oleg Endo ---
Maybe it's this thread?
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00334.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633
--- Comment #13 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #12)
> Perhaps the splitter in problem
> might have to take care of subreg case even when referencing
> a reg rtx in the input operands.
So it looks like a new rtx obje
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
The following program
#include
#include
int main (void)
{
volatile double testval = 1.0;
printf ("testval = %02x%02x%02x%02x%02x%02x%02x%02x\n",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
Oleg Endo changed:
What|Removed |Added
CC||nickc at gcc dot gnu.org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804
--- Comment #3 from Oleg Endo ---
(In reply to Nick Clifton from comment #2)
>
> It is almost certainly a bug in the RX specific parts of the libgcc
> configuration
>
> It is unlikely that the actual code for the _COM_CONVd32s function is w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633
--- Comment #17 from Oleg Endo ---
(In reply to Jakub Jelinek from comment #16)
> When a fix exists, why hasn't it been posted to gcc-patches?
Because, like I wrote in comment #13, I would like to check if there might be a
better fix for the pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79112
--- Comment #1 from Oleg Endo ---
As far as I know GO has not been ported for SH.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79112
--- Comment #3 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #2)
>
> Hmm, I thought gccgo would work on all gcc-supported targets.
No, GO requires some runtime support which has to be provided by the backend.
For examp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67328
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79462
--- Comment #4 from Oleg Endo ---
If the patch fixes the problem, it's OK. But please add a comment where the
line is removed as a hint of what's going on there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83111
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83111
--- Comment #6 from Oleg Endo ---
Author: olegendo
Date: Thu Nov 23 14:06:15 2017
New Revision: 255096
URL: https://gcc.gnu.org/viewcvs?rev=255096&root=gcc&view=rev
Log:
gcc/
PR target/83111
* config/sh/sh.md (udivsi3, divsi3, si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83111
--- Comment #7 from Oleg Endo ---
Author: olegendo
Date: Thu Nov 23 14:08:12 2017
New Revision: 255097
URL: https://gcc.gnu.org/viewcvs?rev=255097&root=gcc&view=rev
Log:
gcc/
Backport from mainline
2017-11-23 Oleg Endo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83111
Oleg Endo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
Oleg Endo changed:
What|Removed |Added
CC||segher at kernel dot
crashing.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
--- Comment #11 from Oleg Endo ---
(In reply to James Clarke from comment #10)
> (In reply to Segher Boessenkool from comment #9)
> > What flags does it need? I can't get it to fail.
>
> Just -O2 -fPIC, at least with 7.2.0.
That is, if your de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #10 from Oleg Endo ---
(In reply to Rich Felker from comment #9)
> From a Linux standpoint, there is no trapa trap number defined that would
> cause a fatal signal. The ones that are defined are for syscalls and debug
> breakpoints. O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #12 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #11)
> >
> > It's OK to add __builtin_trap to GCC 7.
> > Could you have a look and try the patch in Comment 6? I don't have so much
> > time for SH stuff the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #14 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #13)
>
> What about glibc which originally resulted in this bug report?
I have no idea about it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #19 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #18)
> I can confirm that the patch from comment #6 resolves the problem for me.
Thanks for checking.
>
> Can we get it merged in one form or another?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #26 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #25)
> (In reply to Segher Boessenkool from comment #24)
> > Send it to gcc-patches@? If it is approved, I can commit it, sure.
>
> Ok, thanks! Will do!
Tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81485
--- Comment #9 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #8)
>
> Should we mark this as resolved?
No, because it has not been resolved for GCC 6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216
--- Comment #28 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #27)
>
> The problem is that with gcc-7 as the default compiler in Debian, this issue
> always results in glibc and the Linux kernel failing to build from sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
--- Comment #3 from Oleg Endo ---
Go will not work on SH just by adding it to the list of targets. For instance
split stacks support is not implemented on SH.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77610
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77610
--- Comment #6 from Oleg Endo ---
(In reply to Rich Felker from comment #5)
> Of course, fancy memcpy in general is only a win beyond a certain size. For
> DMA I did not mean I want to use DMA for any size beyond gcc's proposed
> function-call th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #87 from Oleg Endo ---
Author: olegendo
Date: Sun Sep 25 06:59:37 2016
New Revision: 240471
URL: https://gcc.gnu.org/viewcvs?rev=240471&root=gcc&view=rev
Log:
This fixes a fallout that actually goes back to 5.0 but went unnoticed.
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58122
--- Comment #5 from Oleg Endo ---
This issue seems to be working just fine. Not sure what kind of test case to
add for this though... just scanning final assembler code for some expected hex
or dec constant?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56365
--- Comment #14 from Oleg Endo ---
Richi, if you're not going to backport any patches, maybe close this one as
fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #88 from Oleg Endo ---
Author: olegendo
Date: Tue Sep 27 12:50:27 2016
New Revision: 240533
URL: https://gcc.gnu.org/viewcvs?rev=240533&root=gcc&view=rev
Log:
gcc/
PR target/51244
* config/sh/sh.c (sh_rtx_costs): Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61056
--- Comment #5 from Oleg Endo ---
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=240568
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #5
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
This is a carry over from the proposed improvement to the strlen-like builtin
functions by Christian. The idea is to unroll some of the loops that are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60539
--- Comment #3 from Oleg Endo ---
As mentioned here
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01692.html:
> IMHO the problem is with the
> non-aligned loop stems from to the generic alignment code in final.c.
> Further tuning of static branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60890
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #2
|ASSIGNED
Last reconfirmed||2014-05-03
CC||olegendo at gcc dot gnu.org
Ever confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61026
--- Comment #3 from Oleg Endo ---
Author: olegendo
Date: Sat May 3 07:51:02 2014
New Revision: 210028
URL: http://gcc.gnu.org/viewcvs?rev=210028&root=gcc&view=rev
Log:
PR target/61026
* config/sh/sh.c: Include stdlib headers before every
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61026
--- Comment #4 from Oleg Endo ---
Author: olegendo
Date: Sat May 3 08:17:43 2014
New Revision: 210029
URL: http://gcc.gnu.org/viewcvs?rev=210029&root=gcc&view=rev
Log:
Back port from mainline
PR target/61026
* config/sh/sh.c: Include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61026
--- Comment #5 from Oleg Endo ---
Author: olegendo
Date: Sat May 3 08:21:24 2014
New Revision: 210030
URL: http://gcc.gnu.org/viewcvs?rev=210030&root=gcc&view=rev
Log:
Back port from mainline
PR target/61026
* config/sh/sh.c: Include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61026
Oleg Endo changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60884
Oleg Endo changed:
What|Removed |Added
CC||christian.bruel at st dot com
--- Comment #1
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
At least on SH and r210026 the following:
extern "C" const char* strchr (const char*,int);
const char* test (const char* x)
{
return str
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60884
--- Comment #2 from Oleg Endo ---
I was trying to see how to implement the strchr builtin function which could
also utilize the cmp/str insn. However, it seems that the necessary builtin
expansion code for strchr is not there (yet).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61056
--- Comment #2 from Oleg Endo ---
(In reply to Jakub Jelinek from comment #1)
> 1) your testcase uses strrchr rather than strchr
Sorry, typo/pasto. It was meant to be "strchr".
> 2) why do you think it is desirable to convert strchr (x, 0) to x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61026
--- Comment #8 from Oleg Endo ---
(In reply to Jan-Benedict Glaw from comment #7)
> I'm not 100% sure, but I guess this fix breaks building GCC on
> gcc111.fsffrance.org . All build details can be found here:
> http://toolchain.lug-owl.de/buildbo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61026
--- Comment #10 from Oleg Endo ---
Sorry for the trouble, but Joseph has a point here ...
http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00414.html
Could you guys please try moving the problematic header includes in sh.c below
the #include "config.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60884
--- Comment #4 from Oleg Endo ---
Author: olegendo
Date: Wed May 7 20:08:23 2014
New Revision: 210187
URL: http://gcc.gnu.org/viewcvs?rev=210187&root=gcc&view=rev
Log:
gcc/
PR target/60884
* config/sh/sh-mem.cc (sh_expand_strlen): Use lo
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
CC: kyrylo.tkachov at arm dot com, mikestump at comcast dot net,
rsandifo at redhat dot com, zadeck at naturalbridge dot com
Target: sh*-*-*
Created
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
http://gcc.gnu.org/ml/gcc/2013-11/msg00131.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #75 from Oleg Endo ---
Author: olegendo
Date: Fri May 16 22:54:32 2014
New Revision: 210535
URL: http://gcc.gnu.org/viewcvs?rev=210535&root=gcc&view=rev
Log:
gcc/
PR target/51244
* config/sh/sh.c (sh_eval_treg_value): Handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #31 from Oleg Endo ---
Author: olegendo
Date: Fri May 16 23:12:19 2014
New Revision: 210537
URL: http://gcc.gnu.org/viewcvs?rev=210537&root=gcc&view=rev
Log:
gcc/
PR target/54089
* config/sh/predicates.md (negt_reg_shl31_oper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54236
--- Comment #8 from Oleg Endo ---
Author: olegendo
Date: Wed May 21 08:06:06 2014
New Revision: 210682
URL: http://gcc.gnu.org/viewcvs?rev=210682&root=gcc&view=rev
Log:
gcc/
PR target/54236
* config/sh/sh.md (*addc_r_1): Rename t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55146
Oleg Endo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64736
Oleg Endo changed:
What|Removed |Added
CC||kkojima at gcc dot gnu.org
--- Comment #1 fr
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Created attachment 35083
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35083&action=edit
reduced test case
This is a reduced test case from the linux kernel. When compiled w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65505
--- Comment #1 from Oleg Endo ---
Created attachment 35084
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35084&action=edit
possible patch
The problem here is that sh_disp_addr_displacement gets an address that looks
like:
(plus:SI (subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65505
Oleg Endo changed:
What|Removed |Added
Target||sh*-*-*
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65505
Oleg Endo changed:
What|Removed |Added
CC||kkojima at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65505
--- Comment #4 from Oleg Endo ---
Author: olegendo
Date: Mon Mar 23 18:57:58 2015
New Revision: 221604
URL: https://gcc.gnu.org/viewcvs?rev=221604&root=gcc&view=rev
Log:
gcc/
PR target/65505
* config/sh/predicates.md (simple_mem_operand,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65505
Oleg Endo changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
The test case for PR 29215 started to fail on SH:
FAIL: gcc.dg/pr29215.c scan-tree-dump-not gimple "memcpy"
Looking at the assembly output of the
901 - 1000 of 1963 matches
Mail list logo
