[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610 --- Comment #13 from Steve Kargl --- On Sat, May 20, 2017 at 04:59:10AM +, jvdelisle at gcc dot gnu.org wrote: > > Yes that will take some frontend magic and we have so few people to support > gfortran (for free remember) that we may not be

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org ---

[Bug target/80833] 32-bit x86 causes store-forwarding stalls for int64_t -> xmm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833 --- Comment #4 from Peter Cordes --- I don't think it's worth anyone's time to implement this in 2017, but using MMX regs for 64-bit store/load would be faster on really old CPUs that split 128b vectors insns into two halves, like K8 and Pentium

[Bug target/80833] 32-bit x86 causes store-forwarding stalls for int64_t -> xmm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833 --- Comment #3 from Peter Cordes --- Atom's movd xmm->int is slower (lat=4, rtput=2) than its movd int->xmm (lat=3, rtput=1), which is opposite of every other CPU (except Silvermont where they're the same throughput but xmm->int is 1c slower).

[Bug target/80833] 32-bit x86 causes store-forwarding stalls for int64_t -> xmm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833 --- Comment #2 from Peter Cordes --- On most CPUs, psrldq / movd is optimal for xmm[1] -> int without SSE4. On SnB-family, movd runs on port0, and psrldq can run on port5, so they can execute in parallel. (And the second movd can run the next

[Bug target/80834] PowerPC gcc -mcpu=power9 seems to turn off vectorization that -mcpu=power8 enables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80834 Michael Meissner changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed|

[Bug target/80834] PowerPC gcc -mcpu=power9 seems to turn off vectorization that -mcpu=power8 enables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80834 Michael Meissner changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/80834] New: PowerPC gcc -mcpu=power9 seems to turn off vectorization that -mcpu=power8 enables

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80834 Bug ID: 80834 Summary: PowerPC gcc -mcpu=power9 seems to turn off vectorization that -mcpu=power8 enables Product: gcc Version: 8.0 Status: UNCONFIRMED

[Bug target/80820] _mm_set_epi64x shouldn't store/reload for -mtune=haswell, Zen should avoid store/reload, and generic should think about it.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80820 --- Comment #3 from Peter Cordes --- Also, going the other direction is not symmetric. On some CPUs, a store/reload strategy for xmm->int might be better even if an ALU strategy for int->xmm is best. Also, the choice can depend on chunk size,

[Bug target/80820] _mm_set_epi64x shouldn't store/reload for -mtune=haswell, Zen should avoid store/reload, and generic should think about it.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80820 --- Comment #2 from Peter Cordes --- See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833. gcc -m32 does an even worse job of getting int64_t into an xmm reg, e.g. as part of a 64-bit atomic store. We get a store-forwarding failure from

[Bug target/80833] 32-bit x86 causes store-forwarding stalls for int64_t -> xmm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833 --- Comment #1 from Peter Cordes --- See https://godbolt.org/g/krXH9M for the functions I was looking at.

[Bug target/80833] New: 32-bit x86 causes store-forwarding stalls for int64_t -> xmm

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833 Bug ID: 80833 Summary: 32-bit x86 causes store-forwarding stalls for int64_t -> xmm Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: missed-optimization

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610 --- Comment #11 from Andrew Pinski --- Basically to initialize all of the values of a static array, the array is stored in gfortan memory. To do a 1GB array, you need at least 32times that amount of virtual memory available. Related to bug

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610 --- Comment #10 from Steve Kargl --- On Fri, May 19, 2017 at 08:31:00PM +, gustavo.hime at mpimet dot mpg.de wrote: > > Are there any maintainers on the gfortran project who can see this? I am going > to reopen the bug once more, but then I

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610 --- Comment #9 from Andrew Pinski --- See https://www.kernel.org/doc/Documentation/vm/overcommit-accounting for more on what is going on here. This is not under the gfortran control.

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610 --- Comment #8 from Gustavo Hime --- > > I understand the issue. It isn't a problem with gfortran. > You do not understand the issue, which I made quite clear when reporting the bug. The code compiles, links and runs if no non-zero option

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

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

