[Bug fortran/79229] [7.0.1 regression] ICE in gfc_trans_assignment_1 with -fcheck=mem

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79229 Jürgen Reuter changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from

[Bug fortran/79229] New: [7.0.1 regression] ICE in gfc_trans_assignment_1 with -fcheck=mem

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79229 Bug ID: 79229 Summary: [7.0.1 regression] ICE in gfc_trans_assignment_1 with -fcheck=mem Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 --- Comment #23 from Tobias Burnus --- (In reply to Tobias Burnus from comment #22) > As I recently did some incremental builds, I will retry it after a full > bootstrap. Didn't make a difference - I still see the ASAN run-time fail. I wonder

[Bug target/70465] [5/6/7 Regression] Poor code for x87 asm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70465 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

[Bug middle-end/39838] [5/6/7 regression] unoptimal code for two simple loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39838 --- Comment #24 from amker at gcc dot gnu.org --- (In reply to amker from comment #23) > I can also confirm Os is fixed on trunk @244877 using reported command line, > while O2 goes up to 76 now. on arm (with -march=armv5te -mthumb

[Bug middle-end/39838] [5/6/7 regression] unoptimal code for two simple loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39838 amker at gcc dot gnu.org changed: What|Removed |Added CC||amker at gcc dot gnu.org ---

[Bug c/79216] Feature request: byte order attributes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79216 --- Comment #7 from Eric Botcazou --- > As in, I would expect that: > > struct foo __attribute__((scalar_storage_order("big-endian"))) > { > uint32_t bar; > } foo; > > uint32_t *baz = > > ... would give an error on a littleendian

[Bug other/79046] g++ -print-file-name=plugin uses full version number in path

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79046 --- Comment #12 from Jakub Jelinek --- Author: jakub Date: Wed Jan 25 11:54:36 2017 New Revision: 244895 URL: https://gcc.gnu.org/viewcvs?rev=244895=gcc=rev Log: PR other/79046 * configure.ac: Add GCC_BASE_VER. *

[Bug middle-end/39838] [5/6/7 regression] unoptimal code for two simple loops

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39838 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|NEW CC|

[Bug c/79216] Feature request: byte order attributes

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

[Bug c++/79228] 'i' suffix for __complex__ extension interferes with C++14 UDLs for std::complex

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79228 --- Comment #2 from Richard Biener --- We have -fext-numeric-literals which we could disable by default (and the user can switch that back on for backward compatibility). Of course that not only guards 'i'...

[Bug libstdc++/79226] Additional overloads needed for __complex__ types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79226 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c++/79228] __complex__ extension interferes with C++14 UDLs for std::complex

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79228 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621 --- Comment #15 from Richard Biener --- On trunk only the cost model prevents vectorization of the s32 loop now (with generic tuning/arch). With core-avx2 I get for both innermost loops .L6: addl$1, %r10d vmovapd

[Bug c++/79228] New: __complex__ extension interferes with C++14 UDLs for std::complex

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79228 Bug ID: 79228 Summary: __complex__ extension interferes with C++14 UDLs for std::complex Product: gcc Version: 6.3.1 Status: UNCONFIRMED Keywords:

[Bug c/79227] New: Questionable -Wmisleading-indentation diagnostic in HSAIL-Tools

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79227 Bug ID: 79227 Summary: Questionable -Wmisleading-indentation diagnostic in HSAIL-Tools Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: minor

[Bug target/79145] [5/6 Regression] iwmmxt: Internal compiler error caused by an unrecognizable insn, during XORing long long with a char constant

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79145 ktkachov at gcc dot gnu.org changed: What|Removed |Added Known to work||7.0

[Bug target/79145] [5/6/7 Regression] iwmmxt: Internal compiler error caused by an unrecognizable insn, during XORing long long with a char constant

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79145 --- Comment #6 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Wed Jan 25 11:10:30 2017 New Revision: 244894 URL: https://gcc.gnu.org/viewcvs?rev=244894=gcc=rev Log: [ARM] PR target/79145 Fix xordi3 expander for immediate operands in

[Bug libstdc++/79226] New: Additional overloads needed for __complex__ types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79226 Bug ID: 79226 Summary: Additional overloads needed for __complex__ types Product: gcc Version: 6.3.1 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 --- Comment #22 from Tobias Burnus --- (In reply to Maxim Ostapenko from comment #21) > Strange, new testcase (with strdup) doesn't fail for me: [...] That's odd; I re-check with your options (except that g++ 7 is here in the PATH) and I still

[Bug libstdc++/61791] [C++11] [constexpr] Additional overloads of std::real should be a constexpr function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61791 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2015-04-09 00:00:00 |2017-1-25 --- Comment #3 from

[Bug middle-end/79176] [6/7 Regression] ICE in mangle_decl with LTO and Os

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79176 Jan Hubicka changed: What|Removed |Added CC||jason at redhat dot com --- Comment #3

[Bug rtl-optimization/77770] [5/6/7 Regression] Internal compiler error on source which compiles with earlier versions.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Nick Clifton changed: What|Removed |Added Status|NEW |ASSIGNED CC|

[Bug middle-end/70831] [6/7 Regression] FTBFS: Build fails with bootstrap-lto and profiledbootstrap

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70831 Jan Hubicka changed: What|Removed |Added CC||enkovich.gnu at gmail dot com,

