Re: gcc 7.2.0 error: no include path in which to search for stdc-predef.h
It seems the last error preceeding the "suffix" error is "no include path in which to search for stdc-predef.h" "This error message is quite misleading and frequently the problem has nothing to do with the message. You have to check the file 'config.log' in the directory where the error occurred. In the example above, you would have to check the 'config.log' file in the directory '/home/manu/gcc/gcc/i686-pc-linux-gnu/libgcc'. There might be several test programs that failed during the configuration, but some of these failures are non-critical. Check for the last error entry in the file. I wonder where to find stdc-predef.h or whether it's generated by gcc during compile time. I'm also compiling against musl. Marek On Tue, Nov 28, 2017 at 12:19 AM, Jonathan Wakely wrote: > N.B. the gcc@gcc.gnu.org mailing list is not for support. For help > building or using GCC use the gcc-h...@gcc.gnu.org mailing list (see > https://gcc.gnu.org/lists.html for information on the lists and what's > on-topic). > > On 27 November 2017 at 20:23, Jim Wilson wrote: >> On 11/26/2017 11:09 PM, Marek wrote: >>> >>> Hi, >>> >>> while compiling 7.2.0 im getting the following: >>> >>> cc1: error: no include path in which to search for stdc-predef.h >>> cc1: note: self-tests are not enabled in this build >> >> >> This doesn't appear to be a build error. Configure runs the compiler to >> check for features, and if a check fails, then the feature is disabled. This >> is normal, and nothing to worry about. Though the message is unusual. If >> the compiler is the one you just built, there might be something wrong with >> it. Or there might be a minor configure script bug. >> >>> configure: error: in >>> `/run/media/void/minnow/build/gcc-7.2.0/x86_64-lfs-linux-gnu/libgcc': >>> configure: error: cannot compute suffix of object files: cannot compile >>> See `config.log' for more details. >>> make[1]: *** [Makefile:12068: configure-target-libgcc] Error 1 >>> make: *** [Makefile:880: all] Error 2 >> >> >> This is the real build error. You need to look at the config.log file in >> the directory where configure failed to see what the problem is. This is >> usually a build environment problem of some sort. > > There's a FAQ entry about this error, please read it: > https://gcc.gnu.org/wiki/FAQ#configure_suffix > >>> If gcc is able to recognize between sources in one dir and objects in >>> another dir >> >> >> Yes. The usual way to configure gcc is something like >> mkdir build >> cd build >> ../gcc/configure > > See https://gcc.gnu.org/wiki/InstallingGCC for more information, > including how to avoid the error above.
Re: gcc 7.2.0 error: no include path in which to search for stdc-predef.h
Marek kirjoitti 1.12.2017 klo 10:51: It seems the last error preceeding the "suffix" error is "no include path in which to search for stdc-predef.h" I wonder where to find stdc-predef.h or whether it's generated by gcc during compile time. This file comes with newer glibc versions. For instance glibc-2.17 coming with CentOS 7 has it in its '/usr/include'. Older glibc versions don't have it... I'm also compiling against musl. No experience with that libc (https://www.musl-libc.org). Should it include the 'stdc-predef.h' in its '/usr/include'? configure: error: in `/run/media/void/minnow/build/gcc-7.2.0/x86_64-lfs-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile The '-lfs' hints about a "making a hammer without any existing hammer" case being in question. Not about a normal case like making a native or cross GCC for CentOS 7 where the target glibc (-2.17) is already made and tested and bug fixes will come from the CentOS 7 maintainers for its glibc... Ok, when your target is the 'x86_64-*-linux-gnu', identical with the example CentOS 7/x86_64 and the default libc for it is glibc, how using 'musl' instead has been taken care of? Have you installed some special patches into your local GCC sources? Maybe there is another target name one should use like 'x86_64-lfs-linux-musl' in your case?
Re: gcc 7.2.0 error: no include path in which to search for stdc-predef.h
Kai Ruottu kirjoitti 1.12.2017 klo 12:02: Marek kirjoitti 1.12.2017 klo 10:51: It seems the last error preceeding the "suffix" error is "no include path in which to search for stdc-predef.h" I wonder where to find stdc-predef.h or whether it's generated by gcc during compile time. This file comes with newer glibc versions. For instance glibc-2.17 coming with CentOS 7 has it in its '/usr/include'. Older glibc versions don't have it... I'm also compiling against musl. No experience with that libc (https://www.musl-libc.org). Should it include the 'stdc-predef.h' in its '/usr/include'? Answering to my own question... Yes, it should include this : https://git.musl-libc.org/cgit/musl/tree/include Maybe there is another target name one should use like 'x86_64-lfs-linux-musl' in your case? The docs for musl are telling just this, one should use the '-linux-musl' triplet!
Re: loading of zeros into {x,y,z}mm registers
On Fri, Dec 1, 2017 at 6:45 AM, Kirill Yukhin wrote: > Hello Jan, > On 29 Nov 08:59, Jan Beulich wrote: >> Kirill, >> >> in an unrelated context I've stumbled across a change of yours >> from Aug 2014 (revision 213847) where you "extend" the ways >> of loading zeros into registers. I don't understand why this was >> done, and the patch submission mail also doesn't give any reason. >> My point is that simple VEX-encoded vxorps/vxorpd/vpxor with >> 128-bit register operands ought to be sufficient to zero any width >> registers, due to the zeroing of the high parts the instructions do. >> Hence by using EVEX encoded insns it looks like all you do is grow >> the instruction length by one or two bytes (besides making the >> source somewhat more complicated to follow). At the very least >> the shorter variants should be used for -Os imo. > As far as I can recall, this was done since we cannot load zeroes > into upper 16 MM registers, which are available in EVEX exclusively. Note on Zen pxor on %ymm also takes double amount of resources as that on %xmm. It would be nice to fix this (and maybe also factor the ability to reference upper 16 MM regs in costing during RA ...?). Richard. >> >> Thanks for any insight, >> Jan >> > > -- > Thanks, K
Re: loading of zeros into {x,y,z}mm registers
>>> On 01.12.17 at 06:45, wrote:
> On 29 Nov 08:59, Jan Beulich wrote:
>> in an unrelated context I've stumbled across a change of yours
>> from Aug 2014 (revision 213847) where you "extend" the ways
>> of loading zeros into registers. I don't understand why this was
>> done, and the patch submission mail also doesn't give any reason.
>> My point is that simple VEX-encoded vxorps/vxorpd/vpxor with
>> 128-bit register operands ought to be sufficient to zero any width
>> registers, due to the zeroing of the high parts the instructions do.
>> Hence by using EVEX encoded insns it looks like all you do is grow
>> the instruction length by one or two bytes (besides making the
>> source somewhat more complicated to follow). At the very least
>> the shorter variants should be used for -Os imo.
> As far as I can recall, this was done since we cannot load zeroes
> into upper 16 MM registers, which are available in EVEX exclusively.
Ah, I did overlook this aspect indeed. I still think the smaller VEX
encoding should then be used for the low 16 registers.
Furthermore this
typedef double __attribute__((vector_size(16))) v2df_t;
typedef double __attribute__((vector_size(32))) v4df_t;
void test1(void) {
register v2df_t x asm("xmm31") = {};
asm volatile("" :: "v" (x));
}
void test2(void) {
register v4df_t x asm("ymm31") = {};
asm volatile("" :: "v" (x));
}
translates to "vxorpd %xmm31, %xmm31, %xmm31" for both
functions with -mavx512vl, yet afaict the instructions would #UD
without AVX-512DQ, which suggests to me that the original
intention wasn't fully met.
Jan
Re: loading of zeros into {x,y,z}mm registers
On Fri, Dec 01, 2017 at 05:08:40AM -0700, Jan Beulich wrote:
> >>> On 01.12.17 at 06:45, wrote:
> > On 29 Nov 08:59, Jan Beulich wrote:
> >> in an unrelated context I've stumbled across a change of yours
> >> from Aug 2014 (revision 213847) where you "extend" the ways
> >> of loading zeros into registers. I don't understand why this was
> >> done, and the patch submission mail also doesn't give any reason.
> >> My point is that simple VEX-encoded vxorps/vxorpd/vpxor with
> >> 128-bit register operands ought to be sufficient to zero any width
> >> registers, due to the zeroing of the high parts the instructions do.
> >> Hence by using EVEX encoded insns it looks like all you do is grow
> >> the instruction length by one or two bytes (besides making the
> >> source somewhat more complicated to follow). At the very least
> >> the shorter variants should be used for -Os imo.
> > As far as I can recall, this was done since we cannot load zeroes
> > into upper 16 MM registers, which are available in EVEX exclusively.
>
> Ah, I did overlook this aspect indeed. I still think the smaller VEX
> encoding should then be used for the low 16 registers.
If you have a testcase where that is not the case, please file a PR with it.
> Furthermore this
>
> typedef double __attribute__((vector_size(16))) v2df_t;
> typedef double __attribute__((vector_size(32))) v4df_t;
>
> void test1(void) {
> register v2df_t x asm("xmm31") = {};
> asm volatile("" :: "v" (x));
> }
>
> void test2(void) {
> register v4df_t x asm("ymm31") = {};
> asm volatile("" :: "v" (x));
> }
>
> translates to "vxorpd %xmm31, %xmm31, %xmm31" for both
> functions with -mavx512vl, yet afaict the instructions would #UD
> without AVX-512DQ, which suggests to me that the original
> intention wasn't fully met.
This indeed is a bug, please file a PR; we should IMHO just use
vpxorq instead in that case, which is just AVX512VL and doesn't need
DQ. Of course if DQ is available, we should use vxorpd.
Working on a fix.
Jakub
Re: loading of zeros into {x,y,z}mm registers
Hello Richard, On 01 Dec 12:44, Richard Biener wrote: > On Fri, Dec 1, 2017 at 6:45 AM, Kirill Yukhin wrote: > > Hello Jan, > > On 29 Nov 08:59, Jan Beulich wrote: > >> Kirill, > >> > >> in an unrelated context I've stumbled across a change of yours > >> from Aug 2014 (revision 213847) where you "extend" the ways > >> of loading zeros into registers. I don't understand why this was > >> done, and the patch submission mail also doesn't give any reason. > >> My point is that simple VEX-encoded vxorps/vxorpd/vpxor with > >> 128-bit register operands ought to be sufficient to zero any width > >> registers, due to the zeroing of the high parts the instructions do. > >> Hence by using EVEX encoded insns it looks like all you do is grow > >> the instruction length by one or two bytes (besides making the > >> source somewhat more complicated to follow). At the very least > >> the shorter variants should be used for -Os imo. > > As far as I can recall, this was done since we cannot load zeroes > > into upper 16 MM registers, which are available in EVEX exclusively. > > Note on Zen pxor on %ymm also takes double amount of resources > as that on %xmm. > > It would be nice to fix this (and maybe also factor the ability to > reference upper 16 MM regs in costing during RA ...?). I think this is not bad idea: to replace insn when we know, that MM regN is less than 16. > > Richard. > > >> > >> Thanks for any insight, > >> Jan > >> > > > > -- > > Thanks, K -- Thanks, K
