Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: andrewm.roberts at sky dot com
Target Milestone: ---
The file INSTALL/specific.html in gcc-8.0.1-RC-20180427
contains many broken links
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85578
--- Comment #2 from Andrew Roberts ---
Ok thanks, just checking on the prerequisites front.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #18 from Andrew Roberts ---
Richard, I'm giving the latest snapshot a test, the armv6 version will be
ready in 16 hrs or so...
Meanwhile a question about consistency with gcc -Q --help=target,
and also what happens if you don't spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #20 from Andrew Roberts ---
The patch in in latest snapshot is working ok on Raspberry Pi Zero. And
-help=target now returns:
/usr/local/gcc/bin/gcc -march=native -mcpu=native -mfpu=auto -Q --help=target |
grep "march\|mcpu\|mfpu"
: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: andrewm.roberts at sky dot com
Target Milestone: ---
Building gcc 8.0.0 20180114 on Darwin (OS X) with llvm fails with an undeclared
identifier:
.../../gcc-8.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #46 from Andrew Roberts ---
With the latest snapshot:
gcc version 8.0.1 20180121
For the mt19937ar things now look reasonable without any strange options on
Ryzen.
Top 5
mt19937ar took 226849 clocks -march=amdfam10 -mtune=btver2
mt1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #47 from Andrew Roberts ---
Again with the latest snapshot:
gcc version 8.0.1 20180121
matrix.c is still needing additional options to get the best out of the Ryzen
processor. But is better than before (223029 clocks vs 371978 origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #48 from Andrew Roberts ---
Correction, that should be 23 not 23000 for the haswell drop in
performance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #50 from Andrew Roberts ---
with the matrix.c benchmark on Ryzen and looking at the other options when
using -march=znver1 and -mtune=znver1
mult took 225281 clocks -march=znver1 -mtune=znver1 -mprefer-vector-width=128
mult took 1859
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: andrewm.roberts at sky dot com
Target Milestone: ---
The latest gcc 9 snapshot (gcc version 9.0.1 20190127
9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: andrewm.roberts at sky dot com
Target Milestone: ---
When building gcc 9.1.0 (or 8.3.0) on Raspberry Pi 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034
--- Comment #1 from Andrew Roberts ---
Configure line used for building gcc 9.1.0:
../gcc-9.1.0/configure --prefix=/usr/local/gcc-9.1.0--program-suffix=
--disa
ble-werror --enable-shared --enable-threads=posix
--enable-checking=release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034
--- Comment #2 from Andrew Roberts ---
Building 9.1.0 with gmp 6.1.2 using "-v -save-temps" gives:
gcc -v -save-temps -c -DHAVE_CONFIG_H -I. -I../../../gcc-9.1.0/gmp/mpn -I..
-D__GMP_WITHIN_GMP -I../../../gcc-9.1.0/gmp -DOPERATION_divrem_1 -DNO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034
--- Comment #3 from Andrew Roberts ---
Created attachment 46535
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46535&action=edit
tmp-divrem_1.s file generated using m4 from divrem_1.asm in gmp/mpn
This is the gmp 6.1.2 version, from the gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034
--- Comment #5 from Andrew Roberts ---
OK I tried again using the latest gmp snapshot:
gmp-6.1.99-20190630.tar.lz
I still get the same error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034
--- Comment #6 from Andrew Roberts ---
I'm now building gcc 9.1.0 with the system gmp (using --with-gmp-lib and
--with-gmp-include). If this is successful I'll use this compiler to rebuild
itself with an in tree gmp and see where that gets me. Ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034
--- Comment #8 from Andrew Roberts ---
Build of 9.1.0 using system gmp worked fine.
Rebuild of 9.1.0 with in tree gmp-6.1.2 using that version of gcc
also worked fine.
Thus probably a host gcc compiler problem,
I'll report to Raspbian.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034
--- Comment #9 from Andrew Roberts ---
For completeness I've also built gcc 8.3.0 with in tree gmp 6.1.2 using the
newly built 9.1.0. And then in turn used this gcc 8.3.0 to rebuild gcc 9.1.0
with in tree gmp.
So the host gcc 8.3.0 doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034
--- Comment #11 from Andrew Roberts ---
Richard,
the cpu supports mls (its a ARM Cortex A72).
Comment 2 shows the -v output for both building gmp within gcc and standalone.
When building gmp in tree using Raspbian compiler:
as --gdwarf2 -v -I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034
--- Comment #12 from Andrew Roberts ---
GMP 6.1.0 and later support the following configure option:
--enable-assembly enable the use of assembly loops [default=yes]
not sure if this could be used to stop gmp using assembler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034
--- Comment #13 from Andrew Roberts ---
Just tried --enable-assembly=no with the standalone build of gmp
and this does seem to work as advertised. Everything symlinked to .c rather
than .asm files, and no .asm or .s files built at all.
Building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034
--- Comment #14 from Andrew Roberts ---
One final point even vanilla gcc 9.1.0 fails to build gmp standalone if
CFLAGS is set, so issue with Raspbian compiler is that it is probably setting
CFLAGS and thus messing up gmp build.
To cause standalo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034
--- Comment #16 from Andrew Roberts ---
That kicks a memory loose, from my build script:
# sed needed for GMP >=5.1 && < 6.2.0 on ARM otherwise isl build fails with
# undefined symbol __gmpn_invert_limb
sed -ixx "s/none-/${uname_m}-/" Makefile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83193
--- Comment #4 from Andrew Roberts ---
Correct, it does not show native in the list of valid options presented to the
user.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #22 from Andrew Roberts ---
The RPI Zero bug was fixed, I'm retesting with the latest snapshot (8.0.1
20180304) just to be sure it is ok. There are still a number of inconsistencies
and things which could be improved.
On Odroid-Xu4 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #23 from Andrew Roberts ---
RPI Zero still looks ok with latest snapshot.
/usr/local/gcc/bin/gcc -mfpu=auto -O3 -o matrix matrix.c
cc1: error: -mfloat-abi=hard: selected processor lacks an FPU
/usr/local/gcc/bin/gcc -mcpu=native -m
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: andrewm.roberts at sky dot com
Target Milestone: ---
Building gcc-8-20180304 failed on native SPARC Solaris 10
(sparc-sun-solaris2.10).
I had previously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84800
--- Comment #2 from Andrew Roberts ---
Rebuilt with 8-20180311 snapshot, and it now builds successfully:
/usr/local/gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-8-20180311/libexec/gcc
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andrewm.roberts at sky dot com
Target Milestone: ---
gcc 4.9.1 (Raspbian Linux)
gcc 5.3.0 (Arch Linux)
gcc 6-20160306 (Arch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70132
--- Comment #4 from Andrew Roberts ---
Patch tested OK,
on Raspberry Pi 3, on Arch Linux using latest gcc 6 snapshot:
/usr/local/gcc-6.0.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-6.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70132
--- Comment #5 from Andrew Roberts ---
Do I need to raise another bug report to get the march=native to actually
generate native code, or has one already been raised?
My original report (Bug 70136) included full /proc/cpuinfo for the BCM2834 as
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andrewm.roberts at sky dot com
Target Milestone: ---
When using -march=native or -mcpu=native with gcc-6-20160306 snapshot (and also
on previous released versions), the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70210
--- Comment #1 from Andrew Roberts ---
Note this was causing bug 70132 (ARM -mcpu=native can cause a double free
abort).
A patch as been subitted to fix the double free, but doesn't address
the failure to detect the CPU
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: andrewm.roberts at sky dot com
Target Milestone: ---
Build of gcc-6-20160306 fails on ARM Linux when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70211
--- Comment #1 from Andrew Roberts ---
Looking at the toplevel Makefile.in the gmp targets (maybe-configure-gmp,
configure-gmp etc)
use:
--build=${build_alias} --host=none-${host_vendor}-${host_os}
--target=none-${host_vendor}-${host_os}
where a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #8 from Andrew Roberts ---
The initial bug report was for cross compiling. Bug 70211 is for native builds
on ARM. Given the huge growth in ARM development boards, this needs at least
documenting. As with the original reporter I spent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #11 from Andrew Roberts ---
On Native ARM platform the bootstrap does work with the old in tree GMP 4.3.2,
regardless of wether you use none-linux-gnu or armv7l-linux-gnu when
configuring GMP.
Bulding by patching toplevel Makefile to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #15 from Andrew Roberts ---
Marc,
not entirely clear what you mean by reproducing the issue without downloading
mpfr, mpc, isl etc. Do you mean the missing symbol in GMP or the issues with
GMP when using assembly code? If you could p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70133
Andrew Roberts changed:
What|Removed |Added
CC||andrewm.roberts at sky dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #21 from Andrew Roberts ---
Tested with:
gcc-6-20160313
and in-tree:
gmp-6.1.99-20160321
mpc-1.0.3
mpfr-3.1.4
isl-0.16.1
On:
x86_64 Centos 7 (Full bootstrap)
This is Ok.
/usr/local/gcc-6.0.0/bin/gcc -v
Using built-in specs.
COLLECT_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #22 from Andrew Roberts ---
Tested with:
gcc-6-20160313
and in-tree:
gmp-6.1.99-20160321
mpc-1.0.3
mpfr-3.1.4
isl-0.16.1
On:
armv7l Arch Linux Arm (Raspberry Pi 3) (not bootstrapped yet due to build time)
This also builds ok with new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
--- Comment #25 from Andrew Roberts ---
The patch works on native armv7l-unknown-linux-gnuabihf with:
gcc-6-20160320
and in tree
gmp 6.1.0
mpc 1.0.3
mpfr 3.1.4
isl 0.16.1
although I wasn't seeing a problem with check-mpc.
At least the build comp
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andrewm.roberts at sky dot com
Target Milestone: ---
Created attachment 41973
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41973&action=edit
System independe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81818
--- Comment #1 from Andrew Roberts ---
Created attachment 41974
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41974&action=edit
Full test report for Raspberry Pi ARM
Test results for -O0, -Os, -O1, -O2, -O3 for gcc 5.4.0, 6.4.0, 7.2.0, 8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81818
--- Comment #2 from Andrew Roberts ---
Created attachment 41975
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41975&action=edit
Full test results for aarch64 on Raspberry Pi3
Test results for -O0, -Os, -O1, -O2, -O3 for gcc 5.4.0, 6.4.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81818
--- Comment #3 from Andrew Roberts ---
I've added the test results for the arm and aarch64 builds on Raspberry Pi3.
These show compilation time, memory used, and object file size for:
-O0, -Os, -O1, -O2, -O3
using gcc 5.4.0, 6.4.0, 7.2.0, and 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81818
--- Comment #4 from Andrew Roberts ---
Looking at --param ggc-min-expand and --param ggc-min-heapsize
For gcc 8.0.0:
on arm with 1Gb RAM:
GGC heuristics: --param ggc-min-expand=93 --param ggc-min-heapsize=119808
on aarch64 with 1Gb RAM:
GGC heur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81818
--- Comment #5 from Andrew Roberts ---
Ok, I've done some more digging.
Looking at the optimization options enabled by -O2 vs -O1, I built the test
program at -O1 and enabled each optimization in turn, on both ARM and AARCH64.
It looks like -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81818
--- Comment #6 from Andrew Roberts ---
Looks like this info got purged by the bugzilla failure, here it is again:
Ok, I've done some more digging.
Looking at the optimization options enabled by -O2 vs -O1, I built the test
program at -O1 and e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81818
--- Comment #7 from Andrew Roberts ---
I'll try the memory testing on both arm and aarch64.
I've also tried -fopt-info-all-optall, I was hoping this would provide some
info on what was happening, but it only seems to give any output under -O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81818
--- Comment #8 from Andrew Roberts ---
I've tried building gcc-8-20170806 and gcc-8-20170813 with
--enable-gather-detailed-mem-stats
This fails on x86-64, arm and aarch64 with the same error.
The recently released 7.2.0 build ok on x86-64 at le
: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: andrewm.roberts at sky dot com
Target Milestone: ---
Building gcc gcc-8-20170806 with --enable-gather-detailed-mem-stats fails:
On x64, arm and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81864
--- Comment #2 from Andrew Roberts ---
I can confirm gcc 7.2.0 builds ok on x86-64, arm and aarch64 with
--enable-gather-detailed-mem-stats.
So its just 8.0.0 which is failing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81818
--- Comment #10 from Andrew Roberts ---
I've attached the output for gcc 7.2.0 with -fmem-report (as
gcc-7.2.0-fmem-report.tar.bz2).
g++ -Ox -fmem-report -c testmap.cpp
where -Ox is one of: -O0, -O1, -O2, -O3, or -O1 -fgcse
This is across: x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81818
--- Comment #11 from Andrew Roberts ---
Created attachment 41992
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41992&action=edit
gcc-7.2.0 -fmem-report output for arm, aarch64, and x86-64
Output for gcc 7.2.0 with -fmem-report (as gcc-7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81864
--- Comment #7 from Andrew Roberts ---
Works for me on x86-64, trying aarch64 now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81864
--- Comment #8 from Andrew Roberts ---
aarch64 also ok with gcc-8.0.0 for me.
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: andrewm.roberts at sky dot com
Target Milestone: ---
gcc-7.2.0 is ok on this target, but gcc-8.0.0 fails to detect native target.
cat > test.c
#include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82175
--- Comment #1 from Andrew Roberts ---
This also fails on a Raspberry PI 3 running armv7 in the same way.
Looks like the armv8 code has got mixed up with the armv7 code...
The RPI3 has:
4x ARM Cortex-A53 rev 4 (0x4100d030)
cat /proc/cpuinfo
pro
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: andrewm.roberts at sky dot com
Target Milestone: ---
Created attachment 40110
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40110&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82175
--- Comment #6 from Andrew Roberts ---
Thanks Richard, this is now ok, tested on armv7 and aarch64.
However I do see differences in what is selected by march=native on arm between
7.2.0 and 8.0.0.20171001. Is this as expected? Or is it a work i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82175
--- Comment #8 from Andrew Roberts ---
I generated it using:
/usr/local/gcc-7.2.0/bin/gcc -march=native -Q --help=target
and
/usr/local/gcc-8.0.0/bin/gcc -march=native -Q --help=target
on each of the systems. Using:
/usr/local/gcc-8.0.0/bin/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82175
--- Comment #9 from Andrew Roberts ---
Created attachment 42275
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42275&action=edit
Output of gcc -march=native -Q --help=target for gcc 8.0.0.20171001
Output of gcc -march=native -Q --help=targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82175
--- Comment #10 from Andrew Roberts ---
Created attachment 42276
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42276&action=edit
Output of gcc -march=native -Q --help=target for gcc 7.2.0
Output of gcc -march=native -Q --help=target for g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
Andrew Roberts changed:
What|Removed |Added
CC||andrewm.roberts at sky dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #5 from Andrew Roberts ---
I've been testing on a Ryzen system and also comparing with Haswell and
Skylake. From my testing -mtune=znver1 does not perform well and never has,
including as of last snapshot:
gcc version 8.0.0 20171119 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #6 from Andrew Roberts ---
Created attachment 42687
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42687&action=edit
Test program used for the attached performance results (matrix.c)
Test program used for the attached performan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #7 from Andrew Roberts ---
Created attachment 42688
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42688&action=edit
Test results for Ryzen system with matrix.c
Test results for Ryzen system with matrix.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #8 from Andrew Roberts ---
Created attachment 42689
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42689&action=edit
Test results for Haswell system with matrix.c
Test results for Haswell system with matrix.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #9 from Andrew Roberts ---
Created attachment 42690
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42690&action=edit
Test results for Skylake system with matrix.c
Test results for Skylake system with matrix.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #10 from Andrew Roberts ---
Created attachment 42691
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42691&action=edit
Script for matrix.c test program
Script for matrix.c test program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #12 from Andrew Roberts ---
Ok I've tried again with this weeks snapshot:
gcc version 8.0.0 20171126 (experimental) (GCC)
Taking combination of -march and -mtune which works well on Ryzen:
/usr/local/gcc/bin/gcc -march=core-avx-i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #14 from Andrew Roberts ---
It would be nice if znver1 for -march and -mtune could be improved before the
gcc 8 release. At present -march=znver1 -mtune=znver1 looks be to about the
worst thing you could do, and not just on this vecto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #17 from Andrew Roberts ---
The general consensus in userland is that the znver1 optimization is much worse
than 0.5%, or even 2% off. Most people are using -march=haswell if they care
about performance.
Just taking one part of one o
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: andrewm.roberts at sky dot com
Target Milestone: ---
-march=native no longer documented in cc1 help message and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83193
--- Comment #1 from Andrew Roberts ---
The same comments also apply to the -mcpu and -mtune options as well. Double
output on arm for -mcpu, and missing help for native.
also:
gcc -Q --help=target
used to document the allowable -mcpu/-mtune opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #18 from Andrew Roberts ---
Ok trying an entirely different algorith, same results:
Using Mersenne Twister algorithm from here:
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html
alter main program to comment out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #19 from Andrew Roberts ---
Created attachment 42735
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42735&action=edit
modified mt19937ar test program, test script and results
modified mt19937ar test program, test script and res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #20 from Andrew Roberts ---
Again those latest mt19937ar results above were with the current snapshot:
/usr/local/gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-8.0.0/libexe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #23 from Andrew Roberts ---
Thanks Honza,
getting closer, with original matrix.c on Ryzen:
/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1 -O3 matrix.c -o matrix
mult took 364850 clocks
/usr/local/gcc/bin/gcc -march=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #24 from Andrew Roberts ---
For the mt19937ar test:
/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1 -O3 mt19937ar.c -o mt19937ar
mt19937ar took 462062 clocks
/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1 -mprefer-vector-wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #28 from Andrew Roberts ---
Adding -mno-avx2 into the mix was a marginal win, but only just showing out of
the noise:
/usr/local/gcc/bin/gcc -march=znver1 -mtune=znver1 -mprefer-vector-width=none
-mno-fma -mno-avx2 -O3 matrix.c -o ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #29 from Andrew Roberts ---
And rerunning all the tests for matrix.c on Ryzen using:
-march=$amarch -mtune=$amtune -mprefer-vector-width=none -mno-fma -O3
The winners were:
mult took 118145 clocks -march=broadwell -mtune=broadwell
mu
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: andrewm.roberts at sky dot com
Target Milestone: ---
On ARM an option to -mfpu is auto, this is given when you do:
/usr/local/gcc/bin/gcc -mcpu=native -Q --help=target
...
Known ARM
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: andrewm.roberts at sky dot com
Target Milestone: ---
On ARM autodetection of the CPU using -mcpu=native does not give
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #1 from Andrew Roberts ---
This was tested using:
/usr/local/gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-8.0.0/libexec/gcc/armv7l-unknown-linux-gnueabihf/8.0.0/lto-wrappe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #2 from Andrew Roberts ---
Correction:
1) This works on gcc 8 snapshot, it doesn't work on gcc-7.2.0
/usr/local/gcc-7.2.0/bin/gcc -march=native -mcpu=cortex-a53 -mfpu=auto -Ofast
-o matrix matrix.c
cc1: error: -mfloat-abi=hard: sel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #31 from Andrew Roberts ---
of for mt19937ar with -mno-avx2
/usr/local/gcc/bin/gcc -march=$amarch -mtune=$amtune -mno-avx2 -O3 -o mt199
37ar mt19937ar.c
Top 2:
mt19937ar took 358493 clocks -march=silvermont -mtune=bdver1
mt19937ar t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #3 from Andrew Roberts ---
ok confirmed, this bug is still present on the gcc-7 branch, with the current
snapshot:
/usr/local/gcc-7.2.1/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-7.2.1/bin/gcc
COLLECT_LTO_WRAPPER=/us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #32 from Andrew Roberts ---
For what its worth, here's what the latest and greatest from the competition
has to offer:
/usr/local/llvm-5.0.1-rc2/bin/clang -march=znver1 -mtune=znver1 -O3 matrix.c -o
matrix
mult took 88714
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #33 from Andrew Roberts ---
That second llvm command line should read:
/usr/local/llvm-5.0.1-rc2/bin/clang -march=znver1 -mtune=znver1 -Ofast
mt19937ar.c -o mt19937ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #5 from Andrew Roberts ---
It looks like I was right about this all along, its just that armv6l isn't
working. armv7l seems ok:
On RaspberryPi B - ARM1176 rev 7 (0x4100b760)
cat /proc/cpuinfo
processor : 0
model name : ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #7 from Andrew Roberts ---
I get the same thing if I just use -mcpu=native:
/usr/local/gcc/bin/gcc -o matrix-v6 -mcpu=native -mfpu=auto -O3 matrix.c
cc1: error: -mfloat-abi=hard: selected processor lacks an FPU
I realize the aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #9 from Andrew Roberts ---
Created attachment 42787
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42787&action=edit
/proc/cpuinfo from cortex-a7 Raspberry Pi 2b v1.1
/proc/cpuinfo from cortex-a7 Raspberry Pi 2b v1.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #10 from Andrew Roberts ---
Created attachment 42788
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42788&action=edit
/proc/cpuinfo from odroid-xu4 big/little cortex-a15/cortex-a7
/proc/cpuinfo from odroid-xu4 big/little cortex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #11 from Andrew Roberts ---
Created attachment 42789
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42789&action=edit
/proc/cpuinfo from rpi b (arm1176jzf-s)
/proc/cpuinfo from rpi b (arm1176jzf-s)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #12 from Andrew Roberts ---
Created attachment 42790
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42790&action=edit
/proc/cpuinfo from Raspberry Pi 3 (cortex-A53) arm mode
/proc/cpuinfo from Raspberry Pi 3 (cortex-A53) arm mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #13 from Andrew Roberts ---
Created attachment 42791
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42791&action=edit
/proc/cpuinfo from odroid-c2 (cortex-A53) aarch64 mode
/proc/cpuinfo from odroid-c2 (cortex-A53) aarch64 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #14 from Andrew Roberts ---
Richard, I have checked with latest snapshot (20171203) and problem persists.
I think the issue is that the CPU on the original Raspberry Pi and Pi Zero is
not detected properly by gcc.
/usr/local/gcc/bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83206
--- Comment #15 from Andrew Roberts ---
Created attachment 42792
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42792&action=edit
/proc/cpuinfo fro rpi3 (cortex a-53) on aarch64
/proc/cpuinfo fro rpi3 (cortex a-53) on aarch64
while this i
100 matches
Mail list logo
