Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-30 Thread Jeff Law
On 07/30/14 05:54, Marc Glisse wrote: On Tue, 29 Jul 2014, David Malcolm wrote: On Tue, 2014-07-29 at 19:36 +0200, Marc Glisse wrote: On Sun, 27 Jul 2014, Richard Sandiford wrote: Marc Glisse writes: Hello, I followed the advice in this discussion: https://gcc.gnu.org/ml/gcc-patches/2014-

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-30 Thread Jeff Law
On 07/22/14 03:03, Marc Glisse wrote: I note you don't catch return &localvar in the isolation code -- it looks like you just catch those which potentially flow from PHIs. I thought I was handling it in the find_explicit_erroneous_behaviour part of the patch (as opposed to the implicit part whi

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-30 Thread Marc Glisse
On Tue, 29 Jul 2014, David Malcolm wrote: On Tue, 2014-07-29 at 19:36 +0200, Marc Glisse wrote: On Sun, 27 Jul 2014, Richard Sandiford wrote: Marc Glisse writes: Hello, I followed the advice in this discussion: https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html and here is a new pat

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-29 Thread David Malcolm
On Tue, 2014-07-29 at 21:13 +0200, Marek Polacek wrote: > On Tue, Jul 29, 2014 at 02:58:03PM -0400, David Malcolm wrote: > > This is possibly a dumb question, but what happens for a static local, > > rather than an auto local? e.g. > > > > int *f (void) > > { > > static int i; > > return &

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-29 Thread Marc Glisse
On Tue, 29 Jul 2014, David Malcolm wrote: On Tue, 2014-07-29 at 19:36 +0200, Marc Glisse wrote: On Sun, 27 Jul 2014, Richard Sandiford wrote: Marc Glisse writes: Hello, I followed the advice in this discussion: https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html and here is a new pat

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-29 Thread Marek Polacek
On Tue, Jul 29, 2014 at 02:58:03PM -0400, David Malcolm wrote: > This is possibly a dumb question, but what happens for a static local, > rather than an auto local? e.g. > > int *f (void) > { > static int i; > return &i; > } This is fine. The variable i has a static storage duration, so

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-29 Thread David Malcolm
On Tue, 2014-07-29 at 19:36 +0200, Marc Glisse wrote: > On Sun, 27 Jul 2014, Richard Sandiford wrote: > > > Marc Glisse writes: > >> Hello, > >> > >> I followed the advice in this discussion: > >> https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html > >> > >> and here is a new patch. I made a

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-29 Thread Marc Glisse
On Sun, 27 Jul 2014, Richard Sandiford wrote: Marc Glisse writes: Hello, I followed the advice in this discussion: https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html and here is a new patch. I made an effort to isolate a path in at least one subcase so it doesn't look too strange that

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-27 Thread Marc Glisse
On Sun, 27 Jul 2014, Andreas Schwab wrote: Marc Glisse writes: On Sun, 27 Jul 2014, Richard Sandiford wrote: Marc Glisse writes: + if (always_executed) + msg = "function returns address of local variable"; + else +

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-27 Thread Andreas Schwab
Marc Glisse writes: > On Sun, 27 Jul 2014, Richard Sandiford wrote: > >> Marc Glisse writes: >>> + if (always_executed) >>> + msg = "function returns address of local variable"; >>> + else >>> + msg = "function may return addres

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-27 Thread Marc Glisse
On Sun, 27 Jul 2014, Richard Sandiford wrote: Marc Glisse writes: Hello, I followed the advice in this discussion: https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html and here is a new patch. I made an effort to isolate a path in at least one subcase so it doesn't look too strange that

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-27 Thread Richard Sandiford
Marc Glisse writes: > Hello, > > I followed the advice in this discussion: > https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html > > and here is a new patch. I made an effort to isolate a path in at least > one subcase so it doesn't look too strange that the warning is in this > file. Compu

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-22 Thread Marc Glisse
On Wed, 16 Jul 2014, Jeff Law wrote: On 06/22/14 12:20, Marc Glisse wrote: Hello, I followed the advice in this discussion: https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html and here is a new patch. I made an effort to isolate a path in at least one subcase so it doesn't look too stran

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-17 Thread Jeff Law
On 06/22/14 12:20, Marc Glisse wrote: Hello, I followed the advice in this discussion: https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html and here is a new patch. I made an effort to isolate a path in at least one subcase so it doesn't look too strange that the warning is in this file. Co

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-02 Thread Jeff Law
On 06/30/14 15:37, Marc Glisse wrote: On Mon, 30 Jun 2014, Jeff Law wrote: On 06/29/14 03:22, Marc Glisse wrote: After looking at PR 61597, I updated the 2 conditions to: + if ((TREE_CODE (valbase) == VAR_DECL + && !is_global_var (valbase)) + || TREE_CODE

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-02 Thread Jeff Law
On 07/02/14 06:19, Alan Modra wrote: On Mon, Jun 30, 2014 at 11:37:50PM +0200, Marc Glisse wrote: On Mon, 30 Jun 2014, Jeff Law wrote: On 06/29/14 03:22, Marc Glisse wrote: After looking at PR 61597, I updated the 2 conditions to: + if ((TREE_CODE (valbase) == VAR_DECL +

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-02 Thread Marc Glisse
On Wed, 2 Jul 2014, Alan Modra wrote: On Mon, Jun 30, 2014 at 11:37:50PM +0200, Marc Glisse wrote: On Mon, 30 Jun 2014, Jeff Law wrote: On 06/29/14 03:22, Marc Glisse wrote: After looking at PR 61597, I updated the 2 conditions to: + if ((TREE_CODE (valbase) == VAR_DECL +

Re: Warn when returning the address of a temporary (middle-end) v2

2014-07-02 Thread Alan Modra
On Mon, Jun 30, 2014 at 11:37:50PM +0200, Marc Glisse wrote: > On Mon, 30 Jun 2014, Jeff Law wrote: > > >On 06/29/14 03:22, Marc Glisse wrote: > >> > >>After looking at PR 61597, I updated the 2 conditions to: > >> > >>+ if ((TREE_CODE (valbase) == VAR_DECL > >>+ && !is_glob

Re: Warn when returning the address of a temporary (middle-end) v2

2014-06-30 Thread Marc Glisse
On Mon, 30 Jun 2014, Jeff Law wrote: On 06/29/14 03:22, Marc Glisse wrote: After looking at PR 61597, I updated the 2 conditions to: + if ((TREE_CODE (valbase) == VAR_DECL + && !is_global_var (valbase)) + || TREE_CODE (valbase) == PARM_DECL) a PARM_DECL is

Re: Warn when returning the address of a temporary (middle-end) v2

2014-06-30 Thread Jeff Law
On 06/29/14 03:22, Marc Glisse wrote: After looking at PR 61597, I updated the 2 conditions to: + if ((TREE_CODE (valbase) == VAR_DECL + && !is_global_var (valbase)) + || TREE_CODE (valbase) == PARM_DECL) a PARM_DECL is a local variable and returning its add

Re: Warn when returning the address of a temporary (middle-end) v2

2014-06-29 Thread Marc Glisse
( https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01692.html ) On Sun, 22 Jun 2014, Marc Glisse wrote: Hello, I followed the advice in this discussion: https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html and here is a new patch. I made an effort to isolate a path in at least one subcase s

Warn when returning the address of a temporary (middle-end) v2

2014-06-22 Thread Marc Glisse
Hello, I followed the advice in this discussion: https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html and here is a new patch. I made an effort to isolate a path in at least one subcase so it doesn't look too strange that the warning is in this file. Computing the dominance info just to tw