* GCC 7 on ppc64le does not recognize vec_xl_be? @ 2019-11-16 1:07 Jeffrey Walton 2019-11-16 11:25 ` Segher Boessenkool 0 siblings, 1 reply; 23+ messages in thread From: Jeffrey Walton @ 2019-11-16 1:07 UTC (permalink / raw) To: gcc-help Hi Everyone, I have a Travis job failing on ppc64le: https://travis-ci.org/noloader/cryptopp-pem/jobs/612654182 . Compiling a source file with Power9 flags: g++ -DNDEBUG -g2 -O3 -mcpu=power9 -maltivec -c ppc_power9.cpp That includes a header with this function: inline uint32x4_p VecLoadBE(const byte src[16]) { #if defined(_ARCH_PWR9) return (uint32x4_p)vec_xl_be(0, CONST_V8_CAST(src)); #elif (BIG_ENDIAN) return (uint32x4_p)VecLoad(src); #else return (uint32x4_p)VecReverse(VecLoad(src)); #endif } Results in: ppc_simd.h: In function ‘uint32x4_p VecLoadBE(const byte*)’: ppc_simd.h:466:24: error: ‘vec_xl_be’ was not declared in this scope return (uint32x4_p)vec_xl_be(0, CONST_V8_CAST(src)); According to the GCC docs vec_xl_be is available with ISA 3.0: https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec-Built-in-Functions-Available-on-ISA-3_002e0.html Does someone know why the compile is failing? Thanks in advance. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 1:07 GCC 7 on ppc64le does not recognize vec_xl_be? Jeffrey Walton @ 2019-11-16 11:25 ` Segher Boessenkool 2019-11-16 11:45 ` Jeffrey Walton 0 siblings, 1 reply; 23+ messages in thread From: Segher Boessenkool @ 2019-11-16 11:25 UTC (permalink / raw) To: Jeffrey Walton; +Cc: gcc-help Hi Jeffrey, On Fri, Nov 15, 2019 at 08:05:57PM -0500, Jeffrey Walton wrote: > g++ -DNDEBUG -g2 -O3 -mcpu=power9 -maltivec -c ppc_power9.cpp You forgot -Wall -Wextra, or at the very least -Wall. It probably will help you find this problem., too. -g2 is the default, and -maltivec is implied by -mcpu=power9. Why do you disable assertions (-DNDEBUG)? > ppc_simd.h: In function âuint32x4_p VecLoadBE(const byte*)â: > ppc_simd.h:466:24: error: âvec_xl_beâ was not declared in this scope > return (uint32x4_p)vec_xl_be(0, CONST_V8_CAST(src)); You didn't #include <altivec.h> in this scope, or you have undefined __VSX__, or undefined something else; it is impossible for us to tell. Always enable warnings, it helps. Segher ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 11:25 ` Segher Boessenkool @ 2019-11-16 11:45 ` Jeffrey Walton 2019-11-16 14:26 ` Segher Boessenkool 0 siblings, 1 reply; 23+ messages in thread From: Jeffrey Walton @ 2019-11-16 11:45 UTC (permalink / raw) To: Segher Boessenkool; +Cc: gcc-help On Sat, Nov 16, 2019 at 6:25 AM Segher Boessenkool <segher@kernel.crashing.org> wrote: > > Hi Jeffrey, > > On Fri, Nov 15, 2019 at 08:05:57PM -0500, Jeffrey Walton wrote: > > g++ -DNDEBUG -g2 -O3 -mcpu=power9 -maltivec -c ppc_power9.cpp > > You forgot -Wall -Wextra, or at the very least -Wall. It probably will > help you find this problem., too. OK, thanks. I have a comprehensive test script that does things like -Wall -Wextra. It takes 4 to 6 hours to run. It is not suitable for Travis, though. GCC135 is Power9, but it only has GCC 4.8 and at12 compilers. The at12 compiler does not warn of anything of interest with elevated warnings. Just the standard unknown pragmas due to some OMP code paths. Do you know where to find a Power9 machine with GCC 7? > -g2 is the default, and -maltivec is implied by -mcpu=power9. > > Why do you disable assertions (-DNDEBUG)? > > > ppc_simd.h: In function ‘uint32x4_p VecLoadBE(const byte*)’: > > ppc_simd.h:466:24: error: ‘vec_xl_be’ was not declared in this scope > > return (uint32x4_p)vec_xl_be(0, CONST_V8_CAST(src)); > > You didn't #include <altivec.h> in this scope, or you have undefined > __VSX__, or undefined something else; it is impossible for us to tell. Yeah, I can't get a terminal so I can't do things like g++ -dM -E on Travis to see what is going on. Jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 11:45 ` Jeffrey Walton @ 2019-11-16 14:26 ` Segher Boessenkool 2019-11-16 14:47 ` Jeffrey Walton 2019-11-16 15:24 ` Xi Ruoyao 0 siblings, 2 replies; 23+ messages in thread From: Segher Boessenkool @ 2019-11-16 14:26 UTC (permalink / raw) To: Jeffrey Walton; +Cc: gcc-help On Sat, Nov 16, 2019 at 06:44:35AM -0500, Jeffrey Walton wrote: > On Sat, Nov 16, 2019 at 6:25 AM Segher Boessenkool > <segher@kernel.crashing.org> wrote: > > On Fri, Nov 15, 2019 at 08:05:57PM -0500, Jeffrey Walton wrote: > > > g++ -DNDEBUG -g2 -O3 -mcpu=power9 -maltivec -c ppc_power9.cpp > > > > You forgot -Wall -Wextra, or at the very least -Wall. It probably will > > help you find this problem., too. > > OK, thanks. > > I have a comprehensive test script that does things like -Wall > -Wextra. It takes 4 to 6 hours to run. It is not suitable for Travis, > though. You should have warnings enabled *always*. It does not take extra time, not measurable anyway. The point is that the compiler will tell you about likely errors you made, right after you made them, so it is easy to correct then, and a huge time saver. And if the compiler think that something may be wrong, but it really all is perfectly fine, perhaps the code should be written in such a way that this is more clear. If you still think it is a compiler bug, please file a bug in bugzilla, with a testcase that reproduces the problem, so that we can investigate (instead of guess). Segher ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 14:26 ` Segher Boessenkool @ 2019-11-16 14:47 ` Jeffrey Walton 2019-11-16 17:41 ` Segher Boessenkool 2019-11-16 15:24 ` Xi Ruoyao 1 sibling, 1 reply; 23+ messages in thread From: Jeffrey Walton @ 2019-11-16 14:47 UTC (permalink / raw) To: Segher Boessenkool; +Cc: gcc-help On Sat, Nov 16, 2019 at 9:26 AM Segher Boessenkool <segher@kernel.crashing.org> wrote: > > On Sat, Nov 16, 2019 at 06:44:35AM -0500, Jeffrey Walton wrote: > > On Sat, Nov 16, 2019 at 6:25 AM Segher Boessenkool > > <segher@kernel.crashing.org> wrote: > > > ... > If you still think it is a compiler bug, please file a bug in bugzilla, > with a testcase that reproduces the problem, so that we can investigate > (instead of guess). If you can find a test rig with Power9 and GCC 7, then I believe this is your reproducer: $ cat test.cxx // g++ -g2 -O3 -mcpu=power9 -maltivec test.cxx #include <altivec> int main(int argc, char* argv[]) { #if defined(_ARCH_PWR9) __vector unsigned char v = vec_xl_be(0, (unsigned char*)argv[0]); #else int XXX[-1]; #endif return 0 } It looks like Travis provides GCC 7.4; see https://travis-ci.org/noloader/cryptopp/jobs/612762432 . Jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 14:47 ` Jeffrey Walton @ 2019-11-16 17:41 ` Segher Boessenkool 2019-11-16 18:26 ` Jonathan Wakely 0 siblings, 1 reply; 23+ messages in thread From: Segher Boessenkool @ 2019-11-16 17:41 UTC (permalink / raw) To: Jeffrey Walton; +Cc: gcc-help Hi again, On Sat, Nov 16, 2019 at 09:47:12AM -0500, Jeffrey Walton wrote: > On Sat, Nov 16, 2019 at 9:26 AM Segher Boessenkool > <segher@kernel.crashing.org> wrote: > If you can find a test rig with Power9 and GCC 7, then I believe this > is your reproducer: > > $ cat test.cxx > // g++ -g2 -O3 -mcpu=power9 -maltivec test.cxx > #include <altivec> (I need <altivec.h> for this to work at all, not <altivec>.) GCC 7 simply does not support vec_xl_be: this is implemented in GCC 8 and later. GCC 7.5 was released just two days ago, and it was the last release of GCC 7, so this won't ever be backported there, even if we wanted to. Sorry. Segher ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 17:41 ` Segher Boessenkool @ 2019-11-16 18:26 ` Jonathan Wakely 2019-11-16 21:25 ` Jeffrey Walton 0 siblings, 1 reply; 23+ messages in thread From: Jonathan Wakely @ 2019-11-16 18:26 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Jeffrey Walton, gcc-help On Sat, 16 Nov 2019 at 17:41, Segher Boessenkool <segher@kernel.crashing.org> wrote: > > Hi again, > > On Sat, Nov 16, 2019 at 09:47:12AM -0500, Jeffrey Walton wrote: > > On Sat, Nov 16, 2019 at 9:26 AM Segher Boessenkool > > <segher@kernel.crashing.org> wrote: > > If you can find a test rig with Power9 and GCC 7, then I believe this > > is your reproducer: > > > > $ cat test.cxx > > // g++ -g2 -O3 -mcpu=power9 -maltivec test.cxx > > #include <altivec> > > (I need <altivec.h> for this to work at all, not <altivec>.) > > GCC 7 simply does not support vec_xl_be: this is implemented in GCC 8 and > later. GCC 7.5 was released just two days ago, and it was the last release > of GCC 7, so this won't ever be backported there, even if we wanted to. > Sorry. I already sent the following to Jeffrey 8 hours ago (off-list, because I could only send HTML mail at the time): "Those are the docs for GCC trunk. That function is not listed in the docs for GCC 7." If you're using GCC 7 then you should consult the docs for GCC 7, which makes the answer obvious. The function isn't recognized, because it's not supported by the GCC version you're using. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 18:26 ` Jonathan Wakely @ 2019-11-16 21:25 ` Jeffrey Walton 2019-11-16 22:19 ` Segher Boessenkool 2019-11-16 22:33 ` Jonathan Wakely 0 siblings, 2 replies; 23+ messages in thread From: Jeffrey Walton @ 2019-11-16 21:25 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc-help On Sat, Nov 16, 2019 at 1:26 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > ... > I already sent the following to Jeffrey 8 hours ago (off-list, because > I could only send HTML mail at the time): > > "Those are the docs for GCC trunk. That function is not listed in the > docs for GCC 7." GCC tells me it supports the load by accepting -mcpu=power9 and defining _ARCH_PWR9. The problems with GCC seem to be a little larger then inaccurate docs. Jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 21:25 ` Jeffrey Walton @ 2019-11-16 22:19 ` Segher Boessenkool 2019-11-16 22:26 ` Jeffrey Walton 2019-11-16 22:33 ` Jonathan Wakely 1 sibling, 1 reply; 23+ messages in thread From: Segher Boessenkool @ 2019-11-16 22:19 UTC (permalink / raw) To: Jeffrey Walton; +Cc: Jonathan Wakely, gcc-help On Sat, Nov 16, 2019 at 04:25:18PM -0500, Jeffrey Walton wrote: > On Sat, Nov 16, 2019 at 1:26 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > > ... > > I already sent the following to Jeffrey 8 hours ago (off-list, because > > I could only send HTML mail at the time): > > > > "Those are the docs for GCC trunk. That function is not listed in the > > docs for GCC 7." > > GCC tells me it supports the load by accepting -mcpu=power9 and > defining _ARCH_PWR9. It does no such thing. GCC does not claim it implements this, and the ELF v2 spec says "The two optional built-in vector functions in Table 6.4 [...]", and defines no specific way to detect it either. > The problems with GCC seem to be a little larger then inaccurate docs. The GCC docs are perfectly accurate for this as well. GCC 7 is older than this revision of the ELFv2 specification, and we never backported this feature: only very important features are backported. It could have made 7.2, over two years ago, but it wasn't considered important enough to backport. Segher ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 22:19 ` Segher Boessenkool @ 2019-11-16 22:26 ` Jeffrey Walton 2019-11-16 22:34 ` Jonathan Wakely 2019-11-18 18:29 ` Richard Sandiford 0 siblings, 2 replies; 23+ messages in thread From: Jeffrey Walton @ 2019-11-16 22:26 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Jonathan Wakely, gcc-help On Sat, Nov 16, 2019 at 5:19 PM Segher Boessenkool <segher@kernel.crashing.org> wrote: > > On Sat, Nov 16, 2019 at 04:25:18PM -0500, Jeffrey Walton wrote: > > On Sat, Nov 16, 2019 at 1:26 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > > > ... > > The problems with GCC seem to be a little larger then inaccurate docs. > > The GCC docs are perfectly accurate for this as well. > > GCC 7 is older than this revision of the ELFv2 specification, and we never > backported this feature: only very important features are backported. It > could have made 7.2, over two years ago, but it wasn't considered important > enough to backport. Then you don't understand how search works in 2019 and how users search for information. We cannot search for the absence of information. Jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 22:26 ` Jeffrey Walton @ 2019-11-16 22:34 ` Jonathan Wakely 2019-11-18 18:29 ` Richard Sandiford 1 sibling, 0 replies; 23+ messages in thread From: Jonathan Wakely @ 2019-11-16 22:34 UTC (permalink / raw) To: Jeffrey Walton; +Cc: Segher Boessenkool, gcc-help On Sat, 16 Nov 2019 at 22:26, Jeffrey Walton <noloader@gmail.com> wrote: > > On Sat, Nov 16, 2019 at 5:19 PM Segher Boessenkool > <segher@kernel.crashing.org> wrote: > > > > On Sat, Nov 16, 2019 at 04:25:18PM -0500, Jeffrey Walton wrote: > > > On Sat, Nov 16, 2019 at 1:26 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > > > > ... > > > The problems with GCC seem to be a little larger then inaccurate docs. > > > > The GCC docs are perfectly accurate for this as well. > > > > GCC 7 is older than this revision of the ELFv2 specification, and we never > > backported this feature: only very important features are backported. It > > could have made 7.2, over two years ago, but it wasn't considered important > > enough to backport. > > Then you don't understand how search works in 2019 and how users > search for information. We cannot search for the absence of > information. The information is there: https://gcc.gnu.org/onlinedocs/gcc-7.5.0/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html#PowerPC-AltiVec_002fVSX-Built-in-Functions That lists the functions enabled by -mcpu=power9 in GCC 7. Stop reading the wrong docs. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 22:26 ` Jeffrey Walton 2019-11-16 22:34 ` Jonathan Wakely @ 2019-11-18 18:29 ` Richard Sandiford 2019-11-18 19:10 ` Segher Boessenkool 2019-11-18 20:05 ` Martin Sebor 1 sibling, 2 replies; 23+ messages in thread From: Richard Sandiford @ 2019-11-18 18:29 UTC (permalink / raw) To: Jeffrey Walton; +Cc: Segher Boessenkool, Jonathan Wakely, gcc-help Jeffrey Walton <noloader@gmail.com> writes: > On Sat, Nov 16, 2019 at 5:19 PM Segher Boessenkool > <segher@kernel.crashing.org> wrote: >> >> On Sat, Nov 16, 2019 at 04:25:18PM -0500, Jeffrey Walton wrote: >> > On Sat, Nov 16, 2019 at 1:26 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: >> > > ... >> > The problems with GCC seem to be a little larger then inaccurate docs. >> >> The GCC docs are perfectly accurate for this as well. >> >> GCC 7 is older than this revision of the ELFv2 specification, and we never >> backported this feature: only very important features are backported. It >> could have made 7.2, over two years ago, but it wasn't considered important >> enough to backport. > > Then you don't understand how search works in 2019 and how users > search for information. We cannot search for the absence of > information. Yeah, I think that's a good point. E.g.: https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options gives no indication which version it's about, or how to find the corresponding page for older versions. It might be obvious to GCC developers that it's about trunk only, but I don't think it's reasonable to expect someone nativigating directly to the page from search results to know that. The "Introduction" section with the version is at the bottom of https://gcc.gnu.org/onlinedocs/gcc/, after a long table of contents. It's not even the first sentence in the introduction. It doesn't seem realistic to expect people to have read it. It would be great if we could have a banner at the top of the generated docs saying which version they're for and providing corresponding links to older versions. But that's obviously much easier said than done. :-) Thanks, Richard ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-18 18:29 ` Richard Sandiford @ 2019-11-18 19:10 ` Segher Boessenkool 2019-11-18 20:05 ` Martin Sebor 1 sibling, 0 replies; 23+ messages in thread From: Segher Boessenkool @ 2019-11-18 19:10 UTC (permalink / raw) To: Jeffrey Walton, Jonathan Wakely, gcc-help, richard.sandiford On Mon, Nov 18, 2019 at 06:29:28PM +0000, Richard Sandiford wrote: > Yeah, I think that's a good point. E.g.: > > https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options > > gives no indication which version it's about, Yes. Although it is one click away ("contents", needs some scrolling as well, alas). > or how to find the corresponding page for older versions. This is exactly the same as with a physical book, and with any other documentation. I would hope people who use GCC would have learned how to use documentation. > It might be obvious to GCC > developers that it's about trunk only, but I don't think it's > reasonable to expect someone nativigating directly to the page > from search results to know that. Yes, it would be nice if it said the GCC version number in the navigation bar. > The "Introduction" section with the version is at the bottom of > https://gcc.gnu.org/onlinedocs/gcc/, after a long table of contents. > It's not even the first sentence in the introduction. It is the second. The first line says what this manual is: This manual documents how to use the GNU compilers, as well as their features and incompatibilities, and how to report bugs. It corresponds to the compilers (GCC) version 10.0.0. (That identification looks a bit funny as well btw). > It would be great if we could have a banner at the top of the generated > docs saying which version they're for and providing corresponding links > to older versions. But that's obviously much easier said than done. :-) Links to older versions is hard to do, and will take up much too much screen real estate anyway. But maybe we could have a link to https://gcc.gnu.org/onlinedocs/ somewhere? Segher ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-18 18:29 ` Richard Sandiford 2019-11-18 19:10 ` Segher Boessenkool @ 2019-11-18 20:05 ` Martin Sebor 2019-11-18 20:20 ` Segher Boessenkool 1 sibling, 1 reply; 23+ messages in thread From: Martin Sebor @ 2019-11-18 20:05 UTC (permalink / raw) To: Jeffrey Walton, Segher Boessenkool, Jonathan Wakely, gcc-help, richard.sandiford On 11/18/19 11:29 AM, Richard Sandiford wrote: > Jeffrey Walton <noloader@gmail.com> writes: >> On Sat, Nov 16, 2019 at 5:19 PM Segher Boessenkool >> <segher@kernel.crashing.org> wrote: >>> >>> On Sat, Nov 16, 2019 at 04:25:18PM -0500, Jeffrey Walton wrote: >>>> On Sat, Nov 16, 2019 at 1:26 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: >>>>> ... >>>> The problems with GCC seem to be a little larger then inaccurate docs. >>> >>> The GCC docs are perfectly accurate for this as well. >>> >>> GCC 7 is older than this revision of the ELFv2 specification, and we never >>> backported this feature: only very important features are backported. It >>> could have made 7.2, over two years ago, but it wasn't considered important >>> enough to backport. >> >> Then you don't understand how search works in 2019 and how users >> search for information. We cannot search for the absence of >> information. > > Yeah, I think that's a good point. E.g.: > > https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options > > gives no indication which version it's about, In my experience, it's common to refer to the latest manual instead of the version being discussed. It is the top hit when searching for "gcc options:" https://www.google.com/search?q=gcc+options As new GCC versions come out, references to changing content become out of date. Including the next major version in the GCC link would keep this from happening: https://gcc.gnu.org/onlinedocs/gcc-<next-major-version>.1.0/gcc If this can't be done, mentioning the major version more prominently, such as both in the title of every HTML page (so that it's displayed in the browser's frame) and at the top of the index.html page (i.e., here https://gcc.gnu.org/onlinedocs/gcc/index.html) would help (but not solve all the problems). Martin > or how to find the > corresponding page for older versions. It might be obvious to GCC > developers that it's about trunk only, but I don't think it's > reasonable to expect someone nativigating directly to the page > from search results to know that. > > The "Introduction" section with the version is at the bottom of > https://gcc.gnu.org/onlinedocs/gcc/, after a long table of contents. > It's not even the first sentence in the introduction. It doesn't > seem realistic to expect people to have read it. > > It would be great if we could have a banner at the top of the generated > docs saying which version they're for and providing corresponding links > to older versions. But that's obviously much easier said than done. :-) > > Thanks, > Richard > ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-18 20:05 ` Martin Sebor @ 2019-11-18 20:20 ` Segher Boessenkool 0 siblings, 0 replies; 23+ messages in thread From: Segher Boessenkool @ 2019-11-18 20:20 UTC (permalink / raw) To: Martin Sebor; +Cc: Jeffrey Walton, Jonathan Wakely, gcc-help, richard.sandiford On Mon, Nov 18, 2019 at 01:05:18PM -0700, Martin Sebor wrote: > In my experience, it's common to refer to the latest manual instead > of the version being discussed. It is the top hit when searching > for "gcc options:" > https://www.google.com/search?q=gcc+options yes, and "gcc manual" points at trunk, 7.2, 4.9.4, the pdf for trunk, and 4.7.4, in that order. "gcc incomplete enum types" points at 8.2, not trunk, as first hit; and there are no other gcc.gnu.org hit on the first page. > As new GCC versions come out, references to changing content become > out of date. > > Including the next major version in the GCC link would keep this > from happening: > https://gcc.gnu.org/onlinedocs/gcc-<next-major-version>.1.0/gcc But this is not the documentation for the next version. Time travel is not possible. The contents will be updated, but even the links themselves are not necessarily stable before the release. This is not documentation of GCC 10.1; it is documentation for the current development version. It is a work in progress. Segher ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 21:25 ` Jeffrey Walton 2019-11-16 22:19 ` Segher Boessenkool @ 2019-11-16 22:33 ` Jonathan Wakely 2019-11-16 22:40 ` Jeffrey Walton 1 sibling, 1 reply; 23+ messages in thread From: Jonathan Wakely @ 2019-11-16 22:33 UTC (permalink / raw) To: Jeffrey Walton; +Cc: gcc-help On Sat, 16 Nov 2019 at 21:25, Jeffrey Walton <noloader@gmail.com> wrote: > > On Sat, Nov 16, 2019 at 1:26 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > > ... > > I already sent the following to Jeffrey 8 hours ago (off-list, because > > I could only send HTML mail at the time): > > > > "Those are the docs for GCC trunk. That function is not listed in the > > docs for GCC 7." > > GCC tells me it supports the load by accepting -mcpu=power9 and > defining _ARCH_PWR9. > > The problems with GCC seem to be a little larger then inaccurate docs. What? You're talking nonsense. You said: "According to the GCC docs vec_xl_be is available with ISA 3.0: https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec-Built-in-Functions-Available-on-ISA-3_002e0.html " You are consulting the docs for GCC trunk and assuming they apply to GCC 7. That's simply wrong. The corresponding docs for GCC 7 are at: https://gcc.gnu.org/onlinedocs/gcc-7.5.0/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html#PowerPC-AltiVec_002fVSX-Built-in-Functions It doesn't mention vec_xl_be in the functions available with -mcpu=power9. So why do you think GCC 7 might not recognise that function? Hmm, maybe because it isn't supported by GCC 7. The docs are accurate. The docs for GCC 7 say which functions -mcpu=power9 enables FOR GCC 7, and that doesn't include the function you're trying to use. The docs for GCC trunk say which functions -mcpu-power9 enables FOR GCC TRUNK. Not for all versions. The intro to the pages you're looking at says "It corresponds to the compilers (GCC) version 10.0.0." so you're simply wrong to assume it also corresponds to older versions. It doesn't. For older versions, see the docs for those versions. ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 22:33 ` Jonathan Wakely @ 2019-11-16 22:40 ` Jeffrey Walton 2019-11-16 22:43 ` Jonathan Wakely 2019-11-16 22:52 ` Segher Boessenkool 0 siblings, 2 replies; 23+ messages in thread From: Jeffrey Walton @ 2019-11-16 22:40 UTC (permalink / raw) To: Jonathan Wakely; +Cc: gcc-help On Sat, Nov 16, 2019 at 5:33 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > > On Sat, 16 Nov 2019 at 21:25, Jeffrey Walton <noloader@gmail.com> wrote: > > > > On Sat, Nov 16, 2019 at 1:26 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > > > ... > > > I already sent the following to Jeffrey 8 hours ago (off-list, because > > > I could only send HTML mail at the time): > > > > > > "Those are the docs for GCC trunk. That function is not listed in the > > > docs for GCC 7." > > > > GCC tells me it supports the load by accepting -mcpu=power9 and > > defining _ARCH_PWR9. > > > > The problems with GCC seem to be a little larger then inaccurate docs. > > What? You're talking nonsense. > > You said: > "According to the GCC docs vec_xl_be is available with ISA 3.0: > https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec-Built-in-Functions-Available-on-ISA-3_002e0.html > " > > You are consulting the docs for GCC trunk and assuming they apply to > GCC 7. That's simply wrong. The docs don't list an "applies to" or "since". We asked for that about 5 years ago. Here is the link returned for a search of "GCC vec_xl_be". There is no mention of GCC 10.0 or limitations on availability: https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec-Built-in-Functions-Available-on-ISA-3_002e0.html Like I said, you don't understand how search works and how users use it. Jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 22:40 ` Jeffrey Walton @ 2019-11-16 22:43 ` Jonathan Wakely 2019-11-16 22:52 ` Segher Boessenkool 1 sibling, 0 replies; 23+ messages in thread From: Jonathan Wakely @ 2019-11-16 22:43 UTC (permalink / raw) To: Jeffrey Walton; +Cc: gcc-help On Sat, 16 Nov 2019 at 22:40, Jeffrey Walton <noloader@gmail.com> wrote: > > On Sat, Nov 16, 2019 at 5:33 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > > > > On Sat, 16 Nov 2019 at 21:25, Jeffrey Walton <noloader@gmail.com> wrote: > > > > > > On Sat, Nov 16, 2019 at 1:26 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote: > > > > ... > > > > I already sent the following to Jeffrey 8 hours ago (off-list, because > > > > I could only send HTML mail at the time): > > > > > > > > "Those are the docs for GCC trunk. That function is not listed in the > > > > docs for GCC 7." > > > > > > GCC tells me it supports the load by accepting -mcpu=power9 and > > > defining _ARCH_PWR9. > > > > > > The problems with GCC seem to be a little larger then inaccurate docs. > > > > What? You're talking nonsense. > > > > You said: > > "According to the GCC docs vec_xl_be is available with ISA 3.0: > > https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec-Built-in-Functions-Available-on-ISA-3_002e0.html > > " > > > > You are consulting the docs for GCC trunk and assuming they apply to > > GCC 7. That's simply wrong. > > The docs don't list an "applies to" or "since". We asked for that > about 5 years ago. They do actually. Not on every page, but they do, as I quoted in another email a few minutes ago. It says the docs apply to GCC 10.0.0, so not the version you're using. If you want to ask for improvements to the docs then file it in bugzilla. Complaining on the mailing list doesn't achieve much. > > Here is the link returned for a search of "GCC vec_xl_be". There is no > mention of GCC 10.0 or limitations on availability: > https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec-Built-in-Functions-Available-on-ISA-3_002e0.html > > Like I said, you don't understand how search works and how users use it. > > Jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 22:40 ` Jeffrey Walton 2019-11-16 22:43 ` Jonathan Wakely @ 2019-11-16 22:52 ` Segher Boessenkool 2019-11-16 22:56 ` Jeffrey Walton 1 sibling, 1 reply; 23+ messages in thread From: Segher Boessenkool @ 2019-11-16 22:52 UTC (permalink / raw) To: Jeffrey Walton; +Cc: Jonathan Wakely, gcc-help On Sat, Nov 16, 2019 at 05:40:11PM -0500, Jeffrey Walton wrote: > The docs don't list an "applies to" or "since". We asked for that > about 5 years ago. The docs have *started* with a statement like this, since at least 2.95, twenty years ago. Segher ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 22:52 ` Segher Boessenkool @ 2019-11-16 22:56 ` Jeffrey Walton 2019-11-16 22:58 ` Jonathan Wakely 0 siblings, 1 reply; 23+ messages in thread From: Jeffrey Walton @ 2019-11-16 22:56 UTC (permalink / raw) To: Segher Boessenkool; +Cc: Jonathan Wakely, gcc-help On Sat, Nov 16, 2019 at 5:52 PM Segher Boessenkool <segher@kernel.crashing.org> wrote: > > On Sat, Nov 16, 2019 at 05:40:11PM -0500, Jeffrey Walton wrote: > > The docs don't list an "applies to" or "since". We asked for that > > about 5 years ago. > > The docs have *started* with a statement like this, since at least 2.95, > twenty years ago. I'm sorry Segher, but I don't see it. Perhaps you can point it out for me: https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec-Built-in-Functions-Available-on-ISA-3_002e0.html jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 22:56 ` Jeffrey Walton @ 2019-11-16 22:58 ` Jonathan Wakely 0 siblings, 0 replies; 23+ messages in thread From: Jonathan Wakely @ 2019-11-16 22:58 UTC (permalink / raw) To: Jeffrey Walton; +Cc: Segher Boessenkool, gcc-help On Sat, 16 Nov 2019 at 22:56, Jeffrey Walton <noloader@gmail.com> wrote: > > On Sat, Nov 16, 2019 at 5:52 PM Segher Boessenkool > <segher@kernel.crashing.org> wrote: > > > > On Sat, Nov 16, 2019 at 05:40:11PM -0500, Jeffrey Walton wrote: > > > The docs don't list an "applies to" or "since". We asked for that > > > about 5 years ago. > > > > The docs have *started* with a statement like this, since at least 2.95, > > twenty years ago. > > I'm sorry Segher, but I don't see it. Perhaps you can point it out for > me: https://gcc.gnu.org/onlinedocs/gcc/PowerPC-AltiVec-Built-in-Functions-Available-on-ISA-3_002e0.html https://gcc.gnu.org/onlinedocs/gcc/#Introduction ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 14:26 ` Segher Boessenkool 2019-11-16 14:47 ` Jeffrey Walton @ 2019-11-16 15:24 ` Xi Ruoyao 2019-11-16 17:47 ` Segher Boessenkool 1 sibling, 1 reply; 23+ messages in thread From: Xi Ruoyao @ 2019-11-16 15:24 UTC (permalink / raw) To: Segher Boessenkool, Jeffrey Walton; +Cc: gcc-help On 2019-11-16 08:26 -0600, Segher Boessenkool wrote: > On Sat, Nov 16, 2019 at 06:44:35AM -0500, Jeffrey Walton wrote: > > On Sat, Nov 16, 2019 at 6:25 AM Segher Boessenkool > > <segher@kernel.crashing.org> wrote: > > > On Fri, Nov 15, 2019 at 08:05:57PM -0500, Jeffrey Walton wrote: > > > > g++ -DNDEBUG -g2 -O3 -mcpu=power9 -maltivec -c > > > > ppc_power9.cpp > > > > > > You forgot -Wall -Wextra, or at the very least -Wall. It > > > probably will > > > help you find this problem., too. > > > > OK, thanks. > > > > I have a comprehensive test script that does things like -Wall > > -Wextra. It takes 4 to 6 hours to run. It is not suitable for > > Travis, > > though. > > You should have warnings enabled *always*. It does not take extra > time, > not measurable anyway. The point is that the compiler will tell you > about likely errors you made, right after you made them, so it is > easy > to correct then, and a huge time saver. And if the compiler think > that > something may be wrong, but it really all is perfectly fine, perhaps > the > code should be written in such a way that this is more clear. Regarding this, is it worth considering to make -Wall the default? Recently our team is training some freshmen to write programs in C/C++. They often make some bugs (invoking UB in some way) and puzzle themselves. But we noticed that 90% of their bugs can be diagnosed by simply adding -Wall. -- Xi Ruoyao <xry111@mengyan1223.wang> School of Aerospace Science and Technology, Xidian University ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: GCC 7 on ppc64le does not recognize vec_xl_be? 2019-11-16 15:24 ` Xi Ruoyao @ 2019-11-16 17:47 ` Segher Boessenkool 0 siblings, 0 replies; 23+ messages in thread From: Segher Boessenkool @ 2019-11-16 17:47 UTC (permalink / raw) To: Xi Ruoyao; +Cc: Jeffrey Walton, gcc-help On Sat, Nov 16, 2019 at 11:23:33PM +0800, Xi Ruoyao wrote: > On 2019-11-16 08:26 -0600, Segher Boessenkool wrote: > > You should have warnings enabled *always*. It does not take extra > > time, > > not measurable anyway. The point is that the compiler will tell you > > about likely errors you made, right after you made them, so it is > > easy > > to correct then, and a huge time saver. And if the compiler think > > that > > something may be wrong, but it really all is perfectly fine, perhaps > > the > > code should be written in such a way that this is more clear. > > Regarding this, is it worth considering to make -Wall the default? > > Recently our team is training some freshmen to write programs in C/C++. > They often make some bugs (invoking UB in some way) and puzzle > themselves. But we noticed that 90% of their bugs can be diagnosed by > simply adding -Wall. It will be very disruptive to all users who do *not* want -Wall (misguided perhaps, but that's not the point), and to build systems (including those that cannot be fixed, think compiling older software with a new compiler). Not to mention the GCC testsuite itself... Making that work should give us some feel for how annoying changing the default is. I agree it is a nicer default, but how do we get there without a lot of pain? Segher ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2019-11-18 20:20 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-11-16 1:07 GCC 7 on ppc64le does not recognize vec_xl_be? Jeffrey Walton 2019-11-16 11:25 ` Segher Boessenkool 2019-11-16 11:45 ` Jeffrey Walton 2019-11-16 14:26 ` Segher Boessenkool 2019-11-16 14:47 ` Jeffrey Walton 2019-11-16 17:41 ` Segher Boessenkool 2019-11-16 18:26 ` Jonathan Wakely 2019-11-16 21:25 ` Jeffrey Walton 2019-11-16 22:19 ` Segher Boessenkool 2019-11-16 22:26 ` Jeffrey Walton 2019-11-16 22:34 ` Jonathan Wakely 2019-11-18 18:29 ` Richard Sandiford 2019-11-18 19:10 ` Segher Boessenkool 2019-11-18 20:05 ` Martin Sebor 2019-11-18 20:20 ` Segher Boessenkool 2019-11-16 22:33 ` Jonathan Wakely 2019-11-16 22:40 ` Jeffrey Walton 2019-11-16 22:43 ` Jonathan Wakely 2019-11-16 22:52 ` Segher Boessenkool 2019-11-16 22:56 ` Jeffrey Walton 2019-11-16 22:58 ` Jonathan Wakely 2019-11-16 15:24 ` Xi Ruoyao 2019-11-16 17:47 ` Segher Boessenkool
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).