Re: tree-prof parallel make check failures
On Wed, Sep 21, 2016 at 1:29 AM, Martin Sebor wrote: > I'm seeing a number of failures in different tests in the tree-prof > directory when I run make check in parallel none of which are > reproducible with -j1. I don't see anything about in Bugzilla or > in recent test results. Has anyone noticed this or am I missing > something? I'm also seeing random FAILs but mostly aut-profile stuff: UNRESOLVED: gcc.dg/tree-prof/ic-misattribution-1a.c compilation, -fauto-profile UNRESOLVED: gcc.dg/tree-prof/ic-misattribution-1a.c execution,-fauto-profile FAIL: gcc.dg/tree-prof/ic-misattribution-1a.c execution,-g (no auto-profile tools installed on the machine but perf is) Richard. > This is on a 56-core x86_64 machine running Fedora 21 and DejaGnu > 1:1.5.1-4.fc21 installed. > > Thanks > Martin > > Serial make check passes: > $ make -C /build/gcc-49905 check-c RUNTESTFLAGS='tree-prof.exp' > ... > === gcc Summary === > > # of expected passes307 > # of unsupported tests 48 > /build/gcc-49905/gcc/xgcc version 7.0.0 20160920 (experimental) (GCC) > > > Parallel make check fails a bunch of different tests each time > it's run: > $ make -C /build/gcc-49905 -j80 -k check-c RUNTESTFLAGS='tree-prof.exp' 2>&1 > | grep FAIL > FAIL: gcc.dg/tree-prof/peel-1.c execution,-g > FAIL: gcc.dg/tree-prof/update-tailcall.c execution,-g > FAIL: gcc.dg/tree-prof/cold_partition_label.c execution,-g > FAIL: gcc.dg/tree-prof/val-prof-1.c execution,-g > FAIL: gcc.dg/tree-prof/pr45354.c execution,-g > FAIL: gcc.dg/tree-prof/val-prof-2.c execution,-g > FAIL: gcc.dg/tree-prof/crossmodule-indircall-1.c execution,-g > FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,-g > FAIL: gcc.dg/tree-prof/pr52027.c execution,-g > FAIL: gcc.dg/tree-prof/20041218-1.c execution,-g > > and again: > $ nice make -C /opt/notnfs/msebor/build/gcc-49905 -j80 -k check-c > RUNTESTFLAGS='tree-prof.exp' 2>&1 | grep FAIL > FAIL: gcc.dg/tree-prof/bb-reorg.c execution,-g > FAIL: gcc.dg/tree-prof/prof-robust-1.c execution,-g > FAIL: gcc.dg/tree-prof/update-loopch.c execution,-g > FAIL: gcc.dg/tree-prof/crossmodule-indircall-1a.c execution,-g > FAIL: gcc.dg/tree-prof/switch-case-2.c execution,-g > FAIL: gcc.dg/tree-prof/ic-misattribution-1.c execution,-g > FAIL: gcc.dg/tree-prof/tracer-1.c execution,-g
Re: why do we need xtensa-config.h?
Am 08.09.2016 um 19:13 schrieb Oleksij Rempel: > Am 08.09.2016 um 18:10 schrieb augustine.sterl...@gmail.com: >> On Thu, Sep 8, 2016 at 8:14 AM, Oleksij Rempel >> wrote: >>> Am 07.09.2016 um 18:21 schrieb augustine.sterl...@gmail.com: On Tue, Sep 6, 2016 at 11:55 PM, Thomas Schwinge wrote: > Hi! > > Neither do I really know anything about Xtensa, nor do I have a lot of > experience in these parts of GCC back ends, but: There is a lot of background to know here. Unfortunately, I have no familiarity with making debian packages, so I'm unfamiliar with that side of it. First--and perhaps most important--the current method of configuring GCC for xtensa targets has worked well for nearly two decades. As far as I know, it is rare to encounter problems. Because of that, the bar to change it will probably be fairly high to change it. > On Tue, 6 Sep 2016 20:42:53 +0200, Oleksij Rempel > wrote: >> i'm one of ath9k-htc-firmware developers. Currently i'm looking for the >> way to provide this firmware as opensource/free package for debian. Main >> problem seems to be the need to patch gcc xtensa-config.h to make it >> suitable for our CPU. >> >> I have fallowing questions: >> >> do we really need this patch? >> https://github.com/qca/open-ath9k-htc-firmware/blob/master/local/patches/gcc.patch > > That I can't tell. ;-) You need something like that patch, for sure. >> Is it possible or welcome to extend gcc to be configurable without >> patching it all the time? > > Yes, I would think. The macros modified in the above patch to GCC's > include/xtensa-config.h file look like these ought to be modifiable with > -m* options defined by the Xtensa back end, and you'd then assign > specific defaults to a specific CPU variant, and build GCC (or build a > multilib) for that configuration. Today, there are literally hundreds of variants of the xtensa cpu actually realized and in use. Having a list of all those variants and their defaults inside gcc would be awkward and unwieldy. But--and here's the rub--literally tomorrow, someone could design a hundred more that are different from all of the ones already out there. There is literally an unlimited number of potential variants, each with potentially brand new, never conceived instructions. (Adding clever custom instructions is xtensa's raison d'etre.) With the current configurability mechanism, supporting all of those variants inside gcc (and, in fact, the rest of the gnu-toolchain) is simply a matter of using the correct xtensa-config.h for that particular variant. If we were to go with the "-m with defaults" mechanism, we would need some way of adding the defaults for the new variant to gcc. But that is patching gcc also, and once you go there, you may as well use the original method. > > This file include/xtensa-config.h is #included in > gcc/config/xtensa/xtensa.h and libgcc/config/xtensa/crti.S, Note that "-m" options can't change the instructions in crti.S and lib?funcs.S, but macros can and do. On the debian packaging side. Forgive me for my ignorance on the topic; I don't know that the tool-flow is, or what the requirements are. As far as I am aware, this is the first time someone has tried to make a debian package for xtensa. >>> >>> The point is to provide a package for "free" repository. It means, any >>> one should be able to use "apt-get source package_name", patch it and >>> recompile it from source. >>> >>> Right now it would work, but the package scripts should download >>> toolchain source, patch and compile it and the compile actual firmware. >>> This is wary high overhead. >>> >>> This is why i asked my self, why the toolchain can't be modular or >>> configurable enough to work without patching and recompiling it. >>> Anyway, I wouldn't expect patching gcc (or configuring it) for an individual package is the right thing. It should probably happen as part of some kind of "setup toolchain" step. Typically, patching gcc for a xtensa config happens just once immediately after designing the processor, or--if you aren't the designer yourself--when one starts development for that variant. >>> >>> after quick look i noticed that: >>> XSHAL_USE_ABSOLUTE_LITERALS affects TRAMPOLINE_SIZE. This seems to be >>> hardcoded every where in gcc, so can't be changed dynamically? >> >> TRAMPOLINE_SIZE is used in quite a few places (so beyond my authority >> to accept patches), but I suspect it would be acceptable to put a >> function behind TRAMPOLINE_SIZE that calculated the value dynamically. >> >>> >>> XCHAL_HAVE_MUL32_HIGH probably can be changed dynamically. >>> XCHAL_ICACHE_SIZE and XCHAL_DCACHE_SI
Re: tree-prof parallel make check failures
On Tue, Sep 20, 2016 at 05:29:03PM -0600, Martin Sebor wrote: > I'm seeing a number of failures in different tests in the tree-prof > directory when I run make check in parallel none of which are > reproducible with -j1. I don't see anything about in Bugzilla or > in recent test results. Has anyone noticed this or am I missing > something? I'm seeing those too and it's very bothering. I think Andi Kleen had some patches to fix these, but seems it needs to be fixed more. Marek
Re: why do we need xtensa-config.h?
On Wed, Sep 21, 2016 at 1:59 AM, Oleksij Rempel wrote: > So, first step is done. Our firmware is using GCC 6.2. > > If i see it correctly, main problem are binutils. First of all we need > custom binutils to compile GCC assambler code with custom opcodes - it's > a horror. > What would be better way to solve it? Have kind of in-project plugins > for binutils and gcc? If this is actually possible to solve it.. :( I don't know of an easy way. A plug-in mechanism for binutils would be a very large amount of work, and would require some pretty broad approvals.
Re: tree-prof parallel make check failures
On 09/21/2016 07:39 AM, Marek Polacek wrote: On Tue, Sep 20, 2016 at 05:29:03PM -0600, Martin Sebor wrote: I'm seeing a number of failures in different tests in the tree-prof directory when I run make check in parallel none of which are reproducible with -j1. I don't see anything about in Bugzilla or in recent test results. Has anyone noticed this or am I missing something? I'm seeing those too and it's very bothering. I think Andi Kleen had some patches to fix these, but seems it needs to be fixed more. Thank you both for confirming that. I've raised testsuite/77684 - many tree-prof testsuite failures in parallel make check. Martin
Successful bootstrap and install of gcc (GCC) 6.2.0 on x86_64-pc-linux-gnu
Hi, Here's a report of a successful build and install of GCC: $ gcc-6.2.0/config.guess x86_64-pc-linux-gnu $ newcompiler/bin/gcc -v Using built-in specs. COLLECT_GCC=newcompiler/bin/gcc COLLECT_LTO_WRAPPER=/home/aaro/gcctest/newcompiler/libexec/gcc/x86_64-unknown-linux-gnu/6.2.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-6.2.0/configure --with-arch=nocona --disable-multilib --disable-nls --prefix=/home/aaro/gcctest/newcompiler --enable-languages=c,c++ --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu --with-system-zlib --with-sysroot=/ Thread model: posix gcc version 6.2.0 (GCC) -- Build environment -- host: amd-fx-6350 distro: los.git rootfs=ff90d27 native=ff90d27 kernel: Linux 4.8.0-rc6-pc-los_ff90d27 binutils: GNU binutils 2.27 make: GNU Make 4.1 libc: GNU C Library (GNU libc) stable release version 2.24 zlib: mpfr: 3.1.3 gmp: 6 -- Time consumed -- configure: real0m 2.52s user0m 1.34s sys 0m 0.30s bootstrap: real34m 55.47s user2h 29m 43s sys 2m 25.80s install:real0m 5.69s user0m 3.80s sys 0m 1.29s -- Hardware details --- MemTotal: 16154184 kB processor : 0 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-6350 Six-Core Processor stepping: 0 microcode : 0x600081c cpu MHz : 2500.000 cache size : 2048 KB physical id : 0 siblings: 6 core id : 0 cpu cores : 3 apicid : 16 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bugs: fxsave_leak sysret_ss_attrs null_seg bogomips: 7799.91 TLB size: 1536 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 1 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-6350 Six-Core Processor stepping: 0 microcode : 0x600081c cpu MHz : 1400.000 cache size : 2048 KB physical id : 0 siblings: 6 core id : 0 cpu cores : 3 apicid : 17 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold bugs: fxsave_leak sysret_ss_attrs null_seg bogomips: 7819.02 TLB size: 1536 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm 100mhzsteps hwpstate cpb eff_freq_ro processor : 2 vendor_id : AuthenticAMD cpu family : 21 model : 2 model name : AMD FX(tm)-6350 Six-Core Processor stepping: 0 microcode : 0x600081c cpu MHz : 3100.000 cache size : 2048 KB physical id : 0 siblings: 6 core id : 1 cpu cores : 3 apicid : 18 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 13 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy
