[Bug fortran/66089] New: elemental dependency mishandling when derived types are involved

[Bug fortran/66089] New: elemental dependency mishandling when derived types are involved

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089

            Bug ID: 66089
           Summary: elemental dependency mishandling when derived types
                    are involved
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mikael at gcc dot gnu.org
  Target Milestone: ---

This is a followup to pr65894.
We don't handle correctly the dependencies when elemental procedures and
derived types are involved.
Test:

  type :: t
    integer :: c
  end type t

  type(t), dimension(5) :: a, b, c

  a = t(1)
  b = t(7)
  c = t(13)
  c = plus(c(1), b)
  print *, c
  if (any(c%c /= 20)) call abort

contains

  elemental function plus(lhs, rhs)
    type(t), intent(in) :: lhs, rhs
    type(t)             :: plus
    plus%c = lhs%c + rhs%c
  end function plus

end

[Bug fortran/66089] elemental dependency mishandling when derived types are involved

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089

--- Comment #1 from Mikael Morin <mikael at gcc dot gnu.org> ---
Draft patch:

Index: trans-array.c
===================================================================
--- trans-array.c       (révision 222968)
+++ trans-array.c       (copie de travail)
@@ -2449,13 +2449,6 @@ gfc_scalar_elemental_arg_saved_as_reference (gfc_s
       && ss_info->expr->ts.type == BT_CLASS)
     return true;

-  /* If the expression is a data reference of aggregate type,
-     avoid a copy by saving a reference to the content.  */
-  if (ss_info->expr->expr_type == EXPR_VARIABLE
-      && (ss_info->expr->ts.type == BT_DERIVED
-         || ss_info->expr->ts.type == BT_CLASS))
-    return true;
-
   /* Otherwise the expression is evaluated to a temporary variable before the
      scalarization loop.  */
   return false;
>From gcc-bugs-return-485923-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat May 09 19:01:55 2015
Return-Path: <gcc-bugs-return-485923-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 84493 invoked by alias); 9 May 2015 19:01:54 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 84457 invoked by uid 48); 9 May 2015 19:01:51 -0000
From: "iains at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin
Date: Sat, 09 May 2015 19:01:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: iains at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61352-4-QmCTY7t3zk@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61352-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61352-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-05/txt/msg00763.txt.bz2
Content-length: 2449

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352

--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Joel Brobecker from comment #13)
> Sorry guys, but dsymutil is not working very well. I have a couple of
> examples where, either dsymutil is excluding some DIEs from the DWARF image,
> or where dsymutil actually segfaults. 

I think we all see this to some degree-or-other...

>There is also the fact that dsymutil
> doesn't know about recent DWARF enhancements, and doesn't work well when
> compiling code with -gno-strict-dwarf.

I think that's pretty much "not supported" with dsymutil; even the LLVM project
makes concessions to the need to support older DWARF output for OS X…  
I'd also wonder if it's 100% safe w.r.t ld64, and other items from the
DWARFutils package (although objdump & friends are pretty good for mach-o, they
are not a standard build for most folks).

however

>Since we do not control dsymutil and its quality level (or lack thereof), 

Yeah .. 'tis the one thing we can't fix at present...

… (let's cross fingers for llvm-dsymutil maturing quickly).

> GDB should be able to use the debug info from the object files without
> requiring the use of dsymutil. 

>I suggest the best course of action is
> trying to figure out why GDB doesn't pick the debugging info up from the .o
> files, and then fix that.

That's a good idea.
My experience is that it's quite variable, sometimes using GDB on the *.o works
better … sometimes the .dSYM works better.

> In the meantime, I suggest we revert this change, or else make it optional
> at the very least.

case 1. gcc  foo.o bar.o baz.o … <= should *not* invoke dsymutil - should work
"as expected" with the .o files.

case 2. gcc foo.o bar.o bad.c <= should invoke dsymutil.

In this case, you don't have baz.o, since it's a temporary file - so you can't
use it for debug (hence the secondary purpose of dsymutil).  You'd need
'save-temps' on the c/l to ensure this...

So we we could try amending the link spec to suppress the call of dsymutil if
"save-temps" is on the c/l?

I'm kinda in favour of this, since we *don't* have control over dsymutil and it
won't be fixed for darwin < bleeding edge even if a radar is filed - I assume
radar(s) have been filed for the issues?

> PS: Our experiments are on Darwin 13.4 and 14.3.

It's much the same across the board Darwin9+
>From gcc-bugs-return-485924-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat May 09 21:29:28 2015
Return-Path: <gcc-bugs-return-485924-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12409 invoked by alias); 9 May 2015 21:29:28 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 12366 invoked by uid 48); 9 May 2015 21:29:24 -0000
From: "aaron at aarongraham dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/58931] condition_variable::wait_until overflowed by large time_point<steady_clock>
Date: Sat, 09 May 2015 21:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: aaron at aarongraham dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-58931-4-0lgW8kaXCn@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58931-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58931-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-05/txt/msg00764.txt.bz2
Content-length: 1780

https://gcc.gnu.org/bugzilla/show_bug.cgi?idX931

Aaron Graham <aaron at aarongraham dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aaron at aarongraham dot com

--- Comment #3 from Aaron Graham <aaron at aarongraham dot com> ---
This is still a problem in current gcc trunk.

The bug is in the condition_variable::wait_until clock conversion. It doesn't
check for overflow in that math. Since the steady_clock and system_clock epochs
can be very different, it's likely to overflow with values much less than
max().

    template<typename _Clock, typename _Duration>
      cv_status
      wait_until(unique_lock<mutex>& __lock,
                 const chrono::time_point<_Clock, _Duration>& __atime)
      {
        // DR 887 - Sync unknown clock to known clock.
        const typename _Clock::time_point __c_entry = _Clock::now();
        const __clock_t::time_point __s_entry = __clock_t::now();
        const auto __delta = __atime - __c_entry;
        const auto __s_atime = __s_entry + __delta;

        return __wait_until_impl(__lock, __s_atime);
      }

