[Bug target/79462] [7 Regression] sh: Stack smashing detected when building __ashrdi3 in libgcc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79462 Kazumoto Kojima changed: What|Removed |Added CC||kkojima at gcc dot gnu.org

[Bug target/79112] [SH] libgo/go/exp/terminal/util.go:70:23: error: integer constant overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79112 --- Comment #5 from Kazumoto Kojima --- It seems that the error message says all. TIOCGWINSZ is defined as #define TIOCGWINSZ0x80087468 /* _IOR('t', 104, struct winsize) */ in the SH kernel header asm/ioctls.h. Perhaps you could

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633 --- Comment #20 from Kazumoto Kojima --- I've applied a quick fix. I'd like to keep this open for further checks.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633 --- Comment #19 from Kazumoto Kojima --- Author: kkojima Date: Tue Jan 17 04:07:51 2017 New Revision: 244516 URL: https://gcc.gnu.org/viewcvs?rev=244516=gcc=rev Log: PR target/78633 * config/sh/sh.md (cmpeqsi_t+1): Call copy_rtx

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633 --- Comment #14 from Kazumoto Kojima --- No problem. I can continue nightly build with a minimal change diff --git a/gcc/config/sh/sh.md b/gcc/config/sh/sh.md index c6956a0..edadba7 100644 --- a/gcc/config/sh/sh.md +++ b/gcc/config/sh/sh.md @@

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633 --- Comment #12 from Kazumoto Kojima --- Hmm... From https://gcc.gnu.org/onlinedocs/gccint/Sharing.html#Sharing the above patch looks wrong. Perhaps the splitter in problem might have to take care of subreg case even when referencing a reg rtx

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633 --- Comment #11 from Kazumoto Kojima --- Created attachment 40271 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40271=edit reduce testcase With -O1, sh4-linux compiler makes insns (insn 67 150 165 5 (set (reg:SI 239) (and:SI

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633 --- Comment #10 from Kazumoto Kojima --- Ah, don't mind. Your patch accidentally hides this PR. Now the SH build failure comes back on trunk :-)

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633 --- Comment #6 from Kazumoto Kojima --- I've tried a bi-sect on git tree. The ICE went away with commit c95f3fa2db12f22bbb2158d18c95f6714b4292b8 Author: krebbel Date: Fri Dec 2 08:32:40 2016

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633 --- Comment #4 from Kazumoto Kojima --- Now I can't reproduce the ICEs for the revision 243217. They failed for the revision 243091. I'm not sure whether the issue is false positive or not. I'd like to keep this PR for a while.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633 --- Comment #2 from Kazumoto Kojima --- Looks not enough. Even with the patch, I got a similar ICE for lto case in testsuite: FAIL: gcc.dg/atomic/stdatomic-op-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error)

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633 Kazumoto Kojima changed: What|Removed |Added CC||olegendo at gcc dot gnu.org ---