[Bug c/80806] gcc does not warn if local array is memset only

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80806 --- Comment #5 from prathamesh3492 at gcc dot gnu.org --- Patch posted for review: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01493.html

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610 --- Comment #6 from Steve Kargl --- On Fri, May 19, 2017 at 08:07:17PM +, pinskia at gcc dot gnu.org wrote: > Status|RESOLVED|REOPENED > Resolution|INVALID |--- > > --- Comment

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610 kargl at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610 Gustavo Hime changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID

[Bug c++/79549] [c++1z] ICE in tsubst, at cp/pt.c:13474 with partial specialization of auto... template parameter pack

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79549 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug c++/70167] Some const array prvalues are incorrectly treated as lvalues

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70167 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c++/80178] Class with deleted copy and move constructors uses wrong argument passing ABI

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80178 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug c/80832] New: GCC_COLORS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80832 Bug ID: 80832 Summary: GCC_COLORS Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at

[Bug target/80799] [7/8 Regression] x86-32 bits generates MMX without EMMS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80799 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/70118] UBSan claims misaligned access in SSE instrinsics

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70118 Bug 70118 depends on bug 80799, which changed state. Bug 80799 Summary: [7/8 Regression] x86-32 bits generates MMX without EMMS https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80799 What|Removed |Added

[Bug target/80799] [7/8 Regression] x86-32 bits generates MMX without EMMS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80799 --- Comment #9 from uros at gcc dot gnu.org --- Author: uros Date: Fri May 19 18:08:19 2017 New Revision: 248297 URL: https://gcc.gnu.org/viewcvs?rev=248297=gcc=rev Log: Backport from mainline 2017-05-18 Uros Bizjak

[Bug c++/80831] New: internal compiler error: Segmentation fault with -fsyntax-only

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80831 Bug ID: 80831 Summary: internal compiler error: Segmentation fault with -fsyntax-only Product: gcc Version: 7.1.1 Status: UNCONFIRMED Severity: normal

[Bug c++/80829] Use of constexpr constructors with base type instantiation fails compilation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80829 --- Comment #1 from Benjamin Bannier --- We believe this code is legal C++11 (AFAICT no explicit restrictions on implicit conversions of `constexpr` vars), and was compiling successfully with e.g., 6.3, so we

[Bug c++/80830] ice in tsubst_copy, at cp/pt.c:14569

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80830 --- Comment #1 from David Binderman --- Reduced code, although it doesn't look like legal C++ to me: class a; template < b > void operator<<(a , ; class {friend operator<<(a , ; template < int = 3 > class c { friend

[Bug fortran/80333] Namelist dtio write of array of class does not traverse the array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80333 --- Comment #4 from Jerry DeLisle --- This is now fixed on trunk. The patch fixes both READ and WRITE traversal of arrays of class objects using User Defined Derived Type I/O in NAMELISTs. This could be a slick feature for "serializing" CLASS

[Bug target/80799] [7/8 Regression] x86-32 bits generates MMX without EMMS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80799 --- Comment #8 from uros at gcc dot gnu.org --- Author: uros Date: Fri May 19 15:51:10 2017 New Revision: 248294 URL: https://gcc.gnu.org/viewcvs?rev=248294=gcc=rev Log: Backport from mainline 2017-05-18 Uros Bizjak

[Bug fortran/80333] Namelist dtio write of array of class does not traverse the array

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80333 --- Comment #3 from Jerry DeLisle --- Author: jvdelisle Date: Fri May 19 15:48:35 2017 New Revision: 248293 URL: https://gcc.gnu.org/viewcvs?rev=248293=gcc=rev Log: 2017-05-19 Paul Thomas PR fortran/80333

[Bug ada/58299] Ada defines UNICODE and _UNICODE too late for __MINGW32__

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58299 --- Comment #4 from Eric Botcazou --- > Huh? So you can blatantly ignore it there too? Not only is that completely > asinine, it contradicts the hint on the "add attachment" link: "proposed > *patch*, testcase, etc." Surely, it is much more

[Bug c/78503] -Wint-in-bool-context false positive on unsigned multiplication

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

[Bug fortran/79842] i18n: subword translation in "Can't use the same %smodule"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79842 --- Comment #2 from Paul Thomas --- (In reply to Dominique d'Humieres from comment #1) > Do you agree with the change in comment 0? If yes, I can do the testing and > packaging. Yes, that's fine by me. Thanks Paul

