[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2016-08-13 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #17 from Thomas Koenig  ---
Fixed on all open branches, closing.

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2016-08-13 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #16 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Aug 13 15:04:04 2016
New Revision: 239445

URL: https://gcc.gnu.org/viewcvs?rev=239445=gcc=rev
Log:
2016-08-13  Thomas Koenig  

Backport from trunk
PR fortran/68147
* frontend-passes.c (realloc_string_callback): Don't set
walk_subtrees.

2016-08-13  Thomas Koenig  

Backport from trunk
* gfortran.dg/realloc_on_assign_26.f90:  New test case.


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/realloc_on_assign_26.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/frontend-passes.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2016-08-11 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #15 from Thomas Koenig  ---
This is fixed on trunk and 6-branch (so it will be in the
next release).  5-branch still to do.

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2016-08-04 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #14 from Dominique d'Humieres  ---
> With one thing and another, I completely forgot about the backport.
> Yes, please do. I am not able to do commits fo the next week.

Upon further investigation revision r233797 caused the pr70040 regression. IMO
it would be better to fix the regression before doing the back port to the
gcc-5 branch.

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2016-07-30 Thread paul.richard.thomas at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #13 from paul.richard.thomas at gmail dot com  ---
Dear Dominique,

With one thing and another, I completely forgot about the backport.
Yes, please do. I am not able to do commits fo the next week.

Thanks

Paul

On 30 July 2016 at 11:26, dominiq at lps dot ens.fr
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147
>
> --- Comment #12 from Dominique d'Humieres  ---
>> When I have a moment, I intend to fix 5- and 6-branches.
>
> It would be nice to have it for the next releases. Do you want me to do the
> back port?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2016-07-30 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #12 from Dominique d'Humieres  ---
> When I have a moment, I intend to fix 5- and 6-branches.

It would be nice to have it for the next releases. Do you want me to do the
back port?

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2016-06-22 Thread paul.richard.thomas at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #11 from paul.richard.thomas at gmail dot com  ---
When I have a moment, I intend to fix 5- and 6-branches.

Cheers

Paul

On 22 June 2016 at 16:12, dominiq at lps dot ens.fr
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147
>
> --- Comment #10 from Dominique d'Humieres  ---
> Any reason why this PR is not closed as FIXED?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2016-06-22 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #10 from Dominique d'Humieres  ---
Any reason why this PR is not closed as FIXED?

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2016-02-28 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #9 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Feb 28 22:27:55 2016
New Revision: 233797

URL: https://gcc.gnu.org/viewcvs?rev=233797=gcc=rev
Log:
2016-02-28  Thomas Koenig  

PR fortran/68147
PR fortran/47674
* frontend-passes.c (realloc_string_callback): Don't set
walk_subtrees.

2016-02-28  Thomas Koenig  

PR fortran/68147
PR fortran/47674
* gfortran.dg/realloc_on_assign_26.f90:  New test case.


Added:
trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_26.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2016-02-17 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #8 from Thomas Koenig  ---
The fix for 47674 wasn't complete.

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2016-02-16 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

--- Comment #7 from Thomas Koenig  ---
Easy enough to fix; I think this one can still go into 6.0

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2016-02-16 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #6 from Thomas Koenig  ---
Here's a patch:

Index: frontend-passes.c
===
--- frontend-passes.c   (Revision 233410)
+++ frontend-passes.c   (Arbeitskopie)
@@ -153,7 +153,7 @@ gfc_run_passes (gfc_namespace *ns)
  */

 static int
-realloc_string_callback (gfc_code **c, int *walk_subtrees,
+realloc_string_callback (gfc_code **c, int *walk_subtrees ATTRIBUTE_UNUSED,
 void *data ATTRIBUTE_UNUSED)
 {
   gfc_expr *expr1, *expr2;
@@ -160,7 +160,6 @@ static int
   gfc_code *co = *c;
   gfc_expr *n;

-  *walk_subtrees = 0;
   if (co->op != EXEC_ASSIGN)
 return 0;

@@ -177,7 +176,7 @@ static int
 return 0;

   current_code = c;
-  n = create_var (expr2, "trim");
+  n = create_var (expr2, "realloc");
   co->expr2 = n;
   return 0;
 }

(The last part is to make the variable name more useful, that's all.)

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2016-02-16 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #5 from Thomas Koenig  ---
This is seriously strange.

Looking into this...

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2016-02-16 Thread mar...@mpa-garching.mpg.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #4 from Martin Reinecke  ---
Any progress on this?

I fear that this might affect quite many people once strings of allocatable
length become more popular in Fortran ... and I sure hope they will!

[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2015-10-29 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-29
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0). The following code

program test
  implicit none
  character(len=:),allocatable ::name, tmp
  name="./a.out"
  print *, name
  print *, name(3:)
  if (index(name,"/")  /=  0) THEN
tmp=name(3:)
!name=name(3:)
name=tmp
print *,name
  endif
end program

outputs

 ./a.out
 a.out
 a.out

so it seems the assignment "name=name(3:)" is missing a temporary.


[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2015-10-29 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #2 from Dominique d'Humieres  ---
If I use

print *, len(name), "'", name, "'"

I get

5 'a.o  '

> If I remove the if-statement, the code works as expected.

I see that too.


[Bug fortran/68147] Potential incorrect code generation for string self-assignment

2015-10-29 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147

--- Comment #3 from Dominique d'Humieres  ---
> If I use
>
> print *, len(name), "'", name, "'"
>
> I get
>
> 5 'a.o  '

AFAICT the length is always right and the number of characters replaced with a
space is equal to the number of characters skipped at the beginning of 'name':

  name="./a.out.dSYM"
...
name=name(5:)

gives

8 'out.'