[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #33 from Marc Glisse --- (In reply to Jonathan Wakely from comment #8) > I think there was a bug report in the last month or so asking for some > builtin to detect when we're in a constexpr context. Now that we have (__builtin_)is_constant_evaluated, does __constant_string_p still serve a purpose, or could we replace it? ISTR __constant_string_p was causing various issues (including PR 86590). (In reply to Jason Merrill from comment #16) > (In reply to Marc Glisse from comment #13) > > it seems better than abusing __builtin_constant_p, which is getting > > contradictory requirements from its various uses: > > - constexpr (forces very early lowering) > > I'm not sure what you mean here; constexpr specifically delays lowering > within a constexpr function until we're actually trying to evaluate to a > constant value. Bug 85746 for instance, where the problem is how hard we should "try".
[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #34 from Jakub Jelinek --- Created attachment 45467 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45467&action=edit gcc9-pr86590.patch Untested patch to use __builtin_is_constant_evaluated() here. I believe it should help, the inliner should be able to see smaller inline functions and could make better decisions.
[Bug fortran/88902] ICE: Segmentation fault (in DFS::DFS_write_tree_body)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88902 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Sat Jan 19 08:43:12 2019 New Revision: 268091 URL: https://gcc.gnu.org/viewcvs?rev=268091&root=gcc&view=rev Log: PR fortran/88902 * trans-decl.c (gfc_get_symbol_decl): Don't add length to function or parent function if it has been added there already. * gfortran.dg/pr88902.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr88902.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88902] ICE: Segmentation fault (in DFS::DFS_write_tree_body)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88902 --- Comment #8 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #35 from Marc Glisse --- I just noticed that Jonathan has already written such a patch in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590#c28 but didn't commit it (maybe because is_constant_evaluated was not committed yet, or because it was not sufficient to solve that PR).
[Bug libstdc++/86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590 --- Comment #31 from Marc Glisse --- Adding "inline" to _M_construct does convince the inliner to proceed, but I don't know if that would cause too much bloat in other code, it would be best if IPA somehow guessed that this case is interesting without having its hand forced.
[Bug fortran/88871] [9 regression] ICE segmentation fault in f951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871 --- Comment #15 from Thomas Koenig --- Author: tkoenig Date: Sat Jan 19 11:03:28 2019 New Revision: 268092 URL: https://gcc.gnu.org/viewcvs?rev=268092&root=gcc&view=rev Log: 2019-01-17 Thomas Koenig PR fortran/88871 * resolve.c (resolve_ref): Fix logic for removal of reference. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c
[Bug fortran/88871] [9 regression] ICE segmentation fault in f951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Thomas Koenig --- Fixed, closing.
[Bug gcov-profile/83599] [GCOV] A If TRUE statement lead the return statement has wrong number of execution in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83599 --- Comment #2 from Yibiao Yang --- (In reply to Martin Liška from comment #1) > Thanks for another report, in this case the code is invalid: > > gcc pr83599.c -Wreturn-type > pr83599.c: In function ‘func’: > pr83599.c:7:1: warning: control reaches end of non-void function > [-Wreturn-type] > } > ^ Thanks, Martin. Will avoid such kind of invalid bug report.
[Bug rtl-optimization/88922] Merge identical constants with different modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88922 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-19 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- > gcc fails to notice that the 3 constants are the same. I would have expected > the constant pool to be handled as an untyped collection of bits at the end. That's indeed not the case, but I wonder if that would be worth the hassle.
[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265 --- Comment #36 from Jakub Jelinek --- (In reply to Marc Glisse from comment #35) > I just noticed that Jonathan has already written such a patch in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590#c28 but didn't commit it > (maybe because is_constant_evaluated was not committed yet, or because it > was not sufficient to solve that PR). I think in the exact PR86590 case in the end __builtin_is_constant_evaluated() hasn't helped, but it can in other cases; without it, the __builtin_constant_p isn't folded at least in the most common case where the argument is not constant early enough, it isn't folded during/after early inlining, nor soon after IPA inlining, it is just fab pass. While with __builtin_is_constant_evaluated(), it can be optimized either before early inlining (if it is used directly in the function), or soon after early inlining (otherwise).
[Bug middle-end/32628] [4.3 Regression] bogus integer overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32628 --- Comment #12 from Marc Glisse --- Nowadays, we consider that we can only access half of the address space, and you can only add up to PTRDIFF_MAX to a pointer, so in some sense this does overflow. I am thinking of removing the testcase, which breaks with a patch I am working on.
[Bug gcov-profile/88924] New: [GCOV] Wrong frequencies when there is complicated if expressions in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88924
Bug ID: 88924
Summary: [GCOV] Wrong frequencies when there is complicated if
expressions in gcov
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)
$ cat small.c
int ca[6] = {244, -245, 244, -246, 245, -246};
void main()
{
for (int i = 0; i < 6; ++i) {
int flag = i % 2 == 1 && ca[i] != (-2 * i - 1955) >> 3;
if (flag) {
;
} else if (i % 2 == 0 && ca[i] != (1955 + 2 * i) >> 3) {
;
}
}
for (int i = 0; i < 6; ++i) {
if (i % 2 == 1 && ca[i] != (-2 * i - 1955) >> 3) {
;
} else if (i % 2 == 0 && ca[i] != (1955 + 2 * i) >> 3) {
;
}
}
}
$ gcc small.c -w --coverage; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 9
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:0:Programs:1
-:1:int ca[6] = {244, -245, 244, -246, 245, -246};
-:2:
1:3:void main()
-:4:{
7:5: for (int i = 0; i < 6; ++i) {
6:6:int flag = i % 2 == 1 && ca[i] != (-2 * i - 1955) >> 3;
6:7:if (flag) {
-:8: ;
6:9:} else if (i % 2 == 0 && ca[i] != (1955 + 2 * i) >> 3) {
-: 10: ;
-: 11:}
-: 12: }
-: 13:
7: 14: for (int i = 0; i < 6; ++i) {
6: 15:if (i % 2 == 1 && ca[i] != (-2 * i - 1955) >> 3) {
-: 16: ;
3: 17:} else if (i % 2 == 0 && ca[i] != (1955 + 2 * i) >> 3) {
-: 18: ;
-: 19:}
-: 20: }
1: 21:}
-: 22:
Line #17 is wrongly marked as executed 3 times. In fact, this line should be
executed 6 times same to Line #9.
[Bug lto/88925] New: address of static string changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88925 Bug ID: 88925 Summary: address of static string changes Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ssbssa at yahoo dot de CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 45468 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45468&action=edit test case With the attached file, I get an unexpected result with these arguments: $ g++ -ovirtual virtual.cpp -flto -flto-partition=max -O3 $ ./virtual This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This is a heavily reduced test case of another program of mine, but I didn't need -flto-partition=max there to get this problem (I think because it's a lot bigger). So the problem is with the static strings typeDerived1 and typeDerived2. I would expect the pointers of Derived1::getType() and Derived2::getType() to always match either typeDerived1 or typeDerived2.
[Bug fortran/56789] Handling of contiguous dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 --- Comment #23 from Thomas Koenig --- Author: tkoenig Date: Sat Jan 19 20:06:41 2019 New Revision: 268096 URL: https://gcc.gnu.org/viewcvs?rev=268096&root=gcc&view=rev Log: 2018-01-19 Thomas Koenig Paul Thomas PR fortran/56789 * trans-expr.c (gfc_conv_procedure_call): Call gfc_conv_subref_array_arg if the formal arg is contiguous and the actual arg may not be. 2018-01-19 Thomas Koenig Paul Thomas PR fortran/56789 * gfortran.dg/contiguous_3.f90: Make code compilant. Remove scan-tree tests that fail with patch. * gfortran.dg/contiguous_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/contiguous_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/contiguous_3.f90
[Bug fortran/56789] Handling of contiguous dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #24 from Thomas Koenig --- Fixed on trunk, closing.
[Bug fortran/77960] ICE in gfc_conv_ss_startstride, at fortran/trans-array.c:3966
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77960 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Jan 19 21:18:26 2019 New Revision: 268097 URL: https://gcc.gnu.org/viewcvs?rev=268097&root=gcc&view=rev Log: 2019-01-19 Steven G. Kargl PR fortran/77960 * io.c (match_io_element): input-item cannot be an external function. 2019-01-19 Steven G. Kargl PR fortran/77960 * gfortran.dg/pr77960.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr77960.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/77960] ICE in gfc_conv_ss_startstride, at fortran/trans-array.c:3966
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77960 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from kargl at gcc dot gnu.org --- Fixed on trunk. Closing.
[Bug fortran/24878] subroutine getting called illegally as a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24878 Jürgen Reuter changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #5 from Jürgen Reuter --- This is not caught by ifort or PGI fortran either. Nagfor, however, gets it.
[Bug fortran/25095] Disallowed intrinsic in initialization statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25095 --- Comment #7 from Jürgen Reuter --- Indeed, ifort and PGI fortran flag this as an error in the implied DO expression. Nagfor flags it just as an extension.
[Bug fortran/25714] concat of strings create an extra temporary variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25714 Jürgen Reuter changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #7 from Jürgen Reuter --- This seems to be now _gfortran_concat_string (2, &str.0, 1, &a, 1, &b); __builtin_memmove (&c, &str.0, 2); so it still has a temporary AFAIC tell.
[Bug fortran/37835] -fno-automatic does not work for derived types with default initalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37835 --- Comment #7 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Sat Jan 19 21:45:43 2019 New Revision: 268098 URL: https://gcc.gnu.org/viewcvs?rev=268098&root=gcc&view=rev Log: 2019-01-19 Dominique d'Humieres PR fortran/37835 * resolve.c (resolve_types): Add !flag_automatic. * symbol.c (gfc_add_save): Silence warnings. 2019-01-18 Dominique d'Humieres PR fortran/37835 * gfortran.dg/no-automatic.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/no-automatic.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/37835] -fno-automatic does not work for derived types with default initalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37835 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Dominique d'Humieres --- Closing.
[Bug fortran/86167] allocation variable length character array in derived type incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86167 --- Comment #2 from Dominique d'Humieres --- This seems to have been fixed on trunk (9.0) around 2018-09-26.
[Bug debug/78685] -Og generates too many ""s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 --- Comment #15 from Eric Gallager --- (In reply to Tom de Vries from comment #13) > (In reply to Tom de Vries from comment #12) > > Created attachment 44343 [details] > > > [debug] Add fkeep-vars-live > > > Guality testing status: Og -fkeep-vars-live gives better results than Og for > > pr54200.c and pr54970.c, but worse results here: > > ... > > FAIL: gcc.dg/guality/csttest.c -Og -fkeep-vars-live -DPREVENT_OPTIMIZATION > > \ > > line 29 n == -(0x17ULL << 50) > > FAIL: gcc.dg/guality/csttest.c -Og -fkeep-vars-live -DPREVENT_OPTIMIZATION > > \ > > line 55 j == -(0x17ULL << 31) > > ... > > Looks like an independent problem, filed as PR86455 - "var-tracking > mishandles pre_dec". That's been fixed now... time to give this one another try?
[Bug tree-optimization/88926] New: ivopts with some NOP conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88926
Bug ID: 88926
Summary: ivopts with some NOP conversions
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Starting from gcc.dg/tree-ssa/ivopts-lt-2.c:
/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-ivopts" } */
/* { dg-skip-if "PR68644" { hppa*-*-* powerpc*-*-* } } */
void
f1 (int *p, unsigned int i)
{
p += i;
do
{
*p = 0;
p += 1;
i++;
}
while (i < 100);
}
/* { dg-final { scan-tree-dump-times "PHI" 1 "ivopts" } } */
/* { dg-final { scan-tree-dump-times "PHI https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01641.html . I am not familiar
with ivopts (I don't see why the instruction p+=i is relevant, it only changes
the initial value of p, but without it we do not eliminate either) so this is
likely one of the last cases I'll try to fix.
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182 --- Comment #18 from Eric Gallager --- (In reply to jos...@codesourcery.com from comment #16) > Subject: Re: stddef.h assumes machinee/ansi.h defines > _ANSI_H_ > > On Mon, 7 Sep 2009, prlw1 at cam dot ac dot uk wrote: > > > I just got stuck with this again: wondered why a NetBSD-5.99.15/i386 box > > with > > gcc-HEAD wouldn't compile. Then remembered the #define _ANSI_H_ fix and all > > is > > well. What is impeding this patch from being applied? > > I don't recall seeing weekly pings of it; presumably no maintainer in a > relevant area picked up review of it the first and only time it was posted > and noone made maintainers aware of the continued need for review by > pinging it until it gets reviewed. There been any new pings in the last 9 and a half years?
[Bug bootstrap/51450] configure's test for -fno-rtti -fno-exceptions broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51450 --- Comment #5 from Eric Gallager --- Is this an issue with upstream libtool, too, or just GCC's patched version of it?
[Bug c/41045] Extended asm with C operands doesn’t work at top level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41045 --- Comment #11 from Eric Gallager --- (In reply to Steven Fuerst from comment #9) > > Of course... since this is not exactly the intent of the (section()) > attribute, tricks like this may break at any time. "not exactly the intent" is a bit of an understatement!
[Bug go/88927] New: [9 Regression] Bootstrap failure on arm in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88927 Bug ID: 88927 Summary: [9 Regression] Bootstrap failure on arm in libgo Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: jakub at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- ../../../libgo/go/internal/cpu/cpu.go:138:2: error: reference to undefined name 'doinit' 138 | doinit() | ^ make[4]: Leaving directory '/builddir/build/BUILD/gcc-9.0.0-20190119/obj-armv7hl-redhat-linux-gnueabi/armv7hl-redhat-linux-gnueabi/libgo' make[4]: *** [Makefile:2833: internal/cpu.lo] Error 1 make[3]: *** [Makefile:2231: all-recursive] Error 1 make[3]: Leaving directory '/builddir/build/BUILD/gcc-9.0.0-20190119/obj-armv7hl-redhat-linux-gnueabi/armv7hl-redhat-linux-gnueabi/libgo' make[2]: Leaving directory '/builddir/build/BUILD/gcc-9.0.0-20190119/obj-armv7hl-redhat-linux-gnueabi/armv7hl-redhat-linux-gnueabi/libgo' make[2]: *** [Makefile:1156: all] Error 2 make[1]: *** [Makefile:20894: all-target-libgo] Error 2 make[1]: *** Waiting for unfinished jobs No idea why, there is cpu_no_init.go with // +build !386 // +build !amd64 // +build !amd64p32 // +build !arm64 // +build !ppc64 // +build !ppc64le // +build !s390x
[Bug go/88927] [9 Regression] Bootstrap failure on arm in libgo starting with r268084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88927 Jakub Jelinek changed: What|Removed |Added Target||armv7hl-unknown-linux-gnuea ||bi Target Milestone|--- |9.0 Summary|[9 Regression] Bootstrap|[9 Regression] Bootstrap |failure on arm in libgo |failure on arm in libgo ||starting with r268084
[Bug go/88927] [9 Regression] Bootstrap failure on arm in libgo starting with r268084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88927 --- Comment #1 from Ian Lance Taylor --- This is likely fixed by https://golang.org/cl/158717.
[Bug go/88927] [9 Regression] Bootstrap failure on arm in libgo starting with r268084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88927 --- Comment #2 from Jakub Jelinek --- Will try that. That said, I don't understand why cpu_no_init.go isn't used in that case. Inthe build log I see /usr/bin/mkdir -p internal; files=`echo ../../../libgo/go/internal/cpu/cpu.go cpugen.go | sed -e 's/[^ ]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/sh ./libtool --tag GO --mode=compile /builddir/build/BUILD/gcc-9.0.0-20190119/obj-armv7hl-redhat-linux-gnueabi/./gcc/gccgo -B/builddir/build/BUILD/gcc-9.0.0-20190119/obj-armv7hl-redhat-linux-gnueabi/./gcc/ -B/usr/armv7hl-redhat-linux-gnueabi/bin/ -B/usr/armv7hl-redhat-linux-gnueabi/lib/ -isystem /usr/armv7hl-redhat-linux-gnueabi/include -isystem /usr/armv7hl-redhat-linux-gnueabi/sys-include -O2 -g -I . -c -fgo-pkgpath=`echo internal/cpu.lo | sed -e 's/.lo$//'` -o internal/cpu.lo $files but if I run by hand (on x86_64-linux): ../../../libgo/match.sh --goarch=arm --goos=linux --srcdir=../../../libgo/go/internal/cpu --extrafiles="cpugen.go" ../../../libgo/go/internal/cpu/cpu.go ../../../libgo/go/internal/cpu/cpu_no_init.go cpugen.go
