[Bug libstdc++/82481] dangling reference in mutex:693

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82481 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org ---

[Bug middle-end/81318] [8 regression] ICE in to_reg_br_prob_base, at profile-count.h:189

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81318 --- Comment #30 from Daniel Black --- Still failing for me. $ toolchain/bin/gcc --version gcc (GCC) 8.0.0 20171008 (experimental) (code from comment 27) $ toolchain/bin/gcc -O1 -c /tmp/x.c ... during GIMPLE pass: profile_estimate /tmp/x.c

[Bug libstdc++/82470] Structured bindings don't work with std::tuple if a type has a get member function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82470 --- Comment #4 from Ville Voutilainen --- Ah yes, the compiler is indeed correct, the standard suggests looking up a member function. Time to fix the spec, then. :)

[Bug libstdc++/82481] New: dangling reference in mutex:693

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82481 Bug ID: 82481 Summary: dangling reference in mutex:693 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++

[Bug fortran/82480] New: KIND array returned by STAT too small for many values on CygWin platforms (and probably others)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82480 Bug ID: 82480 Summary: KIND array returned by STAT too small for many values on CygWin platforms (and probably others) Product: gcc Version: 6.4.1 Status: UNCONFIRMED

[Bug middle-end/82479] missing popcount builtin detection

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82479 --- Comment #5 from Andrew Pinski --- Was added to LLVM back in 2012: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20121119/156272.html Again I don't know how useful it is compared to the compile time that it would take.

[Bug middle-end/82479] missing popcount builtin detection

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82479 --- Comment #4 from kugan at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #2) > Confirmed. How useful this optimization is questionable. This code is part of spec2017/deepsjeng. There is some gain if we can. > > Gcc has

[Bug middle-end/82479] missing popcount builtin detection

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82479 --- Comment #3 from Andrew Pinski --- Note __builtin_popcount is correctly done for aarch64 already (I/Naveen added it for GCC 7).

[Bug middle-end/82479] missing popcount builtin detection

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82479 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug middle-end/82479] missing popcount builtin detection

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82479 --- Comment #1 from kugan at gcc dot gnu.org --- gcc trunk generates: PopCount: mov w2, 0 cbz x0, .L1 .p2align 3 .L3: sub x1, x0, #1 add w2, w2, 1 andsx0, x0, x1 bne

[Bug middle-end/82479] New: missing popcount builtin detection

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82479 Bug ID: 82479 Summary: missing popcount builtin detection Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component:

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 --- Comment #19 from Chris Johns --- (In reply to Francois-Xavier Coudert from comment #18) > Adding ".NOTPARALLEL: install-headers" to the libstdc++ Makefile fixes it > perfectly, from what we can see on our apple-darwin test machines. We've

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 Francois-Xavier Coudert changed: What|Removed |Added Component|target |libstdc++ --- Comment #18

[Bug c++/82478] New: Rejects valid access to private member type that should be allowed by friend

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82478 Bug ID: 82478 Summary: Rejects valid access to private member type that should be allowed by friend Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity:

[Bug libstdc++/82470] Structured bindings don't work with std::tuple if a type has a get member function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82470 --- Comment #3 from Marc Glisse --- As with all the issues caused by the EBCO in std::tuple, I believe the answer is PR 63579 (I think it can be done in a way that preserves the layout of tuple).

[Bug target/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 Chris Johns changed: What|Removed |Added CC||chrisj at rtems dot org --- Comment #17

[Bug libstdc++/82470] Structured bindings don't work with std::tuple if a type has a get member function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82470 --- Comment #2 from Morwenn --- Shouldn't it? My reading of the standard (at least from Tim Song's online version) is that the lookup for a get member function is intended. Here is the relevant excerpt from [dcl.struct.bind]: > The

[Bug libfortran/82233] [6/7/8 Regression] execute_command_line causes program to stop when command fails (or does not exist)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233 --- Comment #5 from Thomas Koenig --- This looks good: Index: intrinsics/execute_command_line.c === --- intrinsics/execute_command_line.c (Revision 253525) +++

[Bug ipa/82476] C++: Inlining fails for a simple function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82476 --- Comment #4 from Andrew Pinski --- Note GCC knows main can only be called once (calling main more than once in C/C++ is undefined IIRC) which is why this heuristic is there. If you change the name from main to say ff, then the function gets

[Bug ipa/82476] C++: Inlining fails for a simple function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82476 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug ipa/82476] C++: Inlining fails for a simple function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82476 --- Comment #2 from Marc Glisse --- What is the point of inlining it? It isn't a hot call (called once from main). And unless you are using something like -flto of -fwhole-program (which would turn the function static), it has to be emitted as a

[Bug c++/82468] [7/8 Regression] ICE with deduction guide template

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82468 Martin Liška changed: What|Removed |Added Keywords||ice-on-invalid-code

[Bug tree-optimization/82472] [8 Regression] ICE in generate_code_for_partition, at tree-loop-distribution.c:1145

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82472 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug tree-optimization/82473] [8 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1524

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82473 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug ipa/82476] C++: Inlining fails for a simple function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82476 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug testsuite/82477] New: New testcase cold-1.c fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82477 Bug ID: 82477 Summary: New testcase cold-1.c fails Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite

