This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/54570] [4.8 Regression] FAIL: gcc.dg/builtin-object-size-8.c execution test
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 11 Dec 2012 12:54:43 +0000
- Subject: [Bug tree-optimization/54570] [4.8 Regression] FAIL: gcc.dg/builtin-object-size-8.c execution test
- Auto-submitted: auto-generated
- References: <bug-54570-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54570
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> 2012-12-11 12:54:43 UTC ---
An alternative suggestion was to allow arbitrary complex addresses (well,
"arbitrary" == gimplified ADDR_EXPRs) in call arguments (either in general
or just for specially marked builtins). That way they escape SSA based CSE.
Yet another variant would be to have an optional 2nd operand for ADDR_EXPRs
for the Frontend to fill in, specifying the "size" of the object at that
address. Preserving that across propagation/substitution would be required
of course (details on what the 'size' of &a[2] with int a[4]; would be is
still to be determined).
I'm leaning towards trying to have explicit information tracked from their
origin rather than trying to re-discover them after optimizations obfuscated
them.