https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #14 from rguenther at suse dot de ---
On Wed, 16 Jun 2021, alexander.gr...@tu-dresden.de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
>
> --- Comment #13 from Alexander Grund ---
> > But what you can see is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #13 from Alexander Grund ---
> But what you can see is that the resulting pointer is used for the
> initialization and not the placement address as literally written in source.
So I assume it was supposed to be "Y::Y (D_6557, 1);"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #12 from rguenther at suse dot de ---
On Wed, 16 Jun 2021, alexander.gr...@tu-dresden.de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
>
> Alexander Grund changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #11 from rguenther at suse dot de ---
On Wed, 16 Jun 2021, alexander.gr...@tu-dresden.de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
>
> --- Comment #9 from Alexander Grund ---
> > Note that when the union type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
Alexander Grund changed:
What|Removed |Added
Version|8.4.0 |8.5.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #9 from Alexander Grund ---
> Note that when the union type is visible in the access path then GCC allows
> punning without further restrictions. Thus the accesses as written above are
> OK.
Now I have to ask again for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #8 from rguenther at suse dot de ---
On June 15, 2021 4:27:37 PM GMT+02:00, "alexander.gr...@tu-dresden.de"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
>
>--- Comment #6 from Alexander Grund ---
>Oh and for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #7 from rguenther at suse dot de ---
On June 15, 2021 4:21:12 PM GMT+02:00, "alexander.gr...@tu-dresden.de"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
>
>--- Comment #5 from Alexander Grund ---
>So am I right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #6 from Alexander Grund ---
Oh and for completeness: The same applies to the following union, doesn't it?
I.e. given this:
struct TF_TString_Raw {
uint8_t raw[24];
};
struct TF_TString_Small {
uint8_t size;
char str[23];
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #5 from Alexander Grund ---
So am I right assuming that the following is basically UB as per GCC (although
it should work as per the standard)?
template
union slot_type {
map_slot_type() {}
~map_slot_type() = delete;
using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #4 from rguenther at suse dot de ---
On Tue, 15 Jun 2021, alexander.gr...@tu-dresden.de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
>
> --- Comment #3 from Alexander Grund ---
> You are right, it actually seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #3 from Alexander Grund ---
You are right, it actually seems to be the combination of those to, so -O2
-fno-strict-aliasing and -O2 -fno-tree-vrp both make it work.
The layout-compatible refers to the "common initial sequence" that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #2 from Richard Biener ---
If it is related to those union accesses then it should have nothing to do with
-ftree-vrp but it should vanish with -O2 -fno-strict-aliasing at least.
Note we do not implement any of "layout compatible"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #1 from Alexander Grund ---
Created attachment 51006
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51006=edit
compressed preprocessed source
15 matches
Mail list logo
