[Bug c++/57826] New: "Internal compiler error: Error reporting routines re-entered" with -Weffc++ and weak_ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57826 Bug ID: 57826 Summary: "Internal compiler error: Error reporting routines re-entered" with -Weffc++ and weak_ptr Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: anders at knatten dot org Created attachment 30461 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30461&action=edit As requested by "Preprocessed source stored into /tmp/ccEQ3cyg.out file, please attach this to your bugreport." When compiling bar.cpp with g++ -o bar.o -c -std=c++0x -Wall -Wextra -Weffc++ bar.cpp I get "Internal compiler error: Error reporting routines re-entered. Please submit a full bug report" I created the minimum example I could think of that triggers the bug. If you omit -Weffc++, it compiles. If you omit the weak_ptr member from Foo, it also compiles. I have attached the preprocessed source as requested.
[Bug c++/91423] New: address-of-packed-member when taking packed struct member by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91423
Bug ID: 91423
Summary: address-of-packed-member when taking packed struct
member by value
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders at knatten dot org
Target Milestone: ---
Compiling this with `-std=c++17 -Wall` on gcc 9.1.0:
```
#include
struct __attribute__((__packed__)) Vec : std::array
{};
struct __attribute__((__packed__)) S
{
Vec size;
};
void g()
{
S s{};
Vec size = s.size;
}
```
gives:
```
:14:18: warning: taking address of packed member of 'S' may result in
an unaligned pointer value [-Waddress-of-packed-member]
14 | Vec size = s.size;
```
However, I'm not taking the address of the packed member, I'm taking it by
value. I think gcc shouldn't warn in this case.
Godbolt: https://godbolt.org/z/v4GZ6f
[Bug c++/91423] address-of-packed-member when taking packed struct member by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91423 --- Comment #3 from Anders Schau Knatten --- (In reply to Richard Biener from comment #1) > I think GCC tells you that deriving from std::array from a packed struct is > going to cause trouble because std::array expects to be naturally aligned? Do you know why std::array expect to be naturally aligned? I checked by the way, and gcc and clang both seem to naturally align base class subobjects. So in this case, the std::array subobject will be naturally aligned regardless of Vec packing: https://godbolt.org/z/9ZZ3eT In any case, if that is what it's trying to tell me, I think the warning could be improved.
[Bug c++/91423] address-of-packed-member when taking packed struct member by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91423 --- Comment #5 from Anders Schau Knatten --- (In reply to Andrew Pinski from comment #4) > Vec size = s.size; > > you are invoking the copy constructor here ... > Which means you are taking the address (implicitly). Good point. This should be safe though, as `Vec` itself is packed, so its copy constructor would have to handle unaligned arguments. (In fact, if `Vec` wasn't packed, the compiler would not allow `S` to be packed either.) I'm however not sure if we should expect gcc to take this information into account when deciding whether to emit the warning, what do you think?
[Bug c++/66672] std::is_same wrong result for captured reference value inside a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66672 Anders Schau Knatten changed: What|Removed |Added CC||anders at knatten dot org --- Comment #3 from Anders Schau Knatten --- Hi, Anders from cppquiz.org here, in which the example code for this bug report originated. The entire §5.1.2¶18 from C++11 seems to be gone from http://eel.is/c++draft/expr.prim.lambda. It used to say: "Every occurrence of decltype((x)) where x is a possibly parenthesized id-expression that names an entity of automatic storage duration is treated as if x were transformed into an access to a corresponding data member of the closure type that would have been declared if x were an odr-use of the denoted entity." So I believe clang is correct according to c++11, and gcc is correct according to whichever standard removed that sentence. A bug was also opened against cppquiz.org for this very question, you can see the discussion at https://github.com/knatten/cppquiz/issues/96 if you're interested.
[Bug c++/66672] std::is_same wrong result for captured reference value inside a lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66672 --- Comment #4 from Anders Schau Knatten --- Update: There's a related issue with Clang, in which Richard Smith makes a good argument: https://bugs.llvm.org/show_bug.cgi?id=35423#c2 He refers to http://eel.is/c++draft/expr.prim.id.unqual#2.sentence-2, of which I was previously unaware, which seems to cover what was previously covered by §5.1.2¶18 in C++11. It says: "If the entity is a local entity and naming it from outside of an unevaluated operand within the declarative region where the unqualified-id appears would result in some intervening lambda-expression capturing it by copy ([expr.prim.lambda.capture]), the type of the expression is the type of a class member access expression ([expr.ref]) naming the non-static data member that would be declared for such a capture in the closure object of the innermost such intervening lambda-expression." If I read that passage correctly, it says that "even if decltype doesn't odr-use the identifier, and thus it isn't actually captured, the type of the expression is still as if it had been captured." So I now believe my previous comment was wrong, and that gcc is wrong both according to C++11 and the current draft.
