Re: [tree-ssa] Merge results as of 2003-05-06

[law at redhat dot com]

In message <20030507032001.GA5056@tornado.toronto.redhat.com>, Diego Novillo wr
ites:
 >FAIL: gcc.c-torture/execute/string-opt-18.c compilation
 >FAIL: gcc.c-torture/execute/string-opt-18.c execution
 >FAIL: gcc.c-torture/execute/string-opt-18.c execution
 >FAIL: gcc.c-torture/execute/string-opt-18.c execution
 >FAIL: gcc.c-torture/execute/string-opt-18.c execution
 >FAIL: gcc.c-torture/execute/string-opt-18.c execution
 >
 >    These are due to a new builtin (stpcpy).  This is the test I
 >    was telling you about today, Jeff.
Note that the failure at -O0 compilation failure has nothing to do with
simplification of builtins.   It's a failure to properly instantiate
a virtual register.  That's probably a failure in genericizing this
code.  Note that it (of course) compiles fine with -fdisable-simple.
tsk tsk for not investigating.  Here's the simplified testcase for
that problem:

[law@speedy gcc]$ more k.c
char p[32] = "";
 
int main()
{
  return (__builtin_mempcpy (p, "ABCDE", 6) != p);
}
[law@speedy gcc]$ ./cc1 k.c
 main
k.c: In function `main':
k.c:6: internal compiler error: in instantiate_virtual_regs_lossage, at 
function.c:3822
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.


The execution failures are probably going to have to stay indefinitely.
The one nasty case the simplification of builtins doesn't handle is
builtin_memcpy, upon which this code depends.   Fixing this is going to
be non-trivial as expand_builtin_memcpy assumes all over the place
that it can generate RTL -- including within calls to helper functions
such as store_by_pieces.   All that code will need to be converted to
not generate RTL, but instead generate some trees that we can 
replace the call with.  Ick.



Jeff