[Bug sanitizer/80800] UBSAN: yet another false positive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80800 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug sanitizer/80800] UBSAN: yet another false positive

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80800 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Fri May 19 15:30:54 2017 New Revision: 248291 URL: https://gcc.gnu.org/viewcvs?rev=248291=gcc=rev Log: PR sanitizer/80800 * fold-const.c (extract_muldiv_1) : Add

[Bug c/80806] gcc does not warn if local array is memset only

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80806 --- Comment #4 from Martin Sebor --- Right, const could be used in lieu of an "in" attribute for warnings. It can't be used for the same thing for optimization because constness can be cast away. Bug 10138 has a good discussion on the subject.

[Bug rtl-optimization/80754] [8 Regression][LRA] Invalid smull instruction generated in lra-remat

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80754 --- Comment #4 from Vladimir Makarov --- (In reply to Wilco from comment #3) > Patch here https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01364.html Thanks for working on the problem, Wilco. I'll review the patch and give you an answer on

[Bug c++/80830] New: ice in tsubst_copy, at cp/pt.c:14569

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80830 Bug ID: 80830 Summary: ice in tsubst_copy, at cp/pt.c:14569 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug c/80793] three signed conversion warnings for the same expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80793 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill

[Bug c/60083] Duplicate conversion warnings from negative integer to unsigned type (gcc-4.3 emits only one warning)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60083 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #4

[Bug c++/80829] New: Use of constexpr constructors with base type instantiation fails compilation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80829 Bug ID: 80829 Summary: Use of constexpr constructors with base type instantiation fails compilation Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity:

[Bug middle-end/80815] wrong code because of broken runtime alias check in vectorizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815 --- Comment #4 from amker at gcc dot gnu.org --- Also the three cases: /* If the left segment does not extend beyond the start of the right segment the new segment length is that of the right plus the segment

[Bug target/72863] Powerpc64le: redundant swaps when using vec_vsx_ld/st

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72863 --- Comment #10 from Bill Schmidt --- Author: wschmidt Date: Fri May 19 14:30:02 2017 New Revision: 248287 URL: https://gcc.gnu.org/viewcvs?rev=248287=gcc=rev Log: 2017-05-19 Bill Schmidt Backport from

[Bug fortran/79842] i18n: subword translation in "Can't use the same %smodule"

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

[Bug fortran/79840] Inconsistent exclamation mark in diagnostic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79840 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug ada/58299] Ada defines UNICODE and _UNICODE too late for __MINGW32__

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58299 --- Comment #3 from Keith Marshall --- (In reply to Eric Botcazou from comment #1) > Patches should be posted on the gcc-patches mailing-list. Huh? So you can blatantly ignore it there too? Not only is that completely asinine, it contradicts

[Bug c/60083] Duplicate conversion warnings from negative integer to unsigned type (gcc-4.3 emits only one warning)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60083 --- Comment #3 from Marek Polacek --- Started with r139049.

[Bug target/80799] [7/8 Regression] x86-32 bits generates MMX without EMMS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80799 --- Comment #7 from uros at gcc dot gnu.org --- Author: uros Date: Fri May 19 14:09:45 2017 New Revision: 248284 URL: https://gcc.gnu.org/viewcvs?rev=248284=gcc=rev Log: Backport from mainline 2017-05-18 Uros Bizjak

[Bug libobjc/54720] libobjc install-strip target not populated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54720 --- Comment #3 from Keith Marshall --- And, more than 4 years later, this issue persists in GCC-6.3.0

[Bug fortran/79840] Inconsistent exclamation mark in diagnostic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79840 David Malcolm changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #5 from David Malcolm

[Bug fortran/79852] diagnostics should not end with exclamation mark

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79852 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug fortran/79852] diagnostics should not end with exclamation mark

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79852 --- Comment #4 from David Malcolm --- Author: dmalcolm Date: Fri May 19 13:52:14 2017 New Revision: 248283 URL: https://gcc.gnu.org/viewcvs?rev=248283=gcc=rev Log: fortran: remove trailing exclamation mark from various diagnostics (PR

[Bug fortran/79840] Inconsistent exclamation mark in diagnostic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79840 --- Comment #4 from Dominique d'Humieres --- > Context is: > > gfc_fatal_error ("Can't USE the same %smodule we're building!", > p->state == COMP_SUBMODULE ? "sub" : ""); > > Possible i18n issue here; are "module" /

