Re: subversion status on gcc.gnu.org
On 3/20/20 12:37 PM, Frank Ch. Eigler via Gcc wrote: > Hi - > > Both svn: and ssh+svn: now work for your archeological needs. > Further, URLs such as > > https://gcc.gnu.org/viewcvs?rev=279160&root=gcc&view=rev > https://gcc.gnu.org/r123456 > > are mapped to gitweb searches that try to locate the matching > From-SVN: rABCDEF commit. This way, historical URLs from bugzilla > should work. > > If you badly need something else subversionish, please let me know. Thanks for working on this!!! However, I still see at least one issue in the following bugzilla entry: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123#c4 The first two git style links work, but the last one which points to the SVN revision doesn't. Is that a bug in the actual url that bugzilla added or can we handle these too? Peter
Re: subversion status on gcc.gnu.org
On 3/24/20 12:06 PM, Frank Ch. Eigler wrote: >> Thanks for working on this!!! However, I still see at least one issue >> in the following bugzilla entry: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94123#c4 >> >> The first two git style links work, but the last one which points >> to the SVN revision doesn't. Is that a bug in the actual url that >> bugzilla added or can we handle these too? > > We can/do handle the last one too. httpd mod_rewrite is powerful. Works now. Thanks for fixing! Peter
Re: D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote:
> On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote:
>> /tmp/cc8zG8DV.s: Assembler messages:
>> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13
>> /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14
[snip]
> So do we need to change
> +else version (PPC)
>
>
> +{
>
>
> +void*[19] regs = void;
>
>
> +asm pure nothrow @nogc
>
>
> +{
>
>
> +"stw r13, %0" : "=m" (regs[ 0]);
>
>
> +"stw r14, %0" : "=m" (regs[ 1]);
>
>
> ...
> +else version (PPC64)
>
>
> +{
>
>
> +void*[19] regs = void;
>
>
> +asm pure nothrow @nogc
>
>
> +{
>
>
> +"std r13, %0" : "=m" (regs[ 0]);
>
>
> +"std r14, %0" : "=m" (regs[ 1]);
>
>
> ...
> to "stw 13, %0" and "std 13, %0" etc. unconditionally, or
> to "stw %%r13, %0" etc. under some conditions?
Yes, I think so. The "r13", etc. names are not accepted by gas unless you
use the -mregnames option. It's easier to just remove the 'r'.
Peter
GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12
Hi all, I recently did a search on a git log of gcc trunk looking for a particular commit of mine, so was searching for my name, and I came across a commit from Uroš that lists me as the Author. I did not author that commit and talking with Uroš offline, he assures me that he didn't use --author when committing that, so we're wondering whether there might be a bug in one of the commit hooks. Is there someone who an dig into the commit below and try to find out how the author field was incorrectly set? Peter commit a325bdd195ee96f826b208c3afb9bed2ec077e12 Author: Peter Bergner AuthorDate: Thu Jun 10 13:54:12 2021 -0500 Commit: Uros Bizjak CommitDate: Thu Jun 10 23:55:24 2021 +0200 i386: Add V8QI and other 64bit vector permutations [PR89021] In addition to V8QI permutations, several other missing permutations are added for 64bit vector modes for TARGET_SSSE3 and TARGET_SSE4_1 targets. 2021-06-10 Uroš Bizjak gcc/ PR target/89021 * config/i386/i386-expand.c (ix86_split_mmx_punpck): Handle V2SF mode. Emit SHUFPS to fixup unpack-high for V2SF mode. (expand_vec_perm_blend): Handle 64bit modes for TARGET_SSE4_1. (expand_vec_perm_pshufb): Handle 64bit modes for TARGET_SSSE3. (expand_vec_perm_pblendv): Handle 64bit modes for TARGET_SSE4_1. (expand_vec_perm_interleave2): Handle 64bit modes. (expand_vec_perm_even_odd_pack): Handle V8QI mode. (expand_vec_perm_even_odd_1): Ditto. (ix86_vectorize_vec_perm_const): Ditto. * config/i386/i386.md (UNSPEC_PSHUFB): Move from ... * config/i386/sse.md: ... here. * config/i386/mmx.md (*vec_interleave_lowv2sf): New insn_and_split pattern. (*vec_interleave_highv2sf): Ditto. (mmx_pshufbv8qi3): New insn pattern. (*mmx_pblendw): Ditto.
Re: GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12
On 6/16/21 1:32 PM, Uros Bizjak wrote: > On Wed, Jun 16, 2021 at 6:08 PM Liu Hao wrote: >> It looks like Uroš was on 00d07ec6e12, committed his changes mistakenly with >> `git commit --amend` >> (which changed the commit message but did not reset the author), then >> rebased the modified commit >> onto ee52bf609bac. Git is smart enough to drop duplicate changes, but the >> leftovers formed a new >> commit, which was exactly a325bdd195e. > > Indeed, IIRC - contrib/gcc_update failed due to the unresolved merge, > and I changed my commit with --amend. There were some issues, but I > was under the impression that I fixed them. It looks like I forgot > something, so the result is the commit with wrong author attribution. > > Perhaps a notice in the documentation should be added what to do if > contrib/gcc_update fails, or perhaps this script should be made more > robust. I admit, that if the same thing happened to me, I would have made the same mistake...or worse :-), so yeah, a comment about what to do to "fix" things when gcc_update fails would be greatly appreciated by me too! Peter
Re: libgfortran.so SONAME and powerpc64le-linux ABI changes
On 10/6/21 12:50 PM, Segher Boessenkool wrote: > So we have three options (well, four): > > 0) Do nothing. We will stay in this hell forever. Not my choice :-) > 1) Use a soft-float-like parameter passing everywhere. This works but >will be horridly slow on newer systems. We can do better than that. > 2) Use the current setup where -mcpu=power8 (or later) makes QP float >available. Most BE stuff isn't compiled with that currently, and it >will split our ecosystem. > 3) As Joseph reminds me the high VSRs are the VRs, so we could use the >same parameter passing on anything with AltiVec. We could even >simply require -maltivec for QP float to be supported (we currently >require -mvsx, this would not be a restriction). > > I think I like 3) :-) I like 3 too, meaning requiring -maltivec to support IEEE QP at all. This would cover POWER6 and later server CPUs, as well as some other cpus like in the Power Macs. Anything without Altivec hardware would need to either not support IEEE QP at all, or go through the work themselves of coming up with a -msoft-altivec like ABI. Peter
Re: How to describe ‘earlyclobber’ explicitly for specific source operand ?
On 11/19/21 1:28 AM, Jojo R via Gcc wrote: > We know gcc supply earlyclobber function to avoid register overlap, > > but it can not describe explicitly for specific source operand, is it > right ? You add the early clobber to the OUTPUT operand(s) that can clobber any of the input source operands. You don't mark the source operands that could be clobbered. Peter
Re: [power-ieee128] What should the math functions be annotated with?
On 12/4/21 9:25 AM, Michael Meissner wrote: > On Sat, Dec 04, 2021 at 02:42:13PM +0100, Thomas Koenig wrote: > Note, the system ldd does not tend to accurately report the library > dependencies for AT libraries: And using AT15's ldd, it shows your a.out is linked to the correct libc: ubuntu@gcc-fortran:/home/tkoenig/Tst$ ldd ./a.out ./a.out: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./a.out) linux-vdso64.so.1 (0x7f633962) libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x7f63393d) /opt/at15.0/lib64/ld64.so.2 => /lib64/ld64.so.2 (0x7f633964) ubuntu@gcc-fortran:/home/tkoenig/Tst$ /opt/at15.0/bin/ldd ./a.out linux-vdso64.so.1 (0x7158fb1c) libc.so.6 => /opt/at15.0/lib64/power9/libc.so.6 (0x7158faf4) /opt/at15.0/lib64/ld64.so.2 (0x7158fb1e) What I would do is place /opt/at15.0/bin as the 2nd directory in your PATH, with your new GCC install dir being first. That way, things should be seemless for you. Peter
Re: [power-ieee128] What should the math functions be annotated with?
On 12/4/21 9:37 AM, Peter Bergner wrote: > On 12/4/21 9:25 AM, Michael Meissner wrote: > ubuntu@gcc-fortran:/home/tkoenig/Tst$ ldd ./a.out > ./a.out: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found > (required by ./a.out) > linux-vdso64.so.1 (0x7f633962) > libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x7f63393d) > /opt/at15.0/lib64/ld64.so.2 => /lib64/ld64.so.2 (0x7f633964) To go into a little more in depth, the important thing is your a.out was linked with the correct loader: ubuntu@gcc-fortran:/home/tkoenig/Tst$ readelf -l a.out | grep interpreter [Requesting program interpreter: /opt/at15.0/lib64/ld64.so.2] ...and the error message you saw was a good thing, it showed your a.out was expecting to see the newer GLIBC 2.34 and didn't. The reason it didn't was that the system ldd which you used does some magic and overrides the a.out runtime loader with the system loader and that loader uses its own ld.so.cache which doesn't include AT15's library paths. The AT15 loader has its own /opt/at15.0/etc/ld.so.cache which includes its lib dirs as well the system lib dirs. This way, the AT15 libs are found first and any library AT15 doesn't provide it automatically picked up from the system. As long as you keep the AT15 bin path before the system bin dirs, you should be fine. Peter
Re: [power-ieee128] What should the math functions be annotated with?
On 12/4/21 10:19 AM, Jakub Jelinek wrote: > But when Thomas is working on the vanilla gcc tree, trying to make it work > for Fortran, I think he'll need to patch that gcc tree too to use the > AT15's dynamic linker and rpath like the AT15 gcc is. That is part of the magic that happens when you configure with --with-advance-toolchain=at15.0, it forces the gcc to use AT15's dynamic linker and AT15's ld.so.cache makes it so that the dynamic linker finds AT15's libs etc. Peter
Re: [power-ieee128] What should the math functions be annotated with?
On 12/4/21 11:40 AM, Thomas Koenig wrote: > OK, what I have now is > > tkoenig@gcc-fortran:~$ echo $PATH > /home/tkoenig/bin:/opt/at15.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin > tkoenig@gcc-fortran:~$ echo $LD_LIBRARY_PATH > /home/tkoenig/lib64 > > I generally use LD_LIBRARY_PATH to point to where the shared > libgfortran and other libraries is installed. > > However, this breaks man (and I don't know what else): So LD_LIBRARY_PATH is searched before the directories in ld.so.cache, so you end up picking up some "new" libs from /home/tkoenig/lib64 and some of these rely on the newer libs in AT15. However, man and some of the other system binaries use the system dynamic linker, so they search first through LD_LIBRARY_PATH an dnot finding something, they fall back to /etc/ld.so.cache and that doesn't have the newer AT15 libs, so you hit errors. Instead of setting LD_LIBRARY_PATH=/home/tkoenig/lib64 could you try setting it to LD_LIBRARY_PATH='$ORIGIN/lib64' instead? This would allow the other system binaries to not find your /home/tkoenig/lib64 directory so they'd behave normally. However, any binary that was compiled in a directory where your lib64/ exists would find your new libs and use them. I'm not sure if that cramps your testing or not, to limit yourself to compiling your tests in that one directory. If that doesn't work, could you instead not set LD_LIBRARY_PATH and instead compile using -L/home/bergner/lib64 -R/home/bergner/lib64 ? Peter
Re: [RFC Linux patch] powerpc: add documentation for HWCAPs
On 5/20/22 12:15 AM, Nicholas Piggin via Gcc wrote: > +PPC_FEATURE_HAS_ALTIVEC > +Vector (aka Altivec, VSX) facility is available. Slight typo. s/VSX/VMX/ Peter
Re: Stepping up as maintainer for ia64
On 3/8/24 7:16 AM, Richard Biener via Gcc wrote: > I CCed Jeff who is on the commitee to forward the maintainer proposal > though I guess this will not go forward as a first step. Instead > you are probably expected to show activity on the port, for example > post the patch series to make ia64 use LRA, get write access to the > git repository and then be promoted maintainer. One other method for showing activity is posting regular testsuite results on the gcc-testresults mailing list to show the community the port is "working". Peter
Re: [PATCH] fix PowerPC < 7 w/ Altivec not to default to power7
On 3/8/24 5:30 AM, Jonathan Wakely via Gcc wrote: > Patches should be sent to the gcc-patches list instead of this one, > and should be against trunk not an old gcc-11 RC. See > https://gcc.gnu.org/contribute.html#patches for more details - thanks! And you need to CC the rs6000/powerpc port maintainers which you can find along with their preferred email addresses in the MAINTAINERS file. If you don't CC them, they may miss seeing the patch. Peter
Re: Stepping up as maintainer for ia64
On 3/8/24 5:28 PM, Jonathan Wakely wrote: > On Fri, 8 Mar 2024 at 22:35, Frank Scheiner via Gcc wrote: >> >> On 08.03.24 23:00, Peter Bergner wrote: >>> On 3/8/24 7:16 AM, Richard Biener via Gcc wrote: I CCed Jeff who is on the commitee to forward the maintainer proposal though I guess this will not go forward as a first step. Instead you are probably expected to show activity on the port, for example post the patch series to make ia64 use LRA, get write access to the git repository and then be promoted maintainer. >>> >>> One other method for showing activity is posting regular testsuite >>> results on the gcc-testresults mailing list to show the community >>> the port is "working". >> >> I don't want to spam this or the other list each and every week, but I > > Sending test results to the gcc-testresults list is **not** spamming, > that's what the list is for! 100% agree! If you look at what we (IBM) post, we roughly post somewhere around 7 testsuite results per day due to runs on different hardware, endianness and OS (Linux versus AIX). So spam ...err... post away! > If you're testing uncommon targets (e.g. ia64-linux) then sending test > results to the list is essential so we know the target builds, because > nobody else is testing it. Again, 100% agree! Peter
