This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: Fix PR tree-optimization/21407


Paolo Bonzini wrote:
I don't think life is that good.

I think that the "what is an object" concerns apply in C++ too. Though you don't have "offsetof" for non-PODs, nothing says you can't just *know* the offset and use it in the exact same way. I really don't think we can language-lawyer our away arounad the issues here; there is no clear answer in the standard at this point. We have to choose ourselves.


You do not need language lawyering for that. You can still provide a switch, but it could/should enable the optimization for C++ by default. You would need reinterpret_cast, the standard says at [expr.reinterpret.cast] that arithmetic tricks on pointers are outlawed, for both reinterpret_casts to integral or pointer types:

I don't believe it says enough.


This is exactly what I mean by the fact that I don't think we can language-lawyer our way out of this issue. Nick's paper still applies; the bottom line is that the committees really have not made clear what operations are allowed.

If you asked someone twenty years ago whether these kinds of operations were legal, the answer would have been uniformly yes. Now, opinions differ, because people are seeing more benefits of restricting these operations. But, the standards still don't say.

  struct I {
    virtual void f(); // I is not a POD.
    int a;
    int b;
  };

  void g() {
    I i;
    int *a_p = &i.b;
    /* 8 is a magic number! */
    I* i_p = (I*)((char *) a_p - 8);
    i_p->a = 3;
  }

There's no casting between pointers and integers. There are reinterpet_casts between pointers. The mapping is implementation-defined, but, in practice, all implementations on, say, IA32, are going to leave the bit-pattern unchanged. I just don't see anything that says conclusively that this code is invalid.

I would be happy if it were invalid. I would be happy to have the optimization. However, I do not think it should be on by default until/unless the standards committees give clear direction. We should not be reading tea-leaves for this decision; we should have some explicit direction.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]