Re: gcc 8.1 + libc.a
Please don't cross-post to both gcc@gcc.gnu.org and gcc-h...@gcc.gnu.org, it is almost never appropriate to send the same email to both lists, because they are for discussing different topics. You're looking for help, so use gcc-help not gcc. Please remove gcc@gcc.gnulorg from further replies in this thread, thanks
Old options in self tests?
My builds from HEAD are failing unless I remove these tests. Are these invalid tests? diff --git a/gcc/opt-suggestions.c b/gcc/opt-suggestions.c index 9444a35cb54..e64ee7e5660 100644 --- a/gcc/opt-suggestions.c +++ b/gcc/opt-suggestions.c @@ -264,8 +264,6 @@ test_completion_valid_options (option_proposer &proposer) "-Wno-format-contains-nul", "-Wnamespaces", "-fisolate-erroneous-paths-attribute", -"-Wno-underflow", -"-Wtarget-lifetime", "--param=asan-globals", "-Wno-empty-body", "-Wno-odr", @@ -273,7 +271,6 @@ test_completion_valid_options (option_proposer &proposer) "-Wstringop-truncation", "-fno-ipa-vrp", "-fmath-errno", -"-Warray-temporaries", "-Wno-unused-label", "-Wreturn-local-addr", "--param=sms-dfa-history", AG
Re: Old options in self tests?
On 10/4/18 6:05 AM, Anthony Green wrote: > > My builds from HEAD are failing unless I remove these tests. Are these > invalid tests? > > diff --git a/gcc/opt-suggestions.c b/gcc/opt-suggestions.c > index 9444a35cb54..e64ee7e5660 100644 > --- a/gcc/opt-suggestions.c > +++ b/gcc/opt-suggestions.c > @@ -264,8 +264,6 @@ test_completion_valid_options (option_proposer &proposer) > "-Wno-format-contains-nul", > "-Wnamespaces", > "-fisolate-erroneous-paths-attribute", > -"-Wno-underflow", > -"-Wtarget-lifetime", > "--param=asan-globals", > "-Wno-empty-body", > "-Wno-odr", > @@ -273,7 +271,6 @@ test_completion_valid_options (option_proposer &proposer) > "-Wstringop-truncation", > "-fno-ipa-vrp", > "-fmath-errno", > -"-Warray-temporaries", > "-Wno-unused-label", > "-Wreturn-local-addr", > "--param=sms-dfa-history", > > AG > They're Fortran specific options. I'm not sure how that impacts your tests though. jeff
Re: Thomas Schwinge appointed OpenACC Maintainer
Hi! On Thu, 20 Sep 2018 10:11:36 -0400, David Edelsohn wrote: > I am pleased to announce that the GCC Steering Committee has > appointed Thomas Schwinge as OpenACC Maintainer. Thanks for your trust, after all these years. I'm happy to accept, and will of course (continue to) work closely and cooperatively with the other maintainers and generally contributors. I'm just returning from a multi-month parental leave :-) so I'll still need a bit of time to catch up with everything, before I can start to maintain, and review proposed changes. Committed to trunk in r264848: commit 042674a54a7346611e789789cdd4bb3194c3211d Author: tschwinge Date: Thu Oct 4 15:50:34 2018 + List myself as "libgomp (OpenACC)" and "OpenACC" maintainer * MAINTAINERS: List myself as "libgomp (OpenACC)" and "OpenACC" maintainer. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@264848 138bc75d-0d04-0410-961f-82ee72b054a4 --- ChangeLog | 5 + MAINTAINERS | 2 ++ 2 files changed, 7 insertions(+) diff --git ChangeLog ChangeLog index 97fd95897c12..2623abd4a9f3 100644 --- ChangeLog +++ ChangeLog @@ -1,3 +1,8 @@ +2018-10-04 Thomas Schwinge + + * MAINTAINERS: List myself as "libgomp (OpenACC)" and "OpenACC" + maintainer. + 2018-09-13 Matthew Malcomson * MAINTAINERS (Write After Approval): Add self. diff --git MAINTAINERS MAINTAINERS index 4c0c30a743cb..e478d3b2dba1 100644 --- MAINTAINERS +++ MAINTAINERS @@ -165,6 +165,7 @@ libdecnumberBen Elliston libgcc Ian Lance Taylor libgo Ian Lance Taylor libgompJakub Jelinek +libgomp (OpenACC) Thomas Schwinge libiberty Ian Lance Taylor libitm Torvald Riegel libobjcNicola Pero @@ -236,6 +237,7 @@ auto-vectorizer Zdenek Dvorak loop infrastructureZdenek Dvorak loop ivoptsBin Cheng loop optimizer Bin Cheng +OpenACCThomas Schwinge OpenMP Jakub Jelinek testsuite Rainer Orth testsuite Mike Stump Grüße Thomas
Videos for GNU Tools Cauldron 2018
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I am pleased to announce that the videos for the GNU Tools Cauldron are now available on the wiki: https://gcc.gnu.org/wiki/cauldron2018 For those who prefer their videos as a playlist, it is available here: https://www.youtube.ca/playlist?list=PLOGTP9W1DX5VSSCvk_OApXX_Zil1F87s- Look forward to seeing you all again at Cauldron 2019. Jeremy - -- Tel: +44 (1590) 610184 Cell:+44 (7970) 676050 SkypeID: jeremybennett Twitter: @jeremypbennett Email: jeremy.benn...@embecosm.com Web: www.embecosm.com PGP key: 1024D/BEF58172FB4754E1 2009-03-20 -BEGIN PGP SIGNATURE- iEYEARECAAYFAlu2N0oACgkQvvWBcvtHVOGgkQCdEIzpNclrZ3263Oxwln01upXf 3jgAnjY6uhxALpSt828xllqLbDYVDTT0 =3MwR -END PGP SIGNATURE-
Re: Old options in self tests?
Jeff Law writes: > They're Fortran specific options. I'm not sure how that impacts your > tests though. Thanks Jeff. I figured this out now. I was building a C compiler from a source tree that does not include the sources for the fortran front-end. It seems that this is no longer supported, and the fortran sources must be available even if you're only building C/C++. I'll stop stripping out gcc/fortran, but I'm wondering if anybody else considers this a misfeature. AG
LP64, unsigned int, vectorization, and PR 61247
I was looking at PR tree-optimization/61247, where a loop with an unsigned
int index on an LP64 platform was not getting vectorized and I noticed an
odd thing. In the function below, if I define N as 1000 or 1, the
loop does get vectorized, even in LP64 mode. But if I define N as 10,
the loop does not get vectorized in LP64 mode. I have not been able to
figure out why this is or where the decision to vectorize (or not) is
getting made. Does anyone have an idea? 10 is not a large enough value
to hit the limit of a 32 bit int or unsigned int value so why can't it be
vectorized like the other two cases?
In the original test case that I added to this PR, N is an argument and
we don't know what value it has. It seems like this could be vectorized
by including a test to make sure that the value is not larger than MAXINT
and thus could not wrap when doing the array indexing.
Steve Ellcey
sell...@cavium.com
/* define N as 1000 - gets vectorized */
/* define N as 1 - gets vectorized */
/* define N as 10 - does not get vectorized */
#define N 10
typedef unsigned int TYPE;
void f(int *C, int *A, int val)
{
TYPE i,j;
for (i=0; i
Re: LP64, unsigned int, vectorization, and PR 61247
On Thu, Oct 4, 2018 at 1:49 PM Steve Ellcey wrote:
>
> I was looking at PR tree-optimization/61247, where a loop with an unsigned
> int index on an LP64 platform was not getting vectorized and I noticed an
> odd thing. In the function below, if I define N as 1000 or 1, the
> loop does get vectorized, even in LP64 mode. But if I define N as 10,
> the loop does not get vectorized in LP64 mode. I have not been able to
> figure out why this is or where the decision to vectorize (or not) is
> getting made. Does anyone have an idea? 10 is not a large enough value
> to hit the limit of a 32 bit int or unsigned int value so why can't it be
> vectorized like the other two cases?
i*N+j doesn't that wrap; e.g. when i is 10-1, it is wrapping as
10*(10-1) needs 34 bits to be represented without wrapping ?
Thanks,
Andrew Pinski
>
> In the original test case that I added to this PR, N is an argument and
> we don't know what value it has. It seems like this could be vectorized
> by including a test to make sure that the value is not larger than MAXINT
> and thus could not wrap when doing the array indexing.
>
> Steve Ellcey
> sell...@cavium.com
>
>
>
> /* define N as 1000 - gets vectorized */
> /* define N as 1 - gets vectorized */
> /* define N as 10 - does not get vectorized */
>
> #define N 10
>
> typedef unsigned int TYPE;
> void f(int *C, int *A, int val)
> {
> TYPE i,j;
> for (i=0; i for (j=0; j C[i*N+j]=A[i*N+j] * val;
> }
> }
> }
gcc-7-20181004 is now available
Snapshot gcc-7-20181004 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20181004/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 264856 You'll find: gcc-7-20181004.tar.xzComplete GCC SHA256=0e8de3aa780b947465c0619bb947a028c7ebfa3853f48dad0d7e6bcfc595b18e SHA1=442ee3512e0da471c695678276077a3357084a3a Diffs from 7-20180927 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
