[Bug c++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342 --- Comment #12 from Rui Oliveira --- (In reply to Jakub Jelinek from comment #11) > No, if you have the packed ph_fcomplex_t not aligned at alignof (float), you > need > to copy it to a properly aligned variable before trying to reinterpret_cast > it. Some `if constexpr` comparing of the remainder between alignof(std::complex) and (alignof(bb_frame_t) + offsetof(bb_iq_samples)) could perhaps make one avoid that. But that's just a side idea to think of. Main point is, the code is de-serializing a serial stream. I do not expect to find the "magic" word at the right aligment for `bb_frame_t` anyway, so generous memcpy'ing to properly aligned variables will be required anyway.
[Bug c++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342
--- Comment #10 from Rui Oliveira ---
So my options are to create like a placeholder, say
```c
typedef struct __attribute__((__packed__)) // Packed isn't really necessary
here I think?
{
float re, im;
} ph_fcomplex_t
```
To silence the warning and get packing to work, and trust
[complex.numbers.general] for a reinterpret_cast into std::complex I
guess.
[Bug libstdc++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342 --- Comment #4 from Rui Oliveira --- (In reply to Andrew Pinski from comment #2) > Hmm: diff.cpp03.numerics I saw you moved the bug to libstdc++ but is the problem libstdc++, or should g++ just accept packing when it encounters it?
[Bug libstdc++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342 --- Comment #3 from Rui Oliveira --- (In reply to Andrew Pinski from comment #1) > > I know about _Atomic and std::atomic but not std::complex and _Complex. > Because std::complex was part of C++98 which was done before C99's _Complex > ... [complex.numbers.general] mentions: If z is an lvalue of type cv complex then: the expression reinterpret_cast(z) is well-formed, https://eel.is/c++draft/complex.numbers.general Basically stating that std::complex is layouted exactly the same as T[2]. C standard says something similar iirc.
[Bug c++/108342] New: std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342 Bug ID: 108342 Summary: std::complex: ignoring packed attribute because of unpacked non-POD field Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ruilvo at ua dot pt Target Milestone: --- Created attachment 54217 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54217=edit Code to reproduce the bug report Summary: With the annexed code, reproduced on the following CE link: https://godbolt.org/z/1q9a5Mq7r I get the following warning: ``` :29:16: warning: ignoring packed attribute because of unpacked non-POD field 'fcomplex_t ::bb_iq_samples [512]' 29 | fcomplex_t bb_iq_samples[BB_FRAME_IQ_SAMPLES_COUNT]; |^ ``` Clang doesn't complain facing the same code. Details: I was trying to write a C++ library, which is going to target an ARM Linux system, but leaving C-compatible "bindings" and structs for using with CFFI on other languages. The library deals with a serial stream that I don't control, and that I wanted to de-serialize, thus the weird structure. I discovered the problem (warning) when I changed from a C source file and `_Complex float` to C++ and `std::complex`. The compiler I first discovered the problem on was arm-linux-gnueabihf-g++ (GCC) 12.2.1 20221203 [releases/gcc-12 revision c03cb4b762aceeba95da918b042583af0d9f6030] from Linaro. The bug is reproducible on x86 and mainline GCC (see Compiler Explorer URL) Expected behaviour: For this code to compile without warnings and producing the desired effect (packing). The C++ standard even carves out a guarantee than `_Complex [float|double]` is memory-layout-compatible with `std::complex<[float|double]>`.
