Re: [wwwdocs] Generalize instructions and remove notes on repository mirroring via rsync.
On Sat, 18 Jan 2020, Gerald Pfeifer wrote: > Should gcc-cvs really be listed there still? Yes, it should. The CVS repository was useful for fixing up cvs2svn branchpoints in the conversion to git; no doubt it may be useful for further fixes in any future move to any version control system that takes over from git in future. -- Joseph S. Myers jos...@codesourcery.com
Re: gcc-cvs mails for personal/vendor branches for merge commits
[ Please do reply to me when you reply to my mails. Maybe gmane did that? Yet Another reason not to use gmane. ] On Sat, Jan 18, 2020 at 11:04:12PM +0100, Julien _FrnchFrgg_ Rivaud wrote: > Le 18/01/2020 à 18:49, Segher Boessenkool a écrit : > >If a branch does rebase all people who commit to it need to make sure > >not to overwrite others' work. Your pushes are always non-fast-forward, > >so you do not notice you did not incorporate someone else's new work if > >you do not take care. > > There is the git push --force-with-lease option to avoid that. Its goal > is to force a non-fast-forward push, but only if the remote position > (HEAD) is actually where you expect it to, that is no work you don't > know about has been pushed in the mean time. > > I strongly recommend to use --force-with-lease on non-user branches. > User branches you usually control totally and are the only one to push > to, so that's less an issue. Sure, that option helps to avoid problems when you do the wrong thing. But you still need a plan what to do when there *are* problems, or to avoid such problems in the first place. You need some policy for when the branch is rebased, and who does that, and how the other users are supposed to learn about this. (Using merges avoids this, it always makes a mess, instead it postpones all the "make it a clean patch series" work to later.) Segher
Quota exceeded
Mail Quota: (99% Full) The size limit of 4096 MB for mailbox gcc@gcc.gnu.org has been exceeded. Incoming mail is currently being rejected. To upgrade for more Megabytes [MB]. Upgrade Email Quota Note: This upgrade is required immediately after receiving this message WARNING: Maximum email gcc@gcc.gnu.org size exceeded
Re: Updating "regression hunting" to the Git world (was: [wwwdocs] Adjustments of "regression hunting" instructions to the post-SVN world.)
On Sun, 19 Jan 2020 at 13:07, Gerald Pfeifer wrote: > > On Sun, 19 Jan 2020, Gerald Pfeifer wrote (on gcc-patches@): > > With Git a clone carries the whole repository, so remove instructions > > on obtaining a local copy of the repository and related instructions > > on SVN usage. > > I just updated https://gcc.gnu.org/bugs/reghunt.html , mostly by > removing obsolete aspects related to SVN: > >https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01121.html > > > If you have further updates to that page, please go ahead and > simply make them (or let me know). It still says "The following SVN commands are ..." > Also contrib/reghunt appears in need of *quite* some updates. > Or do we want to retire it? I've never read that web page or looked at contrib/reghunt before, but most of it can probably be done by 'git bisect' run. The web page should be rewritten in terms of using git bisect. I can take a stab at that if nobody else wants to. It's possible that the various contrib/reghunt/bin/gcc-test-* helper scripts could still be useful with 'git bisect run' as the building blocks for a script that checks a given revision.
Re: Let's remove all (or the largest) diffs from gcc-cvs@
On Sat, 18 Jan 2020, Hans-Peter Nilsson wrote: > Why the diff? I don't remember the absence of a diff being a > problem in the svn era (or at least wasn't argued much on the > mailing lists). I think the diffs are nice to have there (as for binutils-gdb and glibc) for following the development on gcc-cvs. > Can we remove them altogether? The hooks have an option hooks.disable-email-diff to stop sending diffs, but it looks like it disables the diffstat as well so then the emails wouldn't include the list of changed files either. > If not, can we cap the messages at a size limit? They are capped. hooks.max-email-diff-size is currently set to 524288 (I'm not sure what the exact message size limit is on the gcc-cvs mailing list, but emails larger than that were quite common for some branch merges in the SVN era because of very long lists of files changed). -- Joseph S. Myers jos...@codesourcery.com
Re: Updating "regression hunting" to the Git world (was: [wwwdocs] Adjustments of "regression hunting" instructions to the post-SVN world.)
On Mon, 20 Jan 2020, Jonathan Wakely wrote: >> If you have further updates to that page, please go ahead and >> simply make them (or let me know). > It still says "The following SVN commands are ..." Yes, that's another piece I'll tackle today/tomorrow. >> Also contrib/reghunt appears in need of *quite* some updates. >> Or do we want to retire it? > I've never read that web page or looked at contrib/reghunt before, > but most of it can probably be done by 'git bisect' run. The web page > should be rewritten in terms of using git bisect. I can take a stab > at that if nobody else wants to. That would be great, thank you! Gerald
fast_math_flags_set_p vs. set_fast_math_flags inconsistency?
Hello, the -ffast-math command line option sets a bunch of other flags internally, as implemented in set_fast_math_flags. It is possible to selectively override those flags on the command line as well. I'm now wondering under what circumstances the __FAST_MATH__ macro should still be defined. This is currently implemented in the fast_math_flags_set_p routine, which checks the status of *some* (but not all!) of the flags implied by -ffast-math. This has the effect that e.g. after -ffast-math -fno-finite-math-only the __FAST_MATH__ macro is no longer predefined, but after -ffast-math -fno-associative-math the __FAST_MATH__ macro still *is* predefined, even though both -ffinite-math-only and -fassociative-math are implied by -ffast-math. Is this deliberate? (If so, is it documented somewhere?) Or is this just a bug and fast_math_flags_set_p ought to check all flags implied by -ffast-math? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain ulrich.weig...@de.ibm.com
Re: fast_math_flags_set_p vs. set_fast_math_flags inconsistency?
On Mon, 20 Jan 2020, Ulrich Weigand wrote: > This has the effect that e.g. after > > -ffast-math -fno-finite-math-only > > the __FAST_MATH__ macro is no longer predefined, but after > > -ffast-math -fno-associative-math > > the __FAST_MATH__ macro still *is* predefined, even though both > -ffinite-math-only and -fassociative-math are implied by -ffast-math. > > Is this deliberate? (If so, is it documented somewhere?) I'd expect both to cause it to be undefined. My guess would be that some past patch, after fast_math_flags_set_p was added, added more flags to -ffast-math but accidentally failed to update fast_math_flags_set_p; you'd need to look at past patches adding flags to -ffast-math to confirm if it's accidental. -- Joseph S. Myers jos...@codesourcery.com
GCC Multi-Threading Ideas
Greetings All, Unfortunately due to me being rather busy with school and other things I will not be able to post my article to the wiki for awhile. However there is a rough draft here: https://docs.google.com/document/d/1po_RRgSCtRyYgMHjV0itW8iOzJXpTdHYIpC9gUMjOxk/edit that may change a little for people to read in the meantime. Please forgive me if there are grammar errors due to it being a draft. However, the discussion needs to continue in terms of long term and GSoC planning in terms of this project. In addition, Richard mentioned something similar to async workqueues but the biggest issue isn't the garbage collector. The bigger issue is how do we work around IPO passes and order them in order to avoid missed optimizations. Further more I've been thinking about it on and off, but it seems that there will be issues/compromise no matter what. Therefore due to this, the community at large will need to decide what policies we will have about IPO in a multi-threaded gcc including IPA passes. If there are any questions about the draft let me know or ideas about the IPO ordering issues including IPA passes you can contact me here. Sorry for not keeping you up to date as much after Cauldron, Nick
