Re: adacore git-hooks - daemon-mode email vs. systemd-logind linger

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

Re: [RFA] src-release.sh: Fix gdb source tarball build failure due to libsframe

> >>>>> "Joel" == Joel Brobecker via Gdb-patches > >>>>> writes: > > Joel> ChangeLog: > > Joel> * src-release.sh (GDB_SUPPORT_DIRS): Add libsframe. > > Joel> Ok to apply to master? > > Looks good to

[RFA] src-release.sh: Fix gdb source tarball build failure due to libsframe

Hello, This script was recently changed as follow: | commit e619dddb3a45780ae66d762756882a3b896b617d | Date: Tue Nov 15 15:07:13 2022 -0800 | Subject: src-release.sh: Add libsframe | | Add libsframe to the list of top level directories that will be included | in a

Re: [ping] Re: [RFA] gcc.misc-tests/outputs.exp: Use link test to check for -gsplit-dwarf support

> >> gcc/testsuite/ChangeLog: > >> > >> * gcc.misc-tests/outputs.exp: Make the -gsplit-dwarf test > >> a compile-and-link test rather than a compile-only test. > > OK, thanks. Thank you Richard. Pushed to master. -- Joel

[ping] Re: [RFA] gcc.misc-tests/outputs.exp: Use link test to check for -gsplit-dwarf support

Hello, Gentle ping on this patch. Thank you! On Mon, Apr 25, 2022 at 09:04:51AM -0700, Joel Brobecker wrote: > Hello, > > We have noticed that, when running the GCC testsuite on AArch64 > RTEMS 6, we have about 150 tests failing due to a link failure. > When investigating, we

[RFA] gcc.misc-tests/outputs.exp: Use link test to check for -gsplit-dwarf support

Hello, We have noticed that, when running the GCC testsuite on AArch64 RTEMS 6, we have about 150 tests failing due to a link failure. When investigating, we found that all the tests were failing due to the use of -gsplit-dwarf. On this platform, using -gsplit-dwarf currently causes an error

Re: Patch RFA: Support non-ASCII file names in git-changelog

