[8/9/10 Regression] [PR87833] Intel MIC (emulated) offloading still broken

2019-11-11 Thread Thomas Schwinge
Hi!

On 2019-05-29T09:50:42-0600, Jeff Law  wrote:
> On 5/29/19 8:32 AM, Thomas Schwinge wrote:
>> On Thu, 9 May 2019 15:46:06 +0300, Ilya Verbin  wrote:
>>> I have left Intel 3 years ago. If you have any questions regarding MIC
>>> offloading, you can reach me by iver...@gmail.com
>> 
>> We're (a) looking for somebody to step up as a maintainer for that, and

That's still unresolved.

At the 2019 GNU Tools Cauldron, we discussed this topic in the OMP BoF,
and decided that despite its unmaintained status, we shall try to keep
GCC's Intel MIC (emulated) offloading support functional (at least until
any more complicated problems arise), because it might be useful for
Jakub once a year or so, for testing OMP changes.


>> (b) that person to get active, and take ownership of
>> , and review the proposed patch,
>> .
> My question would be where in the world is the -fno-pie stuff coming
> from.  It's also not clear where mkoffload is being called within c#5
> (presumably via the linker plugin) AFAICT we don't get the command line
> for that.  -v  or -Wl,-v probably would have helped.  It's difficult to
> know if HJ's patch is correct or not given the missing bits of information.
>
> But I'm willing to trust HJ here.  I'll ack the patch for the trunk.
> You or HJ can go ahead and install it.

I too have not made an attempt to really understand this problem and
solution.  See attached; as posted by H.J.,
,
I have now committed "[PR87833] x86: Put -fPIC and -shared the last to
create offload image" to trunk in r278041, gcc-9-branch in r278042,
gcc-8-branch in r278043.


> THe bigger question about the viability/usability of MIC is punted ;-)


Grüße
 Thomas


From 73e2538765507c373e1d7c14363094a2f6cf645a Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Mon, 11 Nov 2019 08:38:28 +
Subject: [PATCH] [PR87833] x86: Put -fPIC and -shared the last to create
 offload image

On x86, since -fPIC and -shared should be used to create offload image,
we put them the last to properly create offload image.

2019-11-11  H.J. Lu  

	PR target/87833
	* config/i386/intelmic-mkoffload.c (prepare_target_image): Put
	-fPIC and -shared the last to create offload image.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@278041 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog| 6 ++
 gcc/config/i386/intelmic-mkoffload.c | 5 +++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index ca0cebc20180..1b0145fbc787 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2019-11-11  H.J. Lu  
+
+	PR target/87833
+	* config/i386/intelmic-mkoffload.c (prepare_target_image): Put
+	-fPIC and -shared the last to create offload image.
+
 2019-11-11  Thomas Schwinge  
 
 	* gimplify.c (gimplify_scan_omp_clauses): Assert 'offset2' instead
diff --git a/gcc/config/i386/intelmic-mkoffload.c b/gcc/config/i386/intelmic-mkoffload.c
index 2a3e912ee74f..0b12edc72c14 100644
--- a/gcc/config/i386/intelmic-mkoffload.c
+++ b/gcc/config/i386/intelmic-mkoffload.c
@@ -453,8 +453,6 @@ prepare_target_image (const char *target_compiler, int argc, char **argv)
   if (verbose)
 obstack_ptr_grow (&argv_obstack, "-v");
   obstack_ptr_grow (&argv_obstack, "-xlto");
