public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libgomp/71959] [OpenACC] #pragma acc parallel leads to segfault in x86_64-pc-linux-gnu-accel-nvptx-none-gcc
       [not found] <bug-71959-4@http.gcc.gnu.org/bugzilla/>
@ 2016-08-25 13:37 ` nathan at gcc dot gnu.org
  2021-05-04 12:19 ` [Bug lto/71959] [OpenACC] lto1: ICE in inline_read_section, at ipa-fnsummary.c:3314 rguenth at gcc dot gnu.org
  1 sibling, 0 replies; 2+ messages in thread
From: nathan at gcc dot gnu.org @ 2016-08-25 13:37 UTC (permalink / raw)
  To: gcc-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 10125 bytes --]

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

Nathan Sidwell <nathan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |nathan at gcc dot gnu.org

--- Comment #6 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
The code is ill-formed, for (at least) 3 reasons:

1) only one of the member functions is marked as 'acc routine', before being
called in an offloaded region. the 'pi' function is marked, but the iterator
members, _DummyRed member and the function invoker are not.

2) the loop itself does not contain independent iterations

3) the 'copy(__thread_results[1]...) is copying a single element array, but
then indexing it incorrectly.

Now, openacc doesn't appear to provide any mechanism for marking (say) all the
member fns of a class as routines, and apparently in-class use of 'pragma acc
routine' is not permitted.

Openacc  doesn't appear to address non-pod data objects or member functions.
Let alone the complexities of using the STL.

The compiler shouldn't blow up of course ...
>From gcc-bugs-return-535901-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 25 14:25:07 2016
Return-Path: <gcc-bugs-return-535901-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 123949 invoked by alias); 25 Aug 2016 14:25:06 -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 120127 invoked by uid 55); 25 Aug 2016 14:24:53 -0000
From: "wschmidt at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/72863] Powerpc64le: redundant swaps when using vec_vsx_ld/st
Date: Thu, 25 Aug 2016 14:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 7.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: wschmidt at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: wschmidt at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-72863-4-iu6kSZVLH4@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-72863-4@http.gcc.gnu.org/bugzilla/>
References: <bug-72863-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: 2016-08/txt/msg03237.txt.bz2
Content-length: 1033

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

--- Comment #7 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Author: wschmidt
Date: Thu Aug 25 14:24:17 2016
New Revision: 239761

URL: https://gcc.gnu.org/viewcvs?rev=239761&root=gcc&view=rev
Log:
[gcc]

2016-08-25  Bill Schmidt  <wschmidt@linux.vnet.ibm.com>

        Backport from mainline
        2016-08-11  Bill Schmidt  <wschmidt@linux.vnet.ibm.com>

        PR target/72863
        * vsx.md (vsx_load_<mode>): For P8LE, emit swaps at expand time.
        (vsx_store_<mode>): Likewise.

[gcc/testsuite]

2016-08-25  Bill Schmidt  <wschmidt@linux.vnet.ibm.com>

        Backport from mainline
        2016-08-11  Bill Schmidt  <wschmidt@linux.vnet.ibm.com>

        PR target/72863
        * gcc.target/powerpc/pr72863.c: New test.


Added:
    branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr72863.c
Modified:
    branches/gcc-6-branch/gcc/ChangeLog
    branches/gcc-6-branch/gcc/config/rs6000/vsx.md
    branches/gcc-6-branch/gcc/testsuite/ChangeLog
>From gcc-bugs-return-535902-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Aug 25 14:43:47 2016
Return-Path: <gcc-bugs-return-535902-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 71064 invoked by alias); 25 Aug 2016 14:43:47 -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 71051 invoked by uid 89); 25 Aug 2016 14:43:46 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.3 required=5.0 testsºYES_00,KAM_ASCII_DIVIDERS,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammyX-HELO: mx1.redhat.com
Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 25 Aug 2016 14:43:44 +0000
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26])	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))	(No client certificate requested)	by mx1.redhat.com (Postfix) with ESMTPS id 8E226201FA;	Thu, 25 Aug 2016 14:43:43 +0000 (UTC)
Received: from [10.36.7.117] (vpn1-7-117.ams2.redhat.com [10.36.7.117])	by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7PEhexp025359	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits%6 verify=NO);	Thu, 25 Aug 2016 10:43:42 -0400
Subject: Re: ia64-elf and i386-elf fail to build
To: Joseph Myers <joseph@codesourcery.com>, wilson@tuliptree.org,        sellcey@imgtec.com, hubicka@ucw.cz, ubizjak@gmail.com
References: <87oa4huj3o.fsf@redhat.com> <alpine.DEB.2.20.1608251252120.5284@digraph.polyomino.org.uk>
Cc: gcc-bugs@gcc.gnu.org
From: Nick Clifton <nickc@redhat.com>
Message-ID: <7502a0c2-e9c5-feda-6134-7eb70b6b1540@redhat.com>
Date: Thu, 25 Aug 2016 14:43:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.1608251252120.5284@digraph.polyomino.org.uk>
Content-Type: multipart/mixed; boundary="------------F2BEFB2839EF6C46A365D47D"
X-SW-Source: 2016-08/txt/msg03238.txt.bz2

