http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59871
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59867
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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 ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59870
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59871
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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
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
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
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.
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
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
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):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59871
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59870
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59869
Jonathan Wakely changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #1 from Jonathan
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::_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59862
Dominique d'Humieres changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
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
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59583
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59580
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59872
David Krauss changed:
What|Removed |Added
Attachment #31884|0 |1
is obsolete|
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58087
Sandro Mani changed:
What|Removed |Added
Component|translation |middle-end
Version|4.8.1
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59656
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59869
Paul Pluzhnikov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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. ***
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
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55099
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836
Dominique d'Humieres changed:
What|Removed |Added
CC||thenlich at users dot
sourceforge.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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.
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
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007
Mikael Morin changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
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
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
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.
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #15 from Mikael Morin
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
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.
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
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
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.
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
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
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
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
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.
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
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
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
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
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-
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
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
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
69 matches
Mail list logo
