{"action":"created","issue":{"url":"https://api.github.com/repos/coelckers/gzdoom/issues/522","repository_url":"https://api.github.com/repos/coelckers/gzdoom","labels_url":"https://api.github.com/repos/coelckers/gzdoom/issues/522/labels{/name}","comments_url":"https://api.github.com/repos/coelckers/gzdoom/issues/522/comments","events_url":"https://api.github.com/repos/coelckers/gzdoom/issues/522/events","html_url":"https://github.com/coelckers/gzdoom/pull/522","id":341361295,"node_id":"MDExOlB1bGxSZXF1ZXN0MjAxNTIxMDg1","number":522,"title":"GCC warning fixes","user":{"login":"Blzut3","id":4406100,"node_id":"MDQ6VXNlcjQ0MDYxMDA=","avatar_url":"https://avatars0.githubusercontent.com/u/4406100?v=4","gravatar_id":"","url":"https://api.github.com/users/Blzut3","html_url":"https://github.com/Blzut3","followers_url":"https://api.github.com/users/Blzut3/followers","following_url":"https://api.github.com/users/Blzut3/following{/other_user}","gists_url":"https://api.github.com/users/Blzut3/gists{/gist_id}","starred_url":"https://api.github.com/users/Blzut3/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Blzut3/subscriptions","organizations_url":"https://api.github.com/users/Blzut3/orgs","repos_url":"https://api.github.com/users/Blzut3/repos","events_url":"https://api.github.com/users/Blzut3/events{/privacy}","received_events_url":"https://api.github.com/users/Blzut3/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":7,"created_at":"2018-07-15T23:24:07Z","updated_at":"2018-07-17T00:14:37Z","closed_at":"2018-07-16T18:30:57Z","author_association":"COLLABORATOR","pull_request":{"url":"https://api.github.com/repos/coelckers/gzdoom/pulls/522","html_url":"https://github.com/coelckers/gzdoom/pull/522","diff_url":"https://github.com/coelckers/gzdoom/pull/522.diff","patch_url":"https://github.com/coelckers/gzdoom/pull/522.patch"},"body":"This doesn't fix all of them, but definitely cleans up the output a lot.  GCC introduced a lot of static analysis class warnings which while they point out mostly harmless things they have produced some interesting results.  Like they now warn if you memcpy/set/move on types where the relevant operations would be non-trivial.\r\n\r\nSo with that there is some encouragement to go and explicitly default operations that previously needed to be defined in C++98/03.  Also made me analyze the operator= optimization in TVector which as it turns out appears to be inhibiting the compiler from doing the right thing which the default empowers.  Interestingly on 32-bit GCC the optimization allows the compiler to use SSE where as the opposite is true for 64-bit.  That said what Randi's comment says no longer applies in either case so profiling would need to be done to see if the microoptimization even does anything there and well at this point probably not worth worrying about.  Especially since it makes the type non-trivially copyable according to the standard.\r\n\r\nOne thing I haven't done yet but will need to explore later is reversing FName and FNameNoInit's hierarchy.  Since as it stands FNameNoInit is not trivially constructable which is making a number of otherwise POD types non-POD.\r\n\r\n**I've only tested on Linux**, so please do check Windows before merging.  Also note that I made I_Error [[noreturn]] including in the win32 code.   This assists the static analyzer in making assumptions.  I_FatalError however can't be noreturn as it's written now since it does have a path where it technically returns."},"comment":{"url":"https://api.github.com/repos/coelckers/gzdoom/issues/comments/405419407","html_url":"https://github.com/coelckers/gzdoom/pull/522#issuecomment-405419407","issue_url":"https://api.github.com/repos/coelckers/gzdoom/issues/522","id":405419407,"node_id":"MDEyOklzc3VlQ29tbWVudDQwNTQxOTQwNw==","user":{"login":"Blzut3","id":4406100,"node_id":"MDQ6VXNlcjQ0MDYxMDA=","avatar_url":"https://avatars0.githubusercontent.com/u/4406100?v=4","gravatar_id":"","url":"https://api.github.com/users/Blzut3","html_url":"https://github.com/Blzut3","followers_url":"https://api.github.com/users/Blzut3/followers","following_url":"https://api.github.com/users/Blzut3/following{/other_user}","gists_url":"https://api.github.com/users/Blzut3/gists{/gist_id}","starred_url":"https://api.github.com/users/Blzut3/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Blzut3/subscriptions","organizations_url":"https://api.github.com/users/Blzut3/orgs","repos_url":"https://api.github.com/users/Blzut3/repos","events_url":"https://api.github.com/users/Blzut3/events{/privacy}","received_events_url":"https://api.github.com/users/Blzut3/received_events","type":"User","site_admin":false},"created_at":"2018-07-17T00:14:37Z","updated_at":"2018-07-17T00:14:37Z","author_association":"COLLABORATOR","body":"Playing around with godbolt compiler explorer.  I'm pretty sure the reason you needed the memcpys on VC++ is because of the non-trivial types.  I can explore more when I have the time, but if I create an aggregate type whereby one of the types has a \"non-trivial\" copy then VC++ gives up pretty much immediately, GCC seems to be able to trace a little longer before giving up, and Clang seems to always do a memcpy although for some reason it decides to actually inline it in the cases where the others give up.\r\n\r\nSee: https://godbolt.org/g/giLXyd  Change USE_OPT between 0, 1, and 2.  0 is what this patch would have produced, 1 is what I believe you tried to optimized, and 2 is what you did.  In any case 0 and 2 produce basically identical results across all compilers.  Not an exact replica of the structures, so there could admittedly be minor details."}}
{"actor":{"display_login":"Blzut3"}}