[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #33 from Martin Jambor --- Author: jamborm Date: Wed May 18 13:06:24 2016 New Revision: 236390 URL: https://gcc.gnu.org/viewcvs?rev=236390=gcc=rev Log: Respect --param ipa-max-agg-items=0 2016-05-18 Martin Jambor

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #32 from Martin Jambor --- Author: jamborm Date: Wed May 18 13:04:23 2016 New Revision: 236389 URL: https://gcc.gnu.org/viewcvs?rev=236389=gcc=rev Log: [PR 70646] Store size to inlining predicate conditions 2016-05-18 Martin

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #31 from Martin Jambor --- (In reply to rguent...@suse.de from comment #30) > > Any reason it's not unsigned HOST_WIDE_INT size? The only reason is to use the same type in which get_ref_base_and_extent returns size.

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #30 from rguenther at suse dot de --- On Wed, 20 Apr 2016, jamborm at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 > > --- Comment #29 from Martin Jambor --- > Created attachment 38316 > -->

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #29 from Martin Jambor --- Created attachment 38316 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38316=edit Fix storing access size to conditions Honza asked me to also come up with a version of the patch where we store

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #28 from Martin Jambor --- (In reply to rguent...@suse.de from comment #27) > I was arguing that if IPA proves a condition to true/false then it > should adjust it that way in modification phase. The thing is that it does not prove

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #27 from rguenther at suse dot de --- On April 15, 2016 11:58:39 PM GMT+02:00, "jamborm at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 > >--- Comment #26 from Martin Jambor

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #26 from Martin Jambor --- (In reply to Josh Poimboeuf from comment #24) > > Yes, I'm looking for a general way to either prevent or try to detect > potential other cases of the bug throughout the entire kernel. > > Can it only

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #25 from Martin Jambor --- (In reply to Martin Jambor from comment #22) > I suppose the easiest fix is to overload the value field to store the > size of the access for these two codes and then add the missing check. OK, so the

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #24 from Josh Poimboeuf --- (In reply to Martin Jambor from comment #23) > (In reply to Josh Poimboeuf from comment #20) > > Thanks very much to everyone who has looked into this so far. It would be > > very helpful to get answers

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #23 from Martin Jambor --- (In reply to Josh Poimboeuf from comment #20) > Thanks very much to everyone who has looked into this so far. It would be > very helpful to get answers to the following questions, so we can understand >

[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #22 from Martin Jambor --- (In reply to Jan Hubicka from comment #18) > Jakub: There is indeed aliasing issue, but with -fno-strict-aliasing the bug > is the same. > > Apparently this is ipa-prop bug, because ipa-prop does not track