public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/53642] New: Front-end optimization: Wrong string length for deferred-length strings
@ 2012-06-12  8:09 burnus at gcc dot gnu.org
  2012-06-12 15:52 ` [Bug fortran/53642] " burnus at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-06-12  8:09 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53642

             Bug #: 53642
           Summary: Front-end optimization: Wrong string length for
                    deferred-length strings
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org
                CC: damian@rouson.net, tkoenig@gcc.gnu.org


As reported by Damian Rouson at
http://gcc.gnu.org/ml/fortran/2012-06/msg00069.html

Without optimization, the following program prints - and should print:
           3           3

However, with -ffrontend-optimize the result is, wrongly,
           3           4

Damian: Use -fno-frontend-optimize as work-around.

character(len=4) :: string="123 "
character(:), allocatable :: trimmed
trimmed = trim(string)
print *,len_trim(string),len(trimmed)
end


>From the original dump:

(a) Without FE optimization
        _gfortran_string_trim (&len.1, (void * *) &pstr.0, 4, &string);
        D.1864 = len.1;
        if (trimmed != 0B) goto L.1;
        trimmed = (character(kind=1)[1:.trimmed] *)
                       __builtin_malloc ((sizetype) len.1);
        ...
        .trimmed = len.1;

(b) With FE optimization
        if (trimmed != 0B) goto L.1;
        trimmed = (character(kind=1)[1:.trimmed] *) __builtin_malloc (4);
        ...
        .trimmed = 4;


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug fortran/53642] Front-end optimization: Wrong string length for deferred-length strings
  2012-06-12  8:09 [Bug fortran/53642] New: Front-end optimization: Wrong string length for deferred-length strings burnus at gcc dot gnu.org
@ 2012-06-12 15:52 ` burnus at gcc dot gnu.org
  2012-06-16 18:13 ` burnus at gcc dot gnu.org
  2012-06-16 18:16 ` burnus at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-06-12 15:52 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53642

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-06-12 15:52:34 UTC ---
I was thinking about the following patch - namely, doing in optimize_assignment
the remove_trim only if "!lhs->ts.deferred".

 * * *

However, that does not work; seemingly,  a = trim(b) is replaced by
   a = b(1:len_trim(b))  in such a way, that  len(a) == 0  instead of 3.

The same issue occurs for a manual:
   trimmed = string(1:len_trim(string))

Thus, the follow-up issue is not a FE optimization issue but rather a trans*.c
issue. The generated code is [some casting removed]:

        trimmed = __builtin_malloc (MAX_EXPR <NON_LVALUE_EXPR <D.1861>, 0>);

        .trimmed = MAX_EXPR <NON_LVALUE_EXPR <D.1861>, 0>;

        D.1861 = _gfortran_string_len_trim (4, &string);

Which shows the wrong ordering, similar to bug 45170 comment 34, which is fixed
by the patch at bug 45170 comment 34. That patch also solves the len_trim issue
above.


--- a/gcc/fortran/frontend-passes.c
+++ b/gcc/fortran/frontend-passes.c
@@ -738 +738 @@ optimize_assignment (gfc_code * c)
-  if (lhs->ts.type == BT_CHARACTER)
+  if (lhs->ts.type == BT_CHARACTER && !lhs->ts.deferred)
@@ -740 +740 @@ optimize_assignment (gfc_code * c)
-      /* Optimize away a = trim(b), where a is a character variable.  */
+      /* Optimize  a = trim(b)  to  a = b.  */
@@ -743,4 +743,2 @@ optimize_assignment (gfc_code * c)
-      /* Replace a = '   ' by a = '' to optimize away a memcpy, but only
-        for strings with non-deferred length (otherwise we would
-        reallocate the length.  */
-      if (empty_string(rhs) && ! lhs->ts.deferred)
+      /* Replace a = '   ' by a = '' to optimize away a memcpy.  */
+      if (empty_string(rhs))
@@ -1174 +1172 @@ optimize_trim (gfc_expr *e)
-  /* Build the function call to len_trim(x, gfc_defaul_integer_kind).  */
+  /* Build the function call to len_trim(x, gfc_default_integer_kind).  */


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug fortran/53642] Front-end optimization: Wrong string length for deferred-length strings
  2012-06-12  8:09 [Bug fortran/53642] New: Front-end optimization: Wrong string length for deferred-length strings burnus at gcc dot gnu.org
  2012-06-12 15:52 ` [Bug fortran/53642] " burnus at gcc dot gnu.org
@ 2012-06-16 18:13 ` burnus at gcc dot gnu.org
  2012-06-16 18:16 ` burnus at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-06-16 18:13 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53642

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-06-16 18:13:43 UTC ---
Author: burnus
Date: Sat Jun 16 18:13:38 2012
New Revision: 188692

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188692
Log:
2012-06-16  Tobias Burnus  <burnus@net-b.de>

        PR fortran/53642
        PR fortran/45170
        * frontend-passes.c (optimize_assignment): Don't remove RHS's
        trim when assigning to a deferred-length string.
        * trans-expr.c (gfc_trans_assignment_1): Ensure that the RHS string
        length is evaluated before the deferred-length LHS is reallocated.

2012-06-16  Tobias Burnus  <burnus@net-b.de>

        PR fortran/53642
        PR fortran/45170
        * gfortran.dg/deferred_type_param_8.f90: New.


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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug fortran/53642] Front-end optimization: Wrong string length for deferred-length strings
  2012-06-12  8:09 [Bug fortran/53642] New: Front-end optimization: Wrong string length for deferred-length strings burnus at gcc dot gnu.org
  2012-06-12 15:52 ` [Bug fortran/53642] " burnus at gcc dot gnu.org
  2012-06-16 18:13 ` burnus at gcc dot gnu.org
@ 2012-06-16 18:16 ` burnus at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-06-16 18:16 UTC (permalink / raw)
  To: gcc-bugs

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53642

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-06-16 18:16:45 UTC ---
FIXED on the trunk (4.8).

Damian: Thanks for the bug report!


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-06-16 18:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-12  8:09 [Bug fortran/53642] New: Front-end optimization: Wrong string length for deferred-length strings burnus at gcc dot gnu.org
2012-06-12 15:52 ` [Bug fortran/53642] " burnus at gcc dot gnu.org
2012-06-16 18:13 ` burnus at gcc dot gnu.org
2012-06-16 18:16 ` burnus at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).