{"push_id":1295082282,"size":3,"distinct_size":3,"ref":"refs/heads/trunk","head":"3b8f8dcac2110211b6581f6859a0094c021b54dc","before":"c9d53119e1f3b4a240b91d1cd869678aa060cea4","commits":[{"sha":"25b6a354e6ad7b5ba130771d9f5e765e10781339","author":{"name":"anemet","email":"83a6a0c0be29416f5c01d64e7a687006e7b3bf4b@91177308-0d34-0410-b5e6-96231b3b80d8"},"message":"Fix a long comment line\n\ngit-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@281275 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/spurious/clang-mirror/commits/25b6a354e6ad7b5ba130771d9f5e765e10781339"},{"sha":"ccf9600c68195d3374d3513efb4cefbc1aa455bb","author":{"name":"anemet","email":"83a6a0c0be29416f5c01d64e7a687006e7b3bf4b@91177308-0d34-0410-b5e6-96231b3b80d8"},"message":"Add -fdiagnostics-show-hotness\n\nSummary:\nI've recently added the ability for optimization remarks to include the\nhotness of the corresponding code region.  This uses PGO and allows\nfiltering of the optimization remarks by relevance.  The idea was first\ndiscussed here:\nhttp://thread.gmane.org/gmane.comp.compilers.llvm.devel/98334\n\nThe general goal is to produce a YAML file with the remarks.  Then, an\nexternal tool could dynamically filter these by hotness and perhaps by\nother things.\n\nThat said it makes sense to also expose this at the more basic level\nwhere we just include the hotness info with each optimization remark.\nFor example, in D22694, the clang flag was pretty useful to measure the\noverhead of the additional analyses required to include hotness.\n(Without the flag we don't even run the analyses.)\n\nFor the record, Hal has already expressed support for the idea of this\npatch on IRC.\n\nDifferential Revision: https://reviews.llvm.org/D23284\n\ngit-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@281276 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/spurious/clang-mirror/commits/ccf9600c68195d3374d3513efb4cefbc1aa455bb"},{"sha":"3b8f8dcac2110211b6581f6859a0094c021b54dc","author":{"name":"gbiv","email":"19d9a75c93cb9e6122cf8bf3c14b6ae208c1fd21@91177308-0d34-0410-b5e6-96231b3b80d8"},"message":"[Sema] Fix PR30346: relax __builtin_object_size checks.\n\nThis patch makes us act more conservatively when trying to determine\nthe objectsize for an array at the end of an object. This is in\nresponse to code like the following:\n\n```\nstruct sockaddr {\n  /* snip */\n  char sa_data[14];\n};\n\nvoid foo(const char *s) {\n  size_t slen = strlen(s) + 1;\n  size_t added_len = slen <= 14 ? 0 : slen - 14;\n  struct sockaddr *sa = malloc(sizeof(struct sockaddr) + added_len);\n  strcpy(sa->sa_data, s);\n  // ...\n}\n```\n\n`__builtin_object_size(sa->sa_data, 1)` would return 14, when there\ncould be more than 14 bytes at `sa->sa_data`.\n\nCode like this is apparently not uncommon. FreeBSD's manual even\nexplicitly mentions this pattern:\nhttps://www.freebsd.org/doc/en/books/developers-handbook/sockets-essential-functions.html\n(section 7.5.1.1.2).\n\nIn light of this, we now just give up on any array at the end of an\nobject if we can't find the object's initial allocation.\n\nI lack numbers for how much more conservative we actually become as a\nresult of this change, so I chose the fix that would make us as\ncompatible with GCC as possible. If we want to be more aggressive, I'm\nhappy to consider some kind of whitelist or something instead.\n\n\ngit-svn-id: http://llvm.org/svn/llvm-project/cfe/trunk@281277 91177308-0d34-0410-b5e6-96231b3b80d8","distinct":true,"url":"https://api.github.com/repos/spurious/clang-mirror/commits/3b8f8dcac2110211b6581f6859a0094c021b54dc"}]}
{"actor":{"display_login":"spurious"}}