On 05/11/16 12:02, Thomas Schwinge wrote:
I conceptually agree to that. (If we're serious about that, then we can
remove more code, such as the legacy libgomp entry point itself -- a
"missing symbol: [...]" is still vaguely better than a SIGSEGV.) Yet,
what I fixed here, is just what Jakub and
On 05/11/2016 06:02 PM, Thomas Schwinge wrote:
I conceptually agree to that. (If we're serious about that, then we can
remove more code, such as the legacy libgomp entry point itself -- a
"missing symbol: [...]" is still vaguely better than a SIGSEGV.) Yet,
what I fixed here, is just what Jakub
Hi!
On Wed, 11 May 2016 11:38:39 -0400, Nathan Sidwell wrote:
> On 05/11/16 10:22, Bernd Schmidt wrote:
> > On 05/11/2016 03:46 PM, Thomas Schwinge wrote:
> >>> What we now got, doesn't work, for several reasons. GCC 5 OpenACC
> >>> offloading executables will just run into SIGSEGV.
> >
> > I'm
On 05/11/16 10:22, Bernd Schmidt wrote:
On 05/11/2016 03:46 PM, Thomas Schwinge wrote:
What we now got, doesn't work, for several reasons. GCC 5 OpenACC
offloading executables will just run into SIGSEGV.
I'm tempted to say, let's just wait until someone actually reports that in
bugzilla. Offl
On 05/11/2016 03:46 PM, Thomas Schwinge wrote:
What we now got, doesn't work, for several reasons. GCC 5 OpenACC
offloading executables will just run into SIGSEGV.
I'm tempted to say, let's just wait until someone actually reports that
in bugzilla. Offloading in gcc-5 was broken enough that I
o avoid 6.1
> users running into the SIGSEGV), or delay for 6.2?
>
> We don't have an easy way to add test cases to make sure we don't break
> such legacy interfaces, do we? (So, I just manually checked a few test
> cases.)
>
> commit c6
few test
cases.)
commit c68c6b8e79176f5dc21684efe2517cbfb83a182e
Author: Thomas Schwinge
Date: Wed Apr 20 13:08:57 2016 +0200
libgomp: Make GCC 5 OpenACC offloading executables work
* libgomp.h: Include "openacc.h".
(goacc_get_device_type_201, g