Re: Avoid alloca(0) when temporarily propagating operands during threading

2016-12-02 Thread Jakub Jelinek
On Fri, Dec 02, 2016 at 11:13:29AM -0700, Jeff Law wrote: > >But -Wuninitialized also found tons of real-world bugs. Do we have a single > >real-world example where such a warning would actually be useful (as in, > >there would be an actual bug)? Otherwise we are adding workarounds for a >

Re: Avoid alloca(0) when temporarily propagating operands during threading

2016-12-02 Thread Jeff Law
On 12/02/2016 11:11 AM, Jakub Jelinek wrote: On Fri, Dec 02, 2016 at 11:02:33AM -0700, Jeff Law wrote: It won't cause any problems in this and probably most instances, but leaving the code in its prior state is simply wrong from a maintenance standpoint. I'd much rather have the code

Re: Avoid alloca(0) when temporarily propagating operands during threading

2016-12-02 Thread Jakub Jelinek
On Fri, Dec 02, 2016 at 11:02:33AM -0700, Jeff Law wrote: > It won't cause any problems in this and probably most instances, but leaving > the code in its prior state is simply wrong from a maintenance standpoint. > > I'd much rather have the code explicitly and safely handle the zero operands >

Re: Avoid alloca(0) when temporarily propagating operands during threading

2016-12-02 Thread Jeff Law
On 12/02/2016 10:58 AM, Jakub Jelinek wrote: On Thu, Dec 01, 2016 at 11:43:19PM -0700, Jeff Law wrote: Martin's alloca work flagged this code as problematical. Essentially if we had a statement with no operands and the statement was not in the hash table, then we could end up performing

Re: Avoid alloca(0) when temporarily propagating operands during threading

2016-12-02 Thread Jakub Jelinek
On Thu, Dec 01, 2016 at 11:43:19PM -0700, Jeff Law wrote: > > Martin's alloca work flagged this code as problematical. Essentially if we > had a statement with no operands and the statement was not in the hash > table, then we could end up performing alloca (0), which is inadvisable. I still