[Bug middle-end/69715] g++ crash dump on building SoftFloatWrapper.cpp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69715 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

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

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

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69713 Oleg Endo changed: What|Removed |Added Target|sh-unknown-linux|sh*-*-* Status|UNCONFIRMED

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #10 from Alexander Monakov --- If always using r0 is not an issue, I think it's possible to just use operands[0] (casting it to the right size with subreg:SI, if needed) to avoid using a potentially-reserved hardreg. This would

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment

[Bug inline-asm/68095] "cc" clobber with Flag Output Operands

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68095 --- Comment #6 from David --- Created attachment 37621 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37621=edit Patch for missing clobber validations I have created a patch (attached) that does the check I am describing. And while I was

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #12 from Alexander Monakov --- > Do you have anything in particular in mind? I mostly wonder why does sh.md change RTL representation of a sibcall that way, instead of simply generating the required relative address load upfront,

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69713 --- Comment #2 from Oleg Endo --- Looks like an SH specific issue. The bounds check is there, but it's in the wrong place: _lookup_user_key: mov.l r8,@-r15 mov #0,r3 mov.l r9,@-r15 mov #15,r1

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #11 from Oleg Endo --- (In reply to Alexander Monakov from comment #10) > If always using r0 is not an issue, I think it's possible to just use > operands[0] (casting it to the right size with subreg:SI, if needed) to > avoid using a

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699 --- Comment #3 from bastian.beisc...@rwth-aachen.de --- Jonathan, maybe so but it should be mentioned on the page nevertheless, right? My issue is that we are using (as an example): #if (defined(__GLIBCXX__) && __GLIBCXX__ > 20150626) ||

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69713 --- Comment #3 from Oleg Endo --- It seems that one of the loop optimizations pulls the casesi_0 and casesi_worker_0 insns apart and then things go wrong from there on. Compiling the test case with -fno-move-loop-invariants results in the

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #13 from Oleg Endo --- (In reply to Alexander Monakov from comment #12) > > I mostly wonder why does sh.md change RTL representation of a sibcall that > way, instead of simply generating the required relative address load > upfront,

[Bug c++/66786] [5/6 Regression] ICE: Segmentation fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66786 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED CC|

[Bug fortran/50555] synonymous namelist/statement function dummy argument not allowed (r178939)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555 --- Comment #7 from Jerry DeLisle --- Author: jvdelisle Date: Sun Feb 7 20:15:55 2016 New Revision: 233203 URL: https://gcc.gnu.org/viewcvs?rev=233203=gcc=rev Log: 2016-02-07 Jerry DeLisle PR fortran/50555

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699 --- Comment #5 from bastian.beisc...@rwth-aachen.de --- Thanks for your comments. Does this mean that such a macro does not exist at the present time?

[Bug fortran/50555] synonymous namelist/statement function dummy argument not allowed (r178939)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug fortran/56007] Remarkably bad error message with DO array=1,2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56007 --- Comment #6 from Harald Anlauf --- (In reply to Harald Anlauf from comment #5) > The patch of comment #4 appears to be easily extendible to reject > arrays as loop variables (I hope I got this right): > > Index: gcc/fortran/match.c >

[Bug fortran/50555] synonymous namelist/statement function dummy argument not allowed (r178939)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50555 --- Comment #8 from Jerry DeLisle --- Closing, fixed on trunk.

