Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

2025-04-22 Thread Jason Merrill
On 4/22/25 1:21 PM, Tobias Burnus wrote: Jason Merrill wrote: On 4/22/25 11:04 AM, Tobias Burnus wrote: The question is why does this code trigger at all, given that there is OpenMP but no offload code at all? And how to fix it in case there is offload code and modules are used. This seems to

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

2025-04-22 Thread Jakub Jelinek
On Tue, Apr 22, 2025 at 07:21:14PM +0200, Tobias Burnus wrote: > I currently do not see whether the code is needed in this case or not, but I > assume it is, if we want to support static initializers?!? > > In any case, it seems as if the condition 'if (flag_openmp)' additionally > requires '&& lo

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

2025-04-22 Thread Tobias Burnus
Jason Merrill wrote: On 4/22/25 11:04 AM, Tobias Burnus wrote: The question is why does this code trigger at all, given that there is OpenMP but no offload code at all? And how to fix it in case there is offload code and modules are used. This seems to be because of:   if (module_global_init

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

2025-04-22 Thread Jason Merrill
On 4/22/25 11:04 AM, Tobias Burnus wrote: Jason Merrill wrote: This is OK with a FIXME; presumably if we want to support running static constructors on the offload target we will eventually want to support that in modules as well. Well, the code that added support for static constructors on

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

2025-04-22 Thread Tobias Burnus
Jason Merrill wrote: This is OK with a FIXME; presumably if we want to support running static constructors on the offload target we will eventually want to support that in modules as well. Well, the code that added support for static constructors on the offload target exposed the issue. Thus

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

2025-04-22 Thread Jakub Jelinek
On Tue, Apr 22, 2025 at 10:47:31AM -0400, Jason Merrill wrote: > On 4/21/25 6:46 AM, Nathaniel Shead wrote: > > I don't really know how OpenMP works, hopefully this makes sense. > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? > > And for 15 (I guess after release)? > > This is

Re: [PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

2025-04-22 Thread Jason Merrill
tatic constructors on the offload target we will eventually want to support that in modules as well. In r15-2799-gf1bfba3a9b3f31, a new kind of global constructor was added. Unfortunately this broke C++20 modules, as both the host and target constructors were given the same mangled name. This patch en

[PATCH] c++: Fix OpenMP support with C++20 modules [PR119864]

2025-04-21 Thread Nathaniel Shead
I don't really know how OpenMP works, hopefully this makes sense. Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk? And for 15 (I guess after release)? -- >8 -- In r15-2799-gf1bfba3a9b3f31, a new kind of global constructor was added. Unfortunately this broke C++20 modules,

Re: C++ 20 modules

2020-12-22 Thread Gerald Pfeifer
On Mon, 21 Dec 2020, Nathan Sidwell wrote: > Yes, this is good. I already managed to commit some of this with > the 98412 patch. I wasn't sure, but seeing that you had not applied this, I figured this was approval and pushed the remaining portion this afternoon, per the below. Gerald PS: I am

Re: C++ 20 modules

2020-12-21 Thread Nathan Sidwell
On 12/21/20 12:38 PM, Gerald Pfeifer wrote: O Mon, 21 Dec 2020, Nathan Sidwell wrote: /scratch/tmp/gerald/GCC-HEAD/gcc/cp/mapper-client.cc:31: In file included from /scratch/tmp/gerald/GCC-HEAD/gcc/cp/mapper-client.h:26: In file included from /scratch/tmp/gerald/GCC-HEAD/gcc/../libcody/cody.hh:2

Re: C++ 20 modules

2020-12-21 Thread Gerald Pfeifer
O Mon, 21 Dec 2020, Nathan Sidwell wrote: >> /scratch/tmp/gerald/GCC-HEAD/gcc/cp/mapper-client.cc:31: >> In file included from >> /scratch/tmp/gerald/GCC-HEAD/gcc/cp/mapper-client.h:26: >> In file included from >> /scratch/tmp/gerald/GCC-HEAD/gcc/../libcody/cody.hh:24: >> In file included from /usr

Re: C++ 20 modules

2020-12-21 Thread Nathan Sidwell
On 12/20/20 6:57 PM, Gerald Pfeifer wrote: On Thu, 17 Dec 2020, Nathan Sidwell wrote: As yesterday, several issues fixed: Here is a new one, *-unknown-freebsd11.4; with my previous patch /scratch/tmp/gerald/GCC-HEAD/gcc/cp/mapper-client.cc In file included from /scratch/tmp/gerald/GCC-HEAD/

Re: C++ 20 modules

2020-12-20 Thread Gerald Pfeifer
On Thu, 17 Dec 2020, Nathan Sidwell wrote: > As yesterday, several issues fixed: Here is a new one, *-unknown-freebsd11.4; with my previous patch applied, libcody builds and we now fail in gcc/cp: c++ -std=c++11 -fno-PIE -c -DIN_GCC_FRONTEND -g -DIN_GCC -fno-strict-aliasing -fno-exceptions -fno-

Re: C++ 20 modules

2020-12-17 Thread Nathan Sidwell
As yesterday, several issues fixed: * 98315 Rainer confirmed fixed * 98300 Reported noted progress, first patch committed * An m68k 'nop' issue fixed * 98340 Another clang issue, fixed * 98324 One PIC issue fixed. * 98316 solaris libs, Rainer posted patch, which LGTM * 98324 bootstrap with lto/PI

Re: C++ 20 modules

2020-12-16 Thread Nathan Sidwell
Several issues have been fixed today: * Solaris headers 98315 (hopefully finally) * install-strip 98328 * clang offsetof 98323 (I typoed the PR in the commit) * libcody enable-checking 98311 (thanks Jakub for the followup) * source_location etc fix from Jonathan * More dashisms * detailed-mem-sta

Re: C++ 20 modules

2020-12-15 Thread Rainer Orth
Hi Nathan, > as expected there are a bunch of configurey type errors. I am aware of the > following: [...] > solaris 11, sys/socket.h, bcopy and poisoning. Asked jwakely to try a > patch, he seems to have a build set up. two more Solaris issues (will file proper PRs tomorrow): * Solaris 11.4

Re: C++ 20 modules

2020-12-15 Thread Nathan Sidwell
as expected there are a bunch of configurey type errors. I am aware of the following: windows build (pr 98300), insufficient #ifing. A patch is being tested solaris 11, sys/socket.h, bcopy and poisoning. Asked jwakely to try a patch, he seems to have a build set up. AIX install. Testing

C++ 20 modules

2020-12-15 Thread Nathan Sidwell
I've completed merging modules to trunk modulo the testsuite. I included a few smoke tests, but nothing more. I'll add the rest when the smoke clears. There will undoubtedly be issues related to configs that I've not built. As I mentioned I did what I could. Further, it'll undoubtedly bre

doc: Document C++ 20 modules

2020-12-15 Thread Nathan Sidwell
ined everywhere they are called. +@item -fmodules-ts +@itemx -fno-modules-ts +@opindex fmodules-ts +@opindex fno-modules-ts +Enable support for C++20 modules (@xref{C++ Modules}). The +@option{-fno-modules-ts} is usually not needed, as that is the +default. Even though this is a C++20 feature, it is

Re: [00/32] C++ 20 Modules

2020-11-16 Thread Boris Kolpackov
Nathan Sidwell writes: > It is not a complete implementation. The major missing pieces are: [...] Would now be a good time to start reporting bugs in bugzilla so that things don't fall through the cracks? Is so, would it make sense to add the "c++ modules" component to bugzilla?

Re: [00/32] C++ 20 Modules

2020-11-13 Thread Mike Stump via Gcc-patches
On Nov 3, 2020, at 1:12 PM, Nathan Sidwell wrote: > > Here is the implementation of C++20 modules that I have been developing on > the devel/c++-modules branch over the last few years. I was just recently wondering about this. Congratulations. > It is some 25K new lines o

Re: [00/32] C++ 20 Modules

2020-11-06 Thread Boris Kolpackov
Nathan Sidwell writes: > The repo is providing a mechanism by which two processes can synchronize > on a fixed location in the file system that is not /. You need such a > capability as the file system is the bulk transfer mechanism. > > The alternatives are to always use absolute paths, or r

Re: [00/32] C++ 20 Modules

2020-11-05 Thread Richard Biener via Gcc-patches
On November 5, 2020 4:25:23 PM GMT+01:00, Nathan Sidwell wrote: >On 11/5/20 8:33 AM, Richard Biener wrote: > >> Moving the module mapper to a more easily (build-)testable location >> and to a place where host dependences can be more easily fixed >> & customized than in a bootstrapped directory wou

Re: [00/32] C++ 20 Modules

2020-11-05 Thread Nathan Sidwell
On 11/5/20 2:08 AM, Boris Kolpackov wrote: To give an example of such a likely change, currently the mapper has a notion of the central module repository directory that is used to resolve all the relative CMI (compiled module interface[1]) paths (even paths like ./foo.gcm). However, this model

Re: [00/32] C++ 20 Modules

2020-11-05 Thread Nathan Sidwell
On 11/5/20 8:33 AM, Richard Biener wrote: Moving the module mapper to a more easily (build-)testable location and to a place where host dependences can be more easily fixed & customized than in a bootstrapped directory would be nice. Thus, I think the module mapper should be in the toplevel som

Re: [00/32] C++ 20 Modules

2020-11-05 Thread David Malcolm via Gcc-patches
On Tue, 2020-11-03 at 16:12 -0500, Nathan Sidwell wrote: [...] [CCing Joseph] > I have bootstrapped and tested on: > x86_64-linux > aarch64-linux > powerpc8le-linux > powerpc8-aix > > Iain Sandoe has been regularly bootstrapping on x86_64- > darwin. Joseph > Myers graciously built for i686-mi

Re: [00/32] C++ 20 Modules

2020-11-05 Thread Richard Biener via Gcc-patches
On Tue, Nov 3, 2020 at 10:12 PM Nathan Sidwell wrote: > > Here is the implementation of C++20 modules that I have been developing > on the devel/c++-modules branch over the last few years. > > It is not a complete implementation. The major missing pieces are: > > 1) Pr

Re: [00/32] C++ 20 Modules

2020-11-04 Thread Boris Kolpackov
Nathan Sidwell writes: > Here is the implementation of C++20 modules that I have been developing > on the devel/c++-modules branch over the last few years. Congrats on reaching this point. > It is not a complete implementation. The major missing pieces are: > > [...]

Re: [00/32] C++ 20 Modules

2020-11-04 Thread Nathan Sidwell
On 11/4/20 9:15 AM, Jason Merrill wrote: On Wed, Nov 4, 2020 at 8:50 AM Nathan Sidwell > wrote: We can; apparently the necessary incantation is to #define INCLUDE_ALGORITHM thanks that's fixed the build problem. And working around the i386 error I get a working toolc

Re: [00/32] C++ 20 Modules

2020-11-04 Thread Jason Merrill via Gcc-patches
On Wed, Nov 4, 2020 at 8:50 AM Nathan Sidwell wrote: > On 11/4/20 7:30 AM, Nathan Sidwell wrote: > > > rechecking the compile-farm page, I see gcc45 is a 686 machine, I'll try > > that. > > yeah, that didn't work. There's compilation errors in > ../../../src/gcc/config/i386/x86-tune-costs.h abou

Re: [00/32] C++ 20 Modules

2020-11-04 Thread Nathan Sidwell
On 11/4/20 7:30 AM, Nathan Sidwell wrote: rechecking the compile-farm page, I see gcc45 is a 686 machine, I'll try that. yeah, that didn't work. There's compilation errors in ../../../src/gcc/config/i386/x86-tune-costs.h about missing initializers. and then ... In file included from /usr

Re: [00/32] C++ 20 Modules

2020-11-04 Thread Nathan Sidwell
On 11/3/20 10:14 PM, Hans-Peter Nilsson wrote: On Tue, 3 Nov 2020, Nathan Sidwell wrote: I have bootstrapped and tested on: x86_64-linux aarch64-linux powerpc8le-linux powerpc8-aix Iain Sandoe has been regularly bootstrapping on x86_64-darwin. Joseph Myers graciously built for i686-mingw hos

Re: [00/32] C++ 20 Modules

2020-11-03 Thread Hans-Peter Nilsson
On Tue, 3 Nov 2020, Nathan Sidwell wrote: > Here is the implementation of C++20 modules that I have been developing on the > devel/c++-modules branch over the last few years. Ow. > I have bootstrapped and tested on: > x86_64-linux > aarch64-linux > powerpc8le-linux >

[00/32] C++ 20 Modules

2020-11-03 Thread Nathan Sidwell
Here is the implementation of C++20 modules that I have been developing on the devel/c++-modules branch over the last few years. It is not a complete implementation. The major missing pieces are: 1) Private Module Fragment The syntax is recognized and a sorry emitted 2) textually parsing a