Le 22/05/2013 11:22, burnus at gcc dot gnu.org a écrit :
> --- a/gcc/fortran/resolve.c
> +++ b/gcc/fortran/resolve.c
> @@ -9299,4 +9299,5 @@ get_temp_from_expr (gfc_expr *e, gfc_namespace *ns)
> tmp->n.sym->attr.dimension = 0;
>
> + gfc_commit_symbol (tmp->n.sym);
>gfc_set_sym_referenced
On Thursday 22 September 2011 11:56:12 Teodori Serge wrote:
> Hello,
> I'm building a toolchain in /opt dir. I have already build and installed
> glibc-2.14 and binutils-2.21.1a in /opt.
> Now I want to build and install gcc-4.6.1 with gmp, mpfr and mpc also in
> /opt.
>
> Here is my configure:
>
> It would be nice to have a run time check for such invalid use of
> unallocated allocatable variables (such as -fcheck=use_unalloc).
If you use an unallocated variable you get a segmentation fault.
Isn't this a sufficient runtime check ?
> two() = 7
I don't see how it is possible to distinguish between a statement function and
an assignment here.
> this still fails with a recent trunk.
> Mikael, do you plan to commit your patch?
Thanks for the remainder.
I'm currently on something else, but I plan to do it during stage 3.
On Friday 01 October 2010 16:39:35 jvdelisle at gcc dot gnu.org wrote:
> 2010-10-01 14:39:23 UTC --- This look suspicious: valgrind on f951
>
No, it is unrelated. It happens on the most simple testcases like:
end
It can be circumvented by the following patch. But it is harmless (unrele