I modified my version of gcc to use steady_clock as condition_variable's "known
clock" (__clock_t). This is more correct according to the C++ standard and most
importantly it makes condition_variable resilient to clock changes when used in
conjunction with steady_clock. Because of this, in my case, it works fine with
steady_clock::time_point::max(), but fails with
system_clock::time_point::max().

Because I made that change and since I don't do timed waits on system_clock
(which is unsafe), the overflow hasn't been a problem for me and I haven't
fixed it.

[Bug fortran/66089] elemental dependency mishandling when derived types are involved

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089

--- Comment #2 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 35513
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35513&action=edit
Patch v2

A patch that tries to avoid copies if possible.

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-05-12
                 CC|                            |vehre at gcc dot gnu.org
            Summary|elemental dependency        |[6 Regression] elemental
                   |mishandling when derived    |dependency mishandling when
                   |types are involved          |derived types are involved
     Ever confirmed|0                           |1

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The code in comment 0 does not abort at run time up to revision r222352
(2015-04-23), but does so at r222398 (2015-04-24), likely r222361.

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089

--- Comment #5 from vehre at gcc dot gnu.org ---
Let's have a look at the standard (F2008, 12.8.2, last sentence):

In the array case, the values of the elements, if any, of the result are
the same as would have been obtained if the scalar function had been applied
separately, in array element order, to corresponding elements of each array
actual argument.

How is this to be interpreted?

This way (pseudo-notation):

(c(i)= plus(c(1), b(i)), i = 1, size(c))

If like above, then the output would be

20, 27, 27, 27, 27

which is what is emitted, when the patch of comment #1 is not applied.

Or like this?

t = c(1)
(c(i) = plus(t, b(i)), i = 1, size(c))

which emits

20, 20, 20, 20, 20

But why is the second version expected, when one formulates this kind of
rhs/lhs dependency? I think the first example is covered by the standard, but I
am not happy with it, because it is not what I would expect, when writing the
code. 

So what do you think?
A third approach could be to add a warning for this kind of lhs/rhs dependency.
How hard would the analysis be?

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089

--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to vehre from comment #5)

For the interpretation of (intrinsic) assignment, you have to look at
7.2.1.3:

> The execution of the assignment shall have the same effect as if the
> evaluation of expr and the evaluation of all expressions in variable
> occurred before any portion of the variable is defined by the assignment

This, together with what you already quoted:

> Let's have a look at the standard (F2008, 12.8.2, last sentence):
> 
> In the array case, the values of the elements, if any, of the result are
> the same as would have been obtained if the scalar function had been applied
> separately, in array element order, to corresponding elements of each array
> actual argument.
> 

gives as interpretation:

(<result>(i)= plus(c(1), b(i)), i = 1, size(c))
(c(i) = <result>(i), i=1,size(c))

which gives the same result as your second interpretation.

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089

--- Comment #7 from vehre at gcc dot gnu.org ---
Ah, ok, which opens the question why that isn't done?

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089

--- Comment #9 from vehre at gcc dot gnu.org ---
That was a rhetorical question.

In the patch you submitted in comment #2 could you put a comment (in the
source) at:

Index: trans-array.c
===================================================================
--- trans-array.c       (révision 222968)
+++ trans-array.c       (copie de travail)
@@ -2451,7 +2451,8 @@ gfc_scalar_elemental_arg_saved_as_reference (gfc_s
@@ -4465,6 +4466,10 @@ gfc_conv_resolve_dependencies (gfc_loopinfo * loop

            nDepend = gfc_check_dependency (dest_expr, ss_expr, false);

<here>
+         if (ss->info->type == GFC_SS_REFERENCE
+             && gfc_check_dependency (dest_expr, ss_expr, false) == 1)
+           ss->info->data.scalar.need_temporary = 1;
+
          continue;
        }

what the reason for this check and set of the flag is? Now it is clear to us,
but in the future we might be wondering. 

Furthermore is the flag name "need_temporary" correct here? I think, that it
should have the polymorphic nature of its existence in its name. Like
"non_polymorphic_temp" or the like. 

I am still wondering whether there isn't a counterexample where this is not
working, i.e., we have lhs-rhs-dependency that is polymorphic. But because
assignment to (allocatable) polymorphic entities is not allowed, I could not
come up with one.
>From gcc-bugs-return-487049-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri May 22 09:33:23 2015
Return-Path: <gcc-bugs-return-487049-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 51858 invoked by alias); 22 May 2015 09:33:20 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 51802 invoked by uid 48); 22 May 2015 09:33:17 -0000
From: "ktkachov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/66241] [6 regression] [ARM] ICE: verify_type failed while building libstdc++ (dwarfout.c: gen_type_die_with_usage())
Date: Fri, 22 May 2015 09:33:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: ktkachov at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cf_reconfirmed_on cc
Message-ID: <bug-66241-4-KtDHWTeUPG@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66241-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66241-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-05/txt/msg01889.txt.bz2
Content-length: 491

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf241

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2015-05-21 00:00:00         |2015-5-22
                 CC|                            |ktkachov at gcc dot gnu.org

--- Comment #4 from ktkachov at gcc dot gnu.org ---
I'm seeing this as well (as it is blocking the arm-none-linux-gnueabihf build)

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |6.0

[Bug fortran/66089] [6 Regression] elemental dependency mishandling when derived types are involved

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66089

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4