------- 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