http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54685
--- Comment #6 from Kazumoto Kojima 2013-02-05
00:09:01 UTC ---
(In reply to comment #5)
> FAIL: gcc.target/sh/pr54685.c scan-assembler-not not
>
> I'm curious why this fails. On my sh-elf / newlib config it passes. Do you
> have any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56451
Bug #: 56451
Summary: [4.8 regression] Wrong code for
gcc.c-torture/execute/941015-1.c on SH
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56451
--- Comment #1 from Kazumoto Kojima 2013-02-26
00:32:07 UTC ---
Before dbr_schedule, the insns look like:
r1 := 0xc000
(A)if (r5 > r1) goto L0
(B)if (r5 < r1) goto L1
r1 := 0x8000
(C)if (r4 >= r1) goto L0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56529
Kazumoto Kojima changed:
What|Removed |Added
CC||kkojima at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40797
--- Comment #11 from Kazumoto Kojima 2013-03-06
00:45:48 UTC ---
I've tried current 4.6/4.7/4.8 with --enable-checking=df on sh4-linux
and found that the ice has gone for both original and reduced test cases.
I'd like to close this PR unle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40797
--- Comment #13 from Kazumoto Kojima 2013-03-06
01:08:19 UTC ---
(In reply to comment #12)
> I'd like to add a test case to the test suite for this PR first, if that's OK.
Sounds good idea.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55146
--- Comment #6 from Kazumoto Kojima 2013-03-10
00:23:38 UTC ---
(In reply to comment #5)
I think that your observation is correct. It looks the offset_unsigned
field is handled wrongly somewhere on 4.7 and earlier. I can't find
suspic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49880
--- Comment #6 from Kazumoto Kojima 2013-03-26
01:32:41 UTC ---
(In reply to comment #5)
> OK to close this PR?
OK with me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423
--- Comment #25 from Kazumoto Kojima 2012-08-09
22:44:41 UTC ---
(In reply to comment #24)
> I'm not sure whether this should be back ported to 4.6.x or 4.7.x or not.
> Kaz,
> what do you think?
Looks a bit intrusive for the stable branches.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #9 from Kazumoto Kojima 2012-08-10
00:39:50 UTC ---
(In reply to comment #8)
> #define SH_DYNAMIC_SHIFT_COST (TARGET_DYNSHIFT ? 1 : 20)
Sounds reasonable. Perhaps some historical reason for the original
one, though I don't know why.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54272
--- Comment #2 from Kazumoto Kojima 2012-08-16
11:23:42 UTC ---
(In reply to comment #1)
For linux environment, libc's abort function is a rather complex
function and trapa handler should do equivalent things to keep
complete binary compatibilit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54272
--- Comment #4 from Kazumoto Kojima 2012-08-16
13:00:37 UTC ---
(In reply to comment #3)
> How about small variation:
Sounds reasonable to me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54418
Bug #: 54418
Summary: [4.8 Regression] [SH] Invalid operands for opcode
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54418
--- Comment #3 from Kazumoto Kojima 2012-08-31
10:51:48 UTC ---
(In reply to comment #2)
> Unfortunately I was not able to reproduce this case without the -fopenmp
> option, and that option requires threads, which are not available on the
> sh-s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #50 from Kazumoto Kojima 2012-08-31
10:54:44 UTC ---
(In reply to comment #49)
> Kaz, if you have some time, could you please gather some CSiBE runtime numbers
> for '-mpretend-cmove' and without it?
Here is the runtime result with -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54429
--- Comment #1 from Kazumoto Kojima 2012-08-31
10:59:44 UTC ---
(In reply to comment #0)
I don't know the history about it. I guess that the original
intention would be to use FP registers as fast memories for
integers, though I'm wrong about i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33135
--- Comment #13 from Kazumoto Kojima 2012-09-02
22:43:07 UTC ---
(In reply to comment #12)
> Kaz, would it be OK to remove the whole function 'sh_option_init_struct' from
> gcc/common/sh/sh-common.c ?
Definitely.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52483
--- Comment #3 from Kazumoto Kojima 2012-09-18
12:25:52 UTC ---
(In reply to comment #2)
> If that is the only reason for rejecting volatile mems, then I think it would
> be OK to match volatile mems in the load/store expanders for SH, since ther
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54686
--- Comment #26 from Kazumoto Kojima 2012-09-24
00:16:19 UTC ---
(In reply to comment #6)
FYI, same on sh-linux, though my glibc for gcc tests is a bit dated. Ugh.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457
--- Comment #4 from Kazumoto Kojima 2012-09-25
00:53:23 UTC ---
(In reply to comment #3)
> I don't know how linux/glibc have been handling atomic ops on SH2 or SH2A, but
> I've got an idea that would work in a bare-metal setup.
There i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54699
Bug #: 54699
Summary: [4.8 Regression] [SH] gfortran.dg/class_array_9.f03
ICEs
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457
--- Comment #6 from Kazumoto Kojima 2012-09-25
11:33:09 UTC ---
(In reply to comment #5)
> Does this make sense?
Sounds reasonable.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457
--- Comment #9 from Kazumoto Kojima 2012-10-01
23:29:59 UTC ---
(In reply to comment #8)
> Would that be OK to do?
Yes, that sounds good for maintenance.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457
--- Comment #12 from Kazumoto Kojima 2012-10-02
02:17:51 UTC ---
(In reply to comment #11)
> Created attachment 28321 [details]
> cleanup libgcc/config/sh/linux-atomic
Works fine for me.
> (three leading underscores)
You might get
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54699
--- Comment #5 from Kazumoto Kojima 2012-10-10
00:03:54 UTC ---
(In reply to comment #4)
> I'm wondering whether there is anything after reload that actually needs
> address validation. I guess that after the reload pass pretty much every
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54602
--- Comment #4 from Kazumoto Kojima 2012-10-10
22:44:17 UTC ---
(In reply to comment #3)
> Kaz, could you please also have a pre-look at this? I might be missing
> something...
Looks reasonable to me, though I also might be missing som
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54760
--- Comment #6 from Kazumoto Kojima 2012-10-12
00:13:51 UTC ---
(In reply to comment #5)
> Kaz, do you happen to know something regarding this matter?
My SH4 software manual says for STC that all stc/stc.l instructions
except stc gbr,rn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54760
--- Comment #8 from Kazumoto Kojima 2012-10-12
00:43:09 UTC ---
(In reply to comment #7)
> * Slot illegal instruction exception <<< but which insns?!?!
Ah, you could see a list in that manual rej09b0003_sh4a.pdf,
pdf page 108, Slot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34777
--- Comment #9 from Kazumoto Kojima 2012-10-15
23:04:13 UTC ---
(In reply to comment #8)
> Since this doesn't seem to be an issue on current trunk (4.8), can we close
> this PR?
The test case in PR 34807 which is marked as a duplicate o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54963
Bug #: 54963
Summary: Wrong code generated for
libgfortran/generated/eoshift3_8.c on SH
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54963
Kazumoto Kojima changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54963
--- Comment #4 from Kazumoto Kojima 2012-10-29
00:59:37 UTC ---
(In reply to comment #3)
> Created attachment 28551 [details]
> Proposed patch
>
> This patch fixes the problem, by using 'emit_move_insn' instead of manually
> doing the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54963
--- Comment #7 from Kazumoto Kojima 2012-10-30
02:46:09 UTC ---
(In reply to comment #6)
Agreed, patch is pre-approved.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54963
Kazumoto Kojima changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41993
--- Comment #5 from Kazumoto Kojima 2012-11-05
09:13:57 UTC ---
(In reply to comment #4)
> In -O0 case, we broke discovery loop too early, so we can't find all return
> regs. I would argue, that we should ignore non-relevant pseudos with:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41993
--- Comment #7 from Kazumoto Kojima 2012-11-05
10:19:16 UTC ---
(In reply to comment #6)
> Will you submit the patch to gcc-patches, please?
OK, I'll send it to the list when the tests on i686-linux and sh
are done successfully.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41993
--- Comment #8 from Kazumoto Kojima 2012-11-06
09:16:41 UTC ---
Author: kkojima
Date: Tue Nov 6 09:16:34 2012
New Revision: 193210
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193210
Log:
PR target/41993
* mode-swit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49220
--- Comment #6 from Kazumoto Kojima 2012-11-06
23:21:46 UTC ---
I'll post it when the usual tests on x86 and sh are done.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49220
--- Comment #7 from Kazumoto Kojima 2012-11-07
10:48:22 UTC ---
Author: kkojima
Date: Wed Nov 7 10:48:12 2012
New Revision: 193289
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193289
Log:
PR middle-end/49220
* mode-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49220
Kazumoto Kojima changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41993
Kazumoto Kojima changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44341
--- Comment #6 from Kazumoto Kojima 2010-12-22
13:19:40 UTC ---
I've tried the patch on x86 cross sh4-unknown-linux-gnu. It looks
all possible combinations of --with-gmp and --with-target-gmp
work as expected.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47239
Summary: (int)&func & 3 is always optimized to 0 on some
targets
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47239
--- Comment #3 from Kazumoto Kojima 2011-01-11
23:14:45 UTC ---
I've tried 168661 with arm, hppa and sh64 cc1's. The problem
has gone away on all these 3 targets. Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44341
--- Comment #10 from Kazumoto Kojima 2011-01-14
00:11:39 UTC ---
(In reply to comment #9)
> Another approach to fix the problem
It looks that the patch fixes the issue, though I've got
...
../LOCAL/trunk/configure: line 5232: ${with_target_mpc_
CC||kkojima at gcc dot gnu.org
Ever Confirmed|0 |1
Summary|error: unable to find a |[4.3 Regression] unable to
|register to spill in class |find a register to spill in
|'FPUL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57339
--- Comment #1 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #0)
> One idea for now would be to emit fixed ISR prologue / epilogue asm blocks
> that deal with the FP regs, if FP regs need to be saved/restored for an ISR.
This would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
--- Comment #12 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #11)
> Would it be OK to add this test case to gcc.target/sh/torture and close this
> PR?
Please go ahead.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42947
--- Comment #3 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #2)
> Kaz, maybe you have an idea whether/how this could be improved?
I'm also using symbolic links for those issues and have no good
idea for multilibs handling itself.
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kkojima at gcc dot gnu.org
Target: sh*-*-*
There are many new execution errors on SH after the revision 201833
r201883 | tejohnson | 2013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #67 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #66)
> Kaz, the "WIP status" aside, would you be OK with something like that?
Yep. Sounds good to me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58221
Kazumoto Kojima changed:
What|Removed |Added
CC||kkojima at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58221
--- Comment #6 from Kazumoto Kojima ---
(In reply to Teresa Johnson from comment #5)
> Kaz, are you planning to apply your patch, or do you want me to test
> it and commit it? I'm kicking off x86_64 tests with it right now, but
> I didn't get the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58220
Kazumoto Kojima changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
|NEW
Last reconfirmed||2011-08-16
CC||kkojima at gcc dot gnu.org
Ever Confirmed|0 |1
Known to fail||4.4.6, 4.5.3, 4.6.1, 4.7.0
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50068
--- Comment #6 from Kazumoto Kojima 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=gcc&view=rev&rev=177839
Log:
PR target/50068
* config/sh/sh.c (sh_ou
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: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50287
--- Comment #6 from Kazumoto Kojima 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=49486
--- Comment #2 from Kazumoto Kojima 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=gcc&view=rev&rev=179320
Log:
PR target/49486
* config/sh/sh.md (negd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #8 from Kazumoto Kojima 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% on one target
would be n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #10 from Kazumoto Kojima 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 hack
> of mine, just to se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #12 from Kazumoto Kojima 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:
> + if (GET_CODE (XEXP (x, 0)) == AN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #13 from Kazumoto Kojima 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=gcc&view=rev&rev=180020
Log:
PR target/49263
* config/sh/sh.h (ZERO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50694
Kazumoto Kojima changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #1 from Kazumoto Kojima 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 in that case because other tree/rtl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #1 from Kazumoto Kojima 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 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 changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #3 from Kazumoto Kojima 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-'R0_REGS' club :-)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50694
--- Comment #4 from Kazumoto Kojima 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 for
-m1. Anyway, your chang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50694
--- Comment #6 from Kazumoto Kojima 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=50749
--- Comment #4 from Kazumoto Kojima 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
MOVE_BY_PIECES_P says OK. They
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50694
--- Comment #8 from Kazumoto Kojima 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 which don't get any warning wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50814
--- Comment #1 from Kazumoto Kojima 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 different because sh2a's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #5 from Kazumoto Kojima 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 dump file about that impos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #8 from Kazumoto Kojima 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 was
(insn 13 12 14 3 (se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #12 from Kazumoto Kojima 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 (plus:SI (match_operand:SI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #7 from Kazumoto Kojima 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 with the TARGET_ADDRESS_C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #14 from Kazumoto Kojima 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 is of course not the case. Howev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
--- Comment #20 from Kazumoto Kojima 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 confirmed that there are no ICEs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53250
Bug #: 53250
Summary: [4.8 Regression] [SH] ICE: in change_address_1, at
emit-rtl.c:2018
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53250
--- Comment #5 from Kazumoto Kojima 2012-05-07
10:19:47 UTC ---
(In reply to comment #4)
Although the top level "make -k check" doesn't complete yet,
the failures for C & C++ went away. I'll mark this PR as fixed
when the test completes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53250
Kazumoto Kojima changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53268
--- Comment #1 from Kazumoto Kojima 2012-05-08
02:22:13 UTC ---
Looks like PR53209. BTW, now PR53209 blocks my sh4-unknown-linux-gnu
build with the failure during compiling libstdc++v3. Alex's patch
http://gcc.gnu.org/ml/gcc-patches/2012-05/ms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511
--- Comment #3 from Kazumoto Kojima 2012-06-03
22:48:17 UTC ---
(In reply to comment #2)
It would be better to ask these generic issues to the experts
on the gcc list, I think. About the SH specific one,
> Effectively, the '*macsf3' / 'mac_medi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511
--- Comment #5 from Kazumoto Kojima 2012-06-05
04:47:22 UTC ---
(In reply to comment #4)
> This patch adds the FMA patterns and aligns the SH target with the
> -mfused-madd
> / -mno-fused-madd option handling in other targets.
Make -mfused-madd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511
--- Comment #6 from Kazumoto Kojima 2012-06-05
09:21:49 UTC ---
> It seems that __builtin_sh_media_FMAC_S is broken on trunk
> in the first place, though I can test it only on sh64-elf
> environment now. Anyway the patch should OK in this regard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511
--- Comment #9 from Kazumoto Kojima 2012-06-05
22:35:28 UTC ---
(In reply to comment #7)
> Making -mfused-madd a no-op with special handling will only differ in the (*)
> marked case. Is this what you had in mind?
Yes. -mfused-madd is for a mi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53511
--- Comment #11 from Kazumoto Kojima 2012-06-05
23:49:48 UTC ---
(In reply to comment #10)
> Yeah, probably. I also don't care that much which option is on/off by
> default.
> I just wanted it to be aligned with the other targets and the overa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621
--- Comment #4 from Kazumoto Kojima 2012-06-10
23:24:57 UTC ---
Oleg's patch looks the right thing to do. Perhaps
if (PREFERRED_DEBUGGING_TYPE != DWARF2_DEBUG)
flag_omit_frame_pointer = 0;
might a bit straight representation indicati
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621
--- Comment #6 from Kazumoto Kojima 2012-06-12
00:05:05 UTC ---
I thought that -pg and -fomit-frame-pointer are always incompatible.
Agree with the possible issues for old unwinders.
I've forgotten that sh coff targets went away. Then, removing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621
--- Comment #9 from Kazumoto Kojima 2012-06-12
13:56:37 UTC ---
The patch is pre-approved. Thanks for looking into the issue
thoroughly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621
--- Comment #11 from Kazumoto Kojima 2012-06-13
06:52:20 UTC ---
Looks a problem with the test. It should be tweaked with adding
#elif defined (__sh__)
# define SIZE 252
for frame pointer save area.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621
--- Comment #13 from Kazumoto Kojima 2012-06-13
07:39:13 UTC ---
I thought that the test depends the optimization level and it assumes
-O0. I agree that enforcing -fomit-frame-pointer gives more deterministic
result, though it could break curren
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621
--- Comment #16 from Kazumoto Kojima 2012-06-13
08:09:45 UTC ---
> +/* { dg-options "-fstack-usage -fomit-frame-pointer" { target { sh-*-* } } }
*/
Looks OK. Pre-approved.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621
--- Comment #18 from Kazumoto Kojima 2012-06-13
08:48:40 UTC ---
Please go ahead with the one liner in #15. It looks more
informative than a magic number 256 - 4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53621
--- Comment #24 from Kazumoto Kojima 2012-06-20
08:33:29 UTC ---
I've changed it as requested. Apllied on 4.[678].
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53512
--- Comment #1 from Kazumoto Kojima 2012-05-29
02:39:28 UTC ---
(In reply to comment #0)
Sounds good.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53886
--- Comment #5 from Kazumoto Kojima 2012-07-08
13:41:09 UTC ---
(In reply to comment #4)
> The patch below fixes this particular crash, but I'm not sure whether it is
> the right thing to do in this case.
Looks fine to me except that the line
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53886
--- Comment #7 from Kazumoto Kojima 2012-07-08
13:59:00 UTC ---
(In reply to comment #6)
> Maybe backport it to 4.7, too?
If it's a regression also on 4.7. The test case doesn't fail with 4.7.1
on my environment, though.
1 - 100 of 667 matches
Mail list logo
