[Bug target/80870] [7 Regression] ICE building 7.1.0 sh-elf crosscompiler on macOS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80870 --- Comment #8 from Oleg Endo --- Author: olegendo Date: Sun Jan 21 05:13:20 2018 New Revision: 256928 URL: https://gcc.gnu.org/viewcvs?rev=256928=gcc=rev Log: Backport from mainline 2018-01-21 Oleg Endo

[Bug target/80870] [7 Regression] ICE building 7.1.0 sh-elf crosscompiler on macOS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80870 Oleg Endo changed: What|Removed |Added CC||chrisj at rtems dot org --- Comment #6 from

[Bug target/80870] [7 Regression] ICE building 7.1.0 sh-elf crosscompiler on macOS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80870 Oleg Endo changed: What|Removed |Added CC||chrisj at rtems dot org --- Comment #6 from

[Bug other/82530] RTEMS 4.12 SH build failure on FreeBSD 11.1 (clang) with an error in sh_optimize_sett_clrt.cc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82530 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug lto/83816] [6/7 Regression] lto1: internal compiler error: compressed stream: data error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 Oleg Endo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug lto/83816] [6/7 Regression] lto1: internal compiler error: compressed stream: data error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #18 from Oleg Endo --- Created attachment 43196 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43196=edit binary compressed data I have tapped lto_end_compression and dumped the compressed binary data into a separate file.

[Bug lto/83816] [6/7 Regression] lto1: internal compiler error: compressed stream: data error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #17 from Oleg Endo --- (In reply to Richard Biener from comment #15) > > I can reproduce it: > Nice. (In reply to Richard Biener from comment #16) > Note your testcase only reproduces on the GCC 6 branch. It is expected that >