[Bug libfortran/82233] [6/7/8 Regression] execute_command_line causes program to stop when command fails (or does not exist)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82233 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED CC|

[Bug fortran/82471] do-concurrent is much slower than ordinary-do!

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471 --- Comment #5 from Chinoune --- I have just tried FORALL and it has the same problem : FORALL(K=1:N, J=1:M, I=1:L) is much slower than FORALL(I=1:L, J=1:M, K=1:N).

[Bug c++/82476] New: C++: Inlining fails for a simple function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82476 Bug ID: 82476 Summary: C++: Inlining fails for a simple function Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug fortran/82375] PDT components in PDT declarations fail to compile

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82375 --- Comment #6 from Paul Thomas --- Author: pault Date: Sun Oct 8 15:23:24 2017 New Revision: 253526 URL: https://gcc.gnu.org/viewcvs?rev=253526=gcc=rev Log: 2017-10-08 Paul Thomas PR fortran/82375 *

[Bug web/45778] Append summary information instead of prepending the information

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45778 Frédéric Buclin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug fortran/82471] do-concurrent is much slower than ordinary-do!

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471 --- Comment #4 from Chinoune --- (In reply to Dominique d'Humieres from comment #3) > DO CONCURRENT :8.1975 > DO CONCURRENT : 0.28409 > ORDINARY DO : 0.11604 > ARRAY DO : 0.11808 but with me

[Bug web/33364] reporting bugs + minimizing testcases

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33364 Frédéric Buclin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/61000] No loop interchange for inner loop along the slow index

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000 Thomas Koenig changed: What|Removed |Added Last reconfirmed|2014-06-12 00:00:00 |2017-10-8 CC|

[Bug web/36739] Proposal for clarifications in GCC Bugzilla

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36739 Frédéric Buclin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug fortran/82471] do-concurrent is much slower than ordinary-do!

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug web/79468] Clarify createaccount.cgi

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79468 Frédéric Buclin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c++/82475] New: GCC is unable to compile OpenACC with class fields

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82475 Bug ID: 82475 Summary: GCC is unable to compile OpenACC with class fields Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c++/82475] GCC is unable to compile OpenACC with class fields

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82475 --- Comment #1 from Marcin M. --- Created attachment 42324 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42324=edit test.ii, result from -save-temps

[Bug fortran/82471] do concurrent is much slower the ordinary do!

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82471 --- Comment #2 from Chinoune --- (In reply to Thomas Koenig from comment #1) > There is a subtle problem with your test case, it is the > ordering of the variables in the DO concurrent statement. > > > DO CONCURRENT( K=1:N, J=1:M, I=1:L) >

[Bug libstdc++/82470] Structured bindings don't work with std::tuple if a type has a get member function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82470 Ville Voutilainen changed: What|Removed |Added CC||jason at redhat dot com,

[Bug c++/82474] [8 Regression] ICE: trying to capture ‘list’ in instantiation of generic lambda

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82474 Markus Trippelsdorf changed: What|Removed |Added Keywords||ice-on-valid-code

[Bug c++/82474] New: [8 Regression] ICE: trying to capture ‘list’ in instantiation of generic lambda

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82474 Bug ID: 82474 Summary: [8 Regression] ICE: trying to capture ‘list’ in instantiation of generic lambda Product: gcc Version: 8.0 Status: UNCONFIRMED Severity:

[Bug c++/82466] Missing warning for re-declaration of built-in function as variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82466 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED

[Bug fortran/82471] do concurrent is much slower the ordinary do!

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

[Bug c++/82466] Missing warning for re-declaration of built-in function as variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82466 --- Comment #5 from Bernd Edlinger --- Yes, and I think the C warning should use that option as well.

[Bug tree-optimization/82473] New: [8 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1524

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82473 Bug ID: 82473 Summary: [8 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:1524 Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords:

[Bug tree-optimization/82472] New: [8 Regression] ICE in generate_code_for_partition, at tree-loop-distribution.c:1145

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82472 Bug ID: 82472 Summary: [8 Regression] ICE in generate_code_for_partition, at tree-loop-distribution.c:1145 Product: gcc Version: 8.0 Status: UNCONFIRMED

[Bug c++/82466] Missing warning for re-declaration of built-in function as variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82466 --- Comment #3 from Paolo Carlini --- Yes. Recycling the warning-name that you added seems fine, but we should probably extend the description to something like: "Warn if a built-in function is declared with the wrong signature or as

[Bug c++/82466] Missing warning for re-declaration of built-in function as variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82466 Paolo Carlini changed: What|Removed |Added CC||paolo.carlini at oracle dot com ---