[Bug c++/83732] wrong warning about non-POD field

[kentsangkm at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732

Kenman Tsang  changed:

   What|Removed |Added

 CC||kentsangkm at gmail dot com

--- Comment #6 from Kenman Tsang  ---
Created attachment 47137
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47137&action=edit
An example error case

Sorry for bring this topic back again. But I think there are some inconsistancy
with the std::is_pod and the error messages.

Refers to my example. A1 is a POD, but the error message said it is "non-POD".
Should we either include more detail to the message (like C++98 POD) or to
relax the POD checking?

I tried the same case with clang. clang successfully compiles and return the
correct size. And I cannot found anyway to unify their behavior, hence I cannot
have a compiler independent code base

Thank you

[Bug c++/84194] fails to pack structs with template members

[kentsangkm at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84194

Kenman Tsang  changed:

   What|Removed |Added

 CC||kentsangkm at gmail dot com

--- Comment #1 from Kenman Tsang  ---
Hi, here is another example that the GCC cannot pack a struct correctly.

Refers to the ticket 83732
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732), this is not only related
to the diagnostic message, but how we pack POD.

Because the A1 is not a C++98 pod ( but it is a POD according to C++11 ), B1
should be able to process the pack (and the result should be sizeof(B1) == 10)

Compared with Clang-4.0 or above, clang can pack this structure correctly


>From the ticket 83732, my best guess is gcc pack a struct only if it fulfill
C++98 pod, but not the pod in general


-
main.cpp:34:8: warning: ignoring packed attribute because of unpacked non-POD
field ‘A1 B1::b’
 A1 b;
^
main.cpp:39:1: error: static assertion failed
 static_assert(sizeof(B1) == 10, "");
 ^
-
#include 

struct A1
{
A1() = default;

constexpr A1(const int& value) noexcept
: value(value)
{
}

constexpr A1(int&& value) noexcept
: value(std::move(value))
{
}

int value;
};
static_assert(std::is_pod::value,"Pass");
static_assert(sizeof(A1)==4, "Pass");

struct A2
{
A2() = default;

int value;
};
static_assert(std::is_pod::value,"Pass");
static_assert(sizeof(A2)==4, "Pass");

struct B1
{
char a;
A1 b;
char c;
int d;
} __attribute__((__packed__));
static_assert(std::is_pod::value,"Pass");
static_assert(sizeof(B1)==10, "This is failed");

struct B2
{
char a;
A2 b;
char c;
int d;
} __attribute__((__packed__));
static_assert(std::is_pod::value,"Pass");
static_assert(sizeof(B2)==10, "Pass");

int main()
{
std::cout << sizeof(A1) << std::endl;
std::cout << sizeof(A2) << std::endl;
}

[Bug c++/106619] New: Inconsistent __PRETTY_FUNCTION__ output

[kentsangkm at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106619

Bug ID: 106619
   Summary: Inconsistent __PRETTY_FUNCTION__ output
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kentsangkm at gmail dot com
  Target Milestone: ---

Created attachment 53456
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53456&action=edit
example code

The __PRETTY_FUNCTION__ macro does print the function name as well as the
template arguments (if any), but the output is inconsistent and depends on the
declaration sequence.

// any templated typed with optional parameter(s)
template, void,
T>>
struct Foo
{
};

template
struct Container
{
void get() const{
std::cout << typeid(T).name() << "  "<< __PRETTY_FUNCTION__ <<
std::endl;
}
};

int main()
{
Container> b;
b.get();

Container> a;
a.get();
}


Output:
3FooIiiE  void Container::get() const [with T = Foo]
3FooIiiE  void Container::get() const [with T = Foo]



If we swap the declaration of a and b, the output becomes:
3FooIiiE  void Container::get() const [with T = Foo]
3FooIiiE  void Container::get() const [with T = Foo]


in contrast, the typeid is very consistent on both cases, but it is not an
constexpr function



Clang does not have such issue, as it always expends the optional arguments and
output Foo always


Here is a short link for godbolt
https://godbolt.org/z/vfTnz5bEb

the same code piece is also be enclosed