Re: Targetting p0847 for GCC14 (explicit object parameter)
On Thu, 8 Jun 2023, 05:07 waffl3x via Gcc, wrote: > I would like to boldly suggest implementing P0847 should be targeted at > GCC14. In my anecdotal experiences, this feature is very important to > people, and very important to myself, I believe it should be a priority. > > I am not suggesting this without offering to contribute, however > because of my inexperience with compiler hacking I am concerned I would > hinder efforts. With that said, if no one is interested in starting > work on it, but there is consensus that the feature is important > enough, then I will do my best to take up that job. > > If this was already the understood plan for GCC14, I apologize for my > ignorance on the matter. I searched around and couldn't find any > information regarding it, the mail list didn't seem to have any results > either. If it's there and I missed it, please do point it out. I am > also wondering if there is a public document with information about the > feature roadmap? No, we don't do that. It doesn't really make sense for a project like gcc. There is no management setting goals and priorities, nor assigning work to anybody. For large-ish features like this there should be a bugzilla ticket. If somebody is planning to work on it, that ticket will be ASSIGNED to them. Any plans that exist will probably be noted there. I can understand why there isn't one if that isn't the > case, I imagine it would just cause a nuisance for the developers. I > had read the GCC Development Plan document a few months ago and given > the information in it I decided to wait for development to move on to > GCC14 before getting in touch. In hindsight that might have been a > mistake, oops! > > I apologize if I overlooked something obvious, please don't hesitate to > correct any misconceptions I'm having here as it's not my intention to > step on any toes here, I just really really value this feature and want > to see it sooner rather than later. > > I look forward to hearing everyone's input, > -Alex >
Imagination Technologies Limited - FSF copyright assignment forms
Hi folks. Could you please send across the relevant copyright assignment forms to enable contributions to GCC from Imagination Technologies Limited? Thanks in advance. Best Ed
Re: Imagination Technologies Limited - FSF copyright assignment forms
Hi Ed, On Thu, Jun 08, 2023 at 10:32:15AM +, Ed Crothall wrote: > Could you please send across the relevant copyright assignment forms > to enable contributions to GCC from Imagination Technologies > Limited? At https://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright you'll find the request-assign.changes file which you can sent to ass...@gnu.org who will help you get the correct copyright assignment and company disclaimer forms. Cheers, Mark
Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?
Hi Arsen, On Tue, Jun 06, 2023 at 08:43:05PM +0200, Arsen Arsenović via Gcc wrote: > IMO, the sparing usage of this power on what are clearly purely abusive > participants can only drive away users and contributors. It seems > reasonable to establish a process for dealing with incidents like this > (and appeals, of course), especially given their frecency. I completely agree. Having a clear code of conduct for participants on this list and procedures for when people don't stop harassing others would be really welcome. Thanks, Mark
Re: Targetting p0847 for GCC14 (explicit object parameter)
On Thu, Jun 08, 2023 at 04:06:24 +, waffl3x via Gcc wrote: > I would like to boldly suggest implementing P0847 should be targeted at > GCC14. In my anecdotal experiences, this feature is very important to > people, and very important to myself, I believe it should be a priority. > > I am not suggesting this without offering to contribute, however > because of my inexperience with compiler hacking I am concerned I would > hinder efforts. With that said, if no one is interested in starting > work on it, but there is consensus that the feature is important > enough, then I will do my best to take up that job. Note that one way to help with a "feature that is very important" to oneself without compiler experience is to help write test cases (even better if it includes the necessary `dejagnu` markup). Corner cases are typically the trickiest to handle and filling it out ahead of time is likely very helpful to whoever does end up working on it. Indeed, because you're (likely) different from the feature implementer, you can help fill in blind spots that may be missed otherwise. It would also be useful to be somewhat systematic about it as well and take notes on what, specifically, is being tested in each case as well as where known gaps in the test cases exist. --Ben
Re: Targetting p0847 for GCC14 (explicit object parameter)
On Thu, Jun 8, 2023 at 3:54 AM Jonathan Wakely via Gcc wrote: > On Thu, 8 Jun 2023, 05:07 waffl3x via Gcc, wrote: > > > I would like to boldly suggest implementing P0847 should be targeted at > > GCC14. In my anecdotal experiences, this feature is very important to > > people, and very important to myself, I believe it should be a priority. > > > > I am not suggesting this without offering to contribute, however > > because of my inexperience with compiler hacking I am concerned I would > > hinder efforts. With that said, if no one is interested in starting > > work on it, but there is consensus that the feature is important > > enough, then I will do my best to take up that job. > > > > If this was already the understood plan for GCC14, I apologize for my > > ignorance on the matter. I searched around and couldn't find any > > information regarding it, the mail list didn't seem to have any results > > either. If it's there and I missed it, please do point it out. I am > > also wondering if there is a public document with information about the > > feature roadmap? > > No, we don't do that. It doesn't really make sense for a project like gcc. > There is no management setting goals and priorities, nor assigning work to > anybody. > > For large-ish features like this there should be a bugzilla ticket. If > somebody is planning to work on it, that ticket will be ASSIGNED to them. > Any plans that exist will probably be noted there. > Specifically: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609 In general the implementation status of new language features can be found at https://gcc.gnu.org/projects/cxx-status.html ; for features not yet implemented, the "No" links to the corresponding PR. I definitely agree that we want the feature, but I don't expect to have time to implement it myself for GCC 14. If you're interested in looking at it, that's great! Please feel free to contact me with any questions. Jason
Re: [PATCH v6 0/4] P1689R5 support
> On Jun 7, 2023, at 00:50, Ben Boeckel via Gcc-patches > wrote: > > Hi, > > This patch series adds initial support for ISO C++'s [P1689R5][], a > format for describing C++ module requirements and provisions based on > the source code. This is required because compiling C++ with modules is > not embarrassingly parallel and need to be ordered to ensure that > `import some_module;` can be satisfied in time by making sure that any > TU with `export import some_module;` is compiled first. Hi Ben, This patch series causes ICEs on arm-linux-gnueabihf. Would you please investigate? Please let me know if you need any in reproducing these. === g++ tests === Running g++:g++.dg/modules/modules.exp ... FAIL: g++.dg/modules/ben-1_a.C -std=c++17 (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/ben-1_a.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/ben-1_a.C -std=c++2a (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/ben-1_a.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/ben-1_a.C -std=c++2b (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/ben-1_a.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/ben-1_a.C module-cmi =partitions/module-import.mod (partitions/module-import.mod) FAIL: g++.dg/modules/ben-1_b.C -std=c++17 (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/ben-1_b.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/ben-1_b.C -std=c++2a (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/ben-1_b.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/ben-1_b.C -std=c++2b (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/ben-1_b.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/ben-1_b.C module-cmi =module.mod (module.mod) FAIL: g++.dg/modules/gc-2_a.C -std=c++17 (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/gc-2_a.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/gc-2_a.C -std=c++2a (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/gc-2_a.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/gc-2_a.C -std=c++2b (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/gc-2_a.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/gc-2_a.C module-cmi =map-1_a.nms (map-1_a.nms) UNRESOLVED: g++.dg/modules/map-1 -std=c++17 execute UNRESOLVED: g++.dg/modules/map-1 -std=c++17 link UNRESOLVED: g++.dg/modules/map-1 -std=c++2a execute UNRESOLVED: g++.dg/modules/map-1 -std=c++2a link UNRESOLVED: g++.dg/modules/map-1 -std=c++2b execute UNRESOLVED: g++.dg/modules/map-1 -std=c++2b link FAIL: g++.dg/modules/map-1_a.C -std=c++17 (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-1_a.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/map-1_a.C -std=c++2a (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-1_a.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/map-1_a.C -std=c++2b (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-1_a.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/map-1_a.C module-cmi =map-1_a.nms (map-1_a.nms) FAIL: g++.dg/modules/map-1_b.C -std=c++17 (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-1_b.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/map-1_b.C -std=c++2a (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-1_b.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/map-1_b.C -std=c++2b (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-1_b.C -std=c++2b (test for excess errors) FAIL: g++.dg/modules/map-2.C -std=c++17 at line 8 (test for errors, line 7) FAIL: g++.dg/modules/map-2.C -std=c++17 at line 9 (test for errors, line ) FAIL: g++.dg/modules/map-2.C -std=c++17 (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-2.C -std=c++17 (test for excess errors) FAIL: g++.dg/modules/map-2.C -std=c++2a at line 8 (test for errors, line 7) FAIL: g++.dg/modules/map-2.C -std=c++2a at line 9 (test for errors, line ) FAIL: g++.dg/modules/map-2.C -std=c++2a (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-2.C -std=c++2a (test for excess errors) FAIL: g++.dg/modules/map-2.C -std=c++2b at line 8 (test for errors, line 7) FAIL: g++.dg/modules/map-2.C -std=c++2b at line 9 (test for errors, line ) FAIL: g++.dg/modules/map-2.C -std=c++2b (internal compiler error: Segmentation fault) FAIL: g++.dg/modules/map-2.C -std=c++2b (test for excess errors) === Thanks, -- Maxim Kuvyrkov https://www.linaro.org > > [P1689R5]: https://isocpp.org/files/papers/P1689R5.html > > I've also added patches to include imported module CMI files and the > module mapper file as dependencies of the compilation. I briefly looked > into adding dependencies on response files as well, but that appeared to > need some code contortions to have a `class mkdeps` available before > parsing the comma
gcc-11-20230608 is now available
Snapshot gcc-11-20230608 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20230608/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision e444b8bc680ad4c70cb8c589da565e8f40f48d98 You'll find: gcc-11-20230608.tar.xz Complete GCC SHA256=716de8212789537791f88a960478c2c860ced434c9aaa3c21f8bb1ad4887f5ed SHA1=8e7e6151532e8d86b903dfb9ce003a62ba8d5238 Diffs from 11-20230601 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 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.
