GitHub PushEvent at 2014-09-12 19:06:15
Repository: chapel
Actor: thomasvandoren
Payload: {"shas":[["008b67b98bc34fb20094e6e901dd6f980732eb99","2e1153ecd6addcd932bf8cdd29c11fb7dd39bbb6@gmail.com","Initial pass to switch from CHPL_MEM value of 'default' to 'cstdlib'","Ben Harshbarger",true],["0f84e7198824804cff7d5101915afe240ceccbb1","2e1153ecd6addcd932bf8cdd29c11fb7dd39bbb6@gmail.com","Merge branch 'default-to-cstdlib' of github.com:benharsh/chapel into default-to-cstdlib","Ben Harshbarger",true],["d4f108768534648a25e75eab28bd2604f995e4cd","2e1153ecd6addcd932bf8cdd29c11fb7dd39bbb6@gmail.com","Renaming files to match cstdlib naming; Correcting naming in docs","Ben Harshbarger",true],["7d27a550cdefa643126172ff460ad80e843b50bc","a0eed57aaedf007a763cbac2dd65f90f9fe7ec18@gmail.com","Add overflow checks to bounded iterators\n\nThe default iterators do not support positively strided ranges whose last index\nis max(indexType) or negatively strided ranges whose last index is\nmin(indexType). E.G \"for i in max(int)-10 .. max(int)\"\n\nThe above example turns into the following generated code\n\nfor (i=max(int)-10; i < max(int); i+=1)\n\nand everything is less than max(int) so you would have an infinite loop.\n\nPrior to c for loops our iterators didn't work for maximal ranges, but they did\nwork for the above example. They generated the equivalent of:\nfor (i=max(int)-10; i != max(int)+1; i+=1)\n\nThis relies on well defined integer overflow, which is not valid since integer\noverflow has undefined behavior in c.\n\nSo while the new iterators aren't as capable as the old ones, they're more\nperformant, and don't cause undefined behavior.\n\nTo deal with this limitation I added a function that checks for overflow and\nhalts with a warning about them.\n\nIf a user really wants to iterate over such a range, I added a generalIterator\nthat works for any range including maximal ranges, but is terribly slow. To\navoid the performance cost the user can either rewrite their loop to avoid the\nproblem or try a wider type if they aren't already at the max size.\n\nIf they don't care about performance they can toggle\nuseOptimizedRangeIterators=false which is a big hammer that will use the slow\ngeneral iterator for all cases. This will lead to absolutely awful performance.\nI can't think of a way to support such ranges in an optimal  fashion, but there\nmay be a better way to let users pick and chose what loops use the general\niterator.\n\nThe general iterator exposed some bugs in the c for loop implementation. Namely\nthat the break and continue labels were getting added to the wrong structure.\n\nThere are also some tests changes.\n\ntrivial/deitz/test_max_range_iteration\ntypes/range/hilde/maximalRange\n\nwere tests that has ranges that the new iterators do not support. I updated\nthese tests to include the new error. I also added compopts so they tests the\nunoptimized iterator. With bounds checks off and the optimized iterators being\nused these tests would have infinite loops. We break to avoid this, so one\nvariation of the test captures the fact that these infinite loops will occur\n(and are expected, although unfortunate.)\n\nI also added a test that checks similar behavior as the previous two tests but\nit does it for unsigned and signed variations for positively and negatively\nstrided ranges.","Elliot Ronaghan",true],["dd8ef069e17769ec1c272e1a74dd42e1b501d48a","a0eed57aaedf007a763cbac2dd65f90f9fe7ec18@gmail.com","Need to cast stride.\n\nThe stride needs to be casted when the idxType is unsigned. This is still\ncorrect even if the stride is negative because val:uint + -val2:uint is the\nsame as val:uint + max(uint)-abs(val2)+1\n\nE.G. 1:uint + (-1):uint ends up being 1 + 255 which will end up being 0 since\nunsigned integer overflow is well defined","Elliot Ronaghan",true],["c2a2bd4e10e587dbb0805d9a882c3dbd0dd57af0","a0eed57aaedf007a763cbac2dd65f90f9fe7ec18@gmail.com","Change bigStride to prevent overflowing\n\n[ok'd by brad]\n\nQuote from brad:\n\n\"Re-reading the history of this test, it was basically guarding against\nsome assumptions in the early range code that the idxType and/or stride\nwere 32-bits.  I think as long as the stride for this thing can't be\nstored in an int(32), my earlier self would be happy.  For example,\nmaybe something like:\n\n  1..2*(n/3) by n/3\n\n(with some +/-1's in there to get a few values without hitting the\noverflow issue?).  I can take this if you want.\"","Elliot Ronaghan",true],["34575f99e8e8ef405e63737b134163e4cfc637d3","a0eed57aaedf007a763cbac2dd65f90f9fe7ec18@gmail.com","Change atomictest to prevent range iterator overflow\n\n[ok'd by brad]\n\nquote from brad:\n\n\"Elliot says he doesn't think this is a particularly compelling example,\nwhich I'd agree with.  We can just set n to be something smaller. \"","Elliot Ronaghan",true],["0f5c449403321f2c289a450e21efbc15e6387a1c","a0eed57aaedf007a763cbac2dd65f90f9fe7ec18@gmail.com","Change fannkuch-redux-blc.chpl to use an unbounded range\n\nThis is identical to what brad did to the other fannkuch versions in\n0b09c9534e5ef7bfabdd6040f76b1e4ea817a320\n\nJust changing this test as well","Elliot Ronaghan",true],["18d9b9a59583d509738c40aa3fa9a0740ba1951c","a0eed57aaedf007a763cbac2dd65f90f9fe7ec18@gmail.com","Cast histoSerial iterator indices so they don't overflow the iterator\n\nThe iterator attempts to do something like \"for 0:uint..length:uint by -1\" and\nso the last iteration will result in overflow since 0 -1 for uints will\noverflow. This just casts the uint32 to int64s to prevent that","Elliot Ronaghan",true],["3f851b0dda52090095143763c1ecd5e610157d57","a0eed57aaedf007a763cbac2dd65f90f9fe7ec18@gmail.com","Update t2.chpl and t8.chpl to prevent iterator overflow\n\n[ok'd with vass]\n\nThese tests create unsigned integer overflow in a couple of cases. They have\nthings like for 0..9 by -1. This causes overflow for the iterators. This just\nchanges the bounds to things like 1..9 by -1.","Elliot Ronaghan",true],["8261653064b1df8b4af99544d4fc08b5abe9c317","a0eed57aaedf007a763cbac2dd65f90f9fe7ec18@gmail.com","Remove pointer to STATUS for range iterator overflow\n\nI'm not quite sure where the best place to put the note is, but STATUS isn't\nquite right. Something about what the behavior of iteration over ranges is\nneeded in the spec, but I'm not sure if we want to point to that, or if there\nshould be a technote or something else.","Elliot Ronaghan",true],["f9b632eaa6ea48bc98b3c3e9250e86c4d695f0cd","a0eed57aaedf007a763cbac2dd65f90f9fe7ec18@gmail.com","Fix typo in .good file","Elliot Ronaghan",true],["847564a8256810d47571d1e7623fe70505c030f7","2e1153ecd6addcd932bf8cdd29c11fb7dd39bbb6@gmail.com","Merge branch 'quickstart-use-default' into default-to-cstdlib","Ben Harshbarger",true],["09223621ff691b103b73de369343bf76c22515d4","2e1153ecd6addcd932bf8cdd29c11fb7dd39bbb6@gmail.com","Using cstdlib in quickstart scripts","Ben Harshbarger",true],["ba244a2d2b45edf34d11007b297098abb5b476e5","2e1153ecd6addcd932bf8cdd29c11fb7dd39bbb6@gmail.com","Found another stray default","Ben Harshbarger",true],["a25b1da658366a52ab4214d776c02518c844b88d","e01f471a0a039ccd6e0007037df8ddb2a870c29b@gmail.com","Filter another line of slurm output for lulesh failure cases.\n\nThis only occurs with the ugni comm layer.","Thomas Van Doren",true],["aac66c7d065bff135722c4b548c8ec44e73b6452","e01f471a0a039ccd6e0007037df8ddb2a870c29b@gmail.com","fix typo","Thomas Van Doren",true],["62e57a07290736a7f88a9dfc5555baf5dd193e57","e01f471a0a039ccd6e0007037df8ddb2a870c29b@gmail.com","Merge branch 'master' of github.com:chapel-lang/chapel into slurm-ugni-lulesh-prediff","Thomas Van Doren",true],["653024bbbb8eea46204dc97b2e681f69afdb4eb1","e01f471a0a039ccd6e0007037df8ddb2a870c29b@gmail.com","Start on llvm test script...","Thomas Van Doren",true],["d9c9d6e62c5f4c9ea0567f5c472ce11470c79a76","2e1153ecd6addcd932bf8cdd29c11fb7dd39bbb6@gmail.com","Merge branch 'master' of github.com:chapel-lang/chapel into default-to-cstdlib","Ben Harshbarger",true]],"size":51,"ref":"refs/heads/master","head":"81e3697aaccb60ef0f9499d653f55a67e69d3cb7"}