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 marc.gli...@inria.fr writes:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
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
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 marc.gli...@inria.fr writes:
Hello,
I followed the advice in this discussion:
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse marc.gli...@inria.fr 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
On Tue, 2014-07-29 at 19:36 +0200, Marc Glisse wrote:
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse marc.gli...@inria.fr 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
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 is
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 marc.gli...@inria.fr writes:
Hello,
I followed the advice in this discussion:
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
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 i;
}
This
Marc Glisse marc.gli...@inria.fr 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
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse marc.gli...@inria.fr 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
Marc Glisse marc.gli...@inria.fr writes:
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse marc.gli...@inria.fr writes:
+ if (always_executed)
+ msg = function returns address of local variable;
+ else
+ msg =
On Sun, 27 Jul 2014, Andreas Schwab wrote:
Marc Glisse marc.gli...@inria.fr writes:
On Sun, 27 Jul 2014, Richard Sandiford wrote:
Marc Glisse marc.gli...@inria.fr writes:
+ if (always_executed)
+ msg = function returns address of local variable;
+
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
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.
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_global_var (valbase))
+
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 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 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 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
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
( 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
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
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 marc.gli...@inria.fr 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 Sat, Apr 5, 2014 at 3:52 PM, Marc Glisse marc.gli...@inria.fr 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
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
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
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
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
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
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
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 we are returning the address of a
32 matches
Mail list logo
