https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
Jonathan Wakely changed:
What|Removed |Added
CC||jlame646 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
Jonathan Wakely changed:
What|Removed |Added
CC||redboltz at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
--- Comment #20 from Jonathan Wakely ---
(In reply to Manuel López-Ibáñez from comment #19)
> I wonder what happens if you used something that actually has a
> location, like an expression, for the first test case using emplace().
It doesn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
--- Comment #19 from Manuel López-Ibáñez ---
I think the solution is to have more locations. If the diagnostic code knew
where the user value came from then it will know to not suppress the
diagnostic. I wonder what happens if you used something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
--- Comment #18 from Jonathan Wakely ---
From Matthias Kretz on IRC:
GCC needs to make a difference between warnings that apply when reading the
system headers and warnings that only manifest on a template instantiation or
constprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
--- Comment #17 from Jonathan Wakely ---
And Bug 87614 is a simpler form of Ian's original example in comment 0:
#include
int main() {
std::vector a;
a.emplace_back(7);
}
With -Wsystem-header -Wconversion:
[...]
87614.cc:5:25:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2017-01-24 00:00:00 |2019-3-22
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
--- Comment #14 from redi at gcc dot gnu dot org 2010-04-21 19:02 ---
Bug 43820 shows cases where libstdc++ was *relying* on the front-end issuing
warnings about calling delete with a pointer to incomplete types. I'm going to
change the library code to handle it instead, but it's an
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-02-24 19:35 ---
There was a bug asking the opposite way IIRC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-24 19:37 ---
PR 36760 is an example where it was asking the opposite way. I thought there
was more than that bug though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-24 19:38 ---
Found it, PR 30500 was the exact bug which changed this behavior :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-02-24 19:41 ---
This warning indicates a problem with user code.
Or is it? Since long long does not exist in C++03 :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
--- Comment #5 from ian at airs dot com 2010-02-24 20:56 ---
The use of long long is irrelevant here.
PR 30500 appears to be about non-dependent types. So let's make this bug be
about dependent types. I know that makes it harder, but it seems to me to be
the right thing to do.
--
--- Comment #6 from paolo dot carlini at oracle dot com 2010-02-24 21:43
---
Out of curiosity: what happens with ICC? (normally installed with the system
libstdc++ as C++ run-time)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
--- Comment #7 from ian at airs dot com 2010-02-24 22:33 ---
I don't know about icc, but see also http://llvm.org/PR6418 .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43167
--- Comment #8 from paolo dot carlini at oracle dot com 2010-02-24 22:47
---
ICC doesn't warn (emits another spurious warning, by the way, which has nothing
to do with this issue). More generally, compilers using the EDG front-end, eg,
Comeau, apparently do not warn at the most strict
--- Comment #9 from manu at gcc dot gnu dot org 2010-02-24 22:52 ---
(In reply to comment #7)
I don't know about icc, but see also http://llvm.org/PR6418 .
Out of curiosity. Is it really the output of g++ so messy compared with clang,
or is it an artifact of copy+paste from the
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-02-24 22:56
---
looks like the terminial is wrapping funny.
In file included from
/home/apinski/local-gcc/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../include/c++/4.5.0/numeric:62:0,
from t.cc:2:
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-02-24 23:00
---
Note this is much better than what it was in 4.3 where std::vectorlong was
shown as:
std::vectorlong int, std::allocatorlong int
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from manu at gcc dot gnu dot org 2010-02-24 23:20 ---
(In reply to comment #11)
Note this is much better than what it was in 4.3 where std::vectorlong was
shown as:
std::vectorlong int, std::allocatorlong int
That part looks better GCC, however, in the context
--- Comment #13 from ian at airs dot com 2010-02-25 00:17 ---
Paolo: It is definitely a complicated case, the concern about false positives
is entirely valid. This leads us to introducing more command line options,
plus getting #pragma GCC diagnostic to work. I'm not sure what the
22 matches
Mail list logo
