[Bug c/59870] Gcc should warn conversion from "const char*" to "char*" for string literals

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59870 --- Comment #7 from Andrew Pinski --- (In reply to Chengnian Sun from comment #6) > (In reply to Harald van Dijk from comment #2) > > The type of a string literal in C is char[N], unlike in C++ where it is > > const char[N]. clang's -Weverything o

[Bug c/59870] Gcc should warn conversion from "const char*" to "char*" for string literals

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59870 --- Comment #6 from Chengnian Sun --- (In reply to Harald van Dijk from comment #2) > The type of a string literal in C is char[N], unlike in C++ where it is > const char[N]. clang's -Weverything option enables -Wwrite-strings, which > changes the

[Bug c++/59867] Template string literal loses first symbol

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867 --- Comment #8 from Ed Smith-Rowland <3dw4rd at verizon dot net> --- I put this in a while back because it looked like it was going into C++14. I jumped to gun. Unfortunately, I am not on a place where I can look at this until Tuesday. It should

[Bug tree-optimization/59875] New: Weak symbols in glibc prevent optimizations

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59875 Bug ID: 59875 Summary: Weak symbols in glibc prevent optimizations Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: tree-

[Bug c++/59874] New: Missing builtin (__builtin_clzs) when compiling with g++

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59874 Bug ID: 59874 Summary: Missing builtin (__builtin_clzs) when compiling with g++ Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priori

[Bug target/58928] Different results from gcc when -mlzcnt is used

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58928 --- Comment #5 from Michael Barker --- (In reply to Jakub Jelinek from comment #4) > Intel(R) Xeon(R) CPU E5620 @2.40GHz > is not IvyBridge, plus even IvyBridge doesn't support lzcnt insn, only > Haswell or some recent AMD CPUs. So, this looks li

[Bug fortran/57129] [4.7/4.8/4.9 Regression] ICE (segfault) in check_extended_derived_type

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57129 --- Comment #7 from Dominique d'Humieres --- > On darwin12/13 I don't get the ICE even for r201916. I don't know what I did. After rechecking I found that r202804 gives the ICE and r202825 does not. The error is now pr57129.f90:2.8: type t

[Bug c++/59873] The value of char32_t U'\u0000' and char16_t u'\u000' is 1, instead of 0.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873 Wesley J. Landaker changed: What|Removed |Added See Also||http://llvm.org/bugs/show_b

[Bug c++/59873] The value of char32_t U'\u0000' and char16_t u'\u000' is 1, instead of 0.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873 --- Comment #6 from Andreas Schwab --- \u is only malformed outside of string and char literals, eg. in identifiers.

[Bug fortran/57129] [4.7/4.8/4.9 Regression] ICE (segfault) in check_extended_derived_type

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57129 --- Comment #6 from Dominique d'Humieres --- On darwin10 I get the ICE with r202590 (2013-09-14), but not with r204463 (2013-11-06). On darwin12/13 I don't get the ICE even for r201916. May be fixed by revision 202823 Author:janus Date:M

[Bug c++/59873] The value of char32_t U'\u0000' and char16_t u'\u000' is 1, instead of 0.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873 --- Comment #5 from Wesley J. Landaker --- (In reply to Marc Glisse from comment #4) > Seems to be on purpose, see the comment before _cpp_valid_ucn in > libcpp/charset.c, and the last instruction in that function. > > [lex.charset] is a bit hard

[Bug c/59870] Gcc should warn conversion from "const char*" to "char*" for string literals

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59870 --- Comment #5 from Marc Glisse --- (In reply to Chengnian Sun from comment #4) > I realize that the options "-Wall -Wextra" do not enable all the warnings. > Is there a flag in GCC which enables all the available warning types, > similar to -Weve

[Bug c++/59873] The value of char32_t U'\u0000' and char16_t u'\u000' is 1, instead of 0.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873 --- Comment #4 from Marc Glisse --- Seems to be on purpose, see the comment before _cpp_valid_ucn in libcpp/charset.c, and the last instruction in that function. [lex.charset] is a bit hard to read for me.

[Bug c/59870] Gcc should warn conversion from "const char*" to "char*" for string literals

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59870 --- Comment #4 from Chengnian Sun --- Thanks for your clarification, Harald, Jakub and Andrew. I realize that the options "-Wall -Wextra" do not enable all the warnings. Is there a flag in GCC which enables all the available warning types, simil