[Bug c/69602] [6 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602 Manuel López-Ibáñez changed: What|Removed |Added Depends on||43486, 61534 --- Comment #9 from

[Bug lto/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #6 from Manuel López-Ibáñez --- Note that it is ok to completely ignore such an invalid line directive and: line-map.c: file "" left but not entered should actually be an error or an ICE. As the code says: /* Depending upon

[Bug libstdc++/69699] libstdc++ ABI documentation is out of date

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699 --- Comment #4 from Jonathan Wakely --- (In reply to bastian.beischer from comment #3) > Jonathan, maybe so but it should be mentioned on the page nevertheless, > right? Yes, although I plan to deprecate that macro. > My issue is that we are

[Bug c/69602] [6 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602 --- Comment #11 from Manuel López-Ibáñez --- (In reply to Gerald Pfeifer from comment #10) > (In reply to Jakub Jelinek from comment #8) > > if (errno == EAGAIN || (EWOULDBLOCK != EAGAIN && errno == EWOULDBLOCK)) > > could be better

[Bug c/69602] [6 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602 Gerald Pfeifer changed: What|Removed |Added CC||gerald at pfeifer dot com --- Comment

[Bug fortran/69695] slice of an array retains pointer attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69695 Mikael Morin changed: What|Removed |Added Keywords|accepts-invalid |wrong-code CC|

[Bug other/69554] [6 Regression] Multi-location diagnostics writes too many lines

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554 --- Comment #16 from Manuel López-Ibáñez --- You can also just match the locations and the columns with dg-error. Placing dg-error at the expected lines will match the expected output as explained in comment 12. Fixing dg-begin-multiline-output

[Bug c++/69139] [4.9/5/6 Regression] deduction failure with trailing return type in function template argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69139 --- Comment #3 from TC --- Another test case, slightly modified from the original in the linked SO question: struct X { auto get(int) const & -> int { return {}; } auto get(int) && -> long { return {}; } }; template auto f(auto

[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 fortran/56007] Remarkably bad error message with DO array=1,2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56007 --- Comment #7 from Harald Anlauf --- The patch in comment #6 requires adapting the testsuite accordingly: gfortran.dg/coarray_8.f90:149:7: do i = 1, 5 ! { dg-error "cannot be a sub-component" } needs to be changed to: do i = 1, 5 ! {

[Bug c++/66786] [5/6 Regression] ICE: Segmentation fault

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66786 --- Comment #5 from Patrick Palka --- Looks like the field LAMBDA_TYPE_EXTRA_SCOPE has what we need. I am testing this patch: diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index 4d405cf..5c344c1 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -369,16

[Bug c++/69715] g++ crash dump on building SoftFloatWrapper.cpp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69715 Kip Warner changed: What|Removed |Added CC||kip at thevertigo dot com --- Comment #2

[Bug target/69716] New: asm generates invalid register name

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69716 Bug ID: 69716 Summary: asm generates invalid register name Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target

[Bug middle-end/69714] New: [5 Regression] ffmpeg crc.c test miscompiled

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69714 Bug ID: 69714 Summary: [5 Regression] ffmpeg crc.c test miscompiled Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69713 --- Comment #4 from Oleg Endo --- (In reply to Oleg Endo from comment #3) > > One option could be to merge the casesi_0 and casesi_worker_0 / > casesi_worker_1 patterns somehow into one pattern, so that the block remains > in one place. > >

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67260 --- Comment #15 from Rich Felker --- Is it related to the fact that the relative address load is tied to a specific call site and that the call can't be cloned without producing a new relative address load to go with the clone?

[Bug testsuite/69573] FAIL: gcc.dg/pr61053.c (test for excess errors)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573 --- Comment #3 from Chen Gang --- Created attachment 37625 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37625=edit Under my Darwin mac book OS X Yosemite 10.10.4, it looks short wide alignas for long wide type will cause issue. Under my

[Bug c++/69715] New: g++ crash dump on building SoftFloatWrapper.cpp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69715 Bug ID: 69715 Summary: g++ crash dump on building SoftFloatWrapper.cpp Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component:

[Bug c++/69715] g++ crash dump on building SoftFloatWrapper.cpp

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69715 --- Comment #1 from Kip Warner --- Created attachment 37623 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37623=edit Complete build log (very big, 11 MB decompressed).

[Bug libstdc++/69717] New: std::pair is incompatible with std::is_constructible

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69717 Bug ID: 69717 Summary: std::pair is incompatible with std::is_constructible Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug testsuite/68886] FAIL: gcc.c-torture/execute/stkalign.c execution test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68886 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #4

[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109 --- Comment #14 from David --- I understand that stage 3 is now closed too. I don't have svn write access, so I can't check this in myself.

[Bug c++/69718] New: [concepts] cc1plus segfault on invalid

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69718 Bug ID: 69718 Summary: [concepts] cc1plus segfault on invalid Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug libfortran/69651] Usage of unitialized pointer io/list_read.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69651 --- Comment #3 from Kirill Yukhin --- Created attachment 37627 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37627=edit Reproducer src Reproducer

[Bug libfortran/69651] Usage of unitialized pointer io/list_read.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69651 --- Comment #4 from Kirill Yukhin --- Created attachment 37628 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37628=edit Reproducer input

[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697 --- Comment #4 from raidl at ac dot tuwien.ac.at --- Problem is still present in gcc 5.3.0. Furthermore, it also appears when the thread_local variable is a static class member.

[Bug tree-optimization/69719] New: wrong code at -O3 on x86_64-linux-gnu

model: posix gcc version 6.0.0 20160207 (experimental) [trunk revision 233200] (GCC) $ $ gcc-trunk -O2 small.c; ./a.out $ gcc-5.2 -O3 small.c; ./a.out $ $ gcc-trunk -O3 small.c $ ./a.out Aborted (core dumped) $ gcc-5.3 -O3 small.c $ ./a.out Aborted (core dumped

[Bug tree-optimization/69720] New: wrong code at -O3 on x86_64-linux-gnu

: posix gcc version 6.0.0 20160207 (experimental) [trunk revision 233200] (GCC) $ $ gcc-trunk -O2 small.c; ./a.out $ gcc-5.3 -O3 small.c; ./a.out $ $ gcc-trunk -O3 small.c $ ./a.out Aborted (core dumped) $ - int a, b, c, e, f; long

[Bug fortran/69695] slice of an array retains pointer attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69695 --- Comment #3 from Joost VandeVondele --- (In reply to Mikael Morin from comment #2) > This seems to be allowed, see 12.5.2.7: Interesting, so that's a F2008 feature. The Cray compiler indeed gets this right. > So this is probably a plain

[Bug libfortran/69651] Usage of unitialized pointer io/list_read.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69651 --- Comment #5 from Kirill Yukhin --- A bug in fortran's IO RT has emerged during 21 Apr 2016, between r54 and r92; looks like it's caused by the same revision –r71 (libgfortran/io/list_read.c ), which probably just triggers another

[Bug web/69601] current/ redirect is off by at least a day

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69601 Joost VandeVondele changed: What|Removed |Added CC||gerald at pfeifer dot com,