------- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-06-15 15:12
-------
(In reply to comment #10)
> but I can't see how I could debug further.... pretty please, can somebody look
> into that... I'd like to be able to test all the stuff that went in since the
> bug was opened a few weeks ago.
I don't have much time right now, but here's what I saw and how I would debug
it further: by using -O1 and -fdump-tree-optimized, you can get a dump of the
optimized tree. The memset call is changed by the optimizer into:
__builtin_memset (&(*__result.0)[_s1], 32, 1000 - _s1);
Compared to your original tree, where stride.0 = 1 and offset.1 = -stride.0,
and D.1374 = _s1, they look equivalent, except for the transformation of
&(*array)[_s1] into &(*array)[0] + (char *) _s1. I think that should not be a
problem, except if there is some type mismatch. Further debugging probably
needs to find the part of the front-end that generates this memset call (easily
done by grepping for BUILT_IN_MEMSET in the front-end files), setting a
break-point there and looking into the types of each operands. This last
operation can be done within gdb by calling the debug_tree() function on the
trees you're interested in.
When (and if) I get some time after my PhD defence (next monday), I'll try to
look into it; after all, I am interested in cp2k myself, even though it doesn't
yet work for what I need it to do ;-)
--
fxcoudert at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2007-06-12 15:47:40 |2007-06-15 15:12:01
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32140
