Re: Static sem_item_optimizer instance in ipa-icf pass
On 08/29/2018 03:54 PM, Martin Liška wrote:
> Hi.
>
> There's a patch candidate for the issue that moves the hash
> to sem_item. Doing that you'll have control over it when
> you'll use sem_{item,variable,function} classes.
>
> Is it fine?
>
> Martin
>
Installed as r264014 into trunk.
Martin
Re: Successful bootsrap of gcc 8.2.0 on x86_64-w64-mingw32
On Thu, 30 Aug 2018 at 21:22, Rainer Emrich wrote: > > Am 30.08.2018 um 14:38 schrieb Jonathan Wakely: > > Thanks for these logs, they're very helpful. Trunk revision r263976 > > fixes a number of the libstdc++ FAILs (compilation errors) and trunk > > revision r263977 fixes a load more (linker errors). > > > > I'm about to fix one more FAIL, a recent regression that only affects > > LLP64 targets (i.e. only Windows) where sizeof(size_t) != > > sizeof(long). > > > > For your next trunk build, would it be possible to add > > --enable-libstdcxx-filesystem-ts to the configure options? That will > > test the filesystem TS and C++17 code. I know there are quite a few > > failures on mingw but it would be good to see a full set of results. > Here we go https://gcc.gnu.org/ml/gcc-testresults/2018-08/msg03827.html > trunk rev. 263988, using --enable-languages=all --enable-fully-dynamic-string > --enable-libstdcxx-filesystem-ts > Full build and testsuite logs at > https://cloud.emrich-ebersheim.de/index.php/s/B9J89N94Rc8cgJZ Thanks, the libstdc++ result are looking pretty good. I'll go through the logs next week.
Re: Successful bootsrap of gcc 8.2.0 on x86_64-w64-mingw32
On Fri, Aug 31, 2018 at 9:24 AM Jonathan Wakely wrote: > > On Thu, 30 Aug 2018 at 21:22, Rainer Emrich wrote: > > > > Am 30.08.2018 um 14:38 schrieb Jonathan Wakely: > > > Thanks for these logs, they're very helpful. Trunk revision r263976 > > > fixes a number of the libstdc++ FAILs (compilation errors) and trunk > > > revision r263977 fixes a load more (linker errors). > > > > > > I'm about to fix one more FAIL, a recent regression that only affects > > > LLP64 targets (i.e. only Windows) where sizeof(size_t) != > > > sizeof(long). > > > > > > For your next trunk build, would it be possible to add > > > --enable-libstdcxx-filesystem-ts to the configure options? That will > > > test the filesystem TS and C++17 code. I know there are quite a few > > > failures on mingw but it would be good to see a full set of results. > > Here we go https://gcc.gnu.org/ml/gcc-testresults/2018-08/msg03827.html > > trunk rev. 263988, using --enable-languages=all > > --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts > > Full build and testsuite logs at > > https://cloud.emrich-ebersheim.de/index.php/s/B9J89N94Rc8cgJZ > > Thanks, the libstdc++ result are looking pretty good. I'll go through > the logs next week. Here are some build warnings if you like: ../../../../../../gccsvn/libstdc++-v3/src/filesystem/ops.cc:539:42: warning: unused parameter 'to' [-Wunused-parameter] ../../../../../../gccsvn/libstdc++-v3/src/filesystem/ops.cc:539:58: warning: unused parameter 'new_symlink' [-Wunused-parameter] ../../../../../../gccsvn/libstdc++-v3/src/filesystem/ops.cc:590:32: warning: unused parameter 'to' [-Wunused-parameter] ../../../../../../gccsvn/libstdc++-v3/src/filesystem/ops.cc:590:48: warning: unused parameter 'new_symlink' [-Wunused-parameter] ../../../../../../gccsvn/libstdc++-v3/src/filesystem/std-ops.cc:769:42: warning: unused parameter 'to' [-Wunused-parameter] ../../../../../../gccsvn/libstdc++-v3/src/filesystem/std-ops.cc:769:58: warning: unused parameter 'new_symlink' [-Wunused-parameter] ../../../../../../gccsvn/libstdc++-v3/src/filesystem/std-ops.cc:820:32: warning: unused parameter 'to' [-Wunused-parameter] ../../../../../../gccsvn/libstdc++-v3/src/filesystem/std-ops.cc:820:48: warning: unused parameter 'new_symlink' [-Wunused-parameter] ../../../../../../gccsvn/libstdc++-v3/src/filesystem/ops.cc:539:42: warning: unused parameter 'to' [-Wunused-parameter] ../../../../../../gccsvn/libstdc++-v3/src/filesystem/ops.cc:539:58: warning: unused parameter 'new_symlink' [-Wunused-parameter] ../../../../../../gccsvn/libstdc++-v3/src/filesystem/ops.cc:590:32: warning: unused parameter 'to' [-Wunused-parameter] ../../../../../../gccsvn/libstdc++-v3/src/filesystem/ops.cc:590:48: warning: unused parameter 'new_symlink' [-Wunused-parameter] ../../../../../../gccsvn/libstdc++-v3/src/filesystem/std-ops.cc:769:42: warning: unused parameter 'to' [-Wunused-parameter] ../../../../../../gccsvn/libstdc++-v3/src/filesystem/std-ops.cc:769:58: warning: unused parameter 'new_symlink' [-Wunused-parameter] ../../../../../../gccsvn/libstdc++-v3/src/filesystem/std-ops.cc:820:32: warning: unused parameter 'to' [-Wunused-parameter] ../../../../../../gccsvn/libstdc++-v3/src/filesystem/std-ops.cc:820:48: warning: unused parameter 'new_symlink' [-Wunused-parameter]
Even numbered register pairs restriction on some instructions
Hi there, I'm looking into whether it's possible to require even numbered registers on modes that need more than one hard-register to represent them. But only in some cases. The problem is the one mentioned explicitly here https://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html about enforcing a requirement for a register pair to start with an even-numbered register. I can't use TARGET_HARD_REGNO_MODE_OK as suggested in that document because I'd like to allow register pairs starting with odd-numbered registers in general, but not in some specific cases. From a comment in gcc/config/sparc/constraints.md above the constraint "U" it looks like there isn't a way to define such a constraint when using LRA, and I haven't found any hook that could do so but I'm hoping there's something I'm missing. The best thing I can think of is to define a bunch of classes ZERO_ONE, TWO_THREE, FOUR_FIVE, ..., define a constraint on each of those classes, then use all the constraints as one alternative in my pattern. Is there a better method? Is there some small change that could enable a nicer method? Thanks, Matthew
Re: Even numbered register pairs restriction on some instructions
On 08/31/2018 09:41 AM, Matthew Malcomson wrote: > Hi there, > > I'm looking into whether it's possible to require even numbered > registers on > modes that need more than one hard-register to represent them. But only in > some cases. > > The problem is the one mentioned explicitly here > https://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html about > enforcing a > requirement for a register pair to start with an even-numbered register. > I can't use TARGET_HARD_REGNO_MODE_OK as suggested in that document > because I'd > like to allow register pairs starting with odd-numbered registers in > general, > but not in some specific cases. > > From a comment in gcc/config/sparc/constraints.md above the constraint > "U" it > looks like there isn't a way to define such a constraint when using LRA, > and I > haven't found any hook that could do so but I'm hoping there's something > I'm > missing. > > The best thing I can think of is to define a bunch of classes ZERO_ONE, > TWO_THREE, FOUR_FIVE, ..., define a constraint on each of those classes, > then > use all the constraints as one alternative in my pattern. > > Is there a better method? > > Is there some small change that could enable a nicer method? It would help to know more about when you want to allow odd registers. I'd be surprised if creating a class, but still rejecting in HARD_REGNO_MODE_OK worked... Jeff
EH frame parsing tool
Hi All, As part of a project at the University of Virginia, I had the opportunity to create a parser for the exception handling information stored in ELF binaries. I got permission to open source the project, as I couldn't find anything else out there in the community that did this type of thing. (I'm aware that readelf -w will print some of the EH info, but not all of it (LSDAs, for example), and not in a machine-usable way). If you're interested, you can find the project at http://git.zephyr-software.com/opensrc/libehp I'd love to hear from you if you find it useful, and welcome any comments, feedback, suggestions, or merge requests. Thanks, -j
Re: Even numbered register pairs restriction on some instructions
On 31/08/18 18:06, Jeff Law wrote: On 08/31/2018 09:41 AM, Matthew Malcomson wrote: Hi there, I'm looking into whether it's possible to require even numbered registers on modes that need more than one hard-register to represent them. But only in some cases. The problem is the one mentioned explicitly here https://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html about enforcing a requirement for a register pair to start with an even-numbered register. I can't use TARGET_HARD_REGNO_MODE_OK as suggested in that document because I'd like to allow register pairs starting with odd-numbered registers in general, but not in some specific cases. From a comment in gcc/config/sparc/constraints.md above the constraint "U" it looks like there isn't a way to define such a constraint when using LRA, and I haven't found any hook that could do so but I'm hoping there's something I'm missing. The best thing I can think of is to define a bunch of classes ZERO_ONE, TWO_THREE, FOUR_FIVE, ..., define a constraint on each of those classes, then use all the constraints as one alternative in my pattern. Is there a better method? Is there some small change that could enable a nicer method? It would help to know more about when you want to allow odd registers. For concreteness: I'm looking at TImode registers that will span 2 hard registers. In most cases it's fine for these register pairs to start at either an odd or even hard register. I'd like to restrict TImode registers to even registers only in one or two patterns. (for concreteness: in order to use the aarch64 casp instruction) I'd be surprised if creating a class, but still rejecting in HARD_REGNO_MODE_OK worked... Sorry: I don't know what you mean by creating a class and rejecting it in HARD_REGNO_MODE_OK. As far as I can tell, HARD_REGNO_MODE_OK is only given information on the register number and the mode of the value, so it knows nothing about the register class any constraint may be applying. I mentioned HARD_REGNO_MODE_OK just because the documentation page I linked to said that was the way to implement limiting register pairs to those beginning with an even numbered register and I wanted to explain why this wasn't applicable in my case (due to not being able to limit the restriction to certain patterns). Jeff Matthew
Re: Even numbered register pairs restriction on some instructions
> On Aug 31, 2018, at 11:41 AM, Matthew Malcomson > wrote: > > Hi there, > > I'm looking into whether it's possible to require even numbered registers on > modes that need more than one hard-register to represent them. But only in > some cases. > > The problem is the one mentioned explicitly here > https://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html about enforcing a > requirement for a register pair to start with an even-numbered register. > I can't use TARGET_HARD_REGNO_MODE_OK as suggested in that document because > I'd > like to allow register pairs starting with odd-numbered registers in general, > but not in some specific cases. > > From a comment in gcc/config/sparc/constraints.md above the constraint "U" it > looks like there isn't a way to define such a constraint when using LRA, and I > haven't found any hook that could do so but I'm hoping there's something I'm > missing. I think you can use pdp11 as an example, it does two things that are similar to what you're describing. One is that it requires SImode to go into an even regno, and indicates that it uses two registers. See TARGET_HARD_REGNO_MODE_OK and TARGET_HARD_REGNO_NREGS. The other is that it has one instruction that wants an odd (!) register: 16 bit multiply. Multiply is weird: if you give it an even destination register it produces a 32 bit result in that register pair, with an odd register number it produces a 16 bit result. So pdp11.md defines both "mulhi3" and "mulsihi3" insns. The latter has an SImode output so that uses the even numbered register, as I already described. The former uses a machine-specific constraint "d". That is defined in constraints.md to mean a register in class MUL_REGS. pdp11.h defines that name and what registers it refers to, and pdp11.h does the reverse mapping (REGNO_REG_CLASS). If you want even register numbers for some instructions but that's not tied to a specific type size (like SImode in my case), I think you'd want to use something analogous to the MUL_REGS thing I described. Say, "EVEN_REGS". REGNO_REG_CLASS would report even regnum to be in EVEN_REGS, odd in GENERAL_REGS. The bitmaps for REG_CLASS_CONTENTS would show that EVEN_REGS contains only even numbered registers while GENERAL_REGS contains both odd and even. And you'd defined a register constraint which matches EVEN_REGS. Then the instructions where you want them would use that constraint. paul
Re: Even numbered register pairs restriction on some instructions
On 8/31/18 10:41 AM, Matthew Malcomson wrote: > I'm looking into whether it's possible to require even numbered registers on > modes that need more than one hard-register to represent them. But only in > some cases. Yes, it's possible. You can look at TDmode (128-bit decimal floating point) on powerpc64*-linux, which is only allowed in even-odd register pairs. It's in *all* cases though, not some of the time. Peter
gcc-8-20180831 is now available
Snapshot gcc-8-20180831 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20180831/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 264022 You'll find: gcc-8-20180831.tar.xzComplete GCC SHA256=f3ef66925151cf715597533989deeef25d01d3d35faf74807ef834f0ecf5c851 SHA1=29e824d559f01dd90bdbd12dfd9b067c67ae8942 Diffs from 8-20180824 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