-  obstack_ptr_grow (&argv_obstack, "-shared");
-  obstack_ptr_grow (&argv_obstack, "-fPIC");
   obstack_ptr_grow (&argv_obstack, opt1);
   for (int i = 1; i < argc; i++)
 {
@@ -466,6 +464,9 @@ prepare_target_image (const char *target_compiler, int argc, char **argv)
   if (!out_obj_filename)
 fatal_error (input_location, "output file not specified");
   obstack_ptr_grow (&argv_obstack, opt2);
+  /* NB: Put -fPIC and -shared the last to create shared library.  */
+  obstack_ptr_grow (&argv_obstack, "-fPIC");
+  obstack_ptr_grow (&argv_obstack, "-shared");
   obstack_ptr_grow (&argv_obstack, "-o");
   obstack_ptr_grow (&argv_obstack, target_so_filename);
   compile_for_target (&argv_obstack);
-- 
2.17.1

From 22bf0cb640189880b683180d50b1e5b4b93e1fd9 Mon Sep 17 00:00:00 2001
From: tschwinge 
Date: Mon, 11 Nov 2019 08:39:10 +
Subject: [PATCH] [PR87833] x86: Put -fPIC and -shared the last to create
 offload image

On x86, since -fPIC and -shared should be used to create offload image,
we put them the last to properly create offload image.

2019-11-11  H.J. Lu  

	PR target/87833
	* config/i386/intelmic-mkoffload.c (prepare_target_image): Put
	-fPIC and -shared the last to create offload image.

Backport from trunk r278041.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-9-branch@278042 138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog| 7 +++
 gcc/config/i386/intelmic-mkoffload.c | 5 +++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index fc19dae278d4..8552

Re: GCC 7.5 Release Candidate available from gcc.gnu.org

2019-11-11 Thread Richard Biener
On Fri, 8 Nov 2019, Bill Schmidt wrote:

> On 11/7/19 5:48 AM, Matthias Klose wrote:
> > On 05.11.19 13:45, Richard Biener wrote:
> >>
> >> The first release candidate for GCC 7.5 is available from
> >>
> >>   https://gcc.gnu.org/pub/gcc/snapshots/7.5.0-RC-20191105/
> >>
> >> and shortly its mirrors.  It has been generated from SVN revision 277823.
> >>
> >> I have so far bootstrapped and tested the release candidate on
> >> {x86_64,i586,ppc64le,s390x,aarch64}-linux.  Please test it
> >> and report any issues to bugzilla.
> >>
> >> If all goes well, I'd like to release 7.5 on Thursday, November 14th.
> >
> > With a distribution build (Ubuntu) on amd64, i386, armhf, arm64, ppc64el and
> > s390x, I don't see any regressions in the GCC testsuite (compared to 7.4.0),
> > except for two issues on ppc64el:
> >
> > FAIL: gcc.target/powerpc/pr87532.c (test for excess errors)
> > Excess errors:
> > /build/gcc-7-8odB_r/gcc-7-7.4.0/src/gcc/testsuite/gcc.target/powerpc/pr87532.c:45:27:
> > warning: format '%d' expects argument of type 'int', but argument 2 has type
> > 'size_t {aka long unsigned int}' [-Wformat=]
> >
> > is a new test, and only caused by default hardening settings.
> >
> > PASS: gcc.dg/vect/slp-perm-4.c execution test
> > FAIL: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "vectorized 1 
> > loops" 1
> > PASS: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "gaps requires
> > scalar epilogue loop" 0
> > FAIL: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "vectorizing 
> > stmts using SLP" 1
> 
> 
> I finally bisected this to r275208:
> 
> 
> 2019-08-30  Richard Biener  mailto:rguenther%40suse.de>>
> 
>   Backport from mainline
>   2019-05-27  Richard Biener >
> 
>   PR tree-optimization/90637
>   * tree-ssa-sink.c (statement_sink_location): Honor the
>   computed sink location for single-uses.
> 
>   * gcc.dg/gomp/pr90637.c: New testcase.
> 
>   2019-06-21  Richard Biener   >
> 
>   PR tree-optimization/90930
>   * tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited
>   flag on new stmts to avoid re-processing them.
> 
>   2019-05-15  Richard Biener   >
> 
>   PR c/90474
>   * c-common.c (c_common_mark_addressable_vec): Also mark
>   a COMPOUND_LITERAL_EXPR_DECL addressable similar to
>   c_mark_addressable.
> 
>   2019-04-25  Richard Biener   >
> 
>   PR middle-end/90194
>   * match.pd: Add pattern to simplify view-conversion of an
>   empty constructor.
> 
>   * g++.dg/torture/pr90194.C: New testcase.
> 
>   2019-04-24  Richard Biener   >
> 
>   PR middle-end/90213
>   * gimple-fold.c (fold_const_aggregate_ref_1): Do multiplication
>   by size and BITS_PER_UNIT on poly-wide-ints.
> 
>   2019-04-15  Richard Biener   >
> 
>   PR tree-optimization/90071
>   * tree-ssa-reassoc.c (init_range_entry): Do not pick up
>   abnormal operands from def stmts.
> 
>   * gcc.dg/torture/pr90071.c: New testcase.
> 
>   2019-03-13  Richard Biener   >
> 
>   PR middle-end/89677
>   * tree-scalar-evolution.c (simplify_peeled_chrec): Do not
>   throw FP expressions at tree-affine.
> 
>   * gcc.dg/torture/pr89677.c: New testcase.
> 
> 
> This looks rather familiar, actually.  I seem to recall an SLP degradation
> from a change to tree-ssa-sink.c on trunk this release.  Richi, could there be
> a missing backport here?

Not sure - it's reassoc that messes up things here and a
--param tree-reassoc-width=1 "fixes" the failure.  For PR90930 I
restricted this to the last pass instance (but only on trunk).
Does it also fail on the GCC 8 and 9 branches?  Ah, on GCC 8 at least
the default target setting for this seems to be 1 (it's non-FP,
maybe you changed that), with explicit --param tree-reassoc-width={2,3,4}
it also fails the same way.

It's a bit late to try thinking about backporting this change
but I'll now consider it for GCC 9 at least.

So IMHO a latent issue, somehow the rev. triggered "inconsistent"
reassoc for the testcase.  I'm going to leave it as-is for GCC 7.5
(with the testsuite regression).

Are you fine with that?  An explicit --param tree-reassoc-width=1
on the testcase also would work for me if you prefer that.

Thanks,
Richard.

Re: GCC 7.5 Release Candidate available from gcc.gnu.org

2019-11-11 Thread Bill Schmidt

On 11/11/19 7:26 AM, Richard Biener wrote:

On Fri, 8 Nov 2019, Bill Schmidt wrote:


On 11/7/19 5:48 AM, Matthias Klose wrote:

On 05.11.19 13:45, Richard Biener wrote:

The first release candidate for GCC 7.5 is available from

   https://gcc.gnu.org/pub/gcc/snapshots/7.5.0-RC-20191105/

and shortly its mirrors.  It has been generated from SVN revision 277823.

I have so far bootstrapped and tested the release candidate on
{x86_64,i586,ppc64le,s390x,aarch64}-linux.  Please test it
and report any issues to bugzilla.

If all goes well, I'd like to release 7.5 on Thursday, November 14th.

With a distribution build (Ubuntu) on amd64, i386, armhf, arm64, ppc64el and
s390x, I don't see any regressions in the GCC testsuite (compared to 7.4.0),
except for two issues on ppc64el:

FAIL: gcc.target/powerpc/pr87532.c (test for excess errors)
Excess errors:
/build/gcc-7-8odB_r/gcc-7-7.4.0/src/gcc/testsuite/gcc.target/powerpc/pr87532.c:45:27:
warning: format '%d' expects argument of type 'int', but argument 2 has type
'size_t {aka long unsigned int}' [-Wformat=]

is a new test, and only caused by default hardening settings.

PASS: gcc.dg/vect/slp-perm-4.c execution test
FAIL: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "vectorized 1
loops" 1
PASS: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "gaps requires
scalar epilogue loop" 0
FAIL: gcc.dg/vect/slp-perm-4.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1


I finally bisected this to r275208:


2019-08-30  Richard Biener  mailto:rguenther%40suse.de>>

Backport from mainline
2019-05-27  Richard Biener  mailto:rguenther%40suse.de>>

PR tree-optimization/90637
* tree-ssa-sink.c (statement_sink_location): Honor the
computed sink location for single-uses.

* gcc.dg/gomp/pr90637.c: New testcase.

2019-06-21  Richard Biener  mailto:rguenther%40suse.de>>

PR tree-optimization/90930
* tree-ssa-reassoc.c (rewrite_expr_tree_parallel): Set visited
flag on new stmts to avoid re-processing them.

2019-05-15  Richard Biener  mailto:rguenther%40suse.de>>

PR c/90474
* c-common.c (c_common_mark_addressable_vec): Also mark
a COMPOUND_LITERAL_EXPR_DECL addressable similar to
c_mark_addressable.

2019-04-25  Richard Biener  mailto:rguenther%40suse.de>>

PR middle-end/90194
* match.pd: Add pattern to simplify view-conversion of an
empty constructor.

* g++.dg/torture/pr90194.C: New testcase.

2019-04-24  Richard Biener  mailto:rguenther%40suse.de>>

PR middle-end/90213
* gimple-fold.c (fold_const_aggregate_ref_1): Do multiplication
by size and BITS_PER_UNIT on poly-wide-ints.

2019-04-15  Richard Biener  mailto:rguenther%40suse.de>>

PR tree-optimization/90071
* tree-ssa-reassoc.c (init_range_entry): Do not pick up
abnormal operands from def stmts.

* gcc.dg/torture/pr90071.c: New testcase.

2019-03-13  Richard Biener  mailto:rguenther%40suse.de>>

PR middle-end/89677
* tree-scalar-evolution.c (simplify_peeled_chrec): Do not
throw FP expressions at tree-affine.

* gcc.dg/torture/pr89677.c: New testcase.


This looks rather familiar, actually.  I seem to recall an SLP degradation
from a change to tree-ssa-sink.c on trunk this release.  Richi, could there be
a missing backport here?

Not sure - it's reassoc that messes up things here and a
--param tree-reassoc-width=1 "fixes" the failure.  For PR90930 I
restricted this to the last pass instance (but only on trunk).
Does it also fail on the GCC 8 and 9 branches?  Ah, on GCC 8 at least
the default target setting for this seems to be 1 (it's non-FP,
maybe you changed that), with explicit --param tree-reassoc-width={2,3,4}
it also fails the same way.



OK; yes, I think one of our team did some refining of the reassoc 
parameters in that timeframe, so this makes sense.




It's a bit late to try thinking about backporting this change
but I'll now consider it for GCC 9 at least.

So IMHO a latent issue, somehow the rev. triggered "inconsistent"
reassoc for the testcase.  I'm going to leave it as-is for GCC 7.5
(with the testsuite regression).

Are you fine with that?  An explicit --param tree-reassoc-width=1
on the testcase also would work for me if you prefer that.



I am fine with leaving the testcase regressed; we have a good 
explanation and this isn't a serious issue for users.  Thanks for 
investigating!


Bill



Thanks,
Richard.


Re: Hello, I would like to know how to download gcc 9.2 in windows from here. https://ftp.gnu.org/gnu/gcc/gcc-9.2.0/ Thanks.

2019-11-11 Thread Gerald Pfeifer
On Tue, 5 Nov 2019, Aditya Guharoy wrote:
> I would like to know how to download gcc 9.2 in windows from here.
> https://ftp.gnu.org/gnu/gcc/gcc-9.2.0/

We distribute source code, that in turn can then be built for
various platforms (such as Windows).

If you enter "gcc windows binary" in your favorite search engine,
you should find pre-built binary downloads.

Gerald

PS: Questions like this are better addressed to gcc-h...@gcc.gnu.org;
gcc@gcc.gnu.org is for the development of GCC.