[Bug fortran/79840] Inconsistent exclamation mark in diagnostic

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79840 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment

[Bug fortran/80610] Compiler crashes ungraciously when large static array is initialized with anything other than zero

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

[Bug libstdc++/80826] Compilation Time for many of std::map insertions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826 --- Comment #8 from Jonathan Wakely --- Even the unchanged code is almost acceptable with -fno-var-tracking-assignments TOTAL : 357.361.11 359.181206964 kB

[Bug libstdc++/80826] Compilation Time for many of std::map insertions

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

[Bug libstdc++/80826] Compilation Time for many of std::map insertions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826 --- Comment #6 from Jonathan Wakely --- Using -fno-var-tracking-assignments helps too. Inserting the right type: TOTAL: 291.541.14 293.251237034 kB Range-insert from an array of the right type: TOTAL:

[Bug target/52991] attribute packed broken on mingw32?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 Ladislav Láska changed: What|Removed |Added CC||krakonos at krakonos dot org ---

[Bug libstdc++/80826] Compilation Time for many of std::map insertions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826 --- Comment #5 from Jonathan Wakely --- FWIW using -O1 -g -ftime-report on the original code with GCC 5.4.1 gives: TOTAL :1387.175.14 1462.362427702 kB And also prints the -fvar-tracking-assignments note.

[Bug c++/80593] [7 Regression] GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593 Richard Biener changed: What|Removed |Added Known to work||8.0 Summary|[7/8

[Bug c++/80593] [7/8 Regression] GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593 --- Comment #7 from Richard Biener --- Author: rguenth Date: Fri May 19 12:34:54 2017 New Revision: 248269 URL: https://gcc.gnu.org/viewcvs?rev=248269=gcc=rev Log: 2017-05-19 Richard Biener PR c++/80593 *

[Bug libstdc++/80826] Compilation Time for many of std::map insertions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826 --- Comment #4 from Jonathan Wakely --- I don't know why it's so slow, or if it's possible to change the libstdc++ code to help the c++98 case (I doubt it). But it helps a lot if you insert the correct type: mMap.insert (std::pair("1",

[Bug c++/80593] [7/8 Regression] GCC 7, aligned_storage and “dereferencing type-punned pointer will break strict-aliasing rules”

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80593 Richard Biener changed: What|Removed |Added CC||s-beyer at gmx dot net --- Comment #6

[Bug c++/80827] False strict-aliasing warning with certain settings

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

[Bug libstdc++/80796] std::make_xxx_searcher / std::search(iter, iter, searcher) is missing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80796 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug libstdc++/80796] std::make_xxx_searcher / std::search(iter, iter, searcher) is missing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80796 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Fri May 19 12:28:28 2017 New Revision: 248267 URL: https://gcc.gnu.org/viewcvs?rev=248267=gcc=rev Log: PR libstdc++/80796 Add new std::search overload for C++17 PR

[Bug middle-end/80823] [8 Regression] ICE: verify_flow_info failed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80823 Peter Bergner changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org ---

[Bug libstdc++/80796] std::make_xxx_searcher / std::search(iter, iter, searcher) is missing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80796 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Fri May 19 12:11:31 2017 New Revision: 248266 URL: https://gcc.gnu.org/viewcvs?rev=248266=gcc=rev Log: PR libstdc++/80796 Add new std::search overload for C++17 PR

[Bug libstdc++/80796] std::make_xxx_searcher / std::search(iter, iter, searcher) is missing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80796 --- Comment #3 from d25fe0be@ --- Oh, my bad. I did't know about p0433r2, but at least I should have checked n4659 (make_xxx_searcher has already been removed there) before submitting. My apologize. And thanks for pointing out this.

[Bug driver/80828] New: Command line option -e not documented

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80828 Bug ID: 80828 Summary: Command line option -e not documented Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver

[Bug c++/80827] New: False strict-aliasing warning with certain settings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80827 Bug ID: 80827 Summary: False strict-aliasing warning with certain settings Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug libstdc++/80796] std::make_xxx_searcher / std::search(iter, iter, searcher) is missing

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

