This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)
- From: Jeff Law <law at redhat dot com>
- To: Bernd Edlinger <bernd dot edlinger at hotmail dot de>, Richard Biener <rguenther at suse dot de>
- Cc: "jakub at redhat dot com" <jakub at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Jan Hubicka <hubicka at ucw dot cz>
- Date: Wed, 20 Jul 2016 12:48:45 -0600
- Subject: Re: [PATCH] Fix unsafe function attributes for special functions (PR 71876)
- Authentication-results: sourceware.org; auth=none
- References: <AM4PR0701MB216226C00439A01515A3AA5FE4370@AM4PR0701MB2162.eurprd07.prod.outlook.com> <alpine.LSU.email@example.com> <AM4PR0701MB2162738A0964E4579175FE86E4080@AM4PR0701MB2162.eurprd07.prod.outlook.com> <firstname.lastname@example.org> <AM4PR0701MB2162F81DBC64692DC5100927E4080@AM4PR0701MB2162.eurprd07.prod.outlook.com>
On 07/20/2016 10:54 AM, Bernd Edlinger wrote:
And those optimizations probably aren't safe in the presence of alloca
implemented on top of malloc. They are safe for the built-in alloca though.
Yes. That is another interesting observation. I think, originally this
flag was introduced by Jan Hubicka, and should mean, "it may be alloca
or a weak alias to alloca or maybe even something different".
But some of the later optimizations use it in a way as if it meant
"it must be alloca". However I have not been able to come up with
a test case that makes this assumption false, but I probably just
did not try hard enough.
But I think that alloca just should not be recognized by name any