Re: That light at the end of the tunnel?
On July 21, 2018 4:04:51 AM GMT+02:00, e...@thyrsus.com wrote: >That light at the end of the tunnel turned out to be an oncoming train. > >Until recently I thought the conversion was near finished. I'd had >verified clean conversions across trunk and all branches, except for >one screwed-up branch that the management agreed we could discard. > >I had some minor issues left with execute-permission propagation and >how >to interpret mid-branch deletes I solved the former and was working >on the latter. I expected to converge on a final result well before >the end of the year, probably in August or September. > >Then, as I reported here, my most recent test conversion produced >incorrect content on trunk. That's very bad, because the sheer size >of the GCC repository makes bug forensics extremely slow. Just loading >the SVN dump file for examination in reposurgeon takes 4.5 hours; full >conversions are back up to 9 hours now. The repository is growing >about as fast as my ability to find speed optimizations. > >Then it got worse. I backed up to a commit that I remembered as >producing a clean conversion, and it didn't. This can only mean that >the reposurgeon changes I've been making to handle weird branch-copy >cases have been fighting each other. > >For those of you late to the party, interpreting the operation >sequences in Subversion dump files is simple and produces results that >are easy to verify - except near branch copy operations. The way those >interact with each other and other operations is extremely murky. > >There is *a* correct semantics defined by what the Subversion code >does. But if any of the Subversion devs ever fully understood it, >they no longer do. The dump format was never documented by them. It is >only partly documented now because I reverse-engineered it. But the >document I wrote has questions in it that the Subversion devs can't >answer. > >It's not unusual for me to trip over a novel branch-copy-related >weirdness while converting a repo. Normally the way I handle this is >by performing a bisection procedure to pin down the bad commit. Then >I: > >(1) Truncate the dump to the shortest leading segment that >reproduces the problem. > >(2) Perform a strip operation that replaces all content blobs with >unique small cookies that identify their source commit. Verify that it >still >reproduces... > >(3) Perform a topological reduce that drops out all uninteresting >commits, that is pure content changes not adjacent to any branch >copies or property changes. Verify that it still reproduces... > >(4) Manually remove irrelevant branches with reposurgeon. >Verify that it still reproduces... > >At this point I normally have a fairly small test repository (never, >previously, more than 200 or so commits) that reproduces >the issue. I watch conversions at increasing debug levels until I >figure out what is going on. Then I fix it and the reduced dump >becomes a new regression test. > >In this way I make monotonic progress towards a dumpfile analyzer >that ever more closely emulates what the Subversion code is doing. >It's not anything like easy, and gets less so as the edge cases I'm >probing get more recondite. But until now it worked. > >The size of the GCC repository defeats this strategy. By back of the >envelope calculation, a single full bisection would take a minimum of >18 days. Realistically it would probably be closer to a month. > >That means that, under present assumptions, it's game over >and we've lost. The GCC repo is just too large and weird. > >My tools need to get a lot faster, like more than an order of >magnitude faster, before digging out of the bad situation the >conversion is now in will be practical. > >Hardware improvements won't do that. Nobody knows how to build a >machine that can crank a single process enough faster than 1.3GHz. >And the problem doesn't parallelize. > >There is a software change that might do it. I have been thinking >about translating reposurgeon from Python to Go. Preliminary >experiments with a Go version of repocutter show that it has a >40x speed advantage over the Python version. I don't think I'll >get quite that much speedup on reposurgeon, but I'm pretty >optimistic agout getting enough speedup to make debugging the GCC >conversion tractable. Even at half that, 9 hour test runs would >collapse to 13 minutes. > >The problem with this plan is that a full move to Go will be very >difficult. *Very* difficult. As in, work time in an unknown and >possibly large number of months. > >GCC management will have to make a decision about how patient >it is willing to be. I am at this point not sure it wouldn't be >better to convert your existing tree state and go from there, Can you summarize what is wrong with our current git mirror which was IIRC created by git-svn importing? For practical purposes I'd be happy with converting only trunk history and active release branches. Starting from just TOT is not practical. Maybe s
Re: That light at the end of the tunnel?
On Sat, Jul 21, 2018 at 09:26:10AM +0200, Richard Biener wrote: > Can you summarize what is wrong with our current git mirror which was IIRC > created by git-svn importing? git-svn tends to do subtle danage damage to the back history. See my PSA at http://esr.ibiblio.org/?p=6778 Partial quote: The problem with git-svn as a full importer is that it is not robust in the presence of repository malformations and edge cases – and these are all too common, both as a result of operator errors and scar tissue left by previous conversions from CVS. If anyone on your project has ever done a plain cp rather than “svn cp” when creating a tag directory, or deleted a branch or tag and then recreated it, or otherwise offended against the gods of the Subversion data model, git-svn will cheerfully, silently seize on that flaw and amplify the hell out of it in your git translation. The result is likely to be a repository that looks just right enough at the head end to hide damage further back in the history. People often fail to notice this because they don’t actually spend much time looking at old revisions after a repository conversion – but on the rare occasions when history damage bites you it’s going to bite hard. Since I wrote that I have learned that git-svn full conversions also have a tendency to screw up the location of branch joins.
Re: Detecting superfluous "else"
On 19/07/2018 18:56, Eric Gallager wrote:
On 7/19/18, U.Mutlu wrote:
Hi,
it makes me 'crazy' when I see such if-else constructs:
if (x)
return 7;
else
return 4;
(Of course in this case one better would use the shorthand "return x ? 7 :
4;", but that's not the issue here)
The 'else' is obviously superfluous/redundant, ie. unneeded at all:
if (x)
return 7;
return 4;
Is it possible to warn about such unneccessary occurances of "else"?
If not, then I suggest to add a new warning code -Wsuperfluous-else or
-Wredundant-else or so.
Thx
Semi-related: bug 81851: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81851
(my disagreement with that request is similar to my disagreement with
this request)
Your example might be worth a warning, to allow the developer to refactor
int g (int i)
{
if (i == 0) // no warning
return 0;
#if SOME_OTHER_PLATFORM
if (i == 2)
return 1;
#endif
return 0;
}
to
int g (int i)
{
#if SOME_OTHER_PLATFORM
if (i == 2)
return 1;
#endif
return 0;
}
It is purely stylistic, but if one is worried about dup branch at all, than
it's reasonable to assume one would want this warning too.
It would require distinguishing between multiple possible branches by the
preprocessor, rather than the compiler. No idea who emits the dup branch
warning.
Re: That light at the end of the tunnel?
On Sat, Jul 21, 2018 at 7:32 AM Eric S. Raymond wrote: > > On Fri, Jul 20, 2018 at 11:13:16PM -0400, David Edelsohn wrote: > > Have you considered bisecting your recent changes to reposurgeon to > > determine which one caused the errors in the conversion of GCC Trunk > > and then trying to reason about why the change causes a problem? > > Of course I have. > > The problem is this. Whatever I did to break the previously good conversion > at commit 256000 must have been done to fix breakage turned up at a different > commit or in one of my test cases. If I revert out whatever change that was > I won't be at a state of no problens, I'll just have a different problem - > with no guarantee that it will leave tip conversion in a good state. > > No, this needs a root-cause analysis. Reverting back to a previous version > is unlikely to be helpful, and would be an expensive experiment. Eric, I realize that reverting the change would cause another regression. My suggestion is that the bisection of reposurgeon may be easier / faster and could help you pinpoint the root cause. Then you could consider a different solution to the problem that you were trying to fix with the initial patch. You could see explicitly how the reposurgeon patch fixes one problem and how it creates a different problem in Trunk. Thanks, David
Re: Detecting superfluous "else"
Le 19/07/2018 à 10:49, U.Mutlu a écrit : Hi, it makes me 'crazy' when I see such if-else constructs: if (x) return 7; else return 4; (Of course in this case one better would use the shorthand "return x ? 7 : 4;", but that's not the issue here) The 'else' is obviously superfluous/redundant, ie. unneeded at all: if (x) return 7; return 4; Is it possible to warn about such unneccessary occurances of "else"? If not, then I suggest to add a new warning code -Wsuperfluous-else or -Wredundant-else or so. Thx Let me express the point of view of an old C programmer (and also programmer in other languages). From a semantic point of view (if I can dare to use this word) the two forms are different. The first one, which you dislike, is appropriate in the general situation of an alternative in which the two cases have the same order of probability to happen. The form you propose is more appropriate to catch exceptions while leaving straightforward the "normal" execution thread. Although the C language is very loose about semantics, leaving it to the appreciation of the programmer, a well written program is one in which the author takes care of semantics. Some programmers find it stylish to minimize the character count of expressions and the size of the source file. My opinion is that size doesn't matter; the important is to favour the readibility, which includes making as clear as possible what the intent of the author is. Often, this is better achieved by the way the instructions are written than by adding comments. Thanks. Didier
Re: gcc-gnat for Linux/MIPS-32bit-be, and HPPA2
hi guys
got some deb files from an old Debian's archive(1), converted .deb
into .tgz, and installed
but it seems there is no gnat-gcc
I don't know how Gnat works on Debian, but for sure it doesn't work
like the version I have on my gentoo-x86 box
where I have prepared this test file, hello.adb
with Ada.Text_IO; use Ada.Text_IO;
procedure Hello is
begin
Put_Line ("Hello WORLD!");
end Hello;
that I can compile via "gnatmake hello.adb"
gnat make -v hallo.ada
GNATMAKE 4.3.5
"hello.ali" being checked ...
gnatgcc -c -x ada hello.adb
End of compilation
gnatbind -x hello.ali
gnatlink hello.ali
as you can see it calls "gnatgcc"
On HPPA:
- "gnatgcc" is not existing out of the debian pagkage(1)
- gnat make calls "gcc-4.3"
- the installed gcc (provided by gentoo) can't compile ada-files
- since the compiler was compiled with languages=C,C++,Fortran
and idea? hints?
(1)
http://snapshot.debian.org/archive/debian/20091008T120404Z/pool/main/g/gnat-4.3