[Bug c++/56671] Gcc uses large amounts of memory and processor power with large C++11 bitsets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56671 İsmail Dönmez changed: What|Removed |Added CC||ismail at i10z dot com --- Comment #8

[Bug c++/79225] Memory hog for large initializers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79225 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/79225] New: Memory hog for large initializers

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79225 Bug ID: 79225 Summary: Memory hog for large initializers Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: memory-hog Severity: normal Priority: P3

[Bug c++/56671] Gcc uses large amounts of memory and processor power with large C++11 bitsets

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56671 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment

[Bug lto/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78529 --- Comment #29 from Jan Hubicka --- I think the official answer for LTOing symbols implementing runtime (i.e. those that can be introduced by middle-end) is "don't do that". We may support LTOing them with an explicit attribute "used" on them

[Bug tree-optimization/79224] [7 Regression] Large C-Ray slowdown

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224 --- Comment #3 from Martin Liška --- Just for curiosity, all releases: 4.7.0 (93c5ebd73a4d1626)(22 Mar 2012 07:11): [took: 2.836s] result: OK Rendering took: 2 seconds (2531 milliseconds) 4.7.1 (0e3097e7d505b7be)(14 Jun 2012 08:32): [took:

[Bug tree-optimization/79224] [7 Regression] Large C-Ray slowdown

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224 --- Comment #2 from Martin Liška --- r244884 (current trunk): 2409 milliseconds r240470 (25 Sep 2016): 2309 milliseconds

[Bug tree-optimization/79224] [7 Regression] Large C-Ray slowdown

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

[Bug libstdc++/70607] [5/6/7 Regression] The return type of std::conj must be std::complex

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70607 Jonathan Wakely changed: What|Removed |Added Known to work||4.4.7 Summary|The return

[Bug middle-end/79212] [6/7 Regression] internal compiler error: in maybe_lookup_decl_in_outer_ctx, at omp-low.c:4134

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79212 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code

[Bug middle-end/79212] internal compiler error: in maybe_lookup_decl_in_outer_ctx, at omp-low.c:4134

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79212 --- Comment #2 from davids at gcc dot gnu.org --- Created attachment 40575 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40575=edit Simple openmp test case that exposes the ICE Compile the test with "gfortran -fopenmp"

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 --- Comment #21 from Maxim Ostapenko --- (In reply to Tobias Burnus from comment #20) > Created attachment 40574 [details] > New still failing test case (tar.gz), slightly modifying the previous one > > (In reply to chefmax from comment #19) >

[Bug debug/78363] [7 Regression] ICE in in force_type_die, at dwarf2out.c:24864

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78363 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug debug/78363] [7 Regression] ICE in in force_type_die, at dwarf2out.c:24864

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78363 --- Comment #9 from Richard Biener --- Author: rguenth Date: Wed Jan 25 09:48:10 2017 New Revision: 244892 URL: https://gcc.gnu.org/viewcvs?rev=244892=gcc=rev Log: 2017-01-25 Richard Biener PR debug/78363

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333 --- Comment #12 from Tony Kelman --- Output of dump options uploaded here (8.2 MB file): https://github.com/tkelman/docker-gcc-bisect/raw/07f6fa56e2f6d60ff90613b9c036f830fb8a422a/LLVMVectorize.tar.gz

[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 --- Comment #20 from Tobias Burnus --- Created attachment 40574 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40574=edit New still failing test case (tar.gz), slightly modifying the previous one (In reply to chefmax from comment #19) >

[Bug c/79219] Feature request: double width/single width -> single width integer division and remainder

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333 --- Comment #11 from Tony Kelman --- Thank you! -fno-devirtualize on its own did not help. -fno-ipa-cp on its own did fix the problem. Adding -fno-ipa-cp only when compiling lib/Transforms/Vectorize/SLPVectorizer.cpp was enough to fix the

[Bug c/79219] Feature request: double width/single width -> single width integer division and remainder

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219 --- Comment #2 from Uroš Bizjak --- (In reply to Richard Biener from comment #1) > So you mean DW/W -> W, but that can result in the result being not > representable? > What's the desired behavior in this case? Invoking undefined behavior? x86

[Bug middle-end/79212] internal compiler error: in maybe_lookup_decl_in_outer_ctx, at omp-low.c:4134

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79212 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug tree-optimization/79224] New: [7 Regression] Large C-Ray slowdown

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224 Bug ID: 79224 Summary: [7 Regression] Large C-Ray slowdown Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal

[Bug tree-optimization/79224] [7 Regression] Large C-Ray slowdown

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0

[Bug c/79216] Feature request: byte order attributes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79216 Richard Biener changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org ---

[Bug fortran/60913] [OOP] Memory leak with allocatable polymorphic function result (in type-bound operator)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60913 --- Comment #7 from Chris --- Damian, can you tell me where in the standard allocatable polymorphic results are prohibited with pure functions? I've been using them that way in my code, which compiles without issue using gfortran. I haven't

[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 Yuri Gribov changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #4

[Bug c/79219] Feature request: double width/single width -> single width integer division and remainder

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79219 --- Comment #1 from Richard Biener --- So you mean DW/W -> W, but that can result in the result being not representable? What's the desired behavior in this case? Invoking undefined behavior?

[Bug target/69264] [5/6/7 regression] ICE building spidermonkey -mcpu=970 -maltivec -O3: rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:4350

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69264 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

<    1   2