[Bug ipa/98594] [11 Regression] IPA modref codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594 Richard Biener changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #7 from Richard Biener --- *** Bug 102823 has been marked as a duplicate of this bug. ***
[Bug ipa/98594] [11 Regression] IPA modref codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594 --- Comment #6 from Jeffrey A. Law --- Duh. I should have seen the reinterpret_cast as a red flag on this one. And not surprising -fno-strict-aliasing makes the glm testsuite happy. Sorry for the noise.
[Bug ipa/98594] [11 Regression] IPA modref codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|--- |INVALID
--- Comment #5 from Richard Biener ---
Hmm, I don't think struct X { int i; } and struct X { unsigned int i; } have
the same alias-set (int and unsigned int do). So a reinterpret-cast
from one to the other variant violates TBAA rules. That menas that glm::vec
needs a CTOR from the signed/unsigned variant rather than using a hack
like this - and it seems it has one if Honzas fix still lets things compile?
I see
template
template
inline constexpr vec<1, T, Q>::vec(vec<1, U, P> const& v)
: x(static_cast(v.x))
{}
which probably applies and the used CTOR in the bogus case is the
compiler-generated one.
[Bug ipa/98594] [11 Regression] IPA modref codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594
--- Comment #4 from rguenther at suse dot de ---
On Wed, 27 Jan 2021, hubicka at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594
>
> --- Comment #3 from Jan Hubicka ---
> The initialization is removed by dse1 pass. We get:
> ipa-modref: call stmt D.3199 = bitCount::bitCount_bitfield<1, int,
> glm::packed_highp> (); [return slot optimization]
> ipa-modref: call to glm::vec bitCount::bitCount_bitfield(const
> glm::vec&) [with int L = 1; T = int; glm::qualifier Q =
> glm::packed_highp]/8 does not use ref: D.3185.D.3097.x alias sets: 3->1
> Deleted dead store: D.3185.D.3097.x = x_2(D);
>
>
> ipa-modref: call stmt D.3199 = bitCount::bitCount_bitfield<1, int,
> glm::packed_highp> (); [return slot optimization]
> ipa-modref: call to glm::vec bitCount::bitCount_bitfield(const
> glm::vec&) [with int L = 1; T = int; glm::qualifier Q =
> glm::packed_highp]/8 does not use ref: D.3185 alias sets: 3->3
> Deleted dead store: D.3185 ={v} {CLOBBER};
>
>
> Now the modref summary for function is
> loads:
>
> Limits: 32 bases, 16 refs
>
> Base 0: alias set 5
>
> Ref 0: alias set 5
>
> access: Parm 0 param offset:0 offset:0 size:32 max_size:32
>
>
> alias set 5 correspond to const struct vec but diferent instantiation than
> alias set 3 used in the store.
> There is reinterpret cast:
>
> glm::vec::type, Q>
x(*reinterpret_cast<
glm::vec::type, Q> const *>());
>
> turning it to
>
> glm::vec::type, Q> x(*());
>
> makes the aliasing difference go away. So it seems to me that the testcase
> simply includes TBAA violation?
Not sure but if my visuals do not cheat me then the difference is only
const qualification so it should not matter for TBAA? Of course the
question is what type 'v' has since this maybe invokes a different CTOR?
[Bug ipa/98594] [11 Regression] IPA modref codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594
--- Comment #3 from Jan Hubicka ---
The initialization is removed by dse1 pass. We get:
ipa-modref: call stmt D.3199 = bitCount::bitCount_bitfield<1, int,
glm::packed_highp> (); [return slot optimization]
ipa-modref: call to glm::vec bitCount::bitCount_bitfield(const
glm::vec&) [with int L = 1; T = int; glm::qualifier Q =
glm::packed_highp]/8 does not use ref: D.3185.D.3097.x alias sets: 3->1
Deleted dead store: D.3185.D.3097.x = x_2(D);
ipa-modref: call stmt D.3199 = bitCount::bitCount_bitfield<1, int,
glm::packed_highp> (); [return slot optimization]
ipa-modref: call to glm::vec bitCount::bitCount_bitfield(const
glm::vec&) [with int L = 1; T = int; glm::qualifier Q =
glm::packed_highp]/8 does not use ref: D.3185 alias sets: 3->3
Deleted dead store: D.3185 ={v} {CLOBBER};
Now the modref summary for function is
loads:
Limits: 32 bases, 16 refs
Base 0: alias set 5
Ref 0: alias set 5
access: Parm 0 param offset:0 offset:0 size:32 max_size:32
alias set 5 correspond to const struct vec but diferent instantiation than
alias set 3 used in the store.
There is reinterpret cast:
glm::vec::type,
Q>x(*reinterpret_cast::type,
Q> const *>());
turning it to
glm::vec::type, Q> x(*());
makes the aliasing difference go away. So it seems to me that the testcase
simply includes TBAA violation?
[Bug ipa/98594] [11 Regression] IPA modref codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594 Jan Hubicka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jan Hubicka --- Mine. Note that the initialized warning was not really related to this problem, just to the assumption that parameters declared "const" are read by the callee which was proved false by modref and triggered false positive in the warning.
[Bug ipa/98594] [11 Regression] IPA modref codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594 Richard Biener changed: What|Removed |Added Keywords||wrong-code CC||rguenth at gcc dot gnu.org Last reconfirmed||2021-01-08 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- We have a dup of modref mishandling RSO, but this testcase is nicer I guess. Honza - please have a look.
[Bug ipa/98594] [11 Regression] IPA modref codegen bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98594 Martin Liška changed: What|Removed |Added Priority|P3 |P1 CC||hubicka at gcc dot gnu.org Target Milestone|--- |11.0
