Re: Do we need to do a loop invariant motion after loop interchange ?
On 2019/11/24 2:26 PM, Bin.Cheng wrote:
On Fri, Nov 22, 2019 at 3:23 PM Bin.Cheng wrote:
On Fri, Nov 22, 2019 at 3:19 PM Richard Biener
wrote:
On November 22, 2019 6:51:38 AM GMT+01:00, Li Jia He
wrote:
On 2019/11/21 8:10 PM, Richard Biener wrote:
On Thu, Nov 21, 2019 at 10:22 AM Li Jia He
wrote:
Hi,
I found for the follow code:
#define N 256
int a[N][N][N], b[N][N][N];
int d[N][N], c[N][N];
void __attribute__((noinline))
double_reduc (int n)
{
for (int k = 0; k < n; k++)
{
for (int l = 0; l < n; l++)
{
c[k][l] = 0;
for (int m = 0; m < n; m++)
c[k][l] += a[k][m][l] * d[k][m] + b[k][m][l] * d[k][m];
}
}
}
I dumped the file after loop interchange and got the following
information:
[local count: 118111600]:
# m_46 = PHI <0(7), m_45(11)>
# ivtmp_44 = PHI <_42(7), ivtmp_43(11)>
_39 = _49 + 1;
[local count: 955630224]:
# l_48 = PHI <0(3), l_47(12)>
# ivtmp_41 = PHI <_39(3), ivtmp_40(12)>
c_I_I_lsm.5_18 = c[k_28][l_48];
c_I_I_lsm.5_53 = m_46 != 0 ? c_I_I_lsm.5_18 : 0;
_2 = a[k_28][m_46][l_48];
_3 = d[k_28][m_46];
_4 = _2 * _3;
_5 = b[k_28][m_46][l_48];
_6 = _3 * _5;
_7 = _4 + _6;
_8 = _7 + c_I_I_lsm.5_53;
c[k_28][l_48] = _8;
l_47 = l_48 + 1;
ivtmp_40 = ivtmp_41 - 1;
if (ivtmp_40 != 0)
goto ; [89.00%]
else
goto ; [11.00%]
we can see '_3 = d[k_28][m_46];' is a loop invariant.
Do we need to add a loop invariant motion pass after the loop
interchange?
There is one at the end of the loop pipeline.
Hi,
The one at the end of the loop pipeline may miss some optimization
opportunities. If we vectorize the above code (a.c.158t.vect), we
can get information similar to the following:
bb 3:
# m_46 = PHI <0(7), m_45(11)> // loop m, outer loop
if (_59 <= 2)
goto bb 20;
else
goto bb 15;
bb 15:
_89 = d[k_28][m_46];
vect_cst__90 = {_89, _89, _89, _89};
bb 4:
# l_48 = PHI // loop l, inner loop
vect__6.23_100 = vect_cst__99 * vect__5.22_98;
if (ivtmp_110 < bnd.8_1)
goto bb 12;
else
goto bb 17;
bb 20:
bb 18:
_27 = d[k_28][m_46];
if (ivtmp_12 != 0)
goto bb 19;
else
goto bb 21;
Vectorization will do some conversions in this case. We can see
‘ _89 = d[k_28][m_46];’ and ‘_27 = d[k_28][m_46];’ are loop invariant
relative to loop l. We can move ‘d[k_28][m_46]’ to the front of
‘if (_59 <= 2)’ to get rid of loading data from memory in both
branches.
The one at at the end of the loop pipeline can't handle this situation.
If we move d[k_28][m_46] from loop l to loop m before doing
vectorization, we can get rid of this situation.
But we can't run every pass after every other. With multiple passes having
ordering issues is inevitable.
Now - interchange could trigger a region based invariant motion just for the
nest it interchanged. But that doesn't exist right now.
With data reference/dependence information in the pass, I think it
could be quite straightforward. Didn't realize that we need it
before.
FYI, attachment is a simple fix in loop interchange for the reported
issue. It's untested, neither for GCC10.
Hi,
Thank you for providing a patch so quickly. I did some tests for this
patch.
I found it will cause some test cases failed such as
testsuite/gfortran.dg/vect/pr81303.f.
And I also found that this patch can’t do loop invariant motion in some
cases.
Take pr81303.f as an example
[local count: 118111600]:
# m_55 = PHI <1(9), m_81(20)> // loop m, outer loop
# ivtmp_82 = PHI <_167(9), ivtmp_169(20)>
inv_temp_439 = (*x_138(D))[_94];
inv_temp_440 = (*x_138(D))[_85];
inv_temp_441 = (*x_138(D))[_76];
inv_temp_442 = (*x_138(D))[_68];
inv_temp_443 = (*x_138(D))[_58];
inv_temp_444 = (*x_138(D))[_49];
inv_temp_445 = (*x_138(D))[_41];
_446 = _21 + 1;
[local count: 955630224]:
# l_32 = PHI <1(12), l_54(21)> // loop l, inner loop
# ivtmp_165 = PHI <_446(12), ivtmp_155(21)>
_26 = (integer(kind=8)) l_32;
_27 = _25 + _26;
y__I_lsm.119_136 = (*y_135(D))[_27];
y__I_lsm.119_90 = m_55 != 1 ? y__I_lsm.119_136 : 0.0;
_36 = (integer(kind=8)) m_55;
_37 = _36 * stride.88_111;
_38 = _35 + _37;
_39 = _26 + _38;
_40 = (*a_137(D))[_39];
_41 = _25 + _36;
_42 = inv_temp_445;
_43 = _40 * _42;
_45 = (*axp_139(D))[_39];
We can see that variables such as inv_temp_439 moved to outer loop m.
However, loop invariants such as _36, _37 do not moved to outer loop m.
--
BR,
Lijia He
Thanks,
bin
Thanks,
bin
Richard.
Re: Do we need to do a loop invariant motion after loop interchange ?
On Mon, Nov 25, 2019 at 5:29 PM Li Jia He wrote:
>
>
>
> On 2019/11/24 2:26 PM, Bin.Cheng wrote:
> > On Fri, Nov 22, 2019 at 3:23 PM Bin.Cheng wrote:
> >>
> >> On Fri, Nov 22, 2019 at 3:19 PM Richard Biener
> >> wrote:
> >>>
> >>> On November 22, 2019 6:51:38 AM GMT+01:00, Li Jia He
> >>> wrote:
>
>
> On 2019/11/21 8:10 PM, Richard Biener wrote:
> > On Thu, Nov 21, 2019 at 10:22 AM Li Jia He
> wrote:
> >>
> >> Hi,
> >>
> >> I found for the follow code:
> >>
> >> #define N 256
> >> int a[N][N][N], b[N][N][N];
> >> int d[N][N], c[N][N];
> >> void __attribute__((noinline))
> >> double_reduc (int n)
> >> {
> >> for (int k = 0; k < n; k++)
> >> {
> >>for (int l = 0; l < n; l++)
> >> {
> >> c[k][l] = 0;
> >>for (int m = 0; m < n; m++)
> >> c[k][l] += a[k][m][l] * d[k][m] + b[k][m][l] * d[k][m];
> >> }
> >> }
> >> }
> >>
> >> I dumped the file after loop interchange and got the following
> information:
> >>
> >> [local count: 118111600]:
> >> # m_46 = PHI <0(7), m_45(11)>
> >> # ivtmp_44 = PHI <_42(7), ivtmp_43(11)>
> >> _39 = _49 + 1;
> >>
> >> [local count: 955630224]:
> >> # l_48 = PHI <0(3), l_47(12)>
> >> # ivtmp_41 = PHI <_39(3), ivtmp_40(12)>
> >> c_I_I_lsm.5_18 = c[k_28][l_48];
> >> c_I_I_lsm.5_53 = m_46 != 0 ? c_I_I_lsm.5_18 : 0;
> >> _2 = a[k_28][m_46][l_48];
> >> _3 = d[k_28][m_46];
> >> _4 = _2 * _3;
> >> _5 = b[k_28][m_46][l_48];
> >> _6 = _3 * _5;
> >> _7 = _4 + _6;
> >> _8 = _7 + c_I_I_lsm.5_53;
> >> c[k_28][l_48] = _8;
> >> l_47 = l_48 + 1;
> >> ivtmp_40 = ivtmp_41 - 1;
> >> if (ivtmp_40 != 0)
> >>goto ; [89.00%]
> >> else
> >>goto ; [11.00%]
> >>
> >> we can see '_3 = d[k_28][m_46];' is a loop invariant.
> >> Do we need to add a loop invariant motion pass after the loop
> interchange?
> >
> > There is one at the end of the loop pipeline.
>
> Hi,
>
> The one at the end of the loop pipeline may miss some optimization
> opportunities. If we vectorize the above code (a.c.158t.vect), we
> can get information similar to the following:
>
> bb 3:
> # m_46 = PHI <0(7), m_45(11)> // loop m, outer loop
> if (_59 <= 2)
> goto bb 20;
> else
> goto bb 15;
>
> bb 15:
> _89 = d[k_28][m_46];
> vect_cst__90 = {_89, _89, _89, _89};
>
> bb 4:
> # l_48 = PHI // loop l, inner loop
> vect__6.23_100 = vect_cst__99 * vect__5.22_98;
> if (ivtmp_110 < bnd.8_1)
> goto bb 12;
> else
> goto bb 17;
>
> bb 20:
> bb 18:
> _27 = d[k_28][m_46];
> if (ivtmp_12 != 0)
> goto bb 19;
> else
> goto bb 21;
>
> Vectorization will do some conversions in this case. We can see
> ‘ _89 = d[k_28][m_46];’ and ‘_27 = d[k_28][m_46];’ are loop invariant
> relative to loop l. We can move ‘d[k_28][m_46]’ to the front of
> ‘if (_59 <= 2)’ to get rid of loading data from memory in both
> branches.
>
> The one at at the end of the loop pipeline can't handle this situation.
> If we move d[k_28][m_46] from loop l to loop m before doing
> vectorization, we can get rid of this situation.
> >>>
> >>> But we can't run every pass after every other. With multiple passes
> >>> having ordering issues is inevitable.
> >>>
> >>> Now - interchange could trigger a region based invariant motion just for
> >>> the nest it interchanged. But that doesn't exist right now.
> >> With data reference/dependence information in the pass, I think it
> >> could be quite straightforward. Didn't realize that we need it
> >> before.
> > FYI, attachment is a simple fix in loop interchange for the reported
> > issue. It's untested, neither for GCC10.
>
> Hi,
>
> Thank you for providing a patch so quickly. I did some tests for this
> patch.
> I found it will cause some test cases failed such as
> testsuite/gfortran.dg/vect/pr81303.f.
My bad. It fails because the patch only hoists memory reference, but
not variables used by it.
Thanks,
bin
> And I also found that this patch can’t do loop invariant motion in some
> cases.
> Take pr81303.f as an example
>
> [local count: 118111600]:
># m_55 = PHI <1(9), m_81(20)> // loop m, outer loop
># ivtmp_82 = PHI <_167(9), ivtmp_169(20)>
>inv_temp_439 = (*x_138(D))[_94];
>inv_temp_440 = (*x_138(D))[_85];
>inv_temp_441 = (*x_138(D))[_76];
>inv_temp_442 = (*x_138(D))[_68];
>inv_temp_443 = (*x_138(D))[_58];
>inv_temp_444 = (*x_138(D))[_49];
>inv_temp_445 = (*x_138(D))[_41];
>_446 = _21 + 1;
Split commit naming
I'm testing a gcc-conversion patch to implement the branchpoint fixes I identified for GCC branches where cvs2svn chose a bad parent for the branch-creation commit. With that patch, I see: # /branches/gcc-3_4-rhl-branch <80870>|<81014> reparent --use-order reposurgeon: couldn't match a name at <80870> And indeed, the relevant commit has "Legacy-ID: 80870.2" as a "[[Split portion of a mixed commit.]]" (where the SVN commit changed both gcc-3_3-branch and gcc-3_4-branch). My question is: is it a stable interface to reposurgeon that the portions of such a split commit will always be numbered in lexicographical order by branch name (or some other such well-defined stable ordering), so I can write <80870.2> in gcc.lift and know that some reposurgeon change won't accidentally make that refer to the portion of the commit on gcc-3_3-branch instead? -- Joseph S. Myers jos...@codesourcery.com
Branch and tag deletions
I'm looking at the sets of branches and tags resulting from a GCC repository conversion with reposurgeon. 1. I see 227 branches (and one tag) with names like cxx0x-concepts-branch-deleted-r131428-1 (this is out of 780 branches in total in a conversion of GCC history as of a few days ago). Can we tell reposurgeon not to create such branches (and tags)? I can't simply do "branch /-deleted-r/ delete" because that command doesn't take a regular expression. 2. gcc.lift has a series of "tag delete" commands, generally deleting tags that aren't official GCC releases or prereleases (many of which were artifacts of how creating such tags was necessary to track merges in the CVS and older SVN era). But some such commands are mysteriously failing to work. For example I see tag /ZLIB_/ delete reposurgeon: no tags matching /ZLIB_/ but there are tags ZLIB_1_1_3, ZLIB_1_1_4, ZLIB_1_2_1, ZLIB_1_2_3 left after the conversion. This isn't just an issue with regular expressions; I also see e.g. tag apple/ppc-import-20040330 delete reposurgeon: no tags matching apple/ppc-import-20040330 and again that tag exists after the conversion. -- Joseph S. Myers jos...@codesourcery.com
Re: PPC64 libmvec implementation of sincos
> > > > i wonder if gcc can auto-vectorize scalar sincos > > calls, the vectorizer seems to want the calls to > > have no side-effect, but attribute pure or const > > is not appropriate for sincos (which has no return > > value but takes writable pointer args) > > We have __builtin_cexpi for that but not sure if any of the mechanisms can > provide a mapping to a vectorized variant. > 1. Using flags -fopt-info-all and -fopt-info-internals, the failure to vectorize sincos is reported as "unsupported data-type: complex double". The default GCC behavior is to replace sincos calls with calls to __builtin_cexpi. 2. Using flags -fno-builtin-sincos and -fno-builtin-cexpi, the failure to vectorize sincos is different. In this case, the failure to vectorize is due to "number of iterations could not be computed". No calls to __builtin_cexpi; sincos calls retained. Questions: 1. Should we aim to provide a vectorized version of __builtin_cexpi? If so, it would have to be a PPC64-only vector __builtin-cexpi, right? 2. Or should we require that vectorized sincos be available only when -fno-builtin-sincos flag is used in compilation? I don't think we need to fix both types of vectorization failures in order to obtain sincos vectorization. Thanks. Bert.
GNU Mes 0.21 released
We are pleased to announce the release of GNU Mes 0.21, representing 54 commits over 10 weeks. Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap a GNU/Linux system without binary GNU toolchain or equivalent). See https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/ This release supports a Scheme-only bootstrap: Mes can now be built with Gash and the experimental Gash Core Utils instead of using GNU Awk, GNU Bash, the GNU Core Utilities, GNU Grep, GNU Gzip, GNU Make, GNU SED, and GNU Tar. Also, the Mes C Library now supports bootstrapping those. Finally, this release brings Mes as a package to Debian GNU/Linux. We are excited that the Nlnet Foundation[12] is now sponsoring this work! Next targets: - Introduce the Reduced Binaries Seed bootstrap to NixOS (Debian, Gentoo, ...?) - Scheme-only bootstrap: use Guile, Gash and Gash Core Utils to remove awk, bash, core utilities, grep, gzip, make, sed, tar, etc. from the Guix bootstrap binaries - ARM support - Full Source Bootstrap: compile Mes.c using M2-Planet - Reduced Binary Seed bootstrap for ARM - the Hurd Packages are available in Guix master. * About GNU Mes[0] brings a Reduced Binary Seed bootstrap[1] to GNU Guix[2]. This bootstrap has halved the size of opaque, uninspectable binaries that were needed to bootstrap Guix. The final goal is to help create a full source bootstrap as part of the bootstrappable builds[3] effort for any interested UNIX-like operating system. It consists of a mutual self-hosting Scheme interpreter written in ~5,000 LOC of simple C and a Nyacc-based C compiler written in Scheme. This mes.c is being simplified[4] to be transpiled by M2-Planet[5]. The Scheme interpreter has a Garbage Collector, a library of loadable Scheme modules-- notably Dominique Boucher's LALR[6], Pre-R6RS [portable syntax-case[7] with R7RS ellipsis, Matt Wette's Nyacc[8] --and test suite just enough to support a REPL and a C99 compiler: MesCC. Mes+MesCC can compile an only lightly patched TinyCC[9] that is self-hosting. Using this tcc and the Mes C library we now have a Reduced Binary Seed bootstrap for the gnutools triplet: glibc-2.2.5, binutils-2.20.1, gcc-2.95.3. This is enough to bootstrap Guix for i686-linux and x86_64-linux. Mes is inspired by The Maxwell Equations of Software: LISP-1.5[10] -- John McCarthy page 13, GNU Guix's source/binary packaging transparency and Jeremiah Orians's stage0[11] ~500 byte self-hosting hex assembler. * Download git clone git://git.savannah.gnu.org/mes.git Here are the compressed sources and a GPG detached signature[*]: https://ftp.gnu.org/gnu/mes/mes-0.21.tar.gz https://ftp.gnu.org/gnu/mes/mes-0.21.tar.gz.sig Use a mirror for higher download bandwidth: https://ftpmirror.gnu.org/mes/mes-0.21.tar.gz https://ftpmirror.gnu.org/mes/mes-0.21.tar.gz.sig Here are the MD5 and SHA1 checksums: dea43529d2d84fb4b9d81bdd9efcc715 mes-0.21.tar.gz 35721a81feeab6e0d5913b8bf78f18951edbb964 mes-0.21.tar.gz [*] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify mes-0.21.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.gnupg.net --recv-keys 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273 and rerun the 'gpg --verify' command. * Get informed, get involved See https://bootstrappable.org Join #bootstrappable on irc.freenode.net. * Changes in 0.21 since 0.20 ** Core *** Mes can now be bootstrapped with Gash and Gash Core Utils. *** Mes now supports a Scheme-only bootstrap. *** Mes now supports -c EXPR. ** MesCC *** Mes C Library now supports bootstrapping GNU Awk, GNU Bash, GNU SED, and GNU Tar. *** Mes C Library now has limited float support in vfprintf, vsnprintf, vsscanf. 7 new functions abtod, atof, creat, dtoab, execlp, isgraph, mknod, readlink, strtod, symlink. 5 new stubs getgrgid, getgrnam, getpgid, getpgrp, mktime, setgrent. ** Noteworthy bug fixes *** A bug with `mes -c EXPR' has been fixed. *** The REPL now works again on x86_64. *** --with-system-libc now works again. Greetings, janneke and Danny. [0] https://www.gnu.org/software/mes [1] https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/ [2] https://www.gnu.org/software/guix [3] https://bootstrappable.org [4] https://github.com/oriansj/mes-m2 [5] https://github.com/oriansj/m2-planet [6] https://github.com/schemeway/lalr-scm [7] https://www.cs.indiana.edu/chezscheme/syntax-case/old-psyntax.html [8] https://www.nongnu.org/nyacc [9] https://gitlab.com/janneke/tinycc [10] http://www.softwarepreservation.org/projects/LISP/book/LISP%201.5%20Programmers%20Manual.pdf [11] https://savannah.nongnu.org/projects/stage0 [12] https://nlnet
How to test aarch64 when building a cross-compiler?
Based on https://www.gnu.org/software/hurd/hurd/glibc.html, I'm using glibc/scripts/build-many-glibcs.py targeting aarch64-linux-gnu as so: build-many-glibcs.py build_dir checkout --keep all build-many-glibcs.py build_dir host-libraries --keep all -j 12 build-many-glibcs.py build_dir compilers aarch64-linux-gnu --keep all -j 12 --full-gcc build-many-glibcs.py build_dir glibcs aarch64-linux-gnu --keep all -j 12 This completes successfully. However, when I then try to run the gcc tests like so: runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite aarch64.exp --target aarch64-linux-gnu --target_board aarch64-sim --tool_exec /path_to/build_dir/install/compilers/aarch64-linux-gnu/bin/aarch64-glibc-linux-gnu-gcc --verbose -v I get errors like this: aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file 'rdimon.specs': No such file or directory I can see that the rdimon.specs flag is added based on this line in aarch64-sim.exp: set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags] -specs=rdimon.specs" I've tried searching for how to address this, but so far unsuccessfully. Does anybody know what I'm missing here? Thanks, Andrew
Re: How to test aarch64 when building a cross-compiler?
On Mon, 25 Nov 2019 at 20:17, Andrew Dean via gcc wrote: > > Based on https://www.gnu.org/software/hurd/hurd/glibc.html, I'm using > glibc/scripts/build-many-glibcs.py targeting aarch64-linux-gnu as so: > > build-many-glibcs.py build_dir checkout --keep all > > build-many-glibcs.py build_dir host-libraries --keep all -j 12 > > build-many-glibcs.py build_dir compilers aarch64-linux-gnu --keep all -j 12 > --full-gcc > build-many-glibcs.py build_dir glibcs aarch64-linux-gnu --keep all -j 12 > > This completes successfully. However, when I then try to run the gcc tests > like so: > runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite aarch64.exp > --target aarch64-linux-gnu --target_board aarch64-sim --tool_exec > /path_to/build_dir/install/compilers/aarch64-linux-gnu/bin/aarch64-glibc-linux-gnu-gcc > --verbose -v > > I get errors like this: > > aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file > 'rdimon.specs': No such file or directory > > I can see that the rdimon.specs flag is added based on this line in > aarch64-sim.exp: Where does aarch64-sim.exp comes from? > > set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags] > -specs=rdimon.specs" > I think this is for baremetal/newlib targets, ie. aarch64-elf, not for aarch64-linux-gnu. > I've tried searching for how to address this, but so far unsuccessfully. Does > anybody know what I'm missing here? > > Thanks, > Andrew
RE: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?
> > This completes successfully. However, when I then try to run the gcc tests > > like > so: > > runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite > > aarch64.exp --target aarch64-linux-gnu --target_board aarch64-sim > > --tool_exec > > /path_to/build_dir/install/compilers/aarch64-linux-gnu/bin/aarch64-gli > > bc-linux-gnu-gcc --verbose -v > > > > I get errors like this: > > > > aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file > > 'rdimon.specs': No such file or directory > > > > I can see that the rdimon.specs flag is added based on this line in aarch64- > sim.exp: > > Where does aarch64-sim.exp comes from? /usr/share/dejagnu/baseboards/aarch64-sim.exp > > > > > set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags] - > specs=rdimon.specs" > > > I think this is for baremetal/newlib targets, ie. aarch64-elf, not for > aarch64- > linux-gnu. Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or aarch64-linux-elf... I get a KeyError in build_compilers and build_glibcs when it tries to look up the config with either of those values.
Re: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?
On 25/11/2019 17:28, Andrew Dean via gcc wrote: >>> This completes successfully. However, when I then try to run the gcc tests >>> like >> so: >>> runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite >>> aarch64.exp --target aarch64-linux-gnu --target_board aarch64-sim >>> --tool_exec >>> /path_to/build_dir/install/compilers/aarch64-linux-gnu/bin/aarch64-gli >>> bc-linux-gnu-gcc --verbose -v >>> >>> I get errors like this: >>> >>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file >>> 'rdimon.specs': No such file or directory >>> >>> I can see that the rdimon.specs flag is added based on this line in aarch64- >> sim.exp: >> >> Where does aarch64-sim.exp comes from? > > /usr/share/dejagnu/baseboards/aarch64-sim.exp > >> >>> >>> set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags] - >> specs=rdimon.specs" >>> >> I think this is for baremetal/newlib targets, ie. aarch64-elf, not for >> aarch64- >> linux-gnu. > > Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or > aarch64-linux-elf... > I get a KeyError in build_compilers and build_glibcs when it tries to look up > the config with either of those values. > Unfortunately the build-many-glibcs.py does not have support for baremetal build yet (since it is a tool created to build cross-compiling toolchain using glibc).
Re: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?
On Mon, Nov 25, 2019 at 8:40 PM Adhemerval Zanella wrote: > > > > On 25/11/2019 17:28, Andrew Dean via gcc wrote: > >>> This completes successfully. However, when I then try to run the gcc > >>> tests like > >> so: > >>> runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite > >>> aarch64.exp --target aarch64-linux-gnu --target_board aarch64-sim > >>> --tool_exec > >>> /path_to/build_dir/install/compilers/aarch64-linux-gnu/bin/aarch64-gli > >>> bc-linux-gnu-gcc --verbose -v > >>> > >>> I get errors like this: > >>> > >>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file > >>> 'rdimon.specs': No such file or directory > >>> > >>> I can see that the rdimon.specs flag is added based on this line in > >>> aarch64- > >> sim.exp: > >> > >> Where does aarch64-sim.exp comes from? > > > > /usr/share/dejagnu/baseboards/aarch64-sim.exp > > > >> > >>> > >>> set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags] - > >> specs=rdimon.specs" > >>> > >> I think this is for baremetal/newlib targets, ie. aarch64-elf, not for > >> aarch64- > >> linux-gnu. > > Yes -specs=rdimon.specs and other such flags are for use only on bare-metal targets. > > Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or > > aarch64-linux-elf... > > I get a KeyError in build_compilers and build_glibcs when it tries to look > > up the config with either of those values. > > > > Unfortunately the build-many-glibcs.py does not have support for baremetal > build yet (since it is a tool created to build cross-compiling toolchain > using glibc). And glibc doesn't work bare-metal .. regards Ramana
Questions about where to find information on IPO state in GCC
Greetings Richard, After looking through the current work on multi-threading seems that we can scale better with a workqueue strategy sharing and launching depending on how state is shared between the GCC passes. I'm not very familiar with all the details of how state is share in the GIMPLE,RTL or SSA passes so I was wondering where to find information on this. The manual only seems to mention the pass manager and its interactions with passes for running them. Thanks, Nick
RE: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?
> > >>> I get errors like this: > > >>> > > >>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file > > >>> 'rdimon.specs': No such file or directory > > >>> > > >>> I can see that the rdimon.specs flag is added based on this line > > >>> in aarch64- > > >> sim.exp: > > >> > > >> Where does aarch64-sim.exp comes from? > > > > > > /usr/share/dejagnu/baseboards/aarch64-sim.exp > > > > > >> > > >>> > > >>> set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags] > > >>> - > > >> specs=rdimon.specs" > > >>> > > >> I think this is for baremetal/newlib targets, ie. aarch64-elf, not > > >> for aarch64- linux-gnu. > > > > > Yes -specs=rdimon.specs and other such flags are for use only on bare-metal > targets. > > > > Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or > > > aarch64-linux- > elf... > > > I get a KeyError in build_compilers and build_glibcs when it tries to > > > look up > the config with either of those values. > > > > > > > Unfortunately the build-many-glibcs.py does not have support for > > baremetal build yet (since it is a tool created to build > > cross-compiling toolchain using glibc). > > And glibc doesn't work bare-metal .. > > regards > Ramana I guess that means that the dejagnu baseboard "aarch64-sim" is only meant to do bare-metal testing? How would one build/test GCC hosted on x86_64 and targeting aarch64 then? Is there a different simulator approach I should be using?
Re: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?
On Mon, Nov 25, 2019 at 9:43 PM Andrew Dean wrote: > > > > >>> I get errors like this: > > > >>> > > > >>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file > > > >>> 'rdimon.specs': No such file or directory > > > >>> > > > >>> I can see that the rdimon.specs flag is added based on this line > > > >>> in aarch64- > > > >> sim.exp: > > > >> > > > >> Where does aarch64-sim.exp comes from? > > > > > > > > /usr/share/dejagnu/baseboards/aarch64-sim.exp > > > > > > > >> > > > >>> > > > >>> set_board_info ldflags "[libgloss_link_flags] [newlib_link_flags] > > > >>> - > > > >> specs=rdimon.specs" > > > >>> > > > >> I think this is for baremetal/newlib targets, ie. aarch64-elf, not > > > >> for aarch64- linux-gnu. > > > > > > > > Yes -specs=rdimon.specs and other such flags are for use only on bare-metal > > targets. > > > > > > Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or > > > > aarch64-linux- > > elf... > > > > I get a KeyError in build_compilers and build_glibcs when it tries to > > > > look up > > the config with either of those values. > > > > > > > > > > Unfortunately the build-many-glibcs.py does not have support for > > > baremetal build yet (since it is a tool created to build > > > cross-compiling toolchain using glibc). > > > > And glibc doesn't work bare-metal .. > > > > regards > > Ramana > I guess that means that the dejagnu baseboard "aarch64-sim" is only meant to > do bare-metal testing? How would one build/test GCC hosted on x86_64 and > targeting aarch64 then? Is there a different simulator approach I should be > using? For cross-compilers with Linux, you've got 2 options - write up a board file to use qemu in user-emulation mode or indeed system emulation mode or use real hardware and construct something using ssh / scp. R
Re: Split commit naming
Joseph Myers : > My question is: is it a stable interface to reposurgeon that the portions > of such a split commit will always be numbered in lexicographical order by > branch name (or some other such well-defined stable ordering), so I can > write <80870.2> in gcc.lift and know that some reposurgeon change won't > accidentally make that refer to the portion of the commit on > gcc-3_3-branch instead? Your timing is fortuitous, as I just finished rewriting the code for mixed-commit handling and it is fresh in my mind. The old behavior was indeed that cliques were lexicographically ordered by branch. This was not documented. The master branch still uses the old code. Current behavior on my development branch is that fileops are not sorted before splitting; you get whatever order they had in the dump. I will change this so they are sorted by pathname and document that. And...it's done. You won't see the new code for a few days, until I finish the analyzer rewrite. The old code had become overgrown and brittle; I spent a week trying to find a strategy to get around a particular pathological-tag defect only to discover that I could no longer modify the analyzer without cascade bugs. I'll describe the problem, since I think the GCC repository has some of these and they may explain some of your earlier bug reports. Suppose you create a tag, then later on modify the tag copy by copying to one of its subdirectories. When translating to git you want to attach the tag reference to the revision the *second* copy came from. Simple in concept but the obvious implementation of root-finding prefers the earliest copy. When it proved impossible to change this wthout producing a cascade of breakage, I faced up to the necessity of a scrap-and-rebuild. It's not done yet, but it's pretty well advanced. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: GNU Mes 0.21 released
Jan Nieuwenhuizen writes: > We are pleased to announce the release of GNU Mes 0.21, representing > 54 commits over 10 weeks. > > Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap > a GNU/Linux system without binary GNU toolchain or equivalent). See > https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/ > > This release supports a Scheme-only bootstrap: Mes can now be built with > Gash and the experimental Gash Core Utils instead of using GNU Awk, GNU > Bash, the GNU Core Utilities, GNU Grep, GNU Gzip, GNU Make, GNU SED, and > GNU Tar. Also, the Mes C Library now supports bootstrapping those. > Finally, this release brings Mes as a package to Debian GNU/Linux. > > We are excited that the Nlnet Foundation[12] is now sponsoring this > work! > > Next targets: > > - Introduce the Reduced Binaries Seed bootstrap to NixOS (Debian, >Gentoo, ...?) > - Scheme-only bootstrap: use Guile, Gash and Gash Core Utils to remove >awk, bash, core utilities, grep, gzip, make, sed, tar, etc. from the >Guix bootstrap binaries > - ARM support > - Full Source Bootstrap: compile Mes.c using M2-Planet > - Reduced Binary Seed bootstrap for ARM > - the Hurd > > Packages are available in Guix master. > > * About > > GNU Mes[0] brings a Reduced Binary Seed bootstrap[1] to GNU Guix[2]. > This bootstrap has halved the size of opaque, uninspectable binaries > that were needed to bootstrap Guix. The final goal is to help create > a full source bootstrap as part of the bootstrappable builds[3] effort > for any interested UNIX-like operating system. > > It consists of a mutual self-hosting Scheme interpreter written in > ~5,000 LOC of simple C and a Nyacc-based C compiler written in Scheme. > This mes.c is being simplified[4] to be transpiled by M2-Planet[5]. > > The Scheme interpreter has a Garbage Collector, a library of loadable > Scheme modules-- notably Dominique Boucher's LALR[6], Pre-R6RS > [portable syntax-case[7] with R7RS ellipsis, Matt Wette's Nyacc[8] > --and test suite just enough to support a REPL and a C99 compiler: > MesCC. > > Mes+MesCC can compile an only lightly patched TinyCC[9] that is > self-hosting. Using this tcc and the Mes C library we now have a > Reduced Binary Seed bootstrap for the gnutools triplet: glibc-2.2.5, > binutils-2.20.1, gcc-2.95.3. This is enough to bootstrap Guix for > i686-linux and x86_64-linux. > > Mes is inspired by The Maxwell Equations of Software: LISP-1.5[10] -- John > McCarthy page 13, GNU Guix's source/binary packaging transparency and > Jeremiah Orians's stage0[11] ~500 byte self-hosting hex assembler. > > * Download > > git clone git://git.savannah.gnu.org/mes.git > > Here are the compressed sources and a GPG detached signature[*]: > https://ftp.gnu.org/gnu/mes/mes-0.21.tar.gz > https://ftp.gnu.org/gnu/mes/mes-0.21.tar.gz.sig > > Use a mirror for higher download bandwidth: > https://ftpmirror.gnu.org/mes/mes-0.21.tar.gz > https://ftpmirror.gnu.org/mes/mes-0.21.tar.gz.sig > > Here are the MD5 and SHA1 checksums: > > dea43529d2d84fb4b9d81bdd9efcc715 mes-0.21.tar.gz > 35721a81feeab6e0d5913b8bf78f18951edbb964 mes-0.21.tar.gz > > [*] Use a .sig file to verify that the corresponding file (without the > .sig suffix) is intact. First, be sure to download both the .sig file > and the corresponding tarball. Then, run a command like this: > > gpg --verify mes-0.21.tar.gz.sig > > If that command fails because you don't have the required public key, > then run this command to import it: > > gpg --keyserver keys.gnupg.net --recv-keys > 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273 > > and rerun the 'gpg --verify' command. > > * Get informed, get involved > > See https://bootstrappable.org > Join #bootstrappable on irc.freenode.net. > > * Changes in 0.21 since 0.20 > ** Core > *** Mes can now be bootstrapped with Gash and Gash Core Utils. > *** Mes now supports a Scheme-only bootstrap. > *** Mes now supports -c EXPR. > ** MesCC > *** Mes C Library now supports bootstrapping GNU Awk, GNU Bash, GNU SED, and > GNU Tar. > *** Mes C Library now has limited float support in vfprintf, vsnprintf, > vsscanf. > 7 new functions > abtod, atof, creat, dtoab, execlp, isgraph, mknod, readlink, strtod, > symlink. > 5 new stubs > getgrgid, getgrnam, getpgid, getpgrp, mktime, setgrent. > ** Noteworthy bug fixes > *** A bug with `mes -c EXPR' has been fixed. > *** The REPL now works again on x86_64. > *** --with-system-libc now works again. > > Greetings, > janneke and Danny. > > [0] https://www.gnu.org/software/mes > [1] https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/ > [2] https://www.gnu.org/software/guix > [3] https://bootstrappable.org > [4] https://github.com/oriansj/mes-m2 > [5] https://github.com/oriansj/m2-planet > [6] https://github.com/schemeway/lalr-scm > [7] https://www.cs.indiana.edu/chezscheme/syntax-case/old-p
Re: Branch and tag deletions
Joseph Myers : > I'm looking at the sets of branches and tags resulting from a GCC > repository conversion with reposurgeon. > > 1. I see 227 branches (and one tag) with names like > cxx0x-concepts-branch-deleted-r131428-1 (this is out of 780 branches in > total in a conversion of GCC history as of a few days ago). Can we tell > reposurgeon not to create such branches (and tags)? I can't simply do > "branch /-deleted-r/ delete" because that command doesn't take a regular > expression. Those dead branches were supposed to never be visible in the final conversion. They arise when a tag is created, then deleted, then recreated under the same name. The dumpfile operations for the old tag can't simply ignored, as part of its content could get copied forward from before the delete to a branch that remains live. So I recolor them, then have logic to skip generating commits and tags from them. You;re seeing dome leak through those guards, which is a bug. I'm using a different and much simpler strategy in the analyzer rewrite; this bug should be squashed when it lands. > 2. gcc.lift has a series of "tag delete" commands, generally > deleting tags that aren't official GCC releases or prereleases (many of > which were artifacts of how creating such tags was necessary to track > merges in the CVS and older SVN era). But some such commands are > mysteriously failing to work. For example I see > > tag /ZLIB_/ delete > reposurgeon: no tags matching /ZLIB_/ > > but there are tags ZLIB_1_1_3, ZLIB_1_1_4, ZLIB_1_2_1, ZLIB_1_2_3 left > after the conversion. This isn't just an issue with regular expressions; > I also see e.g. > > tag apple/ppc-import-20040330 delete > reposurgeon: no tags matching apple/ppc-import-20040330 > > and again that tag exists after the conversion. I knew there was a problem with those, but I have not diagnosed it yet. I know generally where it has to be and think it will be relatively easy to clean up once I've dealt with the more pressing issues. Please file issues about these bugs so I can track then. On the first one, it would be helpful if you could list some tags that these match expressions fail to pick up from as early as possible. Shortening the leading segment I need to load speeds up my test cycle significantly, -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: GNU Mes 0.21 released
Congrats! On Tue, Nov 26, 2019, 11:11 Brett Gilio wrote: > Jan Nieuwenhuizen writes: > > > We are pleased to announce the release of GNU Mes 0.21, representing > > 54 commits over 10 weeks. > > > > Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap > > a GNU/Linux system without binary GNU toolchain or equivalent). See > > https://guix.gnu.org/blog/2019/guix-reduces-bootstrap-seed-by-50/ > > > > This release supports a Scheme-only bootstrap: Mes can now be built with > > Gash and the experimental Gash Core Utils instead of using GNU Awk, GNU > > Bash, the GNU Core Utilities, GNU Grep, GNU Gzip, GNU Make, GNU SED, and > > GNU Tar. Also, the Mes C Library now supports bootstrapping those. > > Finally, this release brings Mes as a package to Debian GNU/Linux. > > > > We are excited that the Nlnet Foundation[12] is now sponsoring this > > work! > > > > Next targets: > > > > - Introduce the Reduced Binaries Seed bootstrap to NixOS (Debian, > >Gentoo, ...?) > > - Scheme-only bootstrap: use Guile, Gash and Gash Core Utils to remove > >awk, bash, core utilities, grep, gzip, make, sed, tar, etc. from the > >Guix bootstrap binaries > > - ARM support > > - Full Source Bootstrap: compile Mes.c using M2-Planet > > - Reduced Binary Seed bootstrap for ARM > > - the Hurd > > > > Packages are available in Guix master. > > > > * About > > > > GNU Mes[0] brings a Reduced Binary Seed bootstrap[1] to GNU Guix[2]. > > This bootstrap has halved the size of opaque, uninspectable binaries > > that were needed to bootstrap Guix. The final goal is to help create > > a full source bootstrap as part of the bootstrappable builds[3] effort > > for any interested UNIX-like operating system. > > > > It consists of a mutual self-hosting Scheme interpreter written in > > ~5,000 LOC of simple C and a Nyacc-based C compiler written in Scheme. > > This mes.c is being simplified[4] to be transpiled by M2-Planet[5]. > > > > The Scheme interpreter has a Garbage Collector, a library of loadable > > Scheme modules-- notably Dominique Boucher's LALR[6], Pre-R6RS > > [portable syntax-case[7] with R7RS ellipsis, Matt Wette's Nyacc[8] > > --and test suite just enough to support a REPL and a C99 compiler: > > MesCC. > > > > Mes+MesCC can compile an only lightly patched TinyCC[9] that is > > self-hosting. Using this tcc and the Mes C library we now have a > > Reduced Binary Seed bootstrap for the gnutools triplet: glibc-2.2.5, > > binutils-2.20.1, gcc-2.95.3. This is enough to bootstrap Guix for > > i686-linux and x86_64-linux. > > > > Mes is inspired by The Maxwell Equations of Software: LISP-1.5[10] -- > John > > McCarthy page 13, GNU Guix's source/binary packaging transparency and > > Jeremiah Orians's stage0[11] ~500 byte self-hosting hex assembler. > > > > * Download > > > > git clone git://git.savannah.gnu.org/mes.git > > > > Here are the compressed sources and a GPG detached signature[*]: > > https://ftp.gnu.org/gnu/mes/mes-0.21.tar.gz > > https://ftp.gnu.org/gnu/mes/mes-0.21.tar.gz.sig > > > > Use a mirror for higher download bandwidth: > > https://ftpmirror.gnu.org/mes/mes-0.21.tar.gz > > https://ftpmirror.gnu.org/mes/mes-0.21.tar.gz.sig > > > > Here are the MD5 and SHA1 checksums: > > > > dea43529d2d84fb4b9d81bdd9efcc715 mes-0.21.tar.gz > > 35721a81feeab6e0d5913b8bf78f18951edbb964 mes-0.21.tar.gz > > > > [*] Use a .sig file to verify that the corresponding file (without the > > .sig suffix) is intact. First, be sure to download both the .sig file > > and the corresponding tarball. Then, run a command like this: > > > > gpg --verify mes-0.21.tar.gz.sig > > > > If that command fails because you don't have the required public key, > > then run this command to import it: > > > > gpg --keyserver keys.gnupg.net --recv-keys > 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273 > > > > and rerun the 'gpg --verify' command. > > > > * Get informed, get involved > > > > See https://bootstrappable.org > > Join #bootstrappable on irc.freenode.net. > > > > * Changes in 0.21 since 0.20 > > ** Core > > *** Mes can now be bootstrapped with Gash and Gash Core Utils. > > *** Mes now supports a Scheme-only bootstrap. > > *** Mes now supports -c EXPR. > > ** MesCC > > *** Mes C Library now supports bootstrapping GNU Awk, GNU Bash, GNU > SED, and GNU Tar. > > *** Mes C Library now has limited float support in vfprintf, vsnprintf, > vsscanf. > > 7 new functions > > abtod, atof, creat, dtoab, execlp, isgraph, mknod, readlink, strtod, > > symlink. > > 5 new stubs > > getgrgid, getgrnam, getpgid, getpgrp, mktime, setgrent. > > ** Noteworthy bug fixes > > *** A bug with `mes -c EXPR' has been fixed. > > *** The REPL now works again on x86_64. > > *** --with-system-libc now works again. > > > > Greetings, > > janneke and Danny. > > > > [0] https://www.gnu.org/software/mes > > [1] https://guix.gnu.org/blog/2019/gu
