http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43488
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61004
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965
--- Comment #5 from Andrew Haley ---
Jan, can we please have an ETA to fix this? It is a very importantant problem
for Java because it breaks OpenJDK.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010
--- Comment #4 from ktkachov at gcc dot gnu.org ---
Hmmm...
int main (void)
{
int a = 0;
unsigned b = (a * 64 & 192) | 63;
return 0;
}
works (i.e. 63 without the U).
I suspect there's something dodgy with the implementation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010
Richard Biener changed:
What|Removed |Added
Known to work||4.7.3
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61003
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.1
Summary|[4.9 Regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48329
--- Comment #2 from Dominique d'Humieres ---
This seems to have been fixed during the 4.7 revisions: I see the problem with
4.6.4, but not with 4.7.3 or higher.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61004
--- Comment #5 from Richard Biener ---
B doesn't have a FIELD_DECL for its base A, not sure why. If we make A
non-empty
we get
f ((const struct A &) (const struct A *) &b.D.2231)
with empty A (and no field for it) we get
f ((const struct A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #24 from Domin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61004
--- Comment #6 from Richard Biener ---
Created attachment 32713
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32713&action=edit
untested patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60964
Steffen Hau changed:
What|Removed |Added
URL||https://svn.boost.org/trac/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010
--- Comment #5 from Richard Biener ---
Indeed we iterate in /* Canonicalize (X & C1) | C2. */ because we fold
(unsigned int) (a * 64) & 255
to
(unsigned int) (a * 64) & 192
in /* Fold (X * CST1) & CST2 to zero if we can, or drop known zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60964
Markus Trippelsdorf changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60607
Markus Trippelsdorf changed:
What|Removed |Added
CC||steffen at hauihau dot de
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61011
Bug ID: 61011
Summary: libstdc++-v3 should be target-libstdc++-v3 in top
level configure
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61010
--- Comment #7 from Richard Biener ---
Like
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 209928)
+++ gcc/fold-const.c(working copy)
@@ -11426,7 +11426,6 @@ fold_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000
--- Comment #2 from Mircea Namolaru ---
Again, the problem is due to representation of arrays in Fortran as array with
a single dimnesion (for similar code in C profitability check work as
expected). It is a recurring problem that may lead to comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000
--- Comment #3 from Richard Biener ---
(In reply to Mircea Namolaru from comment #2)
> Again, the problem is due to representation of arrays in Fortran as array
> with a single dimnesion (for similar code in C profitability check work as
> expecte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61012
Bug ID: 61012
Summary: lto1: errors during merging of translation units
(error: variable ‘link’ redeclared as function)
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000
--- Comment #4 from Mircea Namolaru ---
Right, C arrays expressed as pointers suffers from the same problem.
But for C at least there is a way to avoid this.
Many thanks for your suggestion of how to de-linearize arrays in middle-end, it
seems t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
Bug ID: 61013
Summary: Option parsing difference between < 4.9 and 4.9
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: deb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48329
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61004
--- Comment #7 from Lars Gullik Bjønnes ---
(In reply to Richard Biener from comment #6)
> Created attachment 32713 [details]
> untested patch
This fixes the problem for me, in my
application.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48329
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Wed Apr 30 11:43:41 2014
New Revision: 209930
URL: http://gcc.gnu.org/viewcvs?rev=209930&root=gcc&view=rev
Log:
2014-04-30 Richard Biener
PR tree-optimization/48329
* gfortr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61012
Richard Biener changed:
What|Removed |Added
Keywords||lto, rejects-valid
Status|UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61012
--- Comment #2 from Richard Biener ---
Reduced b.c:
extern int link (const char *, const char *);
int main()
{
return foo() + link("foo", "bar");
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014
Bug ID: 61014
Summary: [4.6/4.7/4.8/4.9 Regression] gdb can't find symbol of
derived data type array in nested subroutine
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.7.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60081
--- Comment #4 from Stan Manilov ---
Here is a simple way to reproduce the bug:
==
#include
#include
int main() {
std::vector> v;
std::unique_ptr px(new int (1));
v.push_back(px);
}
=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43996
--- Comment #16 from Dominique d'Humieres ---
The following patch fixes the ICE without reverting the fix for pr40472:
--- ../_clean/gcc/fortran/simplify.c2014-04-27 12:52:10.0 +0200
+++ gcc/fortran/simplify.c2014-04-30 14:23:46.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
--- Comment #25 from Mike Jarvis ---
The bug does not seem to be present with g++ 4.8.2 on OSX 10.9.2. I no longer
have access to a 10.6 machine, so I cannot confirm whether it is fixed with 4.8
on that system.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
--- Comment #26 from simon at pushface dot org ---
(In reply to Dominique d'Humieres from comment #24)
> Is this PR still present?
Not with g++ (or Ada) in 4.9.0 on Max OS X 10.9.2 (darwin13.1.0).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42159
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014
--- Comment #3 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #2)
> As you also have "idb" at hand
I now did it myself with gcc 4.10 and idbc 13.0. (I don't have ifort.)
Result:
In line 10, I get:
(idb) p bar
$3 = {i = -1}
but i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61003
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Wed Apr 30 14:23:18 2014
New Revision: 209934
URL: http://gcc.gnu.org/viewcvs?rev=209934&root=gcc&view=rev
Log:
PR c++/60980
* init.c (build_value_init): Don't try to call an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60951
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Wed Apr 30 14:23:27 2014
New Revision: 209935
URL: http://gcc.gnu.org/viewcvs?rev=209935&root=gcc&view=rev
Log:
PR c++/60951
* typeck2.c (massage_init_elt): Use maybe_constant_init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60951
--- Comment #2 from Jason Merrill ---
Author: jason
Date: Wed Apr 30 14:23:11 2014
New Revision: 209933
URL: http://gcc.gnu.org/viewcvs?rev=209933&root=gcc&view=rev
Log:
PR c++/60951
* typeck2.c (massage_init_elt): Use maybe_constant_init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830
Kai Tietz changed:
What|Removed |Added
CC||fanael4 at gmail dot com
--- Comment #47 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61003
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60951
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61016
Bug ID: 61016
Summary: use of uninitialized memory in gcc/config/i386/i386.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980
--- Comment #7 from Jason Merrill ---
Author: jason
Date: Wed Apr 30 14:23:34 2014
New Revision: 209936
URL: http://gcc.gnu.org/viewcvs?rev=209936&root=gcc&view=rev
Log:
PR c++/60980
* init.c (build_value_init): Don't try to call an array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
--- Comment #2 from Andres Freund ---
Hi,
On 2014-04-30 14:54:20 +, pinskia at gcc dot gnu.org wrote:
> -g is the same as -g2 and the later option is supposed to override the first
> one. Jus like how -O is handled.
The point is that this ha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
Jakub Jelinek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
Michael Chapman changed:
What|Removed |Added
CC||michael.chapman at cortus dot
com
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
--- Comment #4 from Andrew Pinski ---
It was not on accident, see
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00260.html and
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg02077.html
And even where I said http://gcc.gnu.org/ml/gcc-patches/2011-04
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
--- Comment #5 from Andres Freund ---
Hi,
On 2014-04-30 15:48:33 +, pinskia at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
>
> --- Comment #4 from Andrew Pinski ---
> It was not on accident, see
> http://gcc.g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
--- Comment #6 from Jakub Jelinek ---
I certainly haven't noticed that discussion, if I did, I would object already
by that time.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #22 from Matthew Woehlke ---
Thanks for the patch. However, one thing I am not seeing is an easy way to
suppress the warning for a specific occurrence (a la [[clang:fallthrough]]).
Can that be added also? (Or is it there and I miss some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #23 from Manuel López-Ibáñez ---
(In reply to Michael Chapman from comment #21)
> Created attachment 32716 [details]
> Proposed patch
>
> Patch to enable warnings (-Wswitch-fallthrough) when a switch case falls
> through. Enabled by -W
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #24 from Jonathan Wakely ---
(In reply to Matthew Woehlke from comment #22)
> [[gcc:fallthrough]] // suppress warning for fall-through to 'case C'
N.B. the attribute-namespace for GNU extensions is "gnu"
I agree that the attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #25 from Florian Weimer ---
(In reply to Matthew Woehlke from comment #22)
> case B:
> ...
> [[gcc:fallthrough]] // suppress warning for fall-through to 'case C'
Do we have such attributes in the C compiler?
I contemplated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61017
Bug ID: 61017
Summary: lra aborts on optional match_scratch
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimiza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61018
Bug ID: 61018
Summary: -Wvarargs does not print warning for memer functions
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #27 from Matthew Woehlke ---
(In reply to Marek Polacek from comment #26)
> Perhaps we could invent __builtin_fallthrough or some such.
Yes, I was expecting there would be some alternate spelling for cases where
C++11 attributes are no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #28 from Alexander Kornienko ---
(In reply to Jonathan Wakely from comment #24)
> (In reply to Matthew Woehlke from comment #22)
> > [[gcc:fallthrough]] // suppress warning for fall-through to 'case C'
>
> N.B. the attribute-namesp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61017
--- Comment #1 from Jorn Wolfgang Rennecke ---
Created attachment 32717
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32717&action=edit
preprocessed libgcc file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #29 from Manuel López-Ibáñez ---
(In reply to Marek Polacek from comment #26)
> (In reply to Florian Weimer from comment #25)
> > Do we have such attributes in the C compiler?
>
> No, AFAICS. Perhaps we could invent __builtin_fallthro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #30 from Florian Weimer ---
(In reply to Manuel López-Ibáñez from comment #29)
> I like the previous suggestion of using "goto LABEL;". In fact, the warning
> message could explicitly say "use % to silence this warning".
Does this mea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #31 from Manuel López-Ibáñez ---
(In reply to Florian Weimer from comment #30)
> (In reply to Manuel López-Ibáñez from comment #29)
>
> > I like the previous suggestion of using "goto LABEL;". In fact, the warning
> > message could exp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60992
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #32 from Matthew Woehlke ---
(In reply to Florian Weimer from comment #30)
> Does this mean that you propose a GCC extension which allows to write this?
>
> goto 5;
>case 5:
While I personally detest this syntax :-), I feel t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61019
Bug ID: 61019
Summary: ICE: incomplete type of class template as
pseudo-destructor-name
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61019
frankhb1989 at gmail dot com changed:
What|Removed |Added
Known to fail||4.8.2, 4.9.0
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
--- Comment #7 from Cary Coutant ---
(In reply to Andres Freund from comment #2)
> The point is that this has changed between 4.8 and 4.9... And I don't
> see anything relevant in http://gcc.gnu.org/gcc-4.9/changes.html
Yes, you're right. This ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #33 from Michael Chapman ---
(In reply to Florian Weimer from comment #30)
> (In reply to Manuel López-Ibáñez from comment #29)
>
> > I like the previous suggestion of using "goto LABEL;". In fact, the warning
> > message could explici
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61020
Bug ID: 61020
Summary: [4.9/4.10 Regression] typeid(typeid(X)) produces 'ud2'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60971
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61020
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61011
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61020
--- Comment #1 from Andrew Pinski ---
_ZTI7Derived.0_1 = &_ZTI7Derived;
_3 = MEM[(const struct type_info *)_ZTI7Derived.0_1]._vptr.type_info;
_4 = _3 + 18446744073709551608;
_5 = *_4;
Is being optimized to be 0 for some reason.
Looks lik
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
--- Comment #8 from Jakub Jelinek ---
I don't see why there should be any consistency with -O, it is a very different
option, with a very different usage and history.
The 4.8 behavior was that -g set debug level to 2 if the debug level was 0, so
-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
Richard Henderson changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
--- Comment #9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61020
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009
--- Comment #7 from Jeffrey A. Law ---
I see what's happening here... I need to think about how best to handle this
situation. Oh how threading across loop backedges perilous.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60847
--- Comment #8 from Sanjay Patel ---
Thanks, Jakub.
I see that the fix duplicates all of the intrinsics with a
double-leading-underscore variant. Why do we need that? AFAIK, no other x86
intrinsics have this kind of duplication.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60847
--- Comment #9 from Jakub Jelinek ---
(In reply to Sanjay Patel from comment #8)
> Thanks, Jakub.
>
> I see that the fix duplicates all of the intrinsics with a
> double-leading-underscore variant. Why do we need that? AFAIK, no other x86
> intr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60847
--- Comment #10 from Sanjay Patel ---
Ah - thank you for the explanation! I found the original checkin from AMD:
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01356.html
Strangely, I can't find any documentation for those double-underscores from A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
--- Comment #10 from ccoutant at google dot com ---
>> So, my preference would be to revert to the 4.8 and older behavior, or if
>> there really is consensus that -g1 -g should mean -g2 rather than -g1, at
>> least change it so that -g3 -g means -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61021
Bug ID: 61021
Summary: [4.9 regression] libsanitizer fails to build with old
glibc
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60843
--- Comment #3 from joseph at codesourcery dot com ---
On Wed, 30 Apr 2014, kdevel at vogtner dot de wrote:
> The problem is the erroneous wording "reduction modulo 2^N". *Reduction* by
> definition results in the least *nonnegative* number out o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61022
Bug ID: 61022
Summary: [C++11] Bogus "error: parameter packs not expanded
with '...'"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61023
Bug ID: 61023
Summary: set/map move assignment doesn't move (or copy) the
comparator
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61023
--- Comment #1 from Nevin Liber ---
Created attachment 32719
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32719&action=edit
Test case using set showing the problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60324
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61023
--- Comment #2 from Nevin Liber ---
Also happens with multiset and multimap.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44054
--- Comment #9 from Manuel López-Ibáñez ---
Fortran devs, is there any interest in this approach?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687
--- Comment #2 from Manuel López-Ibáñez ---
Note that this is a repetitive but trivial task that consists mostly in
deleting code. Just take for example Wcompare-reals:
Index: gfortran.h
===
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61023
--- Comment #3 from Jonathan Wakely ---
The standard forgot to say what should happen:
http://cplusplus.github.io/LWG/lwg-active.html#2227
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60684
--- Comment #2 from John David Anglin ---
Caused by CPPFLAGS=-I/usr/include/libiberty
1 - 100 of 102 matches
Mail list logo
