Re: PPC64 libmvec implementation of sincos
On Mon, Nov 25, 2019 at 5:53 PM GT wrote: > > > > > > > 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. I think we should have a vectorized cexpi since that's having a sane ABI. The complex return type of cexpi makes it a little awkward for the vectorizer but handling this should be manageable. It's a bit difficult to expose complex types to the vectorizer since most cases are lowered early. Richard. > Thanks. > Bert.
Re: Branch and tag deletions
> On Nov 25, 2019, at 7:07 PM, Joseph Myers wrote: > > 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. IMO, we should aim to convert complete SVN history frozen at a specific point. So that if we don't want to convert some of the branches or tags to git, then we should delete them from SVN repository before conversion. Otherwise it will (a) complicate comparison or repos converted by different tools, and (b) will require us to remember why parts of SVN history were not converted to git. My conversion at https://git.linaro.org/people/maxim-kuvyrkov/gcc-pretty.git/ contains all branches and tags present in current SVN repo. -- Maxim Kuvyrkov https://www.linaro.org
Re: Branch and tag deletions
On Wed, 27 Nov 2019, Maxim Kuvyrkov wrote: > IMO, we should aim to convert complete SVN history frozen at a specific > point. So that if we don't want to convert some of the branches or tags > to git, then we should delete them from SVN repository before > conversion. Sure, we could do that. Eric, can you confirm that, with current reposurgeon, if a branch or tag was deleted in SVN and does not appear in the final revision of /branches or /tags, it should not appear in the resulting converted repository, so that any cases where reposurgeon fails to reflect such a deletion-in-SVN should be reported as a reposurgeon bug? And that the same applies where a branch or tag was renamed - that only the new name, not the old one, should appear in the converted repository? There are quite a few deletions in gcc.lift for tags that do not actually appear in /tags in the current SVN repository, but I'm not sure how many are actually relevant with current reposurgeon. Then there is the policy question to resolve about which tags we actually want to keep (I'm presuming we want to keep essentially all branches by default, absent any clear malformations that make us decide to delete a given branch). Tags in the following classes make up the bulk of those currently in the SVN repository, and right now are deleted in gcc.lift under the comment "Tentative tag removals - might be backed out": (a) Tags for branchpoints and tracking merge status - largely from the CVS era when they were needed to work around the lack of a global version number for the whole source tree, but also from the early SVN era when there were global revision numbers but SVN merge tracking hadn't yet been implemented. (b) Tags for vendor-branch imports of third-party software (maybe tagging just part of the source tree, in the CVS era). That's the GC_*, LIBTOOL_* and ZLIB_* tags, for example. (c) Tags for other (non-GCC) projects, from when ,v files were linked between different repositories (most of those have already been deleted in SVN, however). (d) Tags for snapshots (most of those have already been deleted in SVN, however). (e) Tags with the same names as branches (at least three of them). Formally that's valid in git just as it is in SVN - there's no conflict between refs/heads/ and refs/tags/ - but in practice it's confusing and such tags were surely created by mistake. (f) Tags for distributor releases as opposed to official GCC / EGCS releases. All of the above except for (f) are not particularly idiomatic to have in git, simply because git tracks merges and a global commit identifier can be used to refer to a snapshot etc. rather than needing a tag. (Because SVN does merge tracking, I don't think many tags in the classes (a) through (e) have been created recently in SVN either - they are generally from the CVS or early SVN eras, or created by mistake.) So what do people think about tags in the above classes? Should some or all of those be deleted in SVN? (Note: my checks of parents for cvs2svn-created tags were limited to those currently kept by gcc.lift. If we decide to keep more tags from the cvs2svn era I'll need to run further checks of tag parents.) -- Joseph S. Myers jos...@codesourcery.com
Re: Branch and tag deletions
Joseph Myers : > On Wed, 27 Nov 2019, Maxim Kuvyrkov wrote: > > > IMO, we should aim to convert complete SVN history frozen at a specific > > point. So that if we don't want to convert some of the branches or tags > > to git, then we should delete them from SVN repository before > > conversion. > > Sure, we could do that. Eric, can you confirm that, with current > reposurgeon, if a branch or tag was deleted in SVN and does not appear in > the final revision of /branches or /tags, it should not appear in the > resulting converted repository, so that any cases where reposurgeon fails > to reflect such a deletion-in-SVN should be reported as a reposurgeon bug? Confirmed. The ontological mismatch between the Subversion and Git data models actually *forces* us to pick a preferred view and discard tags and branches that are not visible from that view. For obvious reasons reposurgeon chooses the view backwards from the end of the history, so it will be the most recent incarnation of each tag and branch that you see. There is an alternative, the --nobranch conversion. This would preserve the entire historical structure, including deleted tags and branches, but the cost is that the conversion doesn't have git tags and branches itself - it's just one big directory history on /refs/heads/master. While this is useful for forensics, it is not a conversion you'd want to use for production. > And that the same applies where a branch or tag was renamed - that only > the new name, not the old one, should appear in the converted repository? Confirmed, see above. > There are quite a few deletions in gcc.lift for tags that do not actually > appear in /tags in the current SVN repository, but I'm not sure how many > are actually relevant with current reposurgeon. Many will not be. The recipe file predates the point at which I came to fully undersrand the ramifications of tag delete/recreate sequences. I haven't cleaned it up yet because chasing down the last few bugs in the analyzer is more important. I'll leave it to you guys to discuss the policy issues. In general I think you can safely throw out branchphoint tagas and emptycommits; reposurgeon only preserves those on the theoretical chance that there might be something interesting in the change comments. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Branch and tag deletions
On Wed, 27 Nov 2019, Eric S. Raymond wrote: > > Sure, we could do that. Eric, can you confirm that, with current > > reposurgeon, if a branch or tag was deleted in SVN and does not appear in > > the final revision of /branches or /tags, it should not appear in the > > resulting converted repository, so that any cases where reposurgeon fails > > to reflect such a deletion-in-SVN should be reported as a reposurgeon bug? > > Confirmed. Thanks. My current test conversion run is testing two changes: deleting emptycommit tags, and using --user-ignores to prefer the .gitignore file in SVN over one auto-generated from svn:ignore properties. For the next one after that I'll try eliminating all branch/tag removals that shouldn't be doing anything, based on the current sets of branches and tags in SVN, and report bugs if I see anything appearing in the converted repository that shouldn't be. -- Joseph S. Myers jos...@codesourcery.com
Re: Branch and tag deletions
Joseph Myers : > My current test conversion run is testing two changes: deleting > emptycommit tags, and using --user-ignores to prefer the .gitignore file > in SVN over one auto-generated from svn:ignore properties. For the next > one after that I'll try eliminating all branch/tag removals that shouldn't > be doing anything, based on the current sets of branches and tags in SVN, > and report bugs if I see anything appearing in the converted repository > that shouldn't be. I'm more worried about missing files. I saw a bunch of those on my last test. This could be spurious - the elaborate set of branch mappings you specified confuses my validation test, because there is no longer a 1-1 corresponsence between Subversion and git branches. The next test I run I'm going to comment out your branch mappings. If I get a validated conversion out of that I think it's all over but the cleanup and policy tinkering. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Branch and tag deletions
On Wed, 27 Nov 2019, Eric S. Raymond wrote: > Joseph Myers : > > My current test conversion run is testing two changes: deleting > > emptycommit tags, and using --user-ignores to prefer the .gitignore file > > in SVN over one auto-generated from svn:ignore properties. For the next > > one after that I'll try eliminating all branch/tag removals that shouldn't > > be doing anything, based on the current sets of branches and tags in SVN, > > and report bugs if I see anything appearing in the converted repository > > that shouldn't be. > > I'm more worried about missing files. I saw a bunch of those on my > last test. This could be spurious - the elaborate set of branch > mappings you specified confuses my validation test, because there is > no longer a 1-1 corresponsence between Subversion and git branches. I'm hoping any such missing file problems come from bugs in the old SVN dump reader with complicated commits mixing copies / deletions / replacements with copies from other locations and that your rewrite will fix the semantics in such cases. All the current gcc-conversion merge requests, both mine and Richard's, should now be set to allow rebasing. -- Joseph S. Myers jos...@codesourcery.com
RE: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?
> On 11/25/19 2:43 PM, Andrew Dean via gcc 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?
> I've used qemu for this kind of testing. In my environment I have root
> filesystems with native binaries/libraries. I can just chroot into those
> filesystems and qemu handles everything.
>
> In theory one wouldn't even need to chroot into the filesystems if you set the
> library paths right.
>
> jeff
Thanks, Jeff. qemu did the trick. Specifically, I did the following:
1. sudo apt-get install qemu-user-static
2. export
LD_LIBRARY_PATH=${BuildRoot}/install/glibcs/aarch64-linux-gnu/lib64:${BuildRoot}/install/compilers/aarch64-linux-gnu/aarch64-glibc-linux-gnu/lib64
3. sudo ln -s
${BuildRoot}/install/glibcs/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1
/lib/ld-linux-aarch64.so.1
4. Run the gcc tests as previously described
5. Remove the symlink
6. Restore the previous value of LD_LIBRARY_PATH
There are still a few test failures that we will need to investigate, but this
was a huge leap forward.
Re: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?
On Nov 27 2019, Andrew Dean via gcc wrote:
> 2. export
> LD_LIBRARY_PATH=${BuildRoot}/install/glibcs/aarch64-linux-gnu/lib64:${BuildRoot}/install/compilers/aarch64-linux-gnu/aarch64-glibc-linux-gnu/lib64
>
> 3. sudo ln -s
> ${BuildRoot}/install/glibcs/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1
> /lib/ld-linux-aarch64.so.1
Just set QEMU_LD_PREFIX to your sysroot.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: Branch and tag deletions
Joseph Myers : > > I'm more worried about missing files. I saw a bunch of those on my > > last test. This could be spurious - the elaborate set of branch > > mappings you specified confuses my validation test, because there is > > no longer a 1-1 corresponsence between Subversion and git branches. > > I'm hoping any such missing file problems come from bugs in the old SVN > dump reader with complicated commits mixing copies / deletions / > replacements with copies from other locations and that your rewrite will > fix the semantics in such cases. Also possible. The old code was a hairball. The new code is a bunch of relatively simple sequential passes - 10 so far, final version likely to have 12 or 13 - with well-defined preconditions and exit contracts. If nothing else this is going to make troubleshooting any remaining defects much easier. > All the current gcc-conversion merge requests, both mine and Richard's, > should now be set to allow rebasing. They were, and are all merged now, except for one that Richard just landed. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Branch and tag deletions
On Tue, 26 Nov 2019, Eric S. Raymond wrote: > Joseph Myers : > > A further note: in a previous run of the conversion I didn't see any > > emptycommit-* tags. In my most recent conversion run, I see 4070 such > > tags. How do I tell reposurgeon never to create such tags? Or should I > > add a tag deletion command for them in gcc.lift, once tag deletion is > > working reliably? > > That's what tag deletion by regexp is for. One more observation on that: in my last test conversion, deleting the emptycommit-* tags took over 7 hours (i.e. the bulk of the time for the conversion was spent just deleting those tags). Deleting tags matching /-root$/ took about half an hour. So I think there is a performance issue somewhere with (some cases of) tag deletion by regexp, at least when the regexp matches a large number of tags (but some other bulk deletions seem to run much quicker per tag). Taking a few seconds per tag is fine for an individual deletion, but a problem when you want to delete 4070 tags at once. -- Joseph S. Myers jos...@codesourcery.com
Re: Branch and tag deletions
Joseph Myers : > One more observation on that: in my last test conversion, deleting the > emptycommit-* tags took over 7 hours (i.e. the bulk of the time for the > conversion was spent just deleting those tags). Deleting tags matching > /-root$/ took about half an hour. So I think there is a performance issue > somewhere with (some cases of) tag deletion by regexp, at least when the > regexp matches a large number of tags (but some other bulk deletions seem > to run much quicker per tag). Taking a few seconds per tag is fine for an > individual deletion, but a problem when you want to delete 4070 tags at > once. File that as an issue, please. Go has very good profiling tools, finding the hotspot(s) in situations like this is easy and thus we should be able to fix this quickly when it reaches the top of the priority list, -- http://www.catb.org/~esr/";>Eric S. Raymond
