Re: Building libgccjit with -fno-semantic-interposition? ( was Re: 1.76% performance loss in VRP due to inlining)
> FWIW I've no idea if any libgccjit users are using semantic > interposition; I suspect the answer is "no one is using it". > > Antoyo, Andrea [also CCed]: are either of you using semantic > interposition of symbols within libgccjit? Hi David, AFAIU in Emacs we are not relying on interposition of symbols. Thanks Andrea
Re: GCC 14.1 Release Candidate available from gcc.gnu.org
> On 30 Apr 2024, at 11:33, Jakub Jelinek via Gcc wrote: > > The first release candidate for GCC 14.1 is available from > > https://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240430/ > ftp://gcc.gnu.org/pub/gcc/snapshots/14.1.0-RC-20240430/ > > and shortly its mirrors. It has been generated from git commit > r14-10154-g7a00c459cbb913a. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux. > Please test it and report any issues to bugzilla. > > If all goes well, we'd like to release 14.1 on Tuesday, May 7th. > I have bootstrapped and tested this on powerpc, i686 darwin9 x86_64 darwin10 - 21 and darwin23, also on i686-darwin17. most of the results have been pushed to sourceware bunsen. In doing this I have found a wrong-code regression in Objective-C that is confined to Darwin (NeXT v2 runtime) and I will be applying a patch to trunk later (and then to affected branches) hopefully, it will be considered suitable for 14.1 too. thanks Iain
Re: Updated Sourceware infrastructure plans
On Wed, May 1, 2024 at 11:48 PM Richard Biener wrote: > > We'd only know for sure if we try. But then I'm almost 100% sure that > having to click in a GUI is slower than 'nrOK^X' in the text-mode mail UA > I am using for "quick" patch review. It might be comparable to the > review parts I do in the gmail UI or when I have to download attachments > and cut&paste parts into the reply. It might be also more convenient > for "queued" for review patches which just end up in New state in either > inbox. Gerritt does not require clicking in a GUI, though that is of course the more widely used option. Patches can be approved from the command line. > But then would using gitlab or any similar service enforce the use of > pull requests / forks for each change done or can I just continue to > post patches and push them from the command-line for changes I > can approve myself? Gerritt permits submitting patches from the command line for people who can self-approve. > Btw, for any forge like tool I'd even consider there'd be the requirement > that _all_ functionality is also accessible via a documented (stable) API, > aka there's command-line tooling available or at least possible to write. True of Gerritt. Ian
Re: Updated Sourceware infrastructure plans
Hi Jeff, On Wed, 2024-05-01 at 15:38 -0600, Jeff Law wrote: > What works well? If you've wired up some CI bits, it's is extremely > useful to test an under development patch. Develop, push a branch, > raise an MR. At that point the CI system kicks in. Subsequent pushes > to the branch trigger fresh CI runs. This aspect I really like and if > you were to see internal flows, you'd see dev branches churning as a > patch gets iterated on. It also has features like "when this passes CI, > automatically commit it", which we often use on the final patch > iteration if there was a nit of some kind. Although not as sophisticated (there are no triggers, just reports), builder.sourceware.org not only does normal CI runs, but does also offer try-runs for various Sourceware projects (just binutils, gdb, elfutils, libabigail and valgrind for now) when someone pushes to their own users try-branch. As the binutils wiki describes it: https://sourceware.org/binutils/wiki/Buildbot git checkout -b frob hack, hack, hack... OK, looks good to submit git commit -a -m "Awesome hack" git push origin frob:users/username/try-frob ... wait for the emails to come in or watch buildbot try logs or watch bunsen logs ... Send in patches and mention what the try bot reported This is pretty nice for developing patches that you aren't totally sure yet are ready to submit. And there is of course the Linaro buildbot that watches (and updates) patchworks with results of various ARM systems. Which does something similar but for already submitted (to the mailinglist) patches. The idea is to provide something similar for GCC and RISC-V once we get the larger Pioneer Box: https://riscv.org/blog/2023/06/sophgo-donates-50-risc-v-motherboards-learn-more-about-the-pioneer-box/ But this has been postponed a few times now. Latest update (from about a week ago) is: "The supplier has reached out to let us know that they are still experiencing supply issues. At the moment they are expecting at least two months to get the hardware together." Cheers, Mark
Re: Updated Sourceware infrastructure plans
On 5/1/2024 10:26 PM, Mark Wielaard wrote: Hi Jason, On Wed, May 01, 2024 at 04:04:37PM -0400, Jason Merrill wrote: On 5/1/24 12:15, Jeff Law wrote: We're currently using patchwork to track patches tagged with RISC-V.� We don't do much review with patchwork.� In that model patchwork ultimately just adds overhead as I'm constantly trying to figure out what patches have been integrated vs what are still outstanding. Patchwork definitely isn't the answer IMHO.� Nor is gitlab MRs which we use heavily internally.� But boy I want to get away from email and to a pull request kind of flow. Do you (or others) have any thoughts about GitLab FOSS? The gitlab "community edition" still feels not very much "community". We could run our own instance, but it will still be "open core" with features missing to try to draw you towards the proprietary hosted saas version. Also it seems to have way too much overhead. The focus is clearly corporate developers where managers want assurances the mandatory "pipelines" are executed and "workflows" followed exactly. Hi Mark, I'm clearly in the "corporate developers" category here, and can testify that managers don't care about "pipelines and workflows". They do care that people's (very expensive) time be used sparingly. The most expensive time is reviewer time so the reasoning behind running CI pipelines or workflows before review is that it's not a good use of people's time to review a patch which breaks tests. The next most expensive time is that spent investigating breakages which could have been avoided with automated testing. It doesn't matter what the tool's name is: as long as one can see the change (diffs), whether the change is likely to break stuff (that's CI) and fellow hacker's comments in one place without having to trawl through multiple systems or set up complex local machinery, that's a recipe for faster reviews happening once a build is "green". I think we can agree that's a good thing! Github and GitLab are good from a corporate standpoint and they do the "all the info I need in one place" thing well, but are not exactly Libre. Has anyone considered https://forgejo.org/ ? It's a Libre fork of Gitea. Has functionality similar to github but is Libre and openly advocating compatibility between forges. Cheers, -- Claudio Bantaloukas
Re: Updated Sourceware infrastructure plans
On 5/2/24 2:47 AM, Richard Biener via Overseers wrote:> We'd only know for sure if we try. But then I'm almost 100% sure that > having to click in a GUI is slower than 'nrOK^X' in the text-mode mail UA > I am using for "quick" patch review. It might be comparable to the > review parts I do in the gmail UI or when I have to download attachments > and cut&paste parts into the reply. It might be also more convenient > for "queued" for review patches which just end up in New state in either > inbox. Speaking of my Gerrit experience. I don't think that it will ever be quite as fast and responsive as whatever terminal application you're using (because web app vs highly optimized native app). But the time saved in patch management, tracking down stuff, diffing patch versions, ease of downloading patches locally to try them you, CI integration, more than make up for it in terms of productivity, in my case. The particular case you describe is just one click in Gerrit. The current version of Gerrit has a "Code review +2" button on the top right, which is equivalent to an "OK" without further comments: https://i.imgur.com/UEz5xmM.png So, pretty quick too. If you want to add a general comment on the patch (a comment not bound to a specific line), typing `a` anywhere within a patch review brings you to the place where you can do that, and you can do `shift + enter` to post. In general, I think that Gerrit has a pretty good set of keyboard shortcuts to do most common operations: https://i.imgur.com/RrREsTt.png Not sure that you mean with the gmail UI and cut & paste part. I don't think you'd ever need to do something like that with Gerrit or similar review system. To put a comment on a line, you click on that line and type in the box. > But then would using gitlab or any similar service enforce the use of > pull requests / forks for each change done or can I just continue to > post patches and push them from the command-line for changes I > can approve myself? Like Ian said, with Gerrit, you can configure a repo such that you're still able to git push directly. If a patch review exists with the same Change-Id (noted as a git trailer in each commit) as a commit that gets directly pushed, that patch review gets automatically closed (marked as "Merged"). So you, as a maintainer with the proper rights, could for instance download a patch review I uploaded, fix some nits and git push directly. Gerrit will mark my patch review as Merged and the final version of the patch review will reflect whatever you pushed. Let's say you spot a typo in the code and want to push a trivial patch, you don't need to create a patch review on Gerrit, you just push directly (if the repo is configured to allow it). On the other hand, creating a patch review on Gerrit is not a big overhead, it's basically one "git push" to a magic remote. It prints you the URL, you can click on it, and you're there. Simon
Re: Updated Sourceware infrastructure plans
On 2024-05-01 22:26, Mark Wielaard wrote: > For now I am cleaning up Sergio's gerrit setup and upgrading it to the > latest version, so people can at least try it out. Although I must > admit that I seem to be the only Sourcewware PLC member that believes > this is very useful use of our resources. Even the biggest proponents > of gerrit seem to believe no project will actually adopt it. And on > irc there were some people really critical of the effort. It seems you > either love or really hate gerrit... When GDB upstream tried to use gerrit, I found it basically impossible to follow development, given the volume... The great thing with email is the threading of discussions. A discussion can fork into its own subthread, and any sane email client will display the discussion tree. Email archives also let you follow the discussion subthreads. That is great for archaeology too. With Gerrit that was basically lost, everything is super flat. And then following development via the gerrit instance website alone is just basically impossible too. I mean, gerrit is great to track your own patches, and for the actual review and diffing between versions. But for a maintainer who wants to stay on top of a project, then it's severely lacking, IME and IMO. (Note: I've been using Gerrit for a few years at AMD internally.)
Re: Updated Sourceware infrastructure plans
On 2024-05-01 22:04, Simon Marchi wrote: > The Change-Id trailer works very well for Gerrit: once you have the hook > installed you basically never have to think about it again, and Gerrit > is able to track patch versions perfectly accurately. A while ago, I > asked patchwork developers if they would be open to support something > like that to track patches, and they said they wouldn't be against it > (provided it's not mandatory) [1]. But somebody would have to implement > it. > > Simon > > [1] https://github.com/getpatchwork/patchwork/issues/327 +1000. It's mind boggling to me that people would accept Gerrit, which means that they'd accept Change-Id:, but then they wouldn't accept Change-Id: with a different system... :-)
Re: [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls
Am 28.04.2024 um 20:16 schrieb Ian Lance Taylor:
On Thu, Apr 25, 2024 at 1:15 PM Björn Schäpers wrote:
Attached is the combined version of the two patches, only implementing the
variant with the tlhelp32 API.
Tested on x86 and x86_64 windows.
Kind regards,
Björn.
A friendly ping.
Thanks. Committed as follows.
Which of your other patches are still relevant? Thanks.
Ian
Hi,
only this one.
Kind regards,
Björn.From 55d0f312c0a9c4e2305d72fa2329b37937a02e44 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bj=C3=B6rn=20Sch=C3=A4pers?=
Date: Sat, 6 Jan 2024 22:53:54 +0100
Subject: [PATCH 2/2] libbacktrace: Add loaded dlls after initialize
libbacktrace/Changelog:
* pecoff.c [HAVE_WINDOWS_H]:
(dll_notification_data): Added
(dll_notification_context): Added
(dll_notification): Added
(backtrace_initialize): Use LdrRegisterDllNotification to load
debug information of later loaded
dlls.
---
libbacktrace/pecoff.c | 106 ++
1 file changed, 106 insertions(+)
diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
index faa0be0b700..455a5c2191d 100644
--- a/libbacktrace/pecoff.c
+++ b/libbacktrace/pecoff.c
@@ -61,6 +61,34 @@ POSSIBILITY OF SUCH DAMAGE. */
#undef Module32Next
#endif
#endif
+
+#if defined(_ARM_)
+#define NTAPI
+#else
+#define NTAPI __stdcall
+#endif
+
+/* This is a simplified (but binary compatible) version of what Microsoft
+ defines in their documentation. */
+struct dll_notifcation_data
+{
+ ULONG reserved;
+ /* The name as UNICODE_STRING struct. */
+ PVOID full_dll_name;
+ PVOID base_dll_name;
+ PVOID dll_base;
+ ULONG size_of_image;
+};
+
+#define LDR_DLL_NOTIFICATION_REASON_LOADED 1
+
+typedef LONG NTSTATUS;
+typedef VOID CALLBACK (*LDR_DLL_NOTIFICATION)(ULONG,
+ struct dll_notifcation_data*,
+ PVOID);
+typedef NTSTATUS NTAPI (*LDR_REGISTER_FUNCTION)(ULONG,
+ LDR_DLL_NOTIFICATION, PVOID,
+ PVOID*);
#endif
/* Coff file header. */
@@ -911,6 +939,53 @@ coff_add (struct backtrace_state *state, int descriptor,
return 0;
}
+#ifdef HAVE_WINDOWS_H
+struct dll_notification_context
+{
+ struct backtrace_state *state;
+ backtrace_error_callback error_callback;
+ void *data;
+};
+
+static VOID CALLBACK
+dll_notification (ULONG reason,
+ struct dll_notifcation_data *notification_data,
+ PVOID context)
+{
+ char module_name[MAX_PATH];
+ int descriptor;
+ struct dll_notification_context* dll_context =
+(struct dll_notification_context*) context;
+ struct backtrace_state *state = dll_context->state;
+ void *data = dll_context->data;
+ backtrace_error_callback error_callback = dll_context->data;
+ fileline fileline;
+ int found_sym;
+ int found_dwarf;
+ HMODULE module_handle;
+
+ if (reason != LDR_DLL_NOTIFICATION_REASON_LOADED)
+return;
+
+ if (!GetModuleHandleExW (GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS
+ | GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT,
+ (wchar_t*) notification_data->dll_base,
+ &module_handle))
+return;
+
+ if (!GetModuleFileNameA ((HMODULE) module_handle, module_name, MAX_PATH - 1))
+return;
+
+ descriptor = backtrace_open (module_name, error_callback, data, NULL);
+
+ if (descriptor < 0)
+return;
+
+ coff_add (state, descriptor, error_callback, data, &fileline, &found_sym,
+ &found_dwarf, (uintptr_t) module_handle);
+}
+#endif
+
/* Initialize the backtrace data we need from an ELF executable. At
the ELF level, all we need to do is find the debug info
sections. */
@@ -935,6 +1010,8 @@ backtrace_initialize (struct backtrace_state *state,
#endif
#ifdef HAVE_WINDOWS_H
+ HMODULE nt_dll_handle;
+
module_handle = (uintptr_t) GetModuleHandle (NULL);
#endif
@@ -981,6 +1058,35 @@ backtrace_initialize (struct backtrace_state *state,
}
#endif
+#ifdef HAVE_WINDOWS_H
+ nt_dll_handle = GetModuleHandleW (L"ntdll.dll");
+ if (nt_dll_handle)
+{
+ LDR_REGISTER_FUNCTION register_func;
+ const char register_name[] = "LdrRegisterDllNotification";
+ register_func = (void*) GetProcAddress (nt_dll_handle,
+ register_name);
+
+ if (register_func)
+ {
+ PVOID cookie;
+ struct dll_notification_context *context
+ = backtrace_alloc (state,
+ sizeof(struct dll_notification_context),
+ error_callback, data);
+
+ if (context)
+ {
+ context->state = state;
+ context->data = data;
+ context->error_callback = error_callback;
+
+ register_func (0, &dll_notific
Gcc
Hi Gcc, I'm checking in to see whether you're interested in getting the list of Distribution/Members List. *Harlan County Chamber of Commerce 2024 (Kentucky, USA) *1000+ Contacts I'm waiting for your response so I can let you know the Price and additional information. Warm regards, Sophia - Business Executive
gcc-12-20240502 is now available
Snapshot gcc-12-20240502 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20240502/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision 87e37c72cfb153d65ac8b26d6f2d1fe155818318 You'll find: gcc-12-20240502.tar.xz Complete GCC SHA256=c3d26b0086e19bfa6c8ba12c0f57646dbf6a1ad50df20ed1b4db711b4d719bb7 SHA1=a86c1498b1a7d2b685a46fbf01e37ade836b63f0 Diffs from 12-20240419 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Updated Sourceware infrastructure plans
On Thu, May 2, 2024 at 8:35 AM Pedro Alves wrote: > > On 2024-05-01 22:04, Simon Marchi wrote: > > The Change-Id trailer works very well for Gerrit: once you have the hook > > installed you basically never have to think about it again, and Gerrit > > is able to track patch versions perfectly accurately. A while ago, I > > asked patchwork developers if they would be open to support something > > like that to track patches, and they said they wouldn't be against it > > (provided it's not mandatory) [1]. But somebody would have to implement > > it. > > > > Simon > > > > [1] https://github.com/getpatchwork/patchwork/issues/327 > > +1000. It's mind boggling to me that people would accept Gerrit, which > means that they'd accept Change-Id:, but then they wouldn't accept > Change-Id: with a different system... :-) > Gerrit uses "Change-Id:" as stable identifiers to track patches. https://gregoryszorc.com/blog/2020/01/07/problems-with-pull-requests-and-how-to-fix-them/ has some analysis how they are much better than the alternative smart way. Perhaps URLs as stable identifiers will work better. If a reader wants to find relevant discussions, they can just click the link in many browsers, terminals, and editors. Currently, searching for discussions about a specific commit requires searching its title on https://inbox.sourceware.org/gcc-patches/ . For older patches, I might even need to dig through https://gcc.gnu.org/pipermail/gcc-patches/-/ archives. I agree with Jeff that principal reviewers will drive improvement to the code review process. I am sharing two code review services LLVM has used. --- Between 2012 and Sep 2023, LLVM had relied on its self-hosted Phabricator instance for code review. Fetching a patch to your local branch was as simple as `arc patch D12345`. Similarly, creating or updating a patch involved `arc diff`. I believe other code review services provide similar command line functionality, --- In September 2023, LLVM transitioned to GitHub for code review. I really dislike its code review service (however, this is a large step forward than email based code review). From https://maskray.me/blog/2023-09-09-reflections-on-llvm-switch-to-github-pull-requests > On the other hand, GitHub structures the concept of pull requests around > branches and enforces a branch-centric workflow. A pull request centers on > the difference (commits) between the base branch and the feature branch. > GitHub does not employ a stable identifier for commit tracking. If commits > are rebased, reordered, or combined, GitHub can easily become confused. > > When you force-push a branch after a rebase, the user interface displays a > line such as "force-pushed the BB branch from X to Y". Clicking the "compare" > button in GitHub presents something like git diff X..Y, which includes > unrelated commits. Ideally, GitHub would show the difference between the two > patch files, as Phabricator does, but it only displays the difference between > the two head commits. These unrelated in-between commits might be acceptable > for projects with lower commit frequency but can be challenging for a project > with a code frequency of 100+ commits every day. > > The fidelity of preserving inline comments after a force push has always been > a weakness. The comments may be presented as "outdated". In the past, there > was a notorious "lost inline comment" problem. Nowadays, the situation has > improved, but some users still report that inline comments may occasionally > become misplaced. Thankfully, getcord/spr comes to a rescue. User branches allow me to create/update a patch using `spr diff` like `arc diff` for Phabricator.
Re: Updated Sourceware infrastructure plans
Pedro Alves via Overseers writes: > When GDB upstream tried to use gerrit, I found it basically impossible to > follow development, given the volume... The great thing with email is the > threading of discussions. A discussion can fork into its own subthread, and > any > sane email client will display the discussion tree. Email archives also let > you follow the discussion subthreads. That is great for archaeology too. > With Gerrit that was basically lost, everything is super flat. And > then following > development via the gerrit instance website alone is just basically > impossible too. > I mean, gerrit is great to track your own patches, and for the actual review > and diffing between versions. But for a maintainer who wants to stay > on top of a > project, then it's severely lacking, IME and IMO. My experience is the exact opposite. As I'm sure you know, Gerritt supports specific comments on a code review, and discussions on those comments are tracked separately. For a complex patch, or series of patches, you don't get lost in lots of separate discussions, as Gerritt tracks them all for you separately. But it's true that to use that effectively you have to look at the web interface. The comments are available via git commands, but not in a directly usable format. Ian
Asking for HELP
Hi! I'm trying to modify the GCC source code to get something done. But there's a difficulty in understanding how to use some functions and data structures. Please help me with some hints. Here is the problem: in the file GCC-source/gcc/c/c-decl.c, before 'c_decl_attributes' is called in 'start_function', I want to insert some additional optimize attributes in 'attributes' tree to be proceed, but I could not find the correct way to insert a new tree in it. Thanks in advance.