[Bug target/78633] New: [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kkojima at gcc dot gnu.org Target Milestone: --- Target: sh*-*-* Build fails during compiling libgcc

[Bug target/78426] [7 Regression] wrong code with strncmp on SH

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78426 --- Comment #5 from Kazumoto Kojima --- Fixed on 5/6 branches too.

[Bug target/78426] [7 Regression] wrong code with strncmp on SH

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78426 --- Comment #4 from Kazumoto Kojima --- Author: kkojima Date: Tue Nov 29 23:23:30 2016 New Revision: 242982 URL: https://gcc.gnu.org/viewcvs?rev=242982=gcc=rev Log: Backported from mainline 2016-11-19 Kaz Kojima

[Bug target/78426] [7 Regression] wrong code with strncmp on SH

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78426 --- Comment #3 from Kazumoto Kojima --- Author: kkojima Date: Tue Nov 29 23:20:28 2016 New Revision: 242981 URL: https://gcc.gnu.org/viewcvs?rev=242981=gcc=rev Log: Backported from mainline 2016-11-19 Kaz Kojima

[Bug target/66358] [5/6/7 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66358 --- Comment #24 from Kazumoto Kojima --- (In reply to David Binderman from comment #23) > Problem seems to have gone away with gcc version 6.1.1, dated 20160621 Thanks for your report. I've confirmed that the testcases don't fail with the head

[Bug target/78426] [7 Regression] wrong code with strncmp on SH

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78426 --- Comment #1 from Kazumoto Kojima --- Author: kkojima Date: Sat Nov 19 13:59:47 2016 New Revision: 242622 URL: https://gcc.gnu.org/viewcvs?rev=242622=gcc=rev Log: PR target/78426 * config/sh/sh-mem.cc (sh_expand_cmpnstr): Use

[Bug target/78426] New: [7 Regression] wrong code with strncmp on SH

Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kkojima at gcc dot gnu.org Target Milestone: --- Target: sh-*-* Execution fails for gcc.c-torture/execute/20050218-1.c here: if (strncmp (x + j, a[i], strlen (a[i])) != 0

[Bug target/77610] [sh] memcpy is wrongly inlined even for large copies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77610 --- Comment #3 from Kazumoto Kojima --- Created attachment 39642 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39642=edit patch to add default threshold 256 sounds reasonable to me. Does the attached patch work for you?

[Bug target/77610] [sh] memcpy is wrongly inlined even for large copies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77610 Kazumoto Kojima changed: What|Removed |Added CC||kkojima at gcc dot gnu.org

[Bug target/71045] [SH] gcc.dg/torture/pr68264.c -O0 and -Os failures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71045 --- Comment #1 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #0) > Kaz, do you know what's going wrong there? Some silent wrong code related > to fenv maybe? Maybe, though I have no idea for what is going on. You can see that

[Bug target/70416] [SH]: error: 'asm' operand requires impossible reload when building ruby2.3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70416 --- Comment #12 from Kazumoto Kojima --- Created attachment 38105 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38105=edit reduced test case for -O2 -fpic reload1.c:reload_as_needed function generates the error message with error_for_asm

[Bug target/70216] [SH] Implement __builtin_trap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216 --- Comment #2 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #1) > For sh4-linux this option should be enabled by default with some useful trap > number value. Which trap number should be used in this case? I think that # less

[Bug middle-end/23868] [4.9/5/6 regression] builtin_apply uses wrong mode for multi-hard-register return values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868 --- Comment #29 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #28) > Can anybody comment on the state of this problem here? Were the two commits > in comment #2 and comment #3 merged into mainline at some point? AFAIK, those

[Bug rtl-optimization/29854] reload_combine looses track of uses

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29854 --- Comment #7 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #6) > Looking at the current code in postreload.c, it seems that the patch somehow > made it into mainline at some point. Although some of the lines now look a > bit

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #19 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #17) > Kaz, what do you think? LGTM and looks like we have no choice for 5/4.9.

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #16 from Kazumoto Kojima --- (In reply to Rich Felker from comment #15) Maybe. There are other cases of address computations which could be shared or simplified, as you know. Again very restrictive branches and loads will make

[Bug target/69713] Invalid code of optimization in SH

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69713 --- Comment #6 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #5) > Anyway, I think this could be applied to GCC 5 and GCC 6. Kaz, what do you > think? Looks fine to me. Please go ahead.

[Bug target/67260] [sh] Register spill bug for sibcall+complex+softfloat

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #14 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #13) > Good question indeed. Kaz, maybe you remember anything? With my vague recollection, they were already there when I had looked into them for the first time. I

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #11 from Kazumoto Kojima --- (In reply to Kazumoto Kojima from comment #10) > I'll report back when the regression test currently running is done. I've confirmed that there are no new failures with the new patch on

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #10 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #9) > At the current (lack of) pace I don't know when all of that will be done. > So my idea was to at least reduce the R0 problem for users by making LRA the >

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #7 from Kazumoto Kojima --- (In reply to Kazumoto Kojima from comment #6) I've changed the predicate of the 2nd operand to arith_operand instead of const_int_operand in your patch and run testsuite. There is one new failure: FAIL:

[Bug target/68277] [5] [SH]: error: insn does not satisfy its constraints when compiling erlang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #1 from Kazumoto Kojima --- Created attachment 36686 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36686=edit reduced test case for -O1 It fails on trunk too. It seems that the problematic add insn (insn 765 764 300 46 (set

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 Kazumoto Kojima changed: What|Removed |Added Summary|[5] [SH]: error: insn does |[5/6 Regression] [SH]:

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #4 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #3) > I haven't read reload.*, but my speculation is that if something in reload > instantiates that rtx with an imm8 constant to calculate addresses, it might > also

[Bug target/68277] [5/6 Regression] [SH]: error: insn does not satisfy its constraints when compiling erlang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68277 --- Comment #6 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #5) > Could you please add it to your nightly test run and commit it if there no > other new failures? I'll be away for a few days... OK, will do. > Hm ... so maybe

[Bug target/68091] [6 Regression] [SH] internal compiler error: in expand_vec_cond_expr, at optabs.c:5391

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68091 --- Comment #3 from Kazumoto Kojima --- Author: kkojima Date: Mon Oct 26 11:30:11 2015 New Revision: 229336 URL: https://gcc.gnu.org/viewcvs?rev=229336=gcc=rev Log: [config/sh/sh.c] Fix PR68091: Return false for non shmedia targets in

[Bug target/68091] [6 Regression] [SH] internal compiler error: in expand_vec_cond_expr, at optabs.c:5391

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68091 --- Comment #2 from Kazumoto Kojima --- OK, I'll commit it as a quick fix if the usual tests done successfully.

[Bug target/68091] New: [6 Regression] [SH] internal compiler error: in expand_vec_cond_expr, at optabs.c:5391

Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kkojima at gcc dot gnu.org Target Milestone: --- Target: sh4*-*-* The recent change of middle-end for vector

[Bug target/67732] [SH] Strange LRA addsi3 usage

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67732 --- Comment #2 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #1) > There are some improvements with LRA, but the regression in teem-1.6.0-src > > total: 1105728 -> 1122288+16560 / +1.497656 % > > outweighs all of the

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 --- Comment #20 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #19) I have no objection. I thought that the fix for PR67723 on trunk is first, though either way will be fine.

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 --- Comment #17 from Kazumoto Kojima --- Author: kkojima Date: Tue Sep 29 05:36:01 2015 New Revision: 228228 URL: https://gcc.gnu.org/viewcvs?rev=228228=gcc=rev Log: PR target/67716 * [SH] Implement targetm.override_options_after_change hook

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 --- Comment #18 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #16) > Regardless of those, Kaz, can you please commit attachment 36397 [details]? > Then I can handle the other cases on top of that. Done.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #29 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #26) > OK, I'll commit attachment 36400 [details] to trunk then. Do you think it's > safe for GCC 5 branch, too? Or shall we test it on the branch? I think so,

[Bug target/67391] [SH] Convert clrt addc to normal add insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #25 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #24) > Could you please re-run that test with attachment 36400 [details]? Yes, 36400 fixes that failure: PASS: gcc.c-torture/compile/sync-3.c -O1 (test for

[Bug target/67391] [SH] Convert clrt addc to normal add insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #31 from Kazumoto Kojima --- (In reply to Kazumoto Kojima from comment #29) Tests for 5-branch with/without -mlra completed with no new failures on sh4-unknown-linux-gnu.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #23 from Kazumoto Kojima --- My tests are done. Only gcc.c-torture/compile/sync-3.c -O1 (internal compiler error) for -mno-lra is the new test that fails.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #17 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #16) > Kaz, does this patch fix the issue in c#11 ? Yep, it fixes that ICE. Thanks! My 36387 trial patch can cause a similar problem with PR64533 when sp is taken as

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 --- Comment #11 from Kazumoto Kojima --- Created attachment 36397 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36397=edit patch for targetm.override_options_after_change Could you try this patch? What is going on: 1. align_jumps

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 --- Comment #9 from Kazumoto Kojima --- Created attachment 36395 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36395=edit reduced test case This one fails with the same asm error with my sh-elf c++ for -g -O1. It looks that #pragma GCC

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 --- Comment #13 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #12) > Maybe we should move some > more of the sh_option_override things sh_override_options_after_change? I > don't know ... I thought the same thing too. From the

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 --- Comment #15 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #14) > Yes, there are issues. I've created PR 67723. Ah, you are right. I forgot -m optimization options at all.

[Bug target/67391] [SH] Convert clrt addc to normal add insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #21 from Kazumoto Kojima --- No new failures with -mlra here too. The test without -mlra is still running, though there is a new failure: /home/ldroot/dodes/xsh-gcc/gcc/xgcc -B/home/ldroot/dodes/xsh-gcc/gcc/

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67716 --- Comment #1 from Kazumoto Kojima --- (In reply to John Paul Adrian Glaubitz from comment #0) > I have taken the build directory as is and created a compressed tar ball > from it which can be downloaded here: Could you send .i and .s files

[Bug target/67391] [SH] Convert clrt addc to normal add insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #14 from Kazumoto Kojima --- Created attachment 36387 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36387=edit a trial Although a bit ugly, how about adding pattern using scratch reg? Does it get the original clrt+addc issue

[Bug target/67391] [SH] Convert clrt addc to normal add insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #6 from Kazumoto Kojima --- (In reply to Kazumoto Kojima from comment #5) > Yes, this is clearly a 5/6 regression. My test has passed C and C++ part > with no new failures. I'll report back when test completed. Test completed with

[Bug target/67391] [SH] Convert clrt addc to normal add insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #11 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #10) > The core issue should be fixed. I'd like to keep this PR open though for a > while. I've got

[Bug target/67391] [SH] Convert clrt addc to normal add insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #3 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #1) > Kaz, do you have any memory of the extra checks? Isn't it enough to just > accept the addsi3 pattern as "rC = rA + {rB|imm}" and insert the reg-reg > copy after

[Bug target/67391] [SH] Convert clrt addc to normal add insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #5 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #4) > I've just checked, the code is also present in GCC 5. Because of the funny > side effects even with LRA disabled (this PR) I'd like to backport this to > the GCC

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573 --- Comment #11 from Kazumoto Kojima --- Author: kkojima Date: Sun Sep 20 23:54:03 2015 New Revision: 227953 URL: https://gcc.gnu.org/viewcvs?rev=227953=gcc=rev Log: PR target/67573 * config/sh/sh.md: Add early clobber to scratch operand of

[Bug target/67657] [SH][5]: internal compiler error: in cselib_record_set, at cselib.c:2396 when compiling libjpeg-turbo

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67657 --- Comment #2 from Kazumoto Kojima --- Created attachment 36356 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36356=edit reduced test case I can reproduce it with trunk rev. 227929 but can't with 227887. Clearly very fragile. It looks

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573 --- Comment #10 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #9) > I think this should be backported to GCC 5. Even if it might not be > triggered often, there is a possibility for silent wrong-code bugs. OK, will do.

[Bug target/66609] [sh] Relative address expressions bind at as-time, even if symbol is weak

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66609 --- Comment #6 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #5) > Kaz, do you think it's OK to backport this to GCC 5? It looks like the > patch is not so intrusive... Changing relocation is always intrusive, I think. I won't

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573 --- Comment #5 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #4) > Maybe FPSCR_STAT_REG should be in the clobber list, too? Otherwise stores > of FP exception bits etc (get_fpscr builtin) could be wrongly CSE'd across > function

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573 Kazumoto Kojima changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573 --- Comment #6 from Kazumoto Kojima --- Author: kkojima Date: Thu Sep 17 00:12:57 2015 New Revision: 227837 URL: https://gcc.gnu.org/viewcvs?rev=227837=gcc=rev Log: PR target/67573 * config/sh/sh.md: Add early clobber to scratch operand of

[Bug target/55212] [SH] Switch to LRA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 Bug 55212 depends on bug 67573, which changed state. Bug 67573 Summary: [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573 What|Removed

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573 --- Comment #2 from Kazumoto Kojima --- It seems that LRA allocates r7 for the scratch reg at (define_insn_and_split "call_value_pcrel" [(set (match_operand 0 "" "=rf") (call (mem:SI (match_operand:SI 1 "symbol_ref_operand" ""))

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573 --- Comment #3 from Kazumoto Kojima --- I've wrongly cut call_value_pcrel. It's (define_insn_and_split "call_value_pcrel" [(set (match_operand 0 "" "=rf") (call (mem:SI (match_operand:SI 1 "symbol_ref_operand" ""))

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573 --- Comment #1 from Kazumoto Kojima --- Created attachment 36333 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36333=edit test case

[Bug target/67573] New: [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kkojima at gcc dot gnu.org CC: olegendo at gcc dot gnu.org Blocks: 55212 Target Milestone

[Bug target/55212] [SH] Switch to LRA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #111 from Kazumoto Kojima --- (In reply to Kazumoto Kojima from comment #110) It seems that those failures are the latent wrong code problem triggered with -mlra accidentally. I've filed it as PR67573.

[Bug target/55212] [SH] Switch to LRA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #103 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #102) > Ah! I always wondered why those failures disappeared from your nightly > tests. Did you do this locally in your setup, or has this been committed at > some

[Bug target/55212] [SH] Switch to LRA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #110 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #109) > Maybe it also fixes the std::locale issues. Kaz, could > you please have a look? It doesn't fix those failures. I'll try to bisect that issue.

[Bug target/55212] [SH] Switch to LRA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #101 from Kazumoto Kojima --- > Perhaps the both codes are ok, though something odd happens > on atomic things anyway. I've forgotten that some atomic builtins fail with spill_failure in class 'R0_REGS' for old RA. So libstdc++-v3

[Bug target/55212] [SH] Switch to LRA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #98 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #97) > I've compared the results of r227512 without LRA and r227682 with LRA. > Below are the new failures. A typical example of pr64661-x.c regressions is: [LRA]

[Bug target/55212] [SH] Switch to LRA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #95 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #94) > Kaz, do you think we can enable LRA by default for GCC 6? I think that it's OK to make LRA default on trunk, even if it's better with your R0 pre-allocating

[Bug target/55212] [SH] Switch to LRA

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #100 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #99) > Hm .. those don't fail on sh-elf ... maybe something related to the atomics? > Atomics are off by default for sh-elf, but on for sh-linux. Maybe. It could be

[Bug target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506 --- Comment #5 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #4) > Could you please test it? It fixes all test cases for the cross trunk sh4-unknown-linux-gnu compiler. There is no new failures with the top level "make -k check".

[Bug target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506 --- Comment #2 from Kazumoto Kojima --- Created attachment 36309 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36309=edit reduced test case It looks that some problem happens in tstsi_t splitter. The insns before splitting are: (insn

[Bug target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506 Kazumoto Kojima changed: What|Removed |Added Keywords||ice-on-valid-code Known to work|

[Bug target/66609] [sh] Relative address expressions bind at as-time, even if symbol is weak

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66609 --- Comment #4 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Author: kkojima Date: Mon Aug 24 23:23:00 2015 New Revision: 227155 URL: https://gcc.gnu.org/viewcvs?rev=227155root=gccview=rev Log: PR target/66609 * [SH] Take into account weak

[Bug target/66609] [sh] Relative address expressions bind at as-time, even if symbol is weak

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66609 Kazumoto Kojima kkojima at gcc dot gnu.org changed: What|Removed |Added CC||kkojima

[Bug target/66609] [sh] Relative address expressions bind at as-time, even if symbol is weak

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66609 --- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Rich Felker from comment #2) Thanks for the confirmation. I'll commit the patch after the undergoing additional test done.

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002 --- Comment #23 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Author: kkojima Date: Fri Aug 7 20:41:25 2015 New Revision: 226726 URL: https://gcc.gnu.org/viewcvs?rev=226726root=gccview=rev Log: PR target/67002 * config/sh/sh.c

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002 --- Comment #24 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Author: kkojima Date: Fri Aug 7 08:11:45 2015 New Revision: 226715 URL: https://gcc.gnu.org/viewcvs?rev=226715root=gccview=rev Log: PR target/67002 * config/sh/sh.c

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002 --- Comment #21 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #20) Yes, that looks OK. treg_set_expr-something recog matching is actually only required during combine. The simpler forms like (reg:SI

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002 --- Comment #19 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #18) In the problematic situation, get_max_insn_count returns the false value after if (MAY_HAVE_DEBUG_INSNS

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002 --- Comment #18 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Michael Karcher from comment #15) The first different line of diff of the .pre dumps of Michael's test case with/without -g is: Expression hash table (53 buckets

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002 --- Comment #14 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Created attachment 36117 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36117action=edit reduced test case Michael Karcher, who previously helped smashing some bugs in gcc

[Bug target/67049] sh64-elf: internal compiler error: in df_uses_record, at df-scan.c:3001

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67049 --- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Author: kkojima Date: Fri Jul 31 22:19:51 2015 New Revision: 226457 URL: https://gcc.gnu.org/viewcvs?rev=226457root=gccview=rev Log: PR target/67049 * config/sh/sh.md

[Bug target/67049] sh64-elf: internal compiler error: in df_uses_record, at df-scan.c:3001

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67049 --- Comment #4 from Kazumoto Kojima kkojima at gcc dot gnu.org --- Author: kkojima Date: Fri Jul 31 22:25:57 2015 New Revision: 226458 URL: https://gcc.gnu.org/viewcvs?rev=226458root=gccview=rev Log: PR target/67049 * config/sh/sh.md

[Bug target/67049] sh64-elf: internal compiler error: in df_uses_record, at df-scan.c:3001

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67049 Kazumoto Kojima kkojima at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug target/67061] sh64-elf: internal compiler error: in sh_find_set_of_reg, at config/sh/sh-protos.h:235

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67061 --- Comment #2 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #1) Hm .. for (result.insn = stepfunc (insn); result.insn != NULL_RTX; previnsn = result.insn, result.insn = stepfunc

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002 --- Comment #7 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to John Paul Adrian Glaubitz from comment #6) And here is the diff from the disassembly: A rare indeterminacy of the register choice. Both codes are valid. It seems

[Bug target/67049] sh64-elf: internal compiler error: in df_uses_record, at df-scan.c:3001

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67049 --- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org --- My bad. Could you please try this patch? diff --git a/config/sh/sh.md b/config/sh/sh.md index a86eaad..387ffe3 100644 --- a/config/sh/sh.md +++ b/config/sh/sh.md @@ -10597,7

[Bug target/66780] [4.9 Regression] Compiling with -fstack-protector-strong causes binary to segfault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66780 Kazumoto Kojima kkojima at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug target/66930] [5 Regression]: gengtype.c is miscompiled during stage2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66930 --- Comment #15 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Oleg Endo from comment #13) This would be OK for hardregs (which are clobbered by calls). When working on pseudos, it's actually OK to ignore calls. Maybe it'd

[Bug target/66930] [5 Regression]: gengtype.c is miscompiled during stage2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66930 --- Comment #14 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to Kazumoto Kojima from comment #12) The toplevel make -k check on sh4-unknown-linux-gnu is running. I'll report back when it completes. I've confirmed

  1   2   3   4   5   6   >