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).