http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52941
--- Comment #6 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-04-16
22:37:31 UTC ---
(In reply to comment #5)
The patch looks just fine. I don't mind whether those atomics are
fully optimized or not ATM. Programs having atomics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52941
--- Comment #8 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-04-17
00:54:00 UTC ---
(In reply to comment #7)
Created attachment 27173 [details]
Proposed patch
Looks even better.
Only one thing ... is it safe to do the
@-r15, @+r15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52941
--- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-04-13
03:29:25 UTC ---
(In reply to comment #2)
One more thing regarding movco/movli ... do you think it's OK to use them also
to do atomics on types SImode? As far as I can
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52898
--- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-04-12
01:13:15 UTC ---
(In reply to comment #2)
I don't know about their history. -mcbranchdi is enabled by default,
though. See gcc/common/config/sh/sh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52941
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-04-12
01:18:42 UTC ---
(In reply to comment #0)
Other than that, should we add another option '-mhard-atomic' (which would
enable the movco/movli atomics on SH4A and disable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29366
--- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-04-12
01:20:06 UTC ---
(In reply to comment #2)
I think some of the problems will disappear once PR 52941 is done.
After that, and having the new atomic builtins of 4.7, we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48806
--- Comment #6 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-22
21:39:51 UTC ---
Author: kkojima
Date: Thu Mar 22 21:39:45 2012
New Revision: 185714
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185714
Log:
Backported from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48596
--- Comment #9 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-22
21:39:51 UTC ---
Author: kkojima
Date: Thu Mar 22 21:39:45 2012
New Revision: 185714
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185714
Log:
Backported from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48596
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #35 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-20
01:45:14 UTC ---
(In reply to comment #34)
Interesting, thanks! I'll also test your patch and send it around, OK?
OK, thanks!
I'm a bit confused... was the issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #33 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-15
07:52:21 UTC ---
(In reply to comment #31)
Created attachment 26859 [details]
testresult on sh4-unknown-linux-gnu [trunk revision 185088].
FYI, looking into the libstdc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52479
--- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-16
03:21:08 UTC ---
There is no concrete definition of -ffast-math and users will have
different expectations. Numerical programs for astrodynamics may
expect precisions even
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #29 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-09
08:40:32 UTC ---
(In reply to comment #28)
Regtest on sh4-unknown-lunix-gnu has been done successfully.
Oleg, your patch is pre-approved.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #31 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-09
10:36:31 UTC ---
Created attachment 26859
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26859
A test result
testresult on sh4-unknown-linux-gnu [trunk revision
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #24 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-08
11:11:32 UTC ---
(In reply to comment #23)
Kaz, if you have some time, could you try it out in your setup, too please?
On trunk revision 185088, for sh4-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #25 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-08
11:13:39 UTC ---
Created attachment 26854
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26854
worked .s file associated_4_good.s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #26 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-08
11:16:39 UTC ---
Created attachment 26855
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26855
unworked .s file associated_4_bad.s
I've attached .s files against
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
CC||olegendo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52535
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #28 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-09
01:44:52 UTC ---
(In reply to comment #27)
Created attachment 26858 [details]
Patch for the patch
Looks all fortran regressions gone away. I'll run full tests
on sh4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52503
--- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-07
22:06:28 UTC ---
Author: kkojima
Date: Wed Mar 7 22:06:25 2012
New Revision: 185081
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185081
Log:
PR target/52503
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #15 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-06
08:49:27 UTC ---
(In reply to comment #14)
I've run the testsuite on rev 184966 (without fortran though), but the
failures
that you've mentioned did not show up
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #17 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-06
10:36:01 UTC ---
Created attachment 26837
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26837
preprocessed file ctype_configure_char.i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #18 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-06
10:37:13 UTC ---
Created attachment 26838
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26838
worked .s file ctype_configure_char_good.s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #19 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-06
10:38:22 UTC ---
Created attachment 26839
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26839
unworked .s file ctype_configure_char_bad.s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #20 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-06
10:40:31 UTC ---
(In reply to comment #16)
Can we keep the r184966 changes anyways? I will keep an eye on these failures
whether I can reproduce them. If you have some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52503
--- Comment #2 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-06
23:18:16 UTC ---
Created attachment 26845
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26845
A patch
config/sh/linux.h requires a few changes too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48806
--- Comment #4 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-06
00:26:30 UTC ---
It looks that the testcase came from a FreeBSD kernel code:
http://www.leidinger.net/FreeBSD/dox/net80211/html/d7/d8d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52479
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
CC||aoliva at gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52480
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-05
05:30:18 UTC ---
Created attachment 26831
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26831
A possible patch
Looks to be a similar problem with PR52394.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52483
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-05
05:33:39 UTC ---
(In reply to comment #0)
Maybe a few peepholes would help here?
Sure. Peephole looks to be reasonable for this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48596
--- Comment #6 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-02
23:59:16 UTC ---
Author: kkojima
Date: Fri Mar 2 23:59:08 2012
New Revision: 184844
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184844
Log:
PR target/48596
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48806
--- Comment #2 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-02
23:59:17 UTC ---
Author: kkojima
Date: Fri Mar 2 23:59:08 2012
New Revision: 184844
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184844
Log:
PR target/48596
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52441
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-01
22:00:14 UTC ---
(In reply to comment #0)
The sign/zero extensions in the caller (_xx) are not emitted when using the
original Renesas ABI (-mrenesas), which is correct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11736
--- Comment #9 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-01
22:03:09 UTC ---
I think so too.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468
--- Comment #9 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-02-29
23:18:23 UTC ---
(In reply to comment #8)
Perhaps. Anyway looks fine to me except one minor failure
on sh64-elf:
xsh64-elf-combined/combined/libgcc/libgcc2.c: In function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52394
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-02-28
00:37:56 UTC ---
I guess that now these tests require -fno-strict-volatile-bitfields,
though it isn't enough to avoid failures. It looks that something
wrong happens
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52049
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-01-30
00:15:16 UTC ---
(In reply to comment #0)
I'm not sure whether this is actually a problem of the SH back-end or of some
middle-end passes. It happens for all sub-targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #11 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-12-30
03:24:01 UTC ---
(In reply to comment #10)
If OK, I'd like to change it from target PR to middle-end PR.
Sure.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #7 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-12-28
22:25:48 UTC ---
(In reply to comment #3)
I haven't ran all tests on it yet, but CSiBE shows average code size reduction
of approx. -0.1% for -m4* with some code size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51340
--- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-12-28
22:31:27 UTC ---
(In reply to comment #2)
Uhm, yes...
The title should have been Enable -mfused-madd by -ffast-math
Do you mean something like this?
--- ORIG/trunk/gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #21 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-12-12
22:08:18 UTC ---
(In reply to comment #20)
As far as I could observe it, this is mainly triggered by the following in
sh_legitimate_index_p:
+ if (mode == QImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #19 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-12-11
23:57:13 UTC ---
(In reply to comment #18)
The results look way better now. I've tested your latest patch for
sh4-unknown-linux-gnu and found no new regressions for gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51351
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50814
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51337
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50814
--- Comment #6 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-12-01
23:02:08 UTC ---
Author: kkojima
Date: Thu Dec 1 23:01:58 2011
New Revision: 181896
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181896
Log:
PR target/50814
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51337
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-11-29
22:52:59 UTC ---
Author: kkojima
Date: Tue Nov 29 22:52:55 2011
New Revision: 181823
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181823
Log:
PR target/51337
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51351
Bug #: 51351
Summary: undefined reference to __sync_fetch_and_ior_4
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50814
--- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-11-28
13:43:16 UTC ---
BTW, when regtesting, I've found that there are many ICEs at -O0.
A typical one is gcc.c-torture/compile/2923-1.c with -m2a -O0:
...: error: insn does
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51340
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-11-28
23:09:32 UTC ---
(In reply to comment #0)
Is there any particular reason why this should not be enabled by
default for SH targets that support the FMAC insn?
PR29100
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #9 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-11-28
23:29:57 UTC ---
(In reply to comment #8)
Specifying -fno-tree-forwprop doesn't seem to have any effect on these cases.
For that function, -fdump-tree-all shows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50814
--- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-11-28
00:09:17 UTC ---
(In reply to comment #2)
According to the SW manual document rej09b0051_sh2a.pdf the SHAD and SHLD
insns
have the same 2-byte format as on SH3:
SHAD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50814
--- Comment #4 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-11-28
04:31:51 UTC ---
Created attachment 25927
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25927
A patch
I'm testing the attached patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-11-22
22:33:43 UTC ---
return (a != b || a != c) ? b : c;
test_func_0_NG and test_func_1_NG cases are related with the target
implementation of cstoresi4.
The middle end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51241
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-11-21
01:52:22 UTC ---
Please put the description of the problem into the trail itself
instead of attachment next time.
The problem looks to be splitted into several issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50694
--- Comment #10 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-11-13
23:00:15 UTC ---
Author: kkojima
Date: Sun Nov 13 23:00:10 2011
New Revision: 181340
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=181340
Log:
PR target/50694
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
--- Comment #20 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-11-09
14:07:01 UTC ---
(In reply to comment #19)
So I think the workaround from r105496 can be safely removed now and then
close
this bug as fixed since 4.3.0
I've
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #14 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-11-02
00:57:59 UTC ---
(In reply to comment #13)
Apparently this makes something believe that loading the FPUL register from a
displacement address is possible, which
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #7 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-30
23:36:27 UTC ---
(In reply to comment #6)
I wonder whether there might be something in the target code that suggests the
early optimizers to do that? I've tried playing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #12 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-27
22:30:39 UTC ---
It seems that base_reg+index_reg addressing requires special
handling in RA and the move insn like
(define_insn *movqi_m_reg_reg_store
[(set (mem:QI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #8 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-27
02:31:35 UTC ---
(In reply to comment #7)
Created attachment 25622 [details]
asmcons and ira pass log for the reload failure of z insn constraint
The original insn 13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-24
23:05:08 UTC ---
(In reply to comment #4)
It seems that clobbering R0 in that expander is simply papering
over the real problem. Although the reload issue beyonds me,
.ira
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50694
--- Comment #8 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-20
22:40:27 UTC ---
(In reply to comment #7)
This problem doesn't require the theoretical/mathematical
completeness. There are many inappropriate combinations
of options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50814
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-21
00:24:36 UTC ---
(In reply to comment #0)
It is also not clear to me why SH2A seems to require different handling for
dynamic shifts than SH3 or SH4...
Will be slightly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #4 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-19
21:36:56 UTC ---
(In reply to comment #3)
USE_LOAD_POST_INCREMENT and USE_STORE_PRE_DECREMENT are used only
in move_by_pieces which is for some block operations when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50694
--- Comment #4 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-18
22:24:32 UTC ---
(In reply to comment #3)
There are no real uses of SH1/SH2/SH2E/SH3E cores anymore, I think.
I agree that taking care of -m2e is not worth. Perhaps same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50694
--- Comment #6 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-18
22:50:19 UTC ---
(In reply to comment #5)
I'll send in a patch with a couple of other cosmetic changes later, OK?
Please go for it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50694
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-16
23:33:40 UTC ---
GCC makes usual mem accesses into those with post_inc/pre_dec at
auto_inc_dec pass. I guess that auto_inc_dec pass can't find
post_inc insns well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-17
00:29:55 UTC ---
This is a known issue. See the comment just before sh.c:sh_legitimate_index_p.
Unfortunately, I guess this PR might be marked as WONTFIX.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #2 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-17
00:32:39 UTC ---
*** Bug 50750 has been marked as a duplicate of this bug. ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50750
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-17
00:51:15 UTC ---
(In reply to comment #2)
Yeah, I know this has been around for a while.
I'd like to take my chances anyway :)
Welcome to the spill-failure-for-class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #12 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-14
23:06:06 UTC ---
(In reply to comment #11)
Created attachment 25491 [details]
Proposed patch including test case
Looks fine. A very minor style nits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #13 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-15
02:32:56 UTC ---
Author: kkojima
Date: Sat Oct 15 02:32:53 2011
New Revision: 180020
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180020
Log:
PR target/49263
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #10 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-11
01:47:03 UTC ---
(In reply to comment #9)
3) only zero_extract special cases
looks to be dominant.
I'm sorry, I forgot to mention that it was just a proof of concept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #8 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-10-10
01:31:42 UTC ---
(In reply to comment #7)
Option 2 seems more robust even if it seems less effective, what do you think?
Another combine pass to reduce size less than 0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49486
--- Comment #2 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-09-28
21:43:06 UTC ---
Author: kkojima
Date: Wed Sep 28 21:43:01 2011
New Revision: 179320
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179320
Log:
PR target/49486
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50287
--- Comment #6 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-09-07
00:26:13 UTC ---
(In reply to comment #4)
Testcase that fails on i686-linux for me.
FYI, the testcase is failing also for arm-eabi, mips-elf and sh-elf.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50287
Bug #: 50287
Summary: FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c
compilation, -O2 -flto
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50068
--- Comment #6 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-08-17
22:49:21 UTC ---
Author: kkojima
Date: Wed Aug 17 22:49:18 2011
New Revision: 177839
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=177839
Log:
PR target/50068
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50068
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
Target|shle--netbsdelf |sh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49977
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49686
--- Comment #6 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-08-04
12:18:09 UTC ---
It seems that the problem comes back on trunk revision 177305
for SH. There are many EH test failures which went away with
-fno-delayed-branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49686
--- Comment #8 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-08-04
13:57:14 UTC ---
Thanks for checking cris-elf. I'd like to open a new PR.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49977
Summary: [4.7 Regression] CFI notes are missed for delayed slot
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49977
--- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-08-04
21:18:55 UTC ---
(In reply to comment #2)
Kaz, can you enumerate some specific tests that are now failing?
I've got
FAIL: gcc.dg/cleanup-10.c execution test
FAIL: gcc.dg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49982
Summary: [4.7 Regression] ICE in fixup_args_size_notes, at
expr.c:3625
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48596
--- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-08-02
23:53:30 UTC ---
I was trying to find a way that solves it without penalizing -O2
or the higher cases, though it's not easy to me. It seems that
the target's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49880
--- Comment #2 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-07-31
23:01:17 UTC ---
Author: kkojima
Date: Sun Jul 31 23:01:14 2011
New Revision: 176990
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176990
Log:
PR target/49880
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49880
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
Target|shle--netbsdelf |sh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49686
Summary: [4.7 Regression] CFI notes are missed for delayed slot
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: EH
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49686
--- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-07-09
21:13:52 UTC ---
Thanks for the quick fix!
(In reply to comment #1)
Does the regression look something like this?
For sh, the failures were
FAIL: g++.dg/compat/eh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468
--- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-06-27
06:39:40 UTC ---
Argh, I also missed clobbers. Looks fine to me now, except
that insn_and_split *negdi2 forgot to set constraints and
some minor coding style issues below
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #6 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-06-27
05:14:36 UTC ---
(In reply to comment #5)
Anyway, why not just add all the currently known-to-work cases? What are your
concerns regarding that? I can imagine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #4 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-06-22
22:34:04 UTC ---
Yes, that peephole doesn't catch all the patterns which could
make tst #imm8,r0 use. Perhaps it would be a good idea to get
numbers for the test like
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468
Kazumoto Kojima kkojima at gcc dot gnu.org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49307
--- Comment #4 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-06-16
22:02:48 UTC ---
Author: kkojima
Date: Thu Jun 16 22:02:45 2011
New Revision: 175116
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175116
Log:
PR target/49307
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49307
--- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-06-16
22:08:23 UTC ---
Author: kkojima
Date: Thu Jun 16 22:08:20 2011
New Revision: 175118
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175118
Log:
PR target/49307
401 - 500 of 551 matches
Mail list logo