> > I have no idea who that is (if it is a single user at all, > > if it isn't any user with git write permissions). > > CCing Joel, he should help us how to set a git config > that will be used by the server hooks. I am not sure that requiring both the server and the user to agree on a

Re: Git rejecting branch merge

> > > 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

Re: Git rejecting branch merge

> 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: Git rejecting branch merge

> > 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

Re: Git rejecting branch merge

> > 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

Re: Git rejecting branch merge

> 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.

Re: Git rejecting branch merge

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 chec

Re: Git rejecting branch merge

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 commit

Re: Git rejecting branch merge

> > 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

Re: Git rejecting branch merge

> > 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 > >

Re: Coding style for C++ constructs going forward

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

Re: Ping: [RFA] Require powerpc_vsx_ok in gcc.target/powerpc/pr71763.c

Hi Peter and Segher, > > You should always CC the PPC maintainers on PPC patches. > > I've CC'd both Segher and David. Thanks a lot for doing that. And well understood for future patches. > > >>> This commit adds a powerpc_vsx_ok dg-require-effective-target directive > > >>> to that test, and

Re: Ping: [RFA] Require powerpc_vsx_ok in gcc.target/powerpc/pr71763.c

llowed onto branch master. > > > On Fri, Apr 17, 2020 at 04:49:47PM -0700, Joel Brobecker wrote: > > From: Douglas Rupp > > > > Hello, > > > > (submitting this on behalf of Doug Rupp, one of my colleagues) > > > > We're getting an e

Ping: [RFA] Require powerpc_vsx_ok in gcc.target/powerpc/pr71763.c

Hello, Just a friendly ping on the following patch, hopefully sufficiently straightforward and tested to be allowed onto branch master. Thank you! On Fri, Apr 17, 2020 at 04:49:47PM -0700, Joel Brobecker wrote: > From: Douglas Rupp > > Hello, > > (submitting this on behalf of

[RFA] Require powerpc_vsx_ok in gcc.target/powerpc/pr71763.c

From: Douglas Rupp Hello, (submitting this on behalf of Doug Rupp, one of my colleagues) We're getting an error when running this test on PowerPC VxWorks 7, due to an unexpected warning: | Excess errors: | cc1: warning: '-mvsx' and '-mno-altivec' are incompatible The warning comes

Re: [RFA] skip gcc.target/arm/div64-unwinding.c on vxworks_kernel targets

> > gcc/testsuite/ > > > > * gcc.target/arm/div64-unwinding.c: Skip on vxworks_kernel targets. > OK. Thank you, Richard. Pushed to master. -- Joel

[RFA] skip gcc.target/arm/div64-unwinding.c on vxworks_kernel targets

Hello, This test verifies, by using a weak reference to _Unwind_RaiseException, that performing division by zero does not cause that symbol to get indirectly pulled into our closure. The testing methodology unfortunately does not work on VxWorks targets when building in kernel mode. This is

Re: gcc-cvs mails for personal/vendor branches for merge commits

> > > 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

Re: gcc-cvs mails for personal/vendor branches for merge commits

> > 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

Re: gcc-cvs mails for personal/vendor branches for merge commits

> 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

Re: Whitespace at the start of first line of commit

> 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

Re: Whitespace at the start of first line of commit

> 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

Re: gcc-cvs mails for personal/vendor branches for merge commits

> 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,

Re: limit on emails for merge commits.

Hi Ian, > As I noted, 100 commits to master is a small number, so I expect this problem > to fire almost every time someone does a merge of master to a devel or user > branch (unless they have the habit of doing that almost daily, which I doubt > for > most). The main goal of the limit is really

Re: limit on emails for merge commits.

Hello, > You should include Joel on such questions as the expert on the hooks. > > I don't know whether there's something to put in the commit message to say > "allow this merge of more than 100 commits". I don't think a squashed > merge is the right workaround, supposing you do want the git

Re: gcc-cvs mails for personal/vendor branches for merge commits

> 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

Re: GIT: Monotonically increasing trunk and release branch ids

> 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=gcc=rev > Log: > libstdc++: Fix testcase for C++98

Re: GCC Git hooks

> 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

Re: GCC Git hooks

> > > 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

Re: GIT: Monotonically increasing trunk and release branch ids

> > > 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

Re: GIT: Monotonically increasing trunk and release branch ids

hat 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: | X-Git-Newrev: c4c1e91cddc3d48a2aab7d454bc6537149f37dd8 |

Re: GCC Git hooks

> > 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

Re: GCC Git hooks

> * 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

Re: GCC Git hooks

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

Re: GCC Git hooks

> 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

Re: GCC Git hooks

> > 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

Re: GCC Git hooks

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

Re: GCC Git hooks

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

Re: [RFA] adjust src-release following the renaming of gdb/common/ to gdb/gdbsupport/

> >ChangeLog: > > > >* src-release (getver): If $tool/gdbsupport/create-version.sh > >exists, use that to determine the version number. > > > >Tested on x86_64-linux, by running the src-release script with "gdb" > >as the argument, and verifying that the name of the tarball is now

[RFA] adjust src-release following the renaming of gdb/common/ to gdb/gdbsupport/

Hello, A recent change renamed the common/ directory into gdbsupport/ in gdb. This causes problems in the getver function in the src-release script which doesn't find the create-version.sh script anymore. As a result, it falls back on using the version.in file verbatim, meaning that the "DATE"

Re: [RFA] fix copyright year range in libstdc++ test file (was: "Re: [v3 PATCH] Implement std::string_view and P0254r2, Integrating std::string_view and std::string.")

> > In working on updating the copyright year notices for the GDB files, > > I noticed something very minor regarding the patch which added the > > file below (the same file was copied in gdb's testsuite); it looks > > like the year range for one of the files is truncated: > > >

[RFA] fix copyright year range in libstdc++ test file (was: "Re: [v3 PATCH] Implement std::string_view and P0254r2, Integrating std::string_view and std::string.")

fix pushed to GCC, I will take care of the GDB side. Thank you, -- Joel >From a29191e526c1aeed7da592af3e9bb51c7db8c297 Mon Sep 17 00:00:00 2001 From: Joel Brobecker Date: Tue, 1 Jan 2019 09:40:00 +0400 Subject: [PATCH] Fix year range in libstdc++v3/testsuite/.../empty.cc copyright header

Re: [RFA] require profiling support for gcc.dg/lto/20100430-1_0.c test

> > gcc/testsuite/ChangeLog: > > > > * gcc.dg/lto/20100430-1_0.c: Add dg-require-profiling requirement. > > > > OK to push? > > OK. Thank you Richard. Patch pushed to trunk (r267055). -- Joel

[RFA] require profiling support for gcc.dg/lto/20100430-1_0.c test

Hello, This test currently fails unexpectedly if GCC is configured with --disable-gcov, because it requires -fprofile-arcs. This patch fixes the issue by requiring profiling support in order to run this test. Tested with two compilers, one built with --disable-gcov, resulting in the test

Re: [PATCH] [configure] Added "nfp" to the build for binutils.

> +2018-04-30 Francois H. Theron > + > + * config.sub: Added "nfp" to basic_machine list. > + * configure.ac: Added "nfp" target. > + * configure: Regenerate. I am not a maintainer, but I noticed that config.sub is not being modified by this commit --

Re: MinGW compilation warnings in libiberty's waitpid.c

> I ended up not having time before going on holiday. If the resync > hasn't already been done, I'll do it now. Thanks for doing that, Iain! -- Joel

Re: MinGW compilation warnings in libiberty's waitpid.c

> This has been on my todo-list for a little while, as re-syncing is > something I normally do after pushing D language support updates into > libiberty. However I decided to give it a wait until I got all > pending patches in, the last of which I'm just pushing in now. That's very kind of you

Re: MinGW compilation warnings in libiberty's waitpid.c

> What can I do to expedite the process? This currently holds the 8.0 > release, and I'm uneasy to be the culprit. The way I usually do it is grab the commit in GCC, and apply it as is in the GDB repository. To make it easier, I use the git mirror of the GCC repository, because I can then just

Re: MinGW compilation warnings in libiberty's waitpid.c

> Thanks. Is the environ thing also fixed? > > Joel/Pedro, how should I go about making sure these changes are in the > GDB copy of libiberty? Normally, I'd expect someone pushing to GCC's libibert to also update our repo accordingly. However, it's easy to forget so, if you notice a change that

Re: [PATCH] For broken exception handling in GDB on AIX platform

Hello, > I got some review comment from Bernhard Reutner-Fischer, and I have > updated the patch accordingly. > This patch is for bug opened > here:https://sourceware.org/bugzilla/show_bug.cgi?id=21187 This patch has been identified as one of the desirable patches to have for the GDB 8.0

Re: [RFC] DW_OP_piece vs. DW_OP_bit_piece on a Register

> 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

Re: update zlib to 1.2.8

> No, just a packaging issue with somebody mentioning a static binutils build. > That's when I saw the outdated version. > > Now updated in the GCC VCS. OK, if you have updated the GCC sources, would you mind updating the binutils-gdb.git as well? We should really keep the two as much in sync as

Re: update zlib to 1.2.8

> In GCC zlib is only used for libjava; for binutils and gdb it is used when > building without --with-system-zlib. This just updates zlib from 1.2.7 to > 1.2.8 (released in 2013). Applies cleanly, libjava still builds and doesn't > show any regressions in the testsuite. Ok to apply (even if we

[RFA] Do not use libiberty's getpagesize on Android

Hello, Building libiberty on Android currently fails with the error message shown below. This was discovered by trying to build GDBserver for Android, which stopped building after libiberty became a GDBserver dependency. Here is the error message: [...]/getpagesize.c:64:1: error: redefinition

Re: [RFA] Do not use libiberty's getpagesize on Android

> > libiberty/ChangeLog: > > > > * configure.ac: Set AC_CV_FUNC_GETPAGESIZE to "yes" on > > Android hosts. > > * configure: Regenerate. > > > > OK to apply? > > Ok. Thank you, DJ. committed in gcc's SVN, and pushed to binutils-gdb. -- Joel

[RFA] libiberty/mkstemps.c: Include time.h if sys/time.h not available.

Hello, Attempting to build libiberty on LynxOS-178 fails trying to compile mkstemps.c with the following error: mkstemps.c:84:18: error: storage size of 'tv' isn't known struct timeval tv; ^ This file would normally include sys/time.h to get the type's

Re: [RFA] libiberty/mkstemps.c: Include time.h if sys/time.h not available.

* mkstemps.c: #include time.h if HAVE_TIME_H is defined but not HAVE_SYS_TIME_H. Ok. Thank you, DJ. Pushed to both GCC and binutils-gdb. -- Joel

Re: [PATCH] PR debug/61352 back port from mainline

The attached patch is a back port of the change from https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=211067 for gcc-4_9-branch. Bootstrap and regression tested on x86_64-apple-darwin14 with Xcode 6.3. Okay for gcc-4_9-branch? Jack PR61352_backport.diff Ok.

Re: ping #3: [RFA] Add --with-libz-prefix option in config/zlib.m4

Why do you want to turn off zlib? On Linux/x86, zlib is required for assembler. At least, you should issue an error when --without-libz is used in binutils for Linux/x86 target. I am trying to do the exact opposite, which is to provide an option to compile WITH zlib, but using an install at

Re: ping: [RFA] Add --with-libz-prefix option in config/zlib.m4

What is the rational for having --with-zlib but --with-libz-prefix (ie zlib vs libz) ? Looks not very consistent. I agree it's unfortunate, but it is unavoidable if I want to keep the current option as it is (compatibility), and reuse AC_LIB_HAVE_LINKFLAGS (which is a fairly complex function).

Re: [RFA] Add --with-libz-prefix option in config/zlib.m4

This patch enhances config/zlib.m4 to introduce an extra option --with-libz-prefix which allows us to provide the location of the zlib library we want to use during the build. I prefer the gcc way to provide external library: --with-zlib - system zlib used --with-zlib=pathname - zlib

Re: [PATCH] Add D demangling support to libiberty

From 9e4d74607075ef857dfa4e118f43641494aaff90 Mon Sep 17 00:00:00 2001 From: Joel Brobecker brobec...@adacore.com Date: Tue, 14 Oct 2014 09:54:05 -0400 Subject: [PATCH] libiberty: fallback on strtod if strtold is not available. This patch fixes a build failurer on Solaris 2.9, and all other systems

Re: [PATCH] Add D demangling support to libiberty

2001 From: Joel Brobecker brobec...@adacore.com Date: Tue, 14 Oct 2014 12:47:43 -0400 Subject: [PATCH] Use strtod instead of strtold in libiberty/d-demangle.c strtold is currently used to decode templates which have a floating-point value encoded inside; but this routine is not available on some

Re: [PATCH] Add D demangling support to libiberty

libiberty/ChangeLog: * d-demangle.c: Replace strtold with strtod in global comment. (strtold): Remove declaration. (strtod): New declaration. (dlang_parse_real): Declare value as double instead of long double. Replace call to strtold by call

Re: [RFA/dwarf v2] Add DW_AT_GNAT_use_descriptive_type flag for Ada units.

10:42 PM, Joel Brobecker wrote: This is useful when a DIE does not have a descriptive type attribute. In that case, the debugger needs to determine whether the unit was compiled with a compiler that normally provides that information, or not. Ah. OK, then. But I'd prefer to call

Re: [PATCH 1/2] Windows libibery: Don't quote args unnecessarily

Changelog libiberty/ * pex-win32.c (argv_to_cmdline): Don't quote args unnecessarily Some minor comments... diff --git a/libiberty/pex-win32.c b/libiberty/pex-win32.c index eae72c5..775b53c 100644 --- a/libiberty/pex-win32.c +++ b/libiberty/pex-win32.c @@ -340,17 +340,26

Re: copyright dates in binutils (and includes/)

Joseph, do you know why implicitly adding years to the claimed copyright years is a problem? I'm guessing the file needs to be published somewhere for each year claimed. IANAL, but from 2 discussions with copyright-clerk: 1. We start claiming copyright the year the file as committed

Re: copyright dates in binutils (and includes/)

Hi Alan, My two cents... --- a/bfd/elf32-sparc.c +++ b/bfd/elf32-sparc.c @@ -1,7 +1,5 @@ /* SPARC-specific support for 32-bit ELF - Copyright 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, - 2003, 2004, 2005, 2006, 2007, 2010, 2011 - Free Software Foundation, Inc. +

Re: [RFA/dwarf v2] Add DW_AT_GNAT_use_descriptive_type flag for Ada units.

working on producing standard DWARF in place of our encodings, and small progress has been made. But this is even more of a huge task than we thought, and in the meantime, this little flag will help non-AdaCore users... Thank you! On Fri, Jan 31, 2014 at 09:09:05AM +0400, Joel Brobecker wrote: On Tue

[RFA/dwarf v2] Add DW_AT_GNAT_use_descriptive_type flag for Ada units.

Hi Jason, On Tue, Feb 19, 2013 at 10:50:46PM -0500, Jason Merrill wrote: On 02/19/2013 10:42 PM, Joel Brobecker wrote: This is useful when a DIE does not have a descriptive type attribute. In that case, the debugger needs to determine whether the unit was compiled with a compiler

Re: [RFA/dwarf v2] Add DW_AT_GNAT_use_descriptive_type flag for Ada units.

[resending with the patch - sorry about that] Hi Jason, On Tue, Feb 19, 2013 at 10:50:46PM -0500, Jason Merrill wrote: On 02/19/2013 10:42 PM, Joel Brobecker wrote: This is useful when a DIE does not have a descriptive type attribute. In that case, the debugger needs to determine whether

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

Thanks! That's great progress on the Binutils side. You are very welcome. What is the status of patches for GCC to generate DWARF for AIX XCOFF and do the AIX assembler and linker recognize, consume and process the directives produced by GCC correctly? I haven't looked at this part in

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

AFAICT, for gcc+gas it should already work with binutils that include the AdaCore patch for DWARF support. But this has apparently not been tested with AIX ld, and there are AdaCore local patches pending. http://sourceware.org/ml/binutils/2011-04/msg00250.html

Re: [PATCH] Temporarily revert Steven's PCH changes for 4.8 (PR pch/54117)

-- Joel From dc928a0dbd0e762577c51204b043d6b6f066940d Mon Sep 17 00:00:00 2001 From: Joel Brobecker brobec...@adacore.com Date: Thu, 14 Feb 2013 23:53:25 +0100 Subject: [PATCH] AIX: add DWARF support * bfd/coff-rs6000.c (xcoff_dwsect_names): Add .dwframe, .dwloc, .dwmacif and .dwmacro

Ping: [RFA/dwarf] Add DW_AT_use_GNAT_descriptive_type flag for Ada units.

Hello, I was hoping someone would kindly review this patch? It is an important part for debugging Ada code, helping with performance. Thank you! On Tue, Jan 08, 2013 at 07:24:14AM -0500, Joel Brobecker wrote: Hello, I just noticed that part of the proposal we made for... http://gcc.gnu.org

Re: [RFA/dwarf] Add DW_AT_use_GNAT_descriptive_type flag for Ada units.

Ping? Thank you! On Tue, Jan 08, 2013 at 07:24:14AM -0500, Joel Brobecker wrote: Hello, I just noticed that part of the proposal we made for... http://gcc.gnu.org/wiki/DW_AT_GNAT_descriptive_type ... got missed in the patch that got checked in: http://gcc.gnu.org/ml/gcc-patches/2011-04

Re: stabs support in binutils, gcc, and gdb

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

Re: [RFA] statement before variable declaration in cp_parser_initializer_list.

Hi Richard, Hmm? We compile with a C++ compiler where this is perfectly valid ... I was compiling with GCC 4.7 where it gave me a warning... I don't know much about C++ anymore, so I didn't know. Oh well! Ah, for the 4.7 branch yes. Eric Botcazou asked that we have the same code for

[RFA/dwarf] Add DW_AT_use_GNAT_descriptive_type flag for Ada units.

Hello, I just noticed that part of the proposal we made for... http://gcc.gnu.org/wiki/DW_AT_GNAT_descriptive_type ... got missed in the patch that got checked in: http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00099.html In particular, we're missing the second part, where we are expected to

Re: [RFA] statement before variable declaration in cp_parser_initializer_list.

Eric Botcazou asked that we have the same code for both 4.7 and HEAD. Would it be OK to apply it to both? It's not really strictly necessary for the HEAD, but I don't see it as being harmful either. Sure. Thank you! Now checked in. -- Joel

Re: stabs support in binutils, gcc, and gdb

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,

Re: stabs support in binutils, gcc, and gdb

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 local

Re: stabs support in binutils, gcc, and gdb

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 actually is NOT

Re: stabs support in binutils, gcc, and gdb

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

Re: stabs support in binutils, gcc, and gdb

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

[RFA] statement before variable declaration in cp_parser_initializer_list.

Hello, I happened to notice a warning while compiling GCC, and it seemed like an easy fix... gcc/cp/ChangeLog: * parser.c (cp_parser_initializer_list): Move declaration of variable non_const to start of lexical block. Tested against x86_64-linux, no regression. OK to commit?

Re: [RFA] statement before variable declaration in cp_parser_initializer_list.

Tested against x86_64-linux, no regression. OK to commit? (obvious?) Hmm? We compile with a C++ compiler where this is perfectly valid ... I was compiling with GCC 4.7 where it gave me a warning... I don't know much about C++ anymore, so I didn't know. Oh well! -- Joel

Re: [RFA] .gitignore: Ignore *.pyc files.

Ping. This patch seems fairly straightforward to the point of being almost obvious, but so far, no review (beyond one email expressing interest). Thanks! The GDB sources contain some python files, and executing them causes these .pyc files to appear. We could ignore them in GDB only, but I

[RFA] .gitignore: Ignore *.pyc files.

Hello, The GDB sources contain some python files, and executing them causes these .pyc files to appear. We could ignore them in GDB only, but I think this is the type of extension (compilation artifact) which can be shared amoung all projects. ChangeLog: * .gitignore: Ignore *.pyc

Re: [RFD+PATCH] ISA bit treatment on the MIPS platform

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

Re: [RFA] Update config.sub to 2012-04-18 version.

ChangeLog: * config.sub: Update to 2012-04-18 version from official repo. Thanks to everyone who answered. This patch is no in, both GCC src. -- Joel

[RFA] Update config.sub to 2012-04-18 version.

Hello everyone, I wasn't sure if I needed approval for this patch or not, but better be safe than sorry. I'll apply to both GCC and then src when I receive confirmation that it's OK to apply. I would like to update the config.sub script to the latest version from the official config repo. The

Re: [RFA/libiberty] Darwin has case-insensitive filesystems

Looks OK to me. Thanks, DJ. I've just checked the patch in on the GCC side. I will push it on the src/GDB CVS momentarily. -- Joel

[RFA/libiberty] Darwin has case-insensitive filesystems

Hello, HFS+, the FS on Darwin, is case insensitive. So this patch adjusts filename_cmp.c to ignore the casing when comparing filenames on Darwin. This is visible in GDB when trying to break on a file whose name is, say 'Mixed_Case.adb', but was compiled using 'mixed_case.adb' as the filename.

  1   2   >