Alright, I checked in a new branch, 'fix-test-for-late-gcc', that builds okay on my mac (gcc 4.2.x) and declares the generic pdl_trans with an array of size 20. (The maximum value that occurs in live code in the tree is 14). Give it a shot if you don't mind, and see if it works on the new compiler.
That may be the quickest fix - getting the mechanism Right with a true dynamically allocated helper structure would be enough of a mess that it might be best left for v3.0 if it works for you now. On Oct 11, 2013, at 1:56 PM, Craig DeForest <[email protected]> wrote: > Okay, so PDL_TRANS_START is intended to let you pick the size of your > list-of-PDLs for a transformation structure, on a case-by-case basis in the > code (and PP.pm does just that in all the generated code). The generic case > is pdl_trans (sort of an ersatz superclass) in pdl.h.PL, and it looks like > it's declared with np=1 (at line 272) simply because the PDL_TRANS_START > macro affords no way to declare an undefined-length array. > > > On Oct 11, 2013, at 1:44 PM, Craig DeForest <[email protected]> wrote: > >> Wow, nice work finding this. It is right in the tangled mess that needs >> overhaul for the next major version. The pdls link is a dynamically >> allocated array -- I suspect that a better declaration is *pdls[] rather >> than *pdls[1]. I don't know why it is declared as a unit-length array. >> >> >> On Oct 11, 2013, at 1:34 PM, Dima Kogan <[email protected]> wrote: >> >>> 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 >>> >> >> > > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
