> On Jan 12, 2007, at 12:56 AM, Olivier Hainque wrote:
> >Working on GCC 4 based GNAT port for AIX 5.[23], our testsuite to
> >evaluate GDB (6.4) debugging capabilities currently yields very
> >unpleasant results compared to what we obtain with a GCC 3.4 based
> >compiler (80+ extra failures out of
> Joel, this is definitely a question for you; it's beyond my expertise in
> the working of the hooks. The issue is that when a merge commit is
> pushed, we only want mails for commits that are new *to the repository* -
> not those that are already in the repository (accessible from some other
> I think it's desirable for development that *happens on* the personal and
> vendor branches to be visible in gcc-cvs - that is different from things
> getting merged into them.
>
> Likewise for the refs/heads/devel/* development branches -
> non-fast-forward pushes are not permitted there, bu
> Unfortunately, that's not as simple to implement as I'd hoped, because
> git.py:git_run removes all leading and trailing whitespace from the output
> of the git command it runs, so the code checking commit messages can't
> tell whether there was whitespace at the start of the first line (or th
> A quick run of the testsuite reveals that this assumption is made
> all over. I am opposed to having this feature be a standard feature
> of the git-hooks, so you wouldn't have to add an ad hoc check.
> The way I would do it is by enhancing the git_run function to check
> for a parameter named "_
> AFAIU, we have access to more fine-grained information; isn’t it possible
> to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
> (because a ‘new’ commit does not have the extra fields set up for merges
> and rebases).
In my opinion, this would create a lot of complication for the
> > Would it be sufficient to say that some branches would only
> > trigger a summary email, but not individual commit emails?
>
> Maybe that will end up being appropriate for users / vendors branches, if
> we can't effectively distinguish rebased commits from new ones. But for
> shared fast-fo
> > > AFAIU, we have access to more fine-grained information; isn’t it possible
> > > to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
> > > (because a ‘new’ commit does not have the extra fields set up for merges
> > > and rebases).
> >
> > In my opinion, this would create a lo
Hi Luis,
> cc-ing the GCC mailing list, as we may want to use the same coding style for
> GDB and GCC.
>
> Yesterday I brought this topic up on IRC. I notice we started using more and
> more the "auto" keyword. In some cases, this is actually useful and makes
> the code a bit more compact. GDB ha
> > The problem is that the push fails witih:
> >
> > remote: *** The following commit was rejected by your
> > hooks.commit-extra-checker script (status: 1)
> > remote: *** commit: 03e87724864a17e22c9b692cc0caa014e9dba6b1
> > remote: *** The first line of a commit message should be a short
> > d
> > That's correct. The commit-extra-checker is called using the same list
> > of "added commits" as the other checks implemented in the hooks, and
> > that list excludes all commits accessible from existing references
> > in the repository.
>
> Since 03e87724864a17e22c9b692cc0caa014e9dba6b1 has b
On Tue, Sep 29, 2020 at 10:01:23AM -0700, Joel Brobecker wrote:
> > > That's correct. The commit-extra-checker is called using the same list
> > > of "added commits" as the other checks implemented in the hooks, and
> > > that list excludes all commits ac
On Tue, Sep 29, 2020 at 07:16:45PM +0200, Jan Hubicka wrote:
> > On Tue, 29 Sep 2020, Joel Brobecker wrote:
> >
> > > > > That's correct. The commit-extra-checker is called using the same list
> > > > > of "added commits" as the other
> I wonder I can get the branch moved, so I can do the benchmarking :)
> Any suggestions how to do that?
Unfortunately, I think the only way (sort of adding the suggested
workaround in the commit-extra-checker script), is to update
the branch directly in the bare repository on sourceware.org.
This
> > I wonder I can get the branch moved, so I can do the benchmarking :)
> > Any suggestions how to do that?
I just installed a small patch, hot-fix style which I am hoping will
fix your problem. Can you try it? It passes the testsuite, so the change
should be safe.
Let me know how it goes. I wil
> > I can confirm I was able to delete a branch on remove server:
> >
> > $ git push origin --delete refs/users/marxin/heads/gfc-trailing-spec
> > To git+ssh://gcc.gnu.org/git/gcc.git
> > - [deleted] refs/users/marxin/heads/gfc-trailing-spec
>
> That's because I fixed GCC's hook
> Which is what Joseph said, I think. The problem was that the
> update_hook script still gets called for branch deletions, and it was
> rejecting them. My fix was just to stop rejecting them:
>
> Author: Jonathan Wakely
> Date: Thu Oct 1 18:04:54 2020 +
>
>Do not check anything for re
> > > I wonder I can get the branch moved, so I can do the benchmarking :)
> > > Any suggestions how to do that?
>
> I just installed a small patch, hot-fix style which I am hoping will
> fix your problem. Can you try it? It passes the testsuite, so the change
> should be safe.
And now, the fix t
> After analyzing some test case failures in GCC and GDB I realized that
> there are various problems with the handling of DWARF pieces
> (particularly from registers) in the current implementations of GCC and
> GDB. I'm working on a fix for the GDB part, but first I'd like to check
> whether I'm
Hello everyone,
On Sat, Sep 14, 2019 at 04:53:17PM -0400, Jason Merrill wrote:
> At Cauldron this weekend Joel offered to adjust his git hooks
> (https://github.com/brobecke/git-hooks), which are already used by gdb
> and glibc, to meet GCC's needs. Separately, Joseph volunteered to
> deal with c
Hi Gerald,
On Mon, Sep 16, 2019 at 12:15:57AM +0800, Gerald Pfeifer wrote:
> On Sun, 15 Sep 2019, Joseph Myers wrote:
> > Apart from general review of the test conversion / conversion and hook
> > scripts, which everyone can do, I think the main thing would be to advise
> > on what needs to happ
> > You mean the email notification sent by the hooks when a commit
> > gets pushed? If yes, here is an example:
> >
> > https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00041.html
>
> Thank you, Joel! I got a little worried how to best parse that ;-),
> but then Joseph recommended against it an
> But before I say more I should point to the documentation which,
> for historical reasons, is available on the GDB wiki rather than
> the git-hooks GitHub repository. I will fix that, but in the meantime:
>
> https://sourceware.org/gdb/wiki/GitHooksUsersGuide
Just a quick note to confirm th
Hi Joseph,
Apologies for the slow replies. The end of this week has been
pretty packed, and next week will be as well. But I will make
sure we answer every questions and suggestions you have!
On Thu, Jan 09, 2020 at 02:25:59PM +, Joseph Myers wrote:
> On Mon, 16 Sep 2019, Joel Brobec
> * Additional branch namespaces refs/users//heads and
> refs/vendors//heads, and similar tag namespaces
> refs/users//tags and refs/vendors//tags.
Hmmm. Note to self: I missed the fact that this namespace was
also used for tags.
> * Only allowing branch deletion for certain ref patterns (refs/
> > Concretely, these are the changes I'm currently using to configure the
> > hooks in a way I think appropriate for GCC, and it would be useful if the
> > hooks could support such configuration in a more generic way in future so
> > that we can stop using a GCC-specific patched installation of
, this will trigger an email that looks like this:
| Subject: [repository_name] Created tag v0.1
| X-Act-Checkin: repository_name
| X-Git-Author: Test Suite
| X-Git-Refname: refs/tags/v0.1
| X-Git-Oldrev: 0000
| X-Git-Newrev: c4c1e91cddc3d48a
> > > I think the existing git hook configuration expects you to push
> > > only annotated tags, not lightweight tags (so you'd need to use -a
> > > / -s / -u when creating those tags).
> >
> > Ok, would use -a then; or do we plan to GPG sign some tags such as releases?
>
> I think signing future
> > > Plus one further change now: if a newly created branch is in refs/heads/,
> > > require it to be in refs/heads/devel/ or refs/heads/releases/ (i.e.
> > > enforce a particular branch naming convention, in particular to prevent
> > > mistakes where people accidentally push a branch into refs
> We could, it just feels like "branch names [in refs/heads/] must match one
> of these naming conventions" is something fairly generic rather than
> extremely GCC-specific.
I understand.
My fear is that we're discussing a lot of new configurations knobs.
And from experience, they can start int
> So, the current SVN mails are like:
> Subject: r280117 - in /trunk/libstdc++-v3: ChangeLog tes...
> To: gcc-...@gcc.gnu.org
>
> Author: redi
> Date: Fri Jan 10 15:27:50 2020
> New Revision: 280117
>
> URL: https://gcc.gnu.org/viewcvs?rev=280117&root=gcc&view=rev
> Log:
> libstdc++: Fix testcase f
Hello,
Eric and I discovered a discrepancy in the DWARF register numbering
on SPARC for floating point registers. The problem is more visible
on SPARC 64-bit because they are used for parameter passing, whether
i0 is used on 32-bit SPARC. Consider for instance the following code:
volatile r
> I propose therefore to accept the existing inconsistencies and deal
> with them entirely within GDB. I have figured out that the ISA bit
> lost in various places can still be recovered as long as we have
> symbol information -- that'll have the st_other attribute correctly
> set to one of s
> What is the status of STABS support?
In terms of GDB, it is no longer actively maintained. But if you
submit patches, I will do my best to review them.
--
Joel
> AIX still uses STABS. GCC produces it and GDB consumes it.
>
> Recent releases of AIX now support DWARF as well, but GCC and GDB have
> not been converted to use it on AIX.
Note that GNU ld is now completely usable; and one of the side
effects of using GNU ld is the ability to switch over to D
> > Can you please clarify what "GNU ld is not completely usable" means?
> > Is that referring to DWARF support? to compatibility with specific AIX
> > releases? to compatibility with AIX DWARF feature?
>
> Sorry, I meant what "GNU ld is now completely usable" means because I
> believe that it act
> It does not look like the changes were merged into the FSF tree. This
> also does not support some of the more recent AIX features added to
> GCC.
Tristan is usually pretty good at sending these sorts of patches.
I will ask him on Monday if some might be missing. He's been
extremely busy lately
> I and others have not been able to use GNU as and GNU ld to bootstrap
> GCC. The resulting object files and shared objects mostly worked in
> small experiments, but failed for larger projects, like GCC.
>
> Also, GNU as and GNU ld do not contain support for the new
> cmodel=large and thread loca
I was able to speak to Tristan, yesterday, and he confirmed that
we haven't been able to contribute a few of the patches he wrote.
Unfortunately, his TODO list is more than full, at the moment, and
we don't think he'll have time to work on that for a while. I might
have time in the next few weeks t
[moved to the GCC list]
> > I think that GDB on mips-irix has been in dire need of attention.
> > It's something I have on my list and I hope to get to it by the end
> > of the year, but my hopes often get overridden by more urgent issues...
> > The release that AdaCore uses in its product is GDB
Hi Frank,
> - just send the emails immediately, without the daemon stuff; if the
> delays are there to try to sequentialize them, consider instead
> getting the hooks to emit Message-Id:/In-Reply-To:/Date: headers to
> let MUA's sort properly at reception
We can certainly add a non-daemon m
41 matches
Mail list logo
