{"push_id":701280668,"size":17,"distinct_size":2,"ref":"refs/heads/rewriteLookup","head":"865d7d25f81b061b0264554416e5dd8310207b6a","before":"97a7b83840e8b22393c20b7558e5707e0e31ca2b","commits":[{"sha":"f4dd39b51e6c2168ce21475e15f2a4b613dfb70f","author":{"email":"316f002f21af5ba9752c9bba1f6bc783fdf918a1@users.noreply.github.com","name":"Vassily Litvinov"},"message":"Fixed non-determinism in 21-capture-in-cobegin et al.\nJIRA #63: https://chapel.atlassian.net/browse/CHAPEL-63\n\nTHE ISSUE\n\nIn the following code\n\n```\n    var x = 5;\n    ....\n    coforall .... do\n      writeln(x);\n```\n\nwe want all iterations of coforall to print the value of 'x'\nthat 'x' had immediately before entering 'coforall'.\nAs a result, all iterations are guaranteed to print the same.\n\nPrior to this change, our implementation was capturing\nthe value of 'x' at the time each coforall task was created,\ni.e. when initializing each argument bundle.\nSo it was possible that 'x' changes between initializations\nof the first and second bundle, violating our desired property.\n\nHere are a couple of fleshed-out examples:\n\n```\n    var x = 5;\n    begin with (ref x) { x = 6; }\n    coforall ... do writeln(x);\n```\n\n```\n    var x = 5;\n    proc update() { x = 6; }\n    cobegin { /*Task1*/writeln(x); /*Task2*/update(); }\n```\n\nTHE FIX\n\nFor each variable to be captured, I create a temp and initialize\nit from that variable right before the start of the corresponding\ntask construct. That temp is used instead of the original variable\nwhen initializing the argument bundles.\n\nWHAT'S UP WITH RECORDS?\n\nRight now the blank task intent for records is incorrectly implemented\nas 'const in'. Since this is incorrect, I explicitly exclude records\nfrom The Fix above. Therefore the records continue to be captured at\ntask creation time. I adjusted the tests not to test records, because\nthe behavior remains nondeterministic.\n\nWHAT'S WITH STRINGS AND UNIONS?\n\nWhat I wrote about records above should apply to strings and unions.\nI do not know for sure whether it does. For now I exclude strings and\nunions from testing as well, because most likely their behavior in\nthis regard currently is also most likely nondeterministic.","distinct":false,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/f4dd39b51e6c2168ce21475e15f2a4b613dfb70f"},{"sha":"d510284775757b9c0d021ad54a43f14bf1e1b712","author":{"email":"9efea9f3e732de9799f8e0cd6a4854f20f095f82@users.noreply.github.com","name":"Michael Ferguson"},"message":"attempting to fix odd resolution error","distinct":false,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/d510284775757b9c0d021ad54a43f14bf1e1b712"},{"sha":"44a3030723de990c018f6a384a8c22ef4863f8e8","author":{"email":"9efea9f3e732de9799f8e0cd6a4854f20f095f82@users.noreply.github.com","name":"Michael Ferguson"},"message":"remove printouts","distinct":false,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/44a3030723de990c018f6a384a8c22ef4863f8e8"},{"sha":"cdbd1da01d040b06e80f2e058c22077e5d2e4ded","author":{"email":"9efea9f3e732de9799f8e0cd6a4854f20f095f82@users.noreply.github.com","name":"Michael Ferguson"},"message":"Move _defaultOf closer to involved types\n\nTo resolve some function resolution order problems, I've moved the\nimplementation of _defaultOf from Types.chpl to ChapelBase.chpl for most\nthings. Moved _defaultOf for memory_order to MemConsistency.chpl;\nadded _defaultOf for c_ptr and c_void_ptr to SysBasic.chpl instead\nof relying on a catch-all case.\n\nRemoves the catch-all case for _defaultOf which used to be\n  inline proc _defaultOf(type t) {\n    select t {\n      when memory_order {\n        return _defaultOfMemoryOrder();\n      }\n      otherwise {\n        return nil:t;\n      }\n    }\n  }\n\nand is apparently no longer needed.","distinct":false,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/cdbd1da01d040b06e80f2e058c22077e5d2e4ded"},{"sha":"0d98d256d6b3dff9a693dfa622a13e2f67a1b429","author":{"email":"9efea9f3e732de9799f8e0cd6a4854f20f095f82@users.noreply.github.com","name":"Michael Ferguson"},"message":"Add a test that was failing.","distinct":false,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/0d98d256d6b3dff9a693dfa622a13e2f67a1b429"},{"sha":"9d492193fa9f094a44b1b03a4e0c26e0e1d078dc","author":{"email":"9efea9f3e732de9799f8e0cd6a4854f20f095f82@users.noreply.github.com","name":"Michael Ferguson"},"message":"Merge pull request #2076 from mppf/fix-odd-error2\n\nFix resolution bug with extern var x: c_ptr(c_int)\r\n\r\nThis is a bug fix for code like:\r\n\r\n    extern var x: c_ptr(c_int);\r\n\r\nBefore this patch, such code would generate an error like:\r\n\r\n    use of c_int before encountering its definition, type unknown\r\n\r\n\r\nThe problem is that function resolution treats extern variables specially\r\nand resolves them first. One result of that is that the c_int argument\r\n(which comes from e.g. extern type c_int = int(32) ) is not resolved at\r\nthe time that we're trying here to resolve the type constructor for c_ptr.\r\n\r\nThis patch takes a fairly direct approach to patch this problem, but\r\nideally function resolution would not need a special case for this\r\nsituation.\r\n\r\nTo resolve some function resolution order problems that came up, I've\r\nmoved the implementation of _defaultOf from Types.chpl to ChapelBase.chpl\r\nfor most things. Moved _defaultOf for memory_order to MemConsistency.chpl;\r\nadded _defaultOf for c_ptr and c_void_ptr to SysBasic.chpl instead of\r\nrelying on a catch-all case.\r\n\r\nRemoves the catch-all case for _defaultOf which used to be:\r\n\r\n    inline proc _defaultOf(type t) {\r\n      select t {\r\n        when memory_order {\r\n          return _defaultOfMemoryOrder();\r\n        }\r\n        otherwise {\r\n          return nil:t;\r\n        }\r\n      }\r\n    }\r\n\r\nand is apparently no longer needed.\r\n\r\nPassed full local testing.\r\nReviewed by @hildeth.","distinct":false,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/9d492193fa9f094a44b1b03a4e0c26e0e1d078dc"},{"sha":"88231def12924bea5ce1b024457686d07d2a478e","author":{"email":"316f002f21af5ba9752c9bba1f6bc783fdf918a1@users.noreply.github.com","name":"Vassily Litvinov"},"message":"Added comments and test for isConstValWillNotChange","distinct":false,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/88231def12924bea5ce1b024457686d07d2a478e"},{"sha":"ab41ed7728a464350e24b0538867c48bc3b0731c","author":{"email":"316f002f21af5ba9752c9bba1f6bc783fdf918a1@users.noreply.github.com","name":"Vassily Litvinov"},"message":"Merge pull request #2062 from vasslitvinov/fix--21-capture-in-cobegin\n\nFixed non-determinism in 21-capture-in-cobegin et al.\r\n\r\nSolves JIRA Issue 63: https://chapel.atlassian.net/browse/CHAPEL-63\r\n\r\nTHE ISSUE\r\n\r\nIn the following code\r\n\r\n    var x = 5;\r\n    ....\r\n    coforall .... do\r\n      writeln(x);\r\n\r\nwe want all iterations of coforall to print the value of 'x'\r\nthat 'x' had immediately before entering 'coforall'.\r\nAs a result, all iterations are guaranteed to print the same.\r\n\r\nPrior to this change, our implementation was capturing\r\nthe value of 'x' at the time each coforall task was created,\r\ni.e. when initializing each argument bundle.\r\nSo it was possible that 'x' changes between initializations\r\nof the first and second bundle, violating our desired property.\r\n\r\nHere are a couple of fleshed-out examples:\r\n\r\n    var x = 5;\r\n    begin with (ref x) { x = 6; }\r\n    coforall ... do writeln(x);\r\n\r\n    var x = 5;\r\n    proc update() { x = 6; }\r\n    cobegin { /*Task1*/writeln(x); /*Task2*/update(); }\r\n\r\nTHE FIX\r\n\r\nFor each variable to be captured, I create a temp and initialize\r\nit from that variable right before the start of the corresponding\r\ntask construct. That temp is used instead of the original variable\r\nwhen initializing the argument bundles.\r\n\r\nWHAT'S UP WITH RECORDS?\r\n\r\nRight now the blank task intent for records is incorrectly implemented\r\nas 'const in'. Since this is incorrect, I explicitly exclude records\r\nfrom The Fix above. Therefore the records continue to be captured at\r\ntask creation time. I adjusted the tests not to test records, because\r\nthe behavior remains nondeterministic.\r\n\r\nWHAT'S WITH STRINGS AND UNIONS?\r\n\r\nWhat I wrote above about records should apply to strings and unions.\r\nI do not know for sure whether it does. For now I exclude strings and\r\nunions from testing as well, because most likely their behavior in\r\nthis regard currently is also most likely nondeterministic.\r\n\r\nr: @Kyle-B  @hildeth","distinct":false,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/ab41ed7728a464350e24b0538867c48bc3b0731c"},{"sha":"feb1aabbb96969b92c4316150f4109661a451eec","author":{"email":"316f002f21af5ba9752c9bba1f6bc783fdf918a1@users.noreply.github.com","name":"Vassily Litvinov"},"message":"Pass through ref fields in a tuple's autoCopy.\n\nWhen generating autoCopy for a tuple, we used to autoCopy\neach of its fields. When a field is of a ref type, e.g.\n_ref(int), it would get dereferenced while resolving\nthe autoCopy of that field. The result would look like this:\n\n    fn chpl__autoCopy[784989]:2*int(64)[802618]\n    def arg x[784991]:(int(64),_ref(int(64)))[784120]\n    {\n      def tmp[784999]:int(64)[10]\n      move( tmp[784999] .v( arg x[784991] x1[784116] ) )\n      def tmp[785009]:_ref(int(64))[479651]\n      move( tmp[785009] .v( arg x[784991] x2[784118] ) )\n      def coerce_tmp[827924]:int(64)[10]\n      move( coerce_tmp[827924] deref( tmp[785009] ) )\n      def this[886146]:2*int(64)[802618]\n      .=( this[886146] x1[802614] tmp[784999] )\n      .=( this[886146] x2[802616] coerce_tmp[827924] )\n      return( this[886146] )\n    }\n\nWith this change, ref fields are passed straight through\nwithout dereferencing:\n\n    fn chpl__autoCopy[784989]:(int(64),_ref(int(64)))[784120]\n    def arg x[784991]:(int(64),_ref(int(64)))[784120]\n    {\n      def ret[785020]:(int(64),_ref(int(64)))[784120]\n      def tmp[784999]:int(64)[10]\n      move( tmp[784999] .v( arg x[784991] x1[784116] ) )\n      def tmp[785009]:_ref(int(64))[479651]\n      move( tmp[785009] .v( arg x[784991] x2[784118] ) )\n      def call_tmp[785027]:int(64)[10]\n      move( call_tmp[785027] call( fn chpl__autoCopy[814911] tmp[784999] ) )\n      def call_tmp[785032]:(int(64),_ref(int(64)))[784120]\n      move( call_tmp[785032]\n        call( fn _build_tuple_always_allow_ref[784059]\n              call_tmp[785027] tmp[785009] ) )\n      move( ret[785020] call_tmp[785032] )\n      return( ret[785020] )\n    }","distinct":false,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/feb1aabbb96969b92c4316150f4109661a451eec"},{"sha":"8aa751179b7c3a272692cb2f1345975b8b09408d","author":{"email":"a0eed57aaedf007a763cbac2dd65f90f9fe7ec18@gmail.com","name":"Elliot Ronaghan"},"message":"Skip parallel/forall/vass/ri-3-stress on chpbld01 with CCE\n\nThis test takes ~600 seconds to execute on chpbld01 with both 8.3 and 8.4\nversions of the cray compiler. It only takes ~60 seconds with gcc 4.8.2. For\nreference, on real XC hardware it takes ~5 seconds for both compilers. It seems\nlike a result of chpbld01 having an unusual setup (cray might have bad code gen\nfor an \"XC\" with old AMD hardware or something) and just being an older/slower\nmachine in general.","distinct":false,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/8aa751179b7c3a272692cb2f1345975b8b09408d"},{"sha":"7eb86dcf80587eb9cd6de87a0826c2276c43527d","author":{"email":"a0eed57aaedf007a763cbac2dd65f90f9fe7ec18@gmail.com","name":"Elliot Ronaghan"},"message":"Merge pull request #2079 from ronawho/skip-ri-3-stress\n\nSkip parallel/forall/vass/ri-3-stress on chpbld01 with CCE\r\n\r\n[discussed and ok'd by @vasslitvinov]\r\n\r\nThis test takes ~600 seconds to execute on chpbld01 with both 8.3 and 8.4\r\nversions of the cray compiler. It only takes ~60 seconds with gcc 4.8.2. For\r\nreference, on real XC hardware it takes ~5 seconds for both compilers. It seems\r\nlike a result of chpbld01 having an unusual setup (cray might have bad code gen\r\nfor an \"XC\" with old AMD hardware or something) and just being an older/slower\r\nmachine in general.","distinct":false,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/7eb86dcf80587eb9cd6de87a0826c2276c43527d"},{"sha":"7d041e9c81aa5332ac12b32013284c0f99155593","author":{"email":"316f002f21af5ba9752c9bba1f6bc783fdf918a1@users.noreply.github.com","name":"Vassily Litvinov"},"message":"Merge pull request #2078 from vasslitvinov/pass-through-refs-in-tuple-autoCopy\n\nPass through ref fields in a tuple's autoCopy.\r\n\r\nWhen generating autoCopy for a tuple, we used to autoCopy\r\neach of its fields. When a field is of a ref type, e.g.\r\n_ref(int), it would get dereferenced while resolving\r\nthe autoCopy of that field. The result would look like this:\r\n\r\n    fn chpl__autoCopy[784989]:2*int(64)[802618] \r\n    def arg x[784991]:(int(64),_ref(int(64)))[784120] \r\n    {\r\n      def tmp[784999]:int(64)[10] \r\n      move( tmp[784999] .v( arg x[784991] x1[784116] ) ) \r\n      def tmp[785009]:_ref(int(64))[479651] \r\n      move( tmp[785009] .v( arg x[784991] x2[784118] ) ) \r\n      def coerce_tmp[827924]:int(64)[10] \r\n      move( coerce_tmp[827924] deref( tmp[785009] ) ) \r\n      def this[886146]:2*int(64)[802618] \r\n      .=( this[886146] x1[802614] tmp[784999] ) \r\n      .=( this[886146] x2[802616] coerce_tmp[827924] ) \r\n      return( this[886146] ) \r\n    }\r\n\r\nWith this change, ref fields are passed straight through\r\nwithout dereferencing:\r\n\r\n    fn chpl__autoCopy[784989]:(int(64),_ref(int(64)))[784120] \r\n    def arg x[784991]:(int(64),_ref(int(64)))[784120] \r\n    {\r\n      def ret[785020]:(int(64),_ref(int(64)))[784120] \r\n      def tmp[784999]:int(64)[10] \r\n      move( tmp[784999] .v( arg x[784991] x1[784116] ) ) \r\n      def tmp[785009]:_ref(int(64))[479651] \r\n      move( tmp[785009] .v( arg x[784991] x2[784118] ) ) \r\n      def call_tmp[785027]:int(64)[10] \r\n      move( call_tmp[785027] call( fn chpl__autoCopy[814911] tmp[784999] ) ) \r\n      def call_tmp[785032]:(int(64),_ref(int(64)))[784120] \r\n      move( call_tmp[785032]\r\n        call( fn _build_tuple_always_allow_ref[784059]\r\n              call_tmp[785027] tmp[785009] ) ) \r\n      move( ret[785020] call_tmp[785032] ) \r\n      return( ret[785020] ) \r\n    }\r\n\r\nr: @Kyle-B","distinct":false,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/7d041e9c81aa5332ac12b32013284c0f99155593"},{"sha":"f8cff5a25c9229f8818199d2295bde35dfac6fbc","author":{"email":"fc1bc1fa62cd3225a2eb4cd15c02de1adde8e6aa@cray.com","name":"Kyle Brady"},"message":"Make sure to use the value type of formals/actuals in testArgMapping\n\nIf we don't use the actual type some functions that should or shouldn't\nbe ambiguous are messed up due to _ref types. For example, these two\nfunctions will not be ambiguous without this patch:\n\n    proc foo(const ref x: RecordX) {...};\n    proc foo(const in x: RecordX) {...};","distinct":false,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/f8cff5a25c9229f8818199d2295bde35dfac6fbc"},{"sha":"dc37e556079ec4a72bc04f0afe63b6e5ccae8c97","author":{"email":"fc1bc1fa62cd3225a2eb4cd15c02de1adde8e6aa@cray.com","name":"Kyle Brady"},"message":"Remove bad extern proc in GMP","distinct":false,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/dc37e556079ec4a72bc04f0afe63b6e5ccae8c97"},{"sha":"72ac9d33d51d09f6b42dbbc0174d05efeae00f0f","author":{"email":"3c25b01657254677d3e1a8fd1f0742c5d489bd39@spark-gap.com","name":"Kyle Brady"},"message":"Merge pull request #2080 from Kyle-B/kb-fn-res-actual-types-only\n\nMake sure to use the value type of formals/actuals in testArgMapping\r\n\r\nIf we don't use the actual type some functions that should or shouldn't\r\nbe ambiguous are messed up due to _ref types. For example, these two\r\nfunctions will not be ambiguous without this patch:\r\n\r\n    proc foo(const ref x: RecordX) {...};\r\n    proc foo(const in x: RecordX) {...};\r\n\r\nI've fixed an instance of this ambiguity that became apparent in the GMP wrapper after making this change.","distinct":false,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/72ac9d33d51d09f6b42dbbc0174d05efeae00f0f"},{"sha":"37e4d0f55566faedb5ec0b167fbdfdb19e7fe9c0","author":{"email":"f955cf5f42dff0db8f444c4740a67a0cf0b4805d@users.noreply.github.com","name":"Lydia Duncan"},"message":"Merge branch 'master' into rewriteLookup","distinct":true,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/37e4d0f55566faedb5ec0b167fbdfdb19e7fe9c0"},{"sha":"865d7d25f81b061b0264554416e5dd8310207b6a","author":{"email":"f955cf5f42dff0db8f444c4740a67a0cf0b4805d@users.noreply.github.com","name":"Lydia Duncan"},"message":"Alter my lookup to view variables from used modules and function arguments with\nthe same name as ambiguous.","distinct":true,"url":"https://api.github.com/repos/lydia-duncan/chapel/commits/865d7d25f81b061b0264554416e5dd8310207b6a"}]}