[Bug libstdc++/80796] std::make_xxx_searcher / std::search(iter, iter, searcher) is missing

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80796 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug tree-optimization/80821] genmatch conflicting predicates

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80821 --- Comment #4 from Richard Biener --- Author: rguenth Date: Fri May 19 11:13:48 2017 New Revision: 248264 URL: https://gcc.gnu.org/viewcvs?rev=248264=gcc=rev Log: 2017-05-19 Richard Biener PR build/80821

[Bug tree-optimization/80821] genmatch conflicting predicates

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

[Bug c++/64095] [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095 Jonathan Wakely changed: What|Removed |Added CC||gufideg at gmail dot com --- Comment

[Bug c++/80795] Cannot take the address of call operator of a variadic lambda when parameter pack length differs from 1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80795 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug middle-end/80815] wrong code because of broken runtime alias check in vectorizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815 --- Comment #3 from amker at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #2) > On Fri, 19 May 2017, amker at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815 > > > > --- Comment #1 from amker

[Bug libstdc++/80826] Compilation Time for many of std::map insertions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826 --- Comment #3 from Richard Biener --- For GCC 7 most time is spent in inlining. I suspect C++14 helps with constexpr evaluation doing some of the stuff in the frontend. integration : 21.73 (39%) usr 0.33 (23%) sys 22.02 (39%)

[Bug middle-end/80815] wrong code because of broken runtime alias check in vectorizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815 --- Comment #2 from rguenther at suse dot de --- On Fri, 19 May 2017, amker at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815 > > --- Comment #1 from amker at gcc dot gnu.org --- > GCC uses vect_factor as minimal

[Bug libstdc++/80826] Compilation Time for many of std::map insertions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826 Richard Biener changed: What|Removed |Added Target|Red Hat 7 Linux x86 64bit | Status|UNCONFIRMED

[Bug c++/80826] Compilation Time for many of std::map insertions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826 --- Comment #1 from seanthesheep1 at hotmail dot com --- I had to stop the compilation as it was close to consuming 100% of the memory and making the box unusable: Cpu(s): 0.0%us, 6.3%sy, 0.0%ni, 88.0%id, 5.8%wa, 0.0%hi, 0.0%si,

[Bug tree-optimization/80821] genmatch conflicting predicates

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80821 --- Comment #2 from Richard Biener --- Index: gcc/genmatch.c === --- gcc/genmatch.c (revision 248263) +++ gcc/genmatch.c (working copy) @@ -3005,6 +3013,8 @@

[Bug middle-end/80815] wrong code because of broken runtime alias check in vectorizer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80815 --- Comment #1 from amker at gcc dot gnu.org --- GCC uses vect_factor as minimal segment length for dr_b when merging alias pairs, I think it could be relaxed to vect_factor * abs (DR_STEP (dr_b)). Below test shows this change can merge

[Bug c++/80826] New: Compilation Time for many of std::map insertions

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80826 Bug ID: 80826 Summary: Compilation Time for many of std::map insertions Product: gcc Version: 4.8.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c/80806] gcc does not warn if local array is memset only

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80806 --- Comment #3 from Daniel Fruzynski --- "in" attribute is similar to "const", I am not sure if we need another one for this. "out" attribute would be handy. I recall than in the past I was looking for it. gcc

[Bug c/78503] -Wint-in-bool-context false positive on unsigned multiplication

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78503 jbeulich at novell dot com changed: What|Removed |Added CC||jbeulich at novell dot com

[Bug testsuite/80759] gcc.target/x86_64/abi/ms-sysv FAILs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- Daniel, > Would you be so kind as to test this on Solaris for me please? I don't have > access to a Solaris machine and I've never set it up before, so I wouldn't > even > know where

[Bug target/78962] i386: Missed optimization: unaligned SSE movs with force_align_arg_pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78962 Daniel Santos changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug target/80819] [5/6/7/8 regression] Useless store to the stack in _mm_set_epi64x with SSE4 -mno-avx

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80819 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED

[Bug target/80820] _mm_set_epi64x shouldn't store/reload for -mtune=haswell, Zen should avoid store/reload, and generic should think about it.

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

[Bug tree-optimization/80821] genmatch conflicting predicates

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

[Bug middle-end/80764] [8 Regression] ICE at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in verify_loop_structure, at cfgloop.c:1644)

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

  1   2   >