https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65162
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
These are integer sign functions taken from a book.
For some of them the code got worse after the introduction of the treg_set_expr
stuff
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
The single-step division instruction 'div1 Rm,Rn' does
R[n] = ((R[n] 1) | T) - R[m]
if M = 0 and Q = 0.
Thus it could be utilized to do that calculation.
I've
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61142
--- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org ---
Created attachment 34839
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34839action=edit
A set of peepholes
This is a set of peepholes I have accumulated, although untested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65153
--- Comment #9 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #8)
I've tried to disable the peephole on trunk and compared CSiBE results. It
seems the peephole doesn't hit very often:
sum: 3371887
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65153
--- Comment #11 from Oleg Endo olegendo at gcc dot gnu.org ---
Sure. I was actually referring to trunk all the time :)
I agree to remove the problematic peephole on 4.9 branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65151
--- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #5)
The problem is the following insn:
(insn 45 11 12 2 (set (reg:HI 168 [ x ])
(subreg/s/u:HI (reg:SI 147 t) 0)) cchMsw9Z.out:9 -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65151
--- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org ---
The following fixes the problem:
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c(revision 220889)
+++ gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65153
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=65151
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
CC||olegendo at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65153
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
CC||olegendo at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65151
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=65153
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=65153
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Summary|sh: insn does not satisfy |[SH][4.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65151
--- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org ---
Created attachment 34825
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34825action=edit
a reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65151
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
The problem is the following insn:
(insn 45 11 12 2 (set (reg:HI 168 [ x ])
(subreg/s/u:HI (reg:SI 147 t) 0)) cchMsw9Z.out:9 -1
(expr_list:REG_DEAD (reg:SI 147 t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64793
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Tue Feb 17 21:08:24 2015
New Revision: 220772
URL: https://gcc.gnu.org/viewcvs?rev=220772root=gccview=rev
Log:
gcc/
PR target/64793
* config/sh/sh.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59375
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
CC||glaubitz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59375
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64793
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64793
--- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org ---
Thanks!
If I'm not mistaken, it looks like there's an overall improvement of ~0.35%. I
think I'll go with it.
: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
If constants don't fit into K08 or I08 they are usually placed into the
constant pool and loaded using a PC-relative load. Some constants however can
be calculated with 2..3 arithmetic insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Target||sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64833
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
Would it be possible for you to pull a precompiled source from the build via
the '-save-temps' option?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64793
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=59375
--- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org ---
Any updates regarding this problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842
Bug 29842 depends on bug 29849, which changed state.
Bug 29849 Summary: sh-linux uses inefficient multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29849
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29849
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64974
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
The problem got slightly worse with r220594. The dead store to the stack frame
is not eliminated anymore. Before the memory operands' addresses were loaded
into a reg using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64661
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64479
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29849
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=64661
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Tue Feb 10 20:47:33 2015
New Revision: 220594
URL: https://gcc.gnu.org/viewcvs?rev=220594root=gccview=rev
Log:
gcc/
PR target/64661
* config/sh/sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64974
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Tue Feb 10 20:47:33 2015
New Revision: 220594
URL: https://gcc.gnu.org/viewcvs?rev=220594root=gccview=rev
Log:
gcc/
PR target/64661
* config/sh/sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55302
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
If the atomic model allows it, the GBR logical ops can also be to implement
atomic operations on GBR relative memory.
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
While working on PR 64661, I've noticed that the expansion of the
atomic_compare_and_swapmode pattern's 'expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64660
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64660
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Tue Feb 3 20:24:13 2015
New Revision: 220376
URL: https://gcc.gnu.org/viewcvs?rev=220376root=gccview=rev
Log:
gcc/
PR target/64660
* config/sh/sync.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56590
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to amker from comment #1)
This surely sounds interesting. Like I suggested in PR62173, RTL optimizer
might be able to do more in address expression re-association
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64851
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64851
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Sun Feb 1 11:12:47 2015
New Revision: 220317
URL: https://gcc.gnu.org/viewcvs?rev=220317root=gccview=rev
Log:
gcc/
PR target/64851
* config/sh/sync.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64659
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53949
--- Comment #13 from Oleg Endo olegendo at gcc dot gnu.org ---
A more interesting real-world example from libjpeg would be function
jpeg_idct_ifast (jidctint.c).
If we take the code as-is, there are few mac opportunities due to sharing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53949
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=64785
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #1)
Another more radical approach could be to insert an RTL pass that
pre-allocates the R0 reg for those insns that have z constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64659
--- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Wed Jan 28 21:11:37 2015
New Revision: 220217
URL: https://gcc.gnu.org/viewcvs?rev=220217root=gccview=rev
Log:
gcc/
PR target/64659
* config/sh
: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
Although the __atomic builtins cover only add,sub,or,xor,and,nand, an atomic
not operation can be implicitly done by
- xor (val, -1)
- nand (val, -1)
Combine is already trying to simplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64660
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=64785
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=53987
--- Comment #11 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #9)
Another related issue is this example function:
unsigned char h (unsigned char a, int b)
{
return (unsigned char)(a + b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #26 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Mon Jan 26 23:56:05 2015
New Revision: 220144
URL: https://gcc.gnu.org/viewcvs?rev=220144root=gccview=rev
Log:
gcc/
PR target/49263
* config/sh/sh.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54236
--- Comment #11 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Sun Jan 25 16:41:25 2015
New Revision: 220093
URL: https://gcc.gnu.org/viewcvs?rev=220093root=gccview=rev
Log:
gcc/testsuite/
PR target/54236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29366
--- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Sun Jan 25 16:54:33 2015
New Revision: 220094
URL: https://gcc.gnu.org/viewcvs?rev=220094root=gccview=rev
Log:
libstdc++-v3/
PR target/29366
* config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59533
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
The issues mentioned above have been fixed by the treg_set_expr patch
(r220081).
There is one more thing, though:
int test2 (int x)
{
return x 0;
}
It's effectively a lshiftrt 31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59533
--- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #5)
The same would apply to:
int test (unsigned char* x, int y, int z)
{
return ((*x 7) ^ 0) 1;
}
which compiles to
mov.b @r4,r1
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
The treg_set_expr patch from r220081 disabled early matching of the SH2A movu.b
and movu.w patterns during RTL expansion and combine. This was done because
it's otherwise
: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
The following test case
int test0 (const char* x, int a, int b, int c)
{
if (x[a] == 92)
return b;
return c;
}
compiled with -O2 -m4 results in:
mov r5,r0
mov.b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59533
--- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org ---
If a shll is followed by a cbranch:
unsigned int
test_09_0 (int x, unsigned int y, unsigned int z)
{
return ~(x 31) ? y : z;
}
shllr4
bf .L4
mov
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
It seems that for some reason loading a constant is now favored instead of
using the #imm,R0 alternative.
void test000 (int* x, int xb)
{
x[0] = xb 128;
}
void test001
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
If I'm not mistaken, in the following example:
int test (int a, int b, int* c)
{
enum err_a_t { ERR_A };
enum err_b_t { ERR_B };
try
{
if ((a + b) == 123)
throw ERR_A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52933
--- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Sat Jan 24 13:04:53 2015
New Revision: 220081
URL: https://gcc.gnu.org/viewcvs?rev=220081root=gccview=rev
Log:
gcc/
PR target/49263
PR target/53987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #85 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Sat Jan 24 13:04:53 2015
New Revision: 220081
URL: https://gcc.gnu.org/viewcvs?rev=220081root=gccview=rev
Log:
gcc/
PR target/49263
PR target/53987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64345
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Sat Jan 24 13:04:53 2015
New Revision: 220081
URL: https://gcc.gnu.org/viewcvs?rev=220081root=gccview=rev
Log:
gcc/
PR target/49263
PR target/53987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59533
--- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Sat Jan 24 13:04:53 2015
New Revision: 220081
URL: https://gcc.gnu.org/viewcvs?rev=220081root=gccview=rev
Log:
gcc/
PR target/49263
PR target/53987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54236
--- Comment #10 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Sat Jan 24 13:04:53 2015
New Revision: 220081
URL: https://gcc.gnu.org/viewcvs?rev=220081root=gccview=rev
Log:
gcc/
PR target/49263
PR target/53987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53987
--- Comment #10 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Sat Jan 24 13:04:53 2015
New Revision: 220081
URL: https://gcc.gnu.org/viewcvs?rev=220081root=gccview=rev
Log:
gcc/
PR target/49263
PR target/53987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #25 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Sat Jan 24 13:04:53 2015
New Revision: 220081
URL: https://gcc.gnu.org/viewcvs?rev=220081root=gccview=rev
Log:
gcc/
PR target/49263
PR target/53987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #4)
https://sourceware.org/bugzilla/show_bug.cgi?id=10373
https://sourceware.org/bugzilla/show_bug.cgi?id=10378
These two issues have been
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
In libstdc++ there is code such as:
mov r9,r0
cmp/eq #-1,r0
mov r1,r0
movtr2
cmp/eq
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
The problem has been discovered by another patch here:
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01962.html
It seems that something is creating RTL which is confusing dwarf2cfi.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53988
--- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Mon Jan 19 22:35:53 2015
New Revision: 219864
URL: https://gcc.gnu.org/viewcvs?rev=219864root=gccview=rev
Log:
gcc/
PR target/53988
* config/sh/sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64652
--- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Mon Jan 19 23:25:03 2015
New Revision: 219870
URL: https://gcc.gnu.org/viewcvs?rev=219870root=gccview=rev
Log:
gcc/testsuite/
PR target/64652
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29366
--- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org ---
Created attachment 34478
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34478action=edit
proposed workaround patch
There hasn't been any update for PR 53579. I'd like to propose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64652
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Sun Jan 18 18:12:53 2015
New Revision: 219824
URL: https://gcc.gnu.org/viewcvs?rev=219824root=gccview=rev
Log:
gcc/
PR target/64652
* config/sh/sh.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64652
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
Atomics that do not use the 'movli.l' and 'movco.l' insns should be able to use
the '@(disp,reg)' address mode for SImode, since those don't have a R0 operand
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
Currently, QImode/HImode atomic insns return the values as such, although the
memory loads actually do a sign extension
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
Example:
void test2 (volatile int* mem)
{
__atomic_fetch_add (mem, 1, __ATOMIC_ACQ_REL);
}
void test3 (volatile int* mem)
{
__atomic_add_fetch (mem, 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64659
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=64659
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
The other issue is that atomic add insns for models other than 'hard-llcs' do
not utilize the 'add #imm,Rn' insn at all, because those insns allow
'register_operand' only.
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
Compiling the following example:
void test4 (volatile int* mem)
{
__atomic_or_fetch (mem, 1, __ATOMIC_ACQ_REL);
}
with -O2 -m4a -m{l|b} -matomic-model=soft-gusa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60884
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
The test case gcc.target/sh/memset.c:
void
test00(char *dstb)
{
__builtin_memset (dstb, 0, 15);
}
compiles to:
mov r4,r0
tst #3,r0
mov #0,r1
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
Compiling the following example:
int test (int a, int b, int c, int d)
{
return (a / b) + c + d;
}
with -O2 -m4 -ml -mdiv=call-fp
results in:
sh_tmp.cpp: In function 'test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53988
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Wed Jan 14 23:46:34 2015
New Revision: 219623
URL: https://gcc.gnu.org/viewcvs?rev=219623root=gccview=rev
Log:
gcc/
PR target/53988
* config/sh/sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53987
--- Comment #9 from Oleg Endo olegendo at gcc dot gnu.org ---
Another related issue is this example function:
unsigned char h (unsigned char a, int b)
{
return (unsigned char)(a + b);
}
compiling with -O2 -mrenesas (which allows undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64479
--- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org ---
The issue should be fixed now. I'd like to keep this PR open for a while
though. Maybe we can construct a runtime torture test case, although it seems
a bit difficult.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61157
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=64479
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Tue Jan 13 00:30:57 2015
New Revision: 219506
URL: https://gcc.gnu.org/viewcvs?rev=219506root=gccview=rev
Log:
gcc/
PR target/64479
* rtlanal.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64479
--- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Tue Jan 13 01:01:14 2015
New Revision: 219507
URL: https://gcc.gnu.org/viewcvs?rev=219507root=gccview=rev
Log:
gcc/
Backport form mainline
2015-01-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61157
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64479
--- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Tue Jan 13 01:18:56 2015
New Revision: 219508
URL: https://gcc.gnu.org/viewcvs?rev=219508root=gccview=rev
Log:
gcc/
Backport form mainline
2015-01-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63321
--- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org ---
The shll/shlr insns effectively perform two operations:
T = zero_extract single bit 0 / 31 from reg
reg = reg 1 / reg 1.
The other shift insns as in comment #5 perform only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64479
--- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #2)
I haven't checked it, but maybe this also helps PR 56451 in some way.
Unfortunately it doesn't.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #93 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Thu Jan 8 11:07:45 2015
New Revision: 219341
URL: https://gcc.gnu.org/viewcvs?rev=219341root=gccview=rev
Log:
gcc/
PR target/55212
* config/sh/sh.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64479
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Target|sh3 |sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64479
--- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org ---
The *cbranch_t splitter is done like 4 times, because there are 4 split passes.
The last split pass is split5, which is done right after the delayed-branch
pass. Before delayed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53987
--- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Tue Dec 30 17:26:18 2014
New Revision: 219110
URL: https://gcc.gnu.org/viewcvs?rev=219110root=gccview=rev
Log:
gcc/testsuite/
PR target/53987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #23 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Tue Dec 30 18:44:27 2014
New Revision: 219111
URL: https://gcc.gnu.org/viewcvs?rev=219111root=gccview=rev
Log:
gcc/testsuite/
PR target/49263
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #24 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Tue Dec 30 19:11:42 2014
New Revision: 219113
URL: https://gcc.gnu.org/viewcvs?rev=219113root=gccview=rev
Log:
gcc/testsuite/
PR target/49263
801 - 900 of 1829 matches
Mail list logo