[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #14 from Oleg Endo --- (In reply to rguent...@suse.de from comment #11) > > Smells odd indeed. Can you try building with > --enable-valgrind-annotations and run valgrind on the thing? My theory > would still be a wild write

[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #13 from Oleg Endo --- (In reply to Oleg Endo from comment #12) > I was able to reduce it somewhat. However, I'd be surprised if it does not > reproduce the error on some other system. I meant: I'd be surprised if it does reproduce

[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #12 from Oleg Endo --- Created attachment 43152 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43152=edit preprocessed c++ source I was able to reduce it somewhat. However, I'd be surprised if it does not reproduce the error

[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #9 from Oleg Endo --- This is weird. If I remove empty lines, or rename the paths in the # line markers in the .ii file, the error sometimes disappears...

[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #8 from Oleg Endo --- (In reply to rguent...@suse.de from comment #7) > > If you can produce a testcase and attach that that would be nice. I'm trying. But it's gonna take ages. Have to hand-strip the .ii file line by line ... or

[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #6 from Oleg Endo --- I can reproduce it on a different machine. One of the object files in the whole app build seems to be written bad. I could isolate the pre-processed .ii file. Compiling that .ii file and trying to link it

[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #5 from Oleg Endo --- (In reply to rguent...@suse.de from comment #4) > > I think it should either work always or never ... Yep. In the past the compression-level setting showed different success/failure rates. In this case here,

[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #3 from Oleg Endo --- BTW, I'm using -flto-compression-level=0. In the past (GCC 4.5 ...) I've used it as a workaround for other "lto compression related" errors.

[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #1 from Oleg Endo --- Hmm ... if the program is changed in some places, it can also be triggered on GCC 6.4. It seems it happens when adding/removing function calls inside of C++ lambda functions ... how to find the cause?

[Bug target/43462] Suboptimal switch table jump generation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43462 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #2

[Bug target/83832] New: [RX] Improve bittests

Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target Milestone: --- Target: rx*-*-* If a bit test is done with only a single bit in the constant, the btst instruction should be used to get smaller code. When testing for constants such a 0xFF

[Bug target/83831] New: [6/7/8 Regression][RX] Unused bclr,bnot,bset insns

Component: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target Milestone: --- Target: rx*-*-* These cases should be emitting the bclr, bnot, bset instructions. They are present in rx.md but I guess the combine pass does not catch

[Bug target/80870] [7 Regression] ICE building 7.1.0 sh-elf crosscompiler on macOS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80870 --- Comment #4 from Oleg Endo --- Right, thanks for checking. Can you please try out this patch: Index: gcc/config/sh/sh_optimize_sett_clrt.cc === ---

[Bug target/80870] [7 Regression] ICE building 7.1.0 sh-elf crosscompiler on macOS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80870 --- Comment #2 from Oleg Endo --- Could you please try it out with the latest GCC 7 branch and see if the problem is still there?

[Bug other/82530] RTEMS 4.12 SH build failure on FreeBSD 11.1 (clang) with an error in sh_optimize_sett_clrt.cc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82530 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org

[Bug ada/36939] Build Failure Ada SH2e

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36939 Oleg Endo changed: What|Removed |Added CC||sebastian.huber@embedded-br

[Bug target/83810] sh: s-scaval.adb:103:07: warning: "IV_Ilf" overlays smaller object

||olegendo at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Oleg Endo --- The SH target option -m4-single-only forces all doubles to be 32 bit floats. Some SH variants (e.g. SH2E) have only 32 bit float hardware and all doubles

[Bug target/81819] [7 Regression][RX] internal compiler error: in rx_is_restricted_memory_address, at config/rx/rx.c:311

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81819 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/81819] [7 Regression][RX] internal compiler error: in rx_is_restricted_memory_address, at config/rx/rx.c:311

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81819 --- Comment #4 from Oleg Endo --- Fixed on trunk and GCC 7.

[Bug c++/83817] [8 Regression] internal compiler error: tree check: expected call_expr, have aggr_init_expr in tsubst_copy_and_build, at cp/pt.c:17822

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83817 --- Comment #1 from Oleg Endo --- Created attachment 43117 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43117=edit preprocessed source

[Bug c++/83817] New: [8 Regression]

at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target Milestone: --- Target: rx*-*-* Build: internal compiler error: tree check: expected call_expr, have aggr_init_expr in tsubst_copy_and_build, at cp/pt.c:17822

[Bug lto/83816] New: [7 Regression] lto1: internal compiler error: compressed stream: data error

: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- This happens when building a bigger app on RX with LTO during linking

[Bug target/81819] [7 Regression][RX] internal compiler error: in rx_is_restricted_memory_address, at config/rx/rx.c:311

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81819 --- Comment #3 from Oleg Endo --- Author: olegendo Date: Fri Jan 12 12:12:38 2018 New Revision: 256579 URL: https://gcc.gnu.org/viewcvs?rev=256579=gcc=rev Log: gcc/ Backport from mainline 2018-01-12 Oleg Endo

[Bug target/81819] [7 Regression][RX] internal compiler error: in rx_is_restricted_memory_address, at config/rx/rx.c:311

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81819 --- Comment #2 from Oleg Endo --- Author: olegendo Date: Fri Jan 12 12:10:56 2018 New Revision: 256578 URL: https://gcc.gnu.org/viewcvs?rev=256578=gcc=rev Log: gcc/ PR target/81819 * config/rx/rx.c

[Bug target/81821] [RX] xchg_mem uses wrong memory operand size

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81821 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/81821] [RX] xchg_mem uses wrong memory operand size

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81821 --- Comment #4 from Oleg Endo --- Author: olegendo Date: Thu Jan 11 15:18:38 2018 New Revision: 256538 URL: https://gcc.gnu.org/viewcvs?rev=256538=gcc=rev Log: gcc/ Backport from mainline 2018-01-11 Oleg Endo

[Bug target/81821] [RX] xchg_mem uses wrong memory operand size

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81821 --- Comment #3 from Oleg Endo --- Author: olegendo Date: Thu Jan 11 15:16:21 2018 New Revision: 256536 URL: https://gcc.gnu.org/viewcvs?rev=256536=gcc=rev Log: gcc/ PR target/81821 * config/rx/rx.md (BW): New mode attribute.

[Bug target/81819] [7 Regression][RX] internal compiler error: in rx_is_restricted_memory_address, at config/rx/rx.c:311

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81819 --- Comment #1 from Oleg Endo --- I can confirm that the problem still exists on GCC 7 branch and probably also on trunk (trunk does not build the app because of another bug). The patch above fixes the problem and the app runs.

[Bug go/83308] Missing platform definitions for SH in libgo

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #14 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #13) > Cacheline size is 32 bytes according to the documentation: > > > www.st.com/resource/en/user_manual/cd00147165.pdf (page 75) Cache line sizes of

[Bug go/83308] Missing platform definitions for SH in libgo

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #3 from Oleg Endo --- Go will not work on SH just by adding it to the list of targets. For instance split stacks support is not implemented on SH.

[Bug target/70216] [SH] Implement __builtin_trap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216 --- Comment #28 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #27) > > The problem is that with gcc-7 as the default compiler in Debian, this issue > always results in glibc and the Linux kernel failing to build from

[Bug target/81485] [SH] ICE: in sh_find_set_of_reg, at config/sh/sh-protos.h:232

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81485 --- Comment #9 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #8) > > Should we mark this as resolved? No, because it has not been resolved for GCC 6.

[Bug target/70216] [SH] Implement __builtin_trap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216 --- Comment #26 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #25) > (In reply to Segher Boessenkool from comment #24) > > Send it to gcc-patches@? If it is approved, I can commit it, sure. > > Ok, thanks! Will do!

[Bug target/70216] [SH] Implement __builtin_trap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216 --- Comment #19 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #18) > I can confirm that the patch from comment #6 resolves the problem for me. Thanks for checking. > > Can we get it merged in one form or another? >

[Bug target/70216] [SH] Implement __builtin_trap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216 --- Comment #14 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #13) > > What about glibc which originally resulted in this bug report? I have no idea about it.

[Bug target/70216] [SH] Implement __builtin_trap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216 --- Comment #12 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #11) > > > > It's OK to add __builtin_trap to GCC 7. > > Could you have a look and try the patch in Comment 6? I don't have so much > > time for SH stuff

[Bug target/70216] [SH] Implement __builtin_trap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70216 --- Comment #10 from Oleg Endo --- (In reply to Rich Felker from comment #9) > From a Linux standpoint, there is no trapa trap number defined that would > cause a fatal signal. The ones that are defined are for syscalls and debug > breakpoints.

[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143 --- Comment #11 from Oleg Endo --- (In reply to James Clarke from comment #10) > (In reply to Segher Boessenkool from comment #9) > > What flags does it need? I can't get it to fail. > > Just -O2 -fPIC, at least with 7.2.0. That is, if your

[Bug target/83143] [SH]: Assembler messages: invalid operands (*UND* and .text sections) for `-'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143 Oleg Endo changed: What|Removed |Added CC||segher at kernel dot crashing.org ---

[Bug target/83111] [7/8 Regression][sh] stack smashing detected in gen_udivsi3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83111 Oleg Endo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug target/83111] [7/8 Regression][sh] stack smashing detected in gen_udivsi3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83111 --- Comment #7 from Oleg Endo --- Author: olegendo Date: Thu Nov 23 14:08:12 2017 New Revision: 255097 URL: https://gcc.gnu.org/viewcvs?rev=255097=gcc=rev Log: gcc/ Backport from mainline 2017-11-23 Oleg Endo

[Bug target/83111] [7/8 Regression][sh] stack smashing detected in gen_udivsi3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83111 --- Comment #6 from Oleg Endo --- Author: olegendo Date: Thu Nov 23 14:06:15 2017 New Revision: 255096 URL: https://gcc.gnu.org/viewcvs?rev=255096=gcc=rev Log: gcc/ PR target/83111 * config/sh/sh.md (udivsi3, divsi3,

[Bug target/83111] [sh] stack smashing detected in gen_udivsi3

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83111 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 --- Comment #14 from Oleg Endo --- (In reply to Ian Lance Taylor from comment #25) > I have no particular concerns with dropping the bitfield code, but clearly it > has to be tested on a couple of little-endian platforms. Can we try to narrow

[Bug target/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 Oleg Endo changed: What|Removed |Added CC||ian at airs dot com --- Comment #13 from

[Bug target/67712] [SH] __builtin_strncmp causes code bloat

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67712 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug target/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 --- Comment #23 from Oleg Endo --- (In reply to Ian Lance Taylor from comment #22) > The patch to make the structs themselves attribute((packed)) is approved. > Thanks! > If you want to investigate dropping the bitfield code entirely, that is

[Bug target/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 --- Comment #21 from Oleg Endo --- (In reply to Ian Lance Taylor from comment #18) > How could the size of that struct possibly be 12? Can you figure out what > is causing that to happen? There are exactly 64 bits specified, and the > fields

[Bug target/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 --- Comment #20 from Oleg Endo --- (In reply to jos...@codesourcery.com from comment #17) > Presumably the bit-field issue is RX defaulting to MS bit-field layout > (rx_is_ms_bitfield_layout suggests making the structure itself packed > should

[Bug target/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 --- Comment #16 from Oleg Endo --- (In reply to Ian Lance Taylor from comment #15) > What does this program print on rx? 12 6f883f80 0 0 > > Overall the softfp code is newer and probably better. Converting rx to use > the softfp code is

[Bug target/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 Oleg Endo changed: What|Removed |Added CC||ian at airs dot com --- Comment #14 from

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 Oleg Endo changed: What|Removed |Added CC||amylaar at gcc dot gnu.org --- Comment #11

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 Oleg Endo changed: What|Removed |Added CC||andrew.burgess at embecosm dot com

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 --- Comment #9 from Oleg Endo --- Created attachment 41982 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41982=edit Proposed patch I'd propose to remove the FLOAT_BIT_ORDER_MISMATCH stuff altogether. It's more portable to use

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 Oleg Endo changed: What|Removed |Added CC||joseph at codesourcery dot com --- Comment

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 --- Comment #7 from Oleg Endo --- Created attachment 41981 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41981=edit Disassembled DF code of comment #5

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 --- Comment #6 from Oleg Endo --- Created attachment 41980 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41980=edit Disassembled SF code of comment #5

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 --- Comment #5 from Oleg Endo --- I have checked with the following simplified test code: #include int main (void) { volatile float testval = 1; // volatile double testval = 1; testval = testval + 1; return ((const uint8_t*))[ sizeof

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 --- Comment #4 from Oleg Endo --- (In reply to Nick Clifton from comment #2) > > So what I suspect is that something is missing from the rx libgcc > configuration files (libgcc/config/rx/t-rx and/or libgcc/config/rx/rx-lib.h) > which means that

[Bug target/81823] New: [RX] Improve support for atomics other than SImode

Component: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target Milestone: --- Target: rx*-*-* Atomics that perform arithmetic are only implemented for SImode. It should be extended to support QImode and HImode in the same way

[Bug target/81821] [RX] xchg_mem uses wrong memory operand size

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81821 --- Comment #2 from Oleg Endo --- A possible fix: Index: gcc/config/rx/rx.md === --- gcc/config/rx/rx.md (revision 251045) +++ gcc/config/rx/rx.md (working copy) @@ -2167,6 +2167,7

[Bug target/81821] [RX] xchg_mem uses wrong memory operand size

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81821 Oleg Endo changed: What|Removed |Added Summary|[RX] __atomic_test_and_set |[RX] xchg_mem uses

[Bug target/81822] New: [RX] Should implement __atomic_compare_exchange

: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target Milestone: --- Target: rx*-*-* There are some places which check if the target directly supports SImode atomic compare and exchange, via the __GCC_ATOMIC_INT_LOCK_FREE macro

[Bug target/81821] New: [RX] __atomic_test_and_set overwrites adjacent memory

Component: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target Milestone: --- __atomic_test_and_set is supposed to change only one byte, but on RX it wrongly overwrites adjacent memory locations: int test (volatile char* x) { return

[Bug regression/81819] New: [7 Regression][RX] internal compiler error: in rx_is_restricted_memory_address, at config/rx/rx.c:311

: UNCONFIRMED Severity: normal Priority: P3 Component: regression Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target Milestone: --- This error shows up when building a bigger app on RX with LTO. It is working OK on GCC 6

[Bug target/81485] [SH] ICE: in sh_find_set_of_reg, at config/sh/sh-protos.h:232

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81485 --- Comment #7 from Oleg Endo --- (In reply to Oleg Endo from comment #6) > And in fact, there has been a change to the function sh_find_set_of_reg. > I'd have to dig through the archives etc to find out what was going on > there. The change

[Bug target/81485] [SH] ICE: in sh_find_set_of_reg, at config/sh/sh-protos.h:232

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81485 --- Comment #6 from Oleg Endo --- And in fact, there has been a change to the function sh_find_set_of_reg. I'd have to dig through the archives etc to find out what was going on there. Meanwhile, it seems that the small backport patch below

[Bug target/81485] [SH] ICE: in sh_find_set_of_reg, at config/sh/sh-protos.h:232

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81485 --- Comment #4 from Oleg Endo --- (In reply to Martin Liška from comment #3) > > Good, I can confirm it works for GCC 5. Let's then bisect that.. I'm not sure whether this will reveal anything useful. It's probably just a bug in the function

[Bug target/81485] [SH] ICE: in sh_find_set_of_reg, at config/sh/sh-protos.h:232

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81485 Oleg Endo changed: What|Removed |Added Last reconfirmed|2017-08-08 00:00:00 |2017-8-10 --- Comment #2 from Oleg Endo

[Bug target/67638] [SH] ICE with nosave_low_regs ISR and -mfmovd

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67638 --- Comment #2 from Oleg Endo --- (In reply to Martin Liška from comment #1) > Can't reproduce with cross compiler on trunk and gcc-5 branch. Is it > reproducible with cross compiler? Which options do you use? You have to use -m4 or -m4a (SH4

[Bug rtl-optimization/30065] Could use indexed addressing to reduce const costs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30065 --- Comment #7 from Oleg Endo --- (In reply to Eric Gallager from comment #6) > > Can I change the status to SUSPENDED or assign them to you instead? I'm not > so much trying to reduce the number of open PRs as I am trying to just move > them

[Bug libstdc++/29366] atomics config for sh is weird

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29366 --- Comment #10 from Oleg Endo --- (In reply to Eric Gallager from comment #9) > > Did this fix things? No, not entirely. The whole config/cpu/sh/atomicity.h header should not be required, but because of PR 53579, it is. Please do not close

[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842 Bug 29842 depends on bug 30065, which changed state. Bug 30065 Summary: Could use indexed addressing to reduce const costs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30065 What|Removed |Added

[Bug rtl-optimization/30065] Could use indexed addressing to reduce const costs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30065 Oleg Endo changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID

[Bug target/81426] [SH]: unable to find a register to spill in class 'R0_REGS' when building webkit2gtk

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426 --- Comment #5 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #4) > > It helps, indeed. The build now passes the problematic source code file. > However, it now bails out later with: > > /tmp/cck5XKuE.s: Assembler

[Bug target/81426] [SH]: unable to find a register to spill in class 'R0_REGS' when building webkit2gtk

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426 --- Comment #3 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #2) > > Not yet, I will give it a try now. Please try. It might allow you to at least build the package. Regardless of that, let's keep this PR open.

[Bug target/81426] [SH]: unable to find a register to spill in class 'R0_REGS' when building webkit2gtk

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426 --- Comment #1 from Oleg Endo --- Have you tried compiling the package with -mlra?

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79462 --- Comment #4 from Oleg Endo --- If the patch fixes the problem, it's OK. But please add a comment where the line is removed as a hint of what's going on there.

[Bug tree-optimization/67328] range test rather than single bit test for code testing enum values

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67328 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #5

[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 #3 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #2) > > Hmm, I thought gccgo would work on all gcc-supported targets. No, GO requires some runtime support which has to be provided by the backend. For

[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 #1 from Oleg Endo --- As far as I know GO has not been ported for SH.

[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 #17 from Oleg Endo --- (In reply to Jakub Jelinek from comment #16) > When a fix exists, why hasn't it been posted to gcc-patches? Because, like I wrote in comment #13, I would like to check if there might be a better fix for the

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 --- Comment #3 from Oleg Endo --- (In reply to Nick Clifton from comment #2) > > It is almost certainly a bug in the RX specific parts of the libgcc > configuration > > It is unlikely that the actual code for the _COM_CONVd32s function is

[Bug libgcc/78804] [RX] -m64bit-doubles does not work

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78804 Oleg Endo changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #1

[Bug libgcc/78804] New: [RX] -m64bit-doubles does not work

Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target Milestone: --- The following program #include #include int main (void) { volatile double testval = 1.0; printf ("testval = %02x%02x%02x%02x%02x%02x%02x%02x\n",

[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 #13 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #12) > Perhaps the splitter in problem > might have to take care of subreg case even when referencing > a reg rtx in the input operands. So it looks like a new rtx

[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 #7 from Oleg Endo --- Maybe it's this thread? https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00334.html

[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 #5 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #1) > Here is a trial patch > > diff --git a/config/sh/sh.md b/config/sh/sh.md > index c6956a0..c83bf08 100644 > --- a/config/sh/sh.md > +++ b/config/sh/sh.md > @@

[Bug target/62180] (RX600) - compiler doesn't honor -fstrict-volatile-bitfields and generates incorrect machine code for I/O register access

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62180 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/78460] [7 Regression] [SH] OOM building glibc string tst-cmp.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #2

[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #5

[Bug tree-optimization/61056] strchr (x, 0) is not converted to strlen (x)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61056 --- Comment #5 from Oleg Endo --- https://gcc.gnu.org/viewcvs/gcc?view=revision=240568

[Bug target/51244] [SH] Inefficient conditional branch and code around T bit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244 --- Comment #88 from Oleg Endo --- Author: olegendo Date: Tue Sep 27 12:50:27 2016 New Revision: 240533 URL: https://gcc.gnu.org/viewcvs?rev=240533=gcc=rev Log: gcc/ PR target/51244 * config/sh/sh.c (sh_rtx_costs): Fix return

<    1   2   3   4   5   6   7   8   9   10   >