[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 #7 from Oleg Endo --- Created attachment 36394 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36394=edit preprocessed C++ source for dcraw_common.cpp The code in attachment 36389 doesn't compile with the trunk compiler because

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

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

[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 rtl-optimization/67644] double load on volatile bitfield mem

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67644 --- Comment #5 from Oleg Endo --- Possibly related: PR 50521, PR 56997

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #16 from Oleg Endo --- Created attachment 36396 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36396=edit Another trail, works with LRA (In reply to Oleg Endo from comment #15) > > I'm now trying to come up with something

[Bug fortran/67721] New: deep copy missing when assigning a derived type constructor to an array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67721 Bug ID: 67721 Summary: deep copy missing when assigning a derived type constructor to an array Product: gcc Version: unknown Status: UNCONFIRMED Severity:

[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 #8 from Oleg Endo --- On sh-elf/newlib there are no threads, so -fopenmp doesn't work. I can't reproduce it Without -fopenmp.

[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 #12 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #11) > Created attachment 36397 [details] > patch for targetm.override_options_after_change > > Could you try this patch? > > What is going on: > > 1. align_jumps

[Bug target/67723] [SH] fsrra/fsca not working with #pragma GCC optimize ("fast-math")

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67723 --- Comment #1 from Oleg Endo --- (In reply to Oleg Endo from comment #0) > Instead they should be enabled in > TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE Alternatively, the insn conditions could check the flags directly via a function instead of

[Bug web/64968] Upgrade GCC Bugzilla to 5.0

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #49 from Frédéric Buclin --- (In reply to Markus Trippelsdorf from comment #47) > Another cosmetic issue that I've noticed is that an extra newline is added > after every quoted comment. This problem has been reported upstream, see

[Bug target/67723] New: [SH] fsrra/fsca not working with #pragma GCC optimize ("fast-math")

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67723 Bug ID: 67723 Summary: [SH] fsrra/fsca not working with #pragma GCC optimize ("fast-math") Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug c++/67724] New: internal compiler error in stl_vector.h

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67724 Bug ID: 67724 Summary: internal compiler error in stl_vector.h Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug c++/67687] [c++0x][constexpr] initialize constexpr member with constexpr constructor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67687 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail.

[Bug libstdc++/67617] Non-standard const requirements imposed on associative container comparison objects

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67617 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail.

[Bug fortran/67567] resolve.c: gfc_error called with iface->module == NULL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67567 --- Comment #7 from Paul Thomas --- Author: pault Date: Sat Sep 26 17:52:24 2015 New Revision: 228169 URL: https://gcc.gnu.org/viewcvs?rev=228169=gcc=rev Log: 2013-09-26 Paul Thomas PR fortran/67567 *

[Bug go/67722] Misplaced #endif in libgo/runtime/lfstack.goc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67722 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug bootstrap/67725] New: all gcc versions has hardcoded LD path with bootstrap on illumos platform

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67725 Bug ID: 67725 Summary: all gcc versions has hardcoded LD path with bootstrap on illumos platform Product: gcc Version: unknown Status: UNCONFIRMED Severity:

[Bug fortran/67567] resolve.c: gfc_error called with iface->module == NULL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67567 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug fortran/67567] resolve.c: gfc_error called with iface->module == NULL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67567 --- Comment #9 from paul.richard.thomas at gmail dot com --- Fixed as 'obvious' in revision: 228169. Cheers Paul 2013-09-26 Paul Thomas PR fortran/67567 * resolve.c (resolve_fl_procedure): For module procedures,

[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 fortran/67721] deep copy missing when assigning a derived type constructor to an array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67721 Mikael Morin changed: What|Removed |Added Keywords||patch, wrong-code Known to fail|

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #18 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #17) > (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

[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 c++/67724] internal compiler error in stl_vector.h

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67724 --- Comment #1 from Julius Schmidt --- Created attachment 36398 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36398=edit Testcase

[Bug c++/67319] Short-hand concepts for variadic member functions broken

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67319 --- Comment #1 from Roland B --- Using the terse notation works fine, btw: // - template concept bool Any() { return true; } struct my_struct { auto sample(Any... args) -> void; }; int main() {

[Bug libstdc++/67617] Non-standard const requirements imposed on associative container comparison objects

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67617 --- Comment #4 from Daniel Krügler --- (In reply to Jonathan Wakely from comment #2) > Both Clang/libc++ and MSVC/Dinkumware reject it for the same reason. I notice that the Dinkumware version associated with Visual Studio 2015 accepts 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 bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728 Andrew Pinski changed: What|Removed |Added Component|c |bootstrap Summary|Build

[Bug c/67728] New: Build fails when cross-compiling with in-tree GMP

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728 Bug ID: 67728 Summary: Build fails when cross-compiling with in-tree GMP Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #19 from Oleg Endo --- (In reply to Oleg Endo from comment #16) > Then, there's is messy thing with 3 addsi3 patterns ... the order is very > important. They must be in exactly this order, or else we don't get the > code size

[Bug c++/67678] Nested class can be re-declared after definition

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67678 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail.

[Bug c++/67678] Nested class can be re-declared after definition

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67678 --- Comment #2 from Jonathan Wakely --- Yes, it might be an intentional GNU extension. Older versions of Clang warned about it with the -Wgnu option rather than -Wredeclared-class-member.

[Bug libstdc++/67726] New: std::condition_variable::wait can throw, but should terminate.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67726 Bug ID: 67726 Summary: std::condition_variable::wait can throw, but should terminate. Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal

[Bug c++/67727] New: [concepts] parameterized constraint not being checked for unused variables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67727 Bug ID: 67727 Summary: [concepts] parameterized constraint not being checked for unused variables Product: gcc Version: 6.0 Status: UNCONFIRMED Severity:

[Bug libstdc++/67617] Non-standard const requirements imposed on associative container comparison objects

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67617 --- Comment #5 from Daniel Krügler --- (In reply to Daniel Krügler from comment #3) > [..] I believe the wording for associative containers is not as clear as > it should be. For unordered containers 23.2.5 p11 speaks of "possibly const > value"

[Bug fortran/67721] deep copy missing when assigning a derived type constructor to an array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67721 --- Comment #2 from Mikael Morin --- Author: mikael Date: Sat Sep 26 20:34:39 2015 New Revision: 228170 URL: https://gcc.gnu.org/viewcvs?rev=228170=gcc=rev Log: Fix missing deep copy when assigning a DT constructor to an array This adds the

[Bug libstdc++/67617] Non-standard const requirements imposed on associative container comparison objects

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67617 --- Comment #6 from Daniel Krügler --- (In reply to Daniel Krügler from comment #4) > (In reply to Jonathan Wakely from comment #2) > > Both Clang/libc++ and MSVC/Dinkumware reject it for the same reason. > > I notice that the Dinkumware

[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/67391] [SH] Convert clrt addc to normal add insn

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 Oleg Endo changed: What|Removed |Added Attachment #36396|0 |1 is obsolete|

[Bug target/65317] [SH] Shifts used instead of and with const_int

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65317 --- Comment #2 from Oleg Endo --- It seems this is a general problem. Combine would sometimes synthesize and try to introduce new constants. But because most of the SH insn patterns reject general constants (e.g. arith_reg_operand) combine

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67391 --- Comment #20 from Oleg Endo --- (In reply to Oleg Endo from comment #16) > Created attachment 36396 [details] > Another trail, works with LRA > > I've tested this patch with > make -k check >

[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728 --- Comment #2 from Brett Neumeier --- Thanks for your swift comment! I disagree that the bug is in ISL. The problem is that gmp, although the build appears successful, is *not* correctly built. Six object files that should be compiled and

[Bug target/52628] SH Target: Inefficient shift by T bit result

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52628 --- Comment #2 from Oleg Endo --- To catch cases such as int test_01 (int a, int b, int c) { return c << (a > b ? 1 : 0); } a shift with treg_set_expr can be implemented. Combine is looking for this pattern: Failed to match this

[Bug go/67722] New: Misplaced #endif in libgo/runtime/lfstack.goc

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67722 Bug ID: 67722 Summary: Misplaced #endif in libgo/runtime/lfstack.goc Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: go

[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 #14 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #13) > (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