Dima Kogan <[email protected]> writes:
> Dima Kogan <[email protected]> writes:
>
>> valgrind is reporting some memory corruption, so I'll follow that when I
>> have the time.
>
> Compiler bug!
OK. Things look a little bit different in the morning.
The gcc4.8 compiler is optimizing more heavily than the 4.7 one, and it
looks like it's drawing some possibly incorrect conclusions when looking
at broken pdl code.
As I previously said, the issue is in this:
pdl_trans *trans;
for(j=0; j<trans->vtable->npdls; j++) {
if(trans->pdls[j]->trans == trans)
PDL_ENSURE_ALLOCATED(trans->pdls[j]);
}
pdl_trans is defined as
struct pdl_trans {
PDL_TRANS_START(1);
} ;
which expands to
struct pdl_trans {
int magicno;
short flags;
pdl_transvtable *vtable;
void (*freeproc)(struct pdl_trans *); /* Call to free this
(means whether malloced or not) */
pdl *pdls[1]; /* The pdls involved in the transformation */
int bvalflag; /* required for binary compatability even if
WITH_BADVAL=0 */
int has_badvalue;
double badvalue;
int __datatype
};
Note that pdl_trans has exactly one pdl* pdls[1] member. Gcc 4.8 sees
this, and cuts off the loop to not iterate over more than one element.
But clearly the PDL code intended for multiple iterations there, since
trans->vtable->npdls is > 1.
So what is PDL intending here? It's indexing that array past 1 in many
places in the codebase. What are we doing?
dima
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
