https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
Eric Gallager changed:
What|Removed |Added
CC||zhonghao at pku dot org.cn
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
Eric Gallager changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|egallager at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
Eric Gallager changed:
What|Removed |Added
Keywords||easyhack
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #21 from Jonathan Wakely ---
No, because it doesn't have any tests.
It should probably adjust:
../gcc/testsuite/g++.dg/overload/ellipsis1.C
../gcc/testsuite/g++.dg/overload/ellipsis2.C
../gcc/testsuite/g++.old-deja/g++.pt/vaarg3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #20 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #17)
> This adds -Wnon-pod-varargs, enabled by -Wconditionally-supported, allowing
> e.g.
> -Wconditionally-supported -Werror=non-pod-varargs
>
> diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #19 from Jonathan Wakely ---
Whether Clang warns or not depends on the -std mode active, as that decides the
definition of a POD it uses. GCC always uses the C++11 rule, which I quoted in
comment 9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #17 from Jonathan Wakely ---
This adds -Wnon-pod-varargs, enabled by -Wconditionally-supported, allowing
e.g.
-Wconditionally-supported -Werror=non-pod-varargs
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
Eric Gallager changed:
What|Removed |Added
CC||bisqwit at iki dot fi
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
John Steele Scott changed:
What|Removed |Added
CC||toojays at toojays dot net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #13 from Tom Tromey tromey at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #11)
That's the wrong thing to assert:
Aha, thank you very much. I obviously did not realize the difference :)
Unfortunately I think even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #6 from Tom Tromey tromey at gcc dot gnu.org ---
Also, -Wconditionally-supported triggers other warning as well.
It would be more convenient if different warnings were individually
controllable; and then something like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Tom Tromey from comment #5)
(In reply to Jason Merrill from comment #3)
Passing a non-POD to a varargs function is conditionally-supported, with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #5 from Tom Tromey tromey at gcc dot gnu.org ---
(In reply to Jason Merrill from comment #3)
Passing a non-POD to a varargs function is conditionally-supported, with
implementation-defined semantics. In GCC 5 it's supported and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org ---
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2342.htm . It does
look like gcc is implementing the correct new pod rules and clang is not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #9 from Tom Tromey tromey at gcc dot gnu.org ---
Are you sure that class is not trivial which is why gcc is not warning about
it? C++11 does not really have pod and non-pod any more but rather trivial
and non-trivial and the rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org ---
N.B. trivially-copyable is not the same as trivial (and there are separate type
traits for testing those two properties).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Tom Tromey from comment #9)
However my belief is that because this class has a user-provided
default constructor, it is not trivial.
True, but ...
I tested this by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
From https://gcc.gnu.org/gcc-4.5/changes.html:
Diagnostics that used to complain about passing non-POD types to ... or jumping
past the declaration of a non-POD variable now check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
Jason informs me it's now a warning enabled by -Wconditionally-supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #3 from Jason Merrill jason at gcc dot gnu.org ---
Passing a non-POD to a varargs function is conditionally-supported, with
implementation-defined semantics. In GCC 5 it's supported and treated like
normal pass-by-value. You can get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #4 from Tom Tromey tromey at gcc dot gnu.org ---
Thanks, I'll give it a try.
Here's my test case FWIW and a short demo showing what clang does:
pokyo. cat q.cc
#include stdarg.h
class ConstUTF8CharsZ
{
const char *mData;
25 matches
Mail list logo