[Bug c++/59873] The value of char32_t U'\u0000' and char16_t u'\u000' is 1, instead of 0.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873 --- Comment #3 from Wesley J. Landaker --- Created attachment 31887 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31887&action=edit A truncated version of char32_literal_test.c++ I also made another program that tests ALL possible char32_t

[Bug c++/59873] The value of char32_t U'\u0000' and char16_t u'\u000' is 1, instead of 0.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873 --- Comment #2 from Wesley J. Landaker --- Created attachment 31886 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31886&action=edit The test.c++ program shown in the bug For convenience, here is the test.c++ program as an attachment (same e

[Bug c++/59873] The value of char32_t U'\u0000' and char16_t u'\u000' is 1, instead of 0.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873 Wesley J. Landaker changed: What|Removed |Added Version|4.8.3 |4.9.0 --- Comment #1 from Wesley J.

[Bug c++/59873] New: The value of char32_t U'\u0000' and char16_t u'\u000' is 1, instead of 0.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873 Bug ID: 59873 Summary: The value of char32_t U'\u' and char16_t u'\u000' is 1, instead of 0. Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: major

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007 Mikael Morin changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #15 from Mikael Morin

[Bug fortran/57129] [4.7/4.8/4.9 Regression] ICE (segfault) in check_extended_derived_type

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57129 --- Comment #5 from Dominique d'Humieres --- > Cannot reproduce anymore. I can reproduce it with gfortran 4.8.2, but not with trunk (r206759), nor with 4.7.4/4.8.3.

[Bug bootstrap/59496] [4.9 Regression] Bootstrap fails on powerpc-apple-darwin9 after r205685

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59496 --- Comment #6 from Dominique d'Humieres --- Patch posted at http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00816.html.

[Bug lto/58733] [4.9 Regression] ICE in operator[], at vec.h:827

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58733 --- Comment #10 from Markus Trippelsdorf --- With gold I get: markus@x4 lto % cat 20090302_0.C /* { dg-lto-do link } */ /* { dg-require-effective-target fpic } */ /* { dg-lto-options {{-fPIC -flto -flto-partition=1to1 -r -nostdlib}} } */ struct F

[Bug fortran/57129] [4.7/4.8/4.9 Regression] ICE (segfault) in check_extended_derived_type

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57129 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 f

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007 Mikael Morin changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007 --- Comment #13 from Mikael Morin --- Author: mikael Date: Sat Jan 18 20:05:25 2014 New Revision: 206759 URL: http://gcc.gnu.org/viewcvs?rev=206759&root=gcc&view=rev Log: fortran/ PR fortran/58007 * module.c (MOD_VERSION): Bump.

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 --- Comment #17 from H.J. Lu --- (In reply to Uroš Bizjak from comment #16) > (In reply to H.J. Lu from comment #15) > > > Either patch fixes the problem. > > I prefer first patch. It splits all LEAs, where ix86_avoid_lea_for_addr is > true. Th

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 --- Comment #16 from Uroš Bizjak --- (In reply to H.J. Lu from comment #15) > Either patch fixes the problem. I prefer first patch. It splits all LEAs, where ix86_avoid_lea_for_addr is true.

[Bug c++/59867] Template string literal loses first symbol

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867 --- Comment #7 from Username --- I've heard that it was previously expected to be in C++14, though it was somehow forgotten, because the fix is quite small and one could currently do it with a little bit of preprocessor/constexpr (MPLLIBS_STRING i

[Bug libfortran/59836] [4.7/4.8/4.9 Regression] Wrong outputs with rounding formats for some values.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836 Dominique d'Humieres changed: What|Removed |Added CC||thenlich at users dot sourceforge.

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

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

[Bug libfortran/59836] [4.7/4.8/4.9 Regression] Wrong outputs with rounding formats for some values.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836 --- Comment #7 from Dominique d'Humieres --- I'll do the packaging over the week-end. BTW this PR is a duplicate of what is left in pr48787 (part of it was already analyzed in pr48787 comment 24).

[Bug fortran/55099] Surprising but valid 'PROCEDURE attribute conflicts with INTENT attribute' error

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