This is a multi-part message in MIME format.
--------------F2BEFB2839EF6C46A365D47D
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Content-length: 1210

Hi Guys,

> I think this indicates that i386 and ia64 need their own local version of
> float128_type_node, set up like float80_type_node (i.e. copied from the
> global one if that isn't NULL, otherwise set up locally) instead of using
> the global one unconditionally, because of the existence of i386 and ia64
> targets where the TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P hook can return
> false for TFmode (in which case __float128 still exists, but not
> _Float128).

OK - that I can do.

> Though preferable would be to fix all the targets with
> IX86_NO_LIBGCC_TFMODE / IX86_MAYBE_NO_LIBGCC_TFMODE /
> IA64_NO_LIBGCC_TFMODE so that they include the relevant support code in
> libgcc and so no longer need the TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P
> hook overridden at all.

I would prefer to leave this to the maintainers as I do not want to get target
greping wrong.

So - Jan, Uros, Jim, Steve - are these ia64 and i386 backend patches OK ?

Cheers
  Nick

gcc/ChangeLog
2016-08-25  Nick Clifton  <nickc@redhat.com>

	* config/ia64/ia64.c (ia64_init_builtins): Initialise the
	float128_type_node if that has not been done already.
	* config/i386/i386.c (ix86_init_builtin_types): Likewise.


--------------F2BEFB2839EF6C46A365D47D
Content-Type: text/x-patch;
 name="float128.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="float128.patch"
Content-length: 1825

Index: gcc/config/i386/i386.c
==================================================================--- gcc/config/i386/i386.c	(revision 239761)
+++ gcc/config/i386/i386.c	(working copy)
@@ -33341,9 +33341,19 @@
     }
   lang_hooks.types.register_builtin_type (float80_type_node, "__float80");

-  /* The __float128 type.  The node has already been created as
-     _Float128, so we only need to register the __float128 name for
-     it.  */
+  /* The __float128 type.  If TFmode is supported by libgcc then the node
+     has already been created as _Float128, so we only need to register the
+     __float128 name for  it.  Otherwise we have to create the float128
+     type first.  */
+#if defined IX86_NO_LIBGCC_TFMODE || defined IX86_MAYBE_NO_LIBGCC_TFMODE
+  if (float128_type_node == NULL)
+    {
+      float128_type_node = make_node (REAL_TYPE);
+      TYPE_PRECISION (float128_type_node) = 128;
+      layout_type (float128_type_node);
+      SET_TYPE_MODE (float128_type_node, TFmode);
+    }
+#endif
   lang_hooks.types.register_builtin_type (float128_type_node, "__float128");

   const_string_type_node
Index: gcc/config/ia64/ia64.c
==================================================================--- gcc/config/ia64/ia64.c	(revision 239761)
+++ gcc/config/ia64/ia64.c	(working copy)
@@ -10368,6 +10368,13 @@
       tree const_string_type
 	= build_pointer_type (build_qualified_type
 			      (char_type_node, TYPE_QUAL_CONST));
+#ifdef IA64_NO_LIBGCC_TFMODE
+      gcc_assert (float128_type_node == NULL);
+      float128_type_node = make_node (REAL_TYPE);
+      TYPE_PRECISION (float128_type_node) = 128;
+      layout_type (float128_type_node);
+      SET_TYPE_MODE (float128_type_node, TFmode);
+#endif

       (*lang_hooks.types.register_builtin_type) (float128_type_node,
 						 "__float128");

--------------F2BEFB2839EF6C46A365D47D--


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

* [Bug lto/71959] [OpenACC] lto1: ICE in inline_read_section, at ipa-fnsummary.c:3314
       [not found] <bug-71959-4@http.gcc.gnu.org/bugzilla/>
  2016-08-25 13:37 ` [Bug libgomp/71959] [OpenACC] #pragma acc parallel leads to segfault in x86_64-pc-linux-gnu-accel-nvptx-none-gcc nathan at gcc dot gnu.org
@ 2021-05-04 12:19 ` rguenth at gcc dot gnu.org
  1 sibling, 0 replies; 2+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-05-04 12:19 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW

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

end of thread, other threads:[~2021-05-04 12:19 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-71959-4@http.gcc.gnu.org/bugzilla/>
2016-08-25 13:37 ` [Bug libgomp/71959] [OpenACC] #pragma acc parallel leads to segfault in x86_64-pc-linux-gnu-accel-nvptx-none-gcc nathan at gcc dot gnu.org
2021-05-04 12:19 ` [Bug lto/71959] [OpenACC] lto1: ICE in inline_read_section, at ipa-fnsummary.c:3314 rguenth 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).