Re: Branch and tag deletions
On Mon, 25 Nov 2019, Eric S. Raymond wrote: > 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, Comment added on issue 165 pointing to specific tags that wrongly failed to get deleted. Another comment added on issue 165 regarding cases where a tag deletion command deleted only a subset of the matching tags, since it seems plausible the underlying issue could be the same. Issue 166 filed for the deleted-r branches and tags staying around. Issue 167 filed for the loss of the changes from the commit for the gcc-2_95_3 tag. In all cases, my testing includes changes from my merge requests for the gcc-conversion repository, rather than being based on the unmodified upstream state of that repository, but I don't have any reason to think these bugs depend on those changes. 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? -- Joseph S. Myers jos...@codesourcery.com
Re: Branch and tag deletions
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 of reposurgeon's design rules is "never add a special-purpose switch or flag when an application of the selection-set minilanfuage will do" -- http://www.catb.org/~esr/";>Eric S. Raymond
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
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. Thanks. We've accumulated a lot of merge requests on the gcc-conversion repository, once those are merged I'll test a further change to remove those tags. -- Joseph S. Myers jos...@codesourcery.com
GCC test failures due to GDB session errors?
Every now and then I see test suite failures in my builds that I can't reproduce when I then execute the tests individually via a make check target. In the test log there often (always?) are the following messages around those failures: &"warning: GDB: Failed to set controlling terminal: Operation not permitted\n" FAIL: gcc.dg/torture/pr56488.c -Os (test for excess errors) Excess errors: &"warning: GDB: Failed to set controlling terminal: Operation not permitted\n" I run the tests on the same machine I develop and debug GCC on at the same time, but that's all in separate directories (i.e., separate sources and separate build directory for each). Is it possible that these GDB messages are getting intercepted by the test run somehow and causing these failures? Is there some way to avoid them? Martin PS My GDB is GNU gdb (GDB) Fedora 8.2-7.fc29.
Re: Branch and tag deletions
Joseph Myers : > Thanks. We've accumulated a lot of merge requests on the gcc-conversion > repository, once those are merged I'll test a further change to remove > those tags. I just checked; a rebase button appeared on your MRs and I merged all three, but no rebase option occurs on Richard Earnshaw's reqyests. The GitLab interface seems fickle and arbitrary at times. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Branch and tag deletions
On Tue, 26 Nov 2019, Eric S. Raymond wrote: > Joseph Myers : > > Thanks. We've accumulated a lot of merge requests on the gcc-conversion > > repository, once those are merged I'll test a further change to remove > > those tags. > > I just checked; a rebase button appeared on your MRs and I merged all > three, but no rebase option occurs on Richard Earnshaw's reqyests. Yes, I managed to locate the (not very obvious) "Allow commits from members who can merge to the target branch." checkbox in the MR edit interface to allow that. -- Joseph S. Myers jos...@codesourcery.com