[Bug libfortran/59836] [4.7/4.8/4.9 Regression] Wrong outputs with rounding formats for some values.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836 --- Comment #6 from Jerry DeLisle --- Dominiq, Well, obviously we have a lot of history on this code and many changes to get where we are now. Very much appreciate your analysis. A fresh look is always helpful. If you could prepare a changelog.

[Bug target/59379] [4.9 Regression] gomp_init_num_threads is compiled into an infinite loop with --with-arch=corei7 --with-cpu=slm

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59379 H.J. Lu changed: What|Removed |Added CC||ubizjak at gmail dot com --- Comment #15 from H

[Bug libstdc++/59869] [C++11] std::weak_ptr is thread-unsafe when built with -fno-exceptions

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59869 Paul Pluzhnikov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/59656] weak_ptr::lock function crashes when compiling with -fno-exceptions flag

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656 --- Comment #3 from Paul Pluzhnikov --- *** Bug 59869 has been marked as a duplicate of this bug. ***

[Bug libstdc++/59656] weak_ptr::lock function crashes when compiling with -fno-exceptions flag

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656 Paul Pluzhnikov changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comme

[Bug libfortran/59836] [4.7/4.8/4.9 Regression] Wrong outputs with rounding formats for some values.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836 Dominique d'Humieres changed: What|Removed |Added CC||jb at gcc dot gnu.org --- Comment

[Bug middle-end/58087] Huge memory consumption with #pragma GCC optimize, __attribute__ and long output paths

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58087 Sandro Mani changed: What|Removed |Added Component|translation |middle-end Version|4.8.1

[Bug c++/51253] [C++11][DR 1030] Evaluation order (sequenced-before relation) among initializer-clauses in braced-init-list

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253 --- Comment #6 from Akim Demaille --- FWIW, because of this issue, I no longer use g++ for my project, which saddens me. If there were a means to put money on some bugs, I'd be happy to drop say $50. I do not pretend that should suffice, but may

[Bug libstdc++/59872] Cannot move std::map with move-only mapped_type

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872 David Krauss changed: What|Removed |Added Attachment #31884|0 |1 is obsolete|

[Bug libstdc++/59872] Cannot move std::map with move-only mapped_type

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872 --- Comment #4 from David Krauss --- Created attachment 31884 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31884&action=edit SFINAE based fix This seems stylistically OK, but I did copy-paste the implementation of moving. Perhaps the commo

[Bug libfortran/59774] [4.8/4.9 Regression] Inconsistent rounding between -m32 and -m64

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #13 from Dominique d'Humieres --- The change of behavior occurred between r203500 (2013-10-13) and r203859 (2013-10-19). Since libgfortran/io/write_float.def has not change between r199598 and r206296 (Update copyright years in libgfor

[Bug bootstrap/59580] --with-arch=generic is allowed to configure GCC

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59580 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug bootstrap/59583] --enable-targets=all --with-cpu=broadwell isn't allowed to configure i686-linux

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59583 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/59872] Cannot move std::map with move-only mapped_type

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872 --- Comment #3 from David Krauss --- Thanks, I'm working on it now. Is there some precedent for this kind of SFINAE in libstdc++? The hard part is getting the style right. Metaprogramming looks weird in 80 columns. As for the defect report, my t

[Bug bootstrap/59580] --with-arch=generic is allowed to configure GCC

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59580 --- Comment #1 from hjl at gcc dot gnu.org --- Author: hjl Date: Sat Jan 18 13:25:40 2014 New Revision: 206756 URL: http://gcc.gnu.org/viewcvs?rev=206756&root=gcc&view=rev Log: Update x86 --with-arch/--with-cpu= configure handling PR bootstr

[Bug bootstrap/59583] --enable-targets=all --with-cpu=broadwell isn't allowed to configure i686-linux

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59583 --- Comment #1 from hjl at gcc dot gnu.org --- Author: hjl Date: Sat Jan 18 13:25:40 2014 New Revision: 206756 URL: http://gcc.gnu.org/viewcvs?rev=206756&root=gcc&view=rev Log: Update x86 --with-arch/--with-cpu= configure handling PR bootstr

[Bug libstdc++/59872] Cannot move std::map with move-only mapped_type

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872 --- Comment #2 from Jonathan Wakely --- Yes, the branch that copies needs to be a separate function. http://cplusplus.github.io/LWG/lwg-active.html#2108 might answer your last question

