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 a/gcc/c
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 gnu.org
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 3435fe90cca..b
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 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
John Steele Scott changed:
What|Removed |Added
CC||toojays at toojays dot net
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #13 from Tom Tromey ---
(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 if I made this change I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #12 from Jonathan Wakely ---
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 ---
(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 adding "#include " a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #9 from Tom Tromey ---
> 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 has chnaged with respe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #8 from Andrew Pinski ---
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
--- Comment #7 from Andrew Pinski ---
(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
> > implementation-defined semantics. In GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #6 from Tom Tromey ---
Also, -Wconditionally-supported triggers other warning as well.
It would be more convenient if different warnings were individually
controllable; and then something like -Wconditionally-supported
would act as if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #5 from Tom Tromey ---
(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 treated like
> normal pass-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #4 from Tom Tromey ---
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
class ConstUTF8CharsZ
{
const char *mData;
public:
ConstUTF8CharsZ() : mData
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #3 from Jason Merrill ---
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 a diagnostic about it wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #2 from Jonathan Wakely ---
Jason informs me it's now a warning enabled by -Wconditionally-supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867
--- Comment #1 from Andrew Pinski ---
>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 for triviality rather than
25 matches
Mail list logo
