The gcc optimization issue is important enough that I would like to see it in PDL-2.007. Please merge into master so I can roll another release for CPAN Testers to crank ASAP.
As far as "unsafe code" and compilers fixing things, the issue is that PDL was written before the propagation and implementation of ANSI C in any consistent form. This fix is *exactly* a work-around to an issue with gcc optimization due to the structure of our autogenerated code. As someone who has seen optimizer bugs come and go with every major compiler version change, I doubt the fact that different behavior is being worked around is an insult. This is *exactly* the crufty code that needed comprehension and rework that I was hoping for in a PDL3. Thanks, Chris On Fri, Oct 11, 2013 at 4:51 PM, Craig DeForest <[email protected]> wrote: > Cool, glad it worked! > > I can push it differently in master so as not to appear disparaging to gcc. > I agree that the code impinges on one of the many "behavior not defined" > areas in C, and therefore that it is technical legal for the compiler to do > anything at all (including printing runtime obscenities on stdout). > > But the code isn't really unsafe under less vigorous optimizing compilers -- > the problem is that whoever wrote that (Tuomas?) used a massive autogenerated > collection of similar-but-slightly-different structs to simulate dynamically > allocated arrays, with a superclass generic struct that is used to access > most of them. The memory is out-of-bounds for the type to which the struct > is cast (the generic pdl_trans), but the bounds are maintained with runtime > variables. > > The Right way to implement that is to separate the dynamics from the > framework, but teasing that out will require some thought and testing. > > > On Oct 11, 2013, at 2:43 PM, Dima Kogan <[email protected]> wrote: > >> Craig DeForest <[email protected]> writes: >> >>> 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. >> >> That change does fix that issue. If you intend to push it, can you >> change the comment, commit message to indicate that this really isn't >> done to pacify the new compiler? >> >> The new compiler removes unsafe code, while the old compiler just >> blindly reads/writes out-of-bounds memory. This should have never >> worked, and nobody fingered this earlier due purely to luck. The >> compiler is fine. >> >> 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 _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