[Bug libstdc++/59872] Cannot move std::map with move-only mapped_type

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872 --- Comment #1 from David Krauss --- It looks like the allocator-aware update introduced a copying branch to the move constructor, to handle the case of transferring an object from one stateful allocator to another. The branch on _Alloc_traits::_

[Bug other/59862] Code does not compile with 4.8.1 tarball release but compiles with 4.8.1 SVN release

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59862 Dominique d'Humieres changed: What|Removed |Added CC||jakub at gcc dot gnu.org,

[Bug libstdc++/59869] [C++11] std::weak_ptr is thread-unsafe when built with -fno-exceptions

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59869 Jonathan Wakely changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #1 from Jonathan

[Bug libfortran/59836] [4.7/4.8/4.9 Regression] Wrong outputs with rounding formats for some values.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836 --- Comment #4 from Dominique d'Humieres --- Any comment about the following patch for testing the fix of this PR? --- ../_clean/gcc/testsuite/gfortran.dg/round_3.f082011-05-05 03:54:21.0 +0200 +++ gcc/testsuite/gfortran.dg/round_3.f0

[Bug libstdc++/59872] New: Cannot move std::map with move-only mapped_type

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872 Bug ID: 59872 Summary: Cannot move std::map with move-only mapped_type Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: li

[Bug c/59870] Gcc should warn conversion from "const char*" to "char*" for string literals

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59870 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|

[Bug c/59871] [4.7/4.8/4.9 Regression] No unused value warning for comma expression

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59871 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at

[Bug target/58944] [4.9 Regression] bogus -Wunused-macros warnings when compiling Libreoffice

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug target/58944] [4.9 Regression] bogus -Wunused-macros warnings when compiling Libreoffice

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Sat Jan 18 10:18:33 2014 New Revision: 206750 URL: http://gcc.gnu.org/viewcvs?rev=206750&root=gcc&view=rev Log: PR target/58944 * config/i386/i386-c.c (ix86_pragma_target_parse):

[Bug c/59871] [4.7/4.8/4.9 Regression] No unused value warning for comma expression

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59871 --- Comment #5 from Jakub Jelinek --- And similarly in emit_side_effect_warnings, if there are TREE_SIDE_EFFECTS, but the expr is COMPOUND_EXPR, find the rightmost operand of the nested COMPOUND_EXPRs and if it doesn't have TREE_SIDE_EFFECTS, warn

[Bug c/59871] [4.7/4.8/4.9 Regression] No unused value warning for comma expression

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59871 --- Comment #4 from Jakub Jelinek --- I'd say easiest would be at the spot where we warn currently about the left-hand ... check if the left hand operand is a COMPOUND_EXPR, in that case find the rightmost operand of all the nested COMPOUND_EXPRs

[Bug c++/59867] Template string literal loses first symbol

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867 --- Comment #6 from Paolo Carlini --- I went through the formal motions passed in Bristol and Chicago and didn't see it, thus shouldn't be in C++14. C++17 maybe, nothing is decided yet.

[Bug c/59871] [4.7/4.8/4.9 Regression] No unused value warning for comma expression

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59871 Jakub Jelinek changed: What|Removed |Added Summary|No unused value warning for |[4.7/4.8/4.9 Regression] No

[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763 --- Comment #24 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #23) > (In reply to Jakub Jelinek from comment #22) > > Created attachment 31868 [details] > > gcc49-pr57763.patch > > > > Uros, can you please bootstrap/regtest on alpha

[Bug c++/59867] Template string literal loses first symbol

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867 Jakub Jelinek changed: What|Removed |Added CC||emsr at gcc dot gnu.org --- Comment #5 fr

[Bug c/59871] No unused value warning for comma expression

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59871 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c/59870] Gcc should warn conversion from "const char*" to "char*" for string literals

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59870 Harald van Dijk changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #

[Bug c++/59867] Template string literal loses first symbol

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867 --- Comment #4 from Paolo Carlini --- In fact current clang accepts the code as a GNU extension and we don't ;)

[Bug c++/59867] Template string literal loses first symbol

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c/59871] No unused value warning for comma expression

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59871 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org,