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-
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
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
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 &
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
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
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
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
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
+
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
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
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
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
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
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
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
+
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
+
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
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
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
( 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
On Sat, 5 Apr 2014, Marc Glisse wrote:
> One hard part is avoiding duplicate warnings. Replacing the address with 0 is
> a convenient way to do that, so I did it both for my new warning and for the
> existing C/C++ ones. The patch breaks gfortran.dg/warn_target_lifetime_2.f90
That's not safe the
On Mon, Apr 7, 2014 at 8:51 PM, Marc Glisse wrote:
> On Mon, 7 Apr 2014, Jeff Law wrote:
>
>> On 04/05/14 07:52, Marc Glisse wrote:
>>>
>>> Hello,
>>>
>>> we have front-end warnings about returning the address of a local
>>> variable. However, quite often in C++, people don't directly return the
>
On Mon, 7 Apr 2014, Jeff Law wrote:
I am also afraid we may get more false positives, but maybe not.
The only false positives should come from paths which are unexecutable. One
could argue that if we find any that we should warn, then isolate the path so
that we get an immediate runtime trap
On 04/07/14 12:51, Marc Glisse wrote:
I would tend to start from the return statements (assuming the return
type is a pointer), look at the defining statement, do things if it is
an assignment of an addr_expr, and recurse if it is a PHI. But maybe my
brain is cabled backwards ;-)
It works eith
On Mon, 7 Apr 2014, Jeff Law wrote:
On 04/05/14 07:52, Marc Glisse wrote:
Hello,
we have front-end warnings about returning the address of a local
variable. However, quite often in C++, people don't directly return the
address of a temporary, it goes through a few functions which hide that
fac
On 04/05/14 07:52, Marc Glisse wrote:
Hello,
we have front-end warnings about returning the address of a local
variable. However, quite often in C++, people don't directly return the
address of a temporary, it goes through a few functions which hide that
fact. After some inlining, the fact that
> One hard part is avoiding duplicate warnings. Replacing the address with 0
> is a convenient way to do that, so I did it both for my new warning and
> for the existing C/C++ ones. The patch breaks
> gfortran.dg/warn_target_lifetime_2.f90 because it ends up warning twice. I
> didn't touch that fro
On Mon, 7 Apr 2014, Richard Biener wrote:
One hard part is avoiding duplicate warnings. Replacing the address with 0
is a convenient way to do that, so I did it both for my new warning and for
the existing C/C++ ones. The patch breaks
gfortran.dg/warn_target_lifetime_2.f90 because it ends up war
On Sat, Apr 5, 2014 at 3:52 PM, Marc Glisse wrote:
> Hello,
>
> we have front-end warnings about returning the address of a local variable.
> However, quite often in C++, people don't directly return the address of a
> temporary, it goes through a few functions which hide that fact. After some
> i
30 matches
Mail list logo
