This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/25737] ACATS c974001 c974013 hang with struct aliasing
- From: "dnovillo at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 3 Oct 2006 12:54:56 -0000
- Subject: [Bug tree-optimization/25737] ACATS c974001 c974013 hang with struct aliasing
- References: <bug-25737-10053@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #39 from dnovillo at gcc dot gnu dot org 2006-10-03 12:54 -------
(In reply to comment #38)
> The name, and all the documentation, which say they cannot be
> addressed, which means they cannot be pointed to by any pointer, which
> means they are unaliased.
>
Absolutely. If the Ada FE somehow wants these two predicates to generate
*more* VDEF/VUSE chains, then there is something fundamentally wrong with it.
The meaning of these two predicates is the exact opposite, they will lead to
*fewer* VDEF/VUSE chains.
> > I'm not saying that this is a sane design or that we should try to replicate
> > it in GCC 4, I'm just saying that for the time being struct aliasing totally
> > overlooks this mechanism and doesn't work for Ada because of that.
> Okay, and i'm saying i don't plan on accepting fixes that appear to
> hack around well accepted infrastructure to try to fix symptoms.
> Really. That's all. I'm not going to approve patches that randomly
> skip fields because it seems to get the right result sometimes. If
> you want to try to explain what all this is actually trying to do, i'm
> happy to work with you to come up with a sane solution.
>
Agreed. The Ada FE should either change or prove that there is a
design/implementation flaw in the aliasing machinery.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737