https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739
--- Comment #11 from Jakub Jelinek ---
Author: jakub
Date: Wed Nov 14 16:43:38 2018
New Revision: 266152
URL: https://gcc.gnu.org/viewcvs?rev=266152=gcc=rev
Log:
PR bootstrap/86739
* hash-map.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739
--- Comment #10 from Jakub Jelinek ---
Created attachment 45001
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45001=edit
gcc9-pr86739-2.patch
Variant patch if the conversion operator would not be acceptable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739
--- Comment #9 from Jakub Jelinek ---
Created attachment 45000
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45000=edit
gcc9-pr86739.patch
This works for me (well, make in gcc/ with recent gcc still builds and the
preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739
--- Comment #6 from Jonathan Wakely ---
(In reply to Richard Biener from comment #5)
> ISTR figuring the default hash_map<> template resolution is a bit tricky.
ISTR thinking it was rather overcomplicated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739
--- Comment #5 from Richard Biener ---
So somehow mem_alloc_description::mem_map_t which then is
hash_map ends up with this reference type.
But I can't figure out how :/ It in the end uses pointer_hash which has
value/compare type of T *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739
--- Comment #4 from Jonathan Wakely ---
See PR 7412
"Fixed on mainline for GCC 4.3.0. DR 106 is implemented for C++0x mode and for
non-strict C++98 mode."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739
--- Comment #3 from Jonathan Wakely ---
The code is well-formed according to
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#106 but that
doesn't seem to be implemented in GCC 4.1.2
template
struct X {
X(T&) { }
};
X f(int& i)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739
--- Comment #2 from Richard Biener ---
Created attachment 44466
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44466=edit
preprocessed source
For reference, here's preprocessed source.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86739
--- Comment #1 from Richard Biener ---
Regressed between r262525 (good) and r262545 (bad). Thus probably caused by
r262539.
/usr/include/c++/4.1.2/bits/stl_pair.h:84 is
/** Two objects may be passed to a @c pair constructor to be
14 matches
Mail list logo
