From: Jakub Jelinek
Sent: Saturday, May 17, 2025 22:11
To: Yuao Ma
Cc: gcc-patc...@gcc.gnu.org ; fortran@gcc.gnu.org
; tbur...@baylibre.com ;
j...@polyomino.org.uk
Subject: Re: [PATCH] gcc: add trigonometric pi-based functions as gcc builtins
On Wed, May 14, 2025 at 02:22:23PM +
On Wed, May 14, 2025 at 02:22:23PM +, Yuao Ma wrote:
> If approved, I suggest committing this foundational change first. Constant
> folding for these builtins will be addressed in subsequent patches.
Note, not just constant folding is needed, but I think the builtins should
be handled in
tree-
On 5/14/25 2:22 PM, Joseph Myers wrote:
On Wed, 14 May 2025, Yuao Ma wrote:
Hi Joseph,
I have updated the patch based on your review comments. I added the
newly introduced builtin to extend.texi and mentioned the PR in the
commit message. Could you please take another look when you have a
m
On Wed, 14 May 2025, Yuao Ma wrote:
> Hi Joseph,
>
> I have updated the patch based on your review comments. I added the
> newly introduced builtin to extend.texi and mentioned the PR in the
> commit message. Could you please take another look when you have a
> moment?
This version is OK in t
, May 15, 2025 0:47
To: Yuao Ma
Cc: gcc-patc...@gcc.gnu.org ; fortran@gcc.gnu.org
; tbur...@baylibre.com
Subject: Re: [PATCH] gcc: add trigonometric pi-based functions as gcc builtins
On Wed, 14 May 2025, Yuao Ma wrote:
> Hi all,
>
> This patch adds trigonometric pi-based functio
On Wed, 14 May 2025, Yuao Ma wrote:
> Hi all,
>
> This patch adds trigonometric pi-based functions as gcc builtins: acospi,
> asinpi, atan2pi,
> atanpi, cospi, sinpi, and tanpi. Latest glibc already provides support for
> these functions, which we plan to leverage
Hi all,
This patch adds trigonometric pi-based functions as gcc builtins: acospi,
asinpi, atan2pi,
atanpi, cospi, sinpi, and tanpi. Latest glibc already provides support for
these functions, which we plan to leverage in future gfortran implementations.
The patch includes two test cases to
On Fri, Apr 18, 2025 at 05:48:46PM -0700, Jerry D wrote:
> I will be committing a fix for this to the 16 mainline tonight.
>
> I am requesting Release Manager approval to push to 15 release branch after
> full testing here.
>
> Regards,
>
> Jerry
>
> See attached diff.
>
> 2025-04-18 Steven G
Ping! Can we backport this to 15 please?
Regards,
Jerry
On 4/18/25 6:35 PM, Jerry D wrote:
On 4/18/25 5:48 PM, Jerry D wrote:
I will be committing a fix for this to the 16 mainline tonight.
I am requesting Release Manager approval to push to 15 release branch
after full testing here.
Rega
On 4/18/25 5:48 PM, Jerry D wrote:
I will be committing a fix for this to the 16 mainline tonight.
I am requesting Release Manager approval to push to 15 release branch
after full testing here.
Regards,
Jerry
See attached diff.
2025-04-18 Steven G. Kargl
PR fortran/119836
* resolve.cc(
I will be committing a fix for this to the 16 mainline tonight.
I am requesting Release Manager approval to push to 15 release branch
after full testing here.
Regards,
Jerry
See attached diff.
2025-04-18 Steven G. Kargl
PR fortran/119836
* resolve.cc(check_pure_function, pure_subroutine
Hi Jerry,
Thank you very much. Hopefully there won't be any other issues to complain
about.
I will re-test the compilation once Fedora 42 upgrades its gcc / gfortran
toolchain to the one containing your fixes (yes it will take SOME time).
Probably in gcc/gfortran 15.1? Or maybe Intel Clear Lin
Hi Christopher,
I was somewhat surprised as well to find the pre-release version of
gfortran in Fedora 42.
sudo dnf install gcc14-gfortran.x86_64
will recover gfortran-14.2.1 for you, which is then invoked with:
pault@fedora:~/prs/pr101047$ gfortran-14 --version
GNU Fortran (GCC) 14.2.1
On 4/16/25 6:48 PM, ZAPART CHRISTOPHER ANDREW wrote:
Sorry don’t have a bugzilla account yet. For completeness here is a full
test code that also calls a pure subroutine from within a “block”
located inside a “do concurrent” loop.
Regards,
Chris
gfortran -march=native -g -Ofast -fPIC -fno-fin
Sorry don’t have a bugzilla account yet. For completeness here is a full test
code that also calls a pure subroutine from within a “block” located inside a
“do concurrent” loop.
Regards,
Chris
gfortran -march=native -g -Ofast -fPIC -fno-finite-math-only -funroll-loops
-ftree-vectorize -fopenmp
Hi guys,
Thank you everyone for looking so promptly into it. Since you already have
created a test program on GCC Bugzilla there is no point in duplicating the
efforts. The “offending” intrinsics “shift” and “min” are indeed used from
within a “block”, as per your “wrongly rejected” test code
version 15.0.1 seems to treat "shiftl" elemental intrinsic
functions as IMPURE. As a consequence "shiftl" cannot be used inside
DO CONCURRENT anymore:
Error: Reference to impure function at (1) inside a DO CONCURRENT
src/fixed_array.f90:118:27:
118 | x1 = 1
"shiftl" elemental intrinsic functions as IMPURE.
As a consequence "shiftl" cannot be used inside DO CONCURRENT anymore:
Error: Reference to impure function at (1) inside a DO CONCURRENT
src/fixed_array.f90:118:27:
118 | x1 = 1 + shiftl(i - 1, BASE)
|
t;
> The new version 15.0.1 seems to treat "shiftl" elemental intrinsic functions
> as IMPURE. As a consequence "shiftl" cannot be used inside DO CONCURRENT
> anymore:
>
> Error: Reference to impure function at (1) inside a DO CONCURRENT
> src/fixed_array
Hello,
After a recent upgrade from Fedora 41 to 42 the gfortran got updated from 14 to
15.0.1:
[chris@fedora FITSWEBQLSE]$ gfortran --version
GNU Fortran (GCC) 15.0.1 20250329 (Red Hat 15.0.1-0)
The new version 15.0.1 seems to treat "shiftl" elemental intrinsic functions as
IM
. This does not happen here, probably
because the function is used as a dummy here.
The least invasive fix seems to be to look at the symbol's attributes
when isym or esym is not set.
Regression testing lead to additional redundant error messages for two
testcases, so I opted to restric
because the function is used as a dummy here.
The least invasive fix seems to be to look at the symbol's attributes
when isym or esym is not set.
Regression testing lead to additional redundant error messages for two
testcases, so I opted to restrict the change to the case of functions
as
Dear all,
I've committed the attached obvious patch to reject an invalid NULL
in ALLOCATE after it was OK'ed in the PR by Steve.
Regtested on x86_64-pc-linux-gnu. Pushed as r15-6925-g892304f1fe .
Thanks,
Harald
From 892304f1fe3e808b9f498353c144f1ae0591 Mon Sep 17 00:00:00
f you can reproduce the above, then please
> open a separate PR to track this. Given what the patch resolves,
> this is not a real show-stopper, so you may go ahead.
>
Committed as r15-5897. I will be following up with a new PR for the ICE.
Thanks for the review.
Paul
>
> Thanks,
iginally pushed as r15-2739. Subsequently memory faults
were found and so the patch was reverted. At the time, I could find where
the problem lay. This morning I had another look and found it almost
immediately :-)
The fix is the 'gfc_resize_class_size_with_len' in the ch
f90, and the chunks in
> class.cc and resolve.cc). Can you please check?
>
> Cheers,
> Harald
>
> Am 29.11.24 um 17:34 schrieb Paul Richard Thomas:
> > Hi All,
> >
> > This patch was originally pushed as r15-2739. Subsequently memory faults
> > were found an
Hi Paul,
the patch seems to contain stuff that has already been pushed
(gcc/testsuite/gfortran.dg/pr117768.f90, and the chunks in
class.cc and resolve.cc). Can you please check?
Cheers,
Harald
Am 29.11.24 um 17:34 schrieb Paul Richard Thomas:
Hi All,
This patch was originally pushed as r15
Hi All,
This patch was originally pushed as r15-2739. Subsequently memory faults
were found and so the patch was reverted. At the time, I could find where
the problem lay. This morning I had another look and found it almost
immediately :-)
The fix is the 'gfc_resize_class_size_with_len&#x
Hi Paul,
thank you for the review. Committed as: gcc-15-4329-gfd1a2f63bca
No problem. I will persist :-)
- Regards,
Andre
On Mon, 14 Oct 2024 11:27:58 +0100
Paul Richard Thomas wrote:
> Hi Andre,
>
> This looks fine to me. OK for mainline.
>
> Thanks for the patch an
024 13:43:52 +0200
> > > Andre Vehreschild wrote:
> > >
> > > > Hi all,
> > > >
> > > > pinging this patch for the first time.
> > > >
> > > > Rebased and regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for
> > >
>
> > > Hi all,
> > >
> > > pinging this patch for the first time.
> > >
> > > Rebased and regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for
> > > mainline?
> > >
> > > - Andre
> > >
> >
l,
> >
> > pinging this patch for the first time.
> >
> > Rebased and regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for
> > mainline?
> >
> > - Andre
> >
> > On Thu, 15 Aug 2024 14:39:25 +0200
> > Andre Vehreschild wrote:
> >
> >
irst time.
>
> Rebased and regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
>
> - Andre
>
> On Thu, 15 Aug 2024 14:39:25 +0200
> Andre Vehreschild wrote:
>
> > Hi all,
> >
> > attached patch fixes another regression on coarrays. This time for cl
ass typed
> coarrays as dummys.
>
> Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
--
Andre Vehreschild * Email: vehre ad gmx dot de
From eeacd9a2c5cc4ddfe6201ad335adb0f48767f
Hi all,
attached patch fixes another regression on coarrays. This time for class typed
coarrays as dummys.
Regtested ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
From d16ef6fe8e792063064d930f1b3ffd31c74594e1 Mon
pendently of the implementation
of maybe_absent_optional_variable.
I expect the compiler to optimize it away, so I can surely make it a
checking-only assert.
I would also lean towards checking only.
OK with that change (or, if you really prefer, as submitted is also
fine).
Thanks for the patc
ptional_variable.
I expect the compiler to optimize it away, so I can surely make it a
checking-only assert.
I would also lean towards checking only.
OK with that change (or, if you really prefer, as submitted is also
fine).
Thanks for the patch! It's good to see so much prog
On 27 July 2024 21:11:19 CEST, Mikael Morin wrote:
>Le 27/07/2024 à 19:23, rep.dot@gmail.com a écrit :
>> On 22 July 2024 20:53:18 CEST, Mikael Morin wrote:
>>> From: Mikael Morin
>>>
>>> Hello,
>>>
>>> this fixes a null pointer der
Le 27/07/2024 à 19:23, rep.dot@gmail.com a écrit :
On 22 July 2024 20:53:18 CEST, Mikael Morin wrote:
From: Mikael Morin
Hello,
this fixes a null pointer dereference with absent optional dummy passed
as BACK argument of MINLOC/MAXLOC.
Tested for regression on x86_64-linux.
OK for
On 22 July 2024 20:53:18 CEST, Mikael Morin wrote:
>From: Mikael Morin
>
>Hello,
>
>this fixes a null pointer dereference with absent optional dummy passed
>as BACK argument of MINLOC/MAXLOC.
>
>Tested for regression on x86_64-linux.
>OK for master?
>
>-- >8
From: Mikael Morin
Hello,
this fixes a null pointer dereference with absent optional dummy passed
as BACK argument of MINLOC/MAXLOC.
Tested for regression on x86_64-linux.
OK for master?
-- >8 --
Protect the evaluation of BACK with a check that the reference is non-null
in case
Hi Paul,
thanks for the review. I have added a stripped down version of the initial
submission as testcase pr88624.f90 (for compile only) and commited as:
gcc-15-2190-g913bab282d9
Thanks for the review and regards,
Andre
On Fri, 19 Jul 2024 17:16:20 +0100
Paul Richard Thomas wrote
Hi Andre,
The patch looks fine to me. Please add the original testcase as
pr88624.f90, since it can be a compile only. The addition to
coarray/dummy_1.f90 is fine as well but I think that it is good to address
the reporter's problem directly.
Thanks
Paul
On Wed, 17 Jul 2024 at 14:10,
Hi all,
and another ping...
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline?
- Andre
On Thu, 11 Jul 2024 15:42:54 +0200
Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes using of coarrays as dummy arguments. The coarray
> dummy argument was not
Hi all,
attached patch fixes using of coarrays as dummy arguments. The coarray
dummy argument was not dereferenced correctly, which is fixed now.
Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gcc dot gnu dot org
Hi Richard,
bootstrap finally passed and the fix is now merged as
gcc-15-1971-gb9513c6746b
Thanks for your patience.
- Andre
On Thu, 11 Jul 2024 14:01:02 +0200
Richard Biener wrote:
> On Thu, Jul 11, 2024 at 11:24 AM Andre Vehreschild
> wrote:
> >
> > Hi Richard,
>
l 2024 10:57:48 +0200
> > > Richard Biener wrote:
> > >
> > > > On Thu, Jul 11, 2024 at 10:54 AM Richard Biener
> > > > wrote:
> > > > >
> > > > > On Thu, Jul 11, 2024 at 10:04 AM Andre Vehreschild
> > > > > wrote:
> > > &
> >
> > > On Thu, Jul 11, 2024 at 10:54 AM Richard Biener
> > > wrote:
> > > >
> > > > On Thu, Jul 11, 2024 at 10:04 AM Andre Vehreschild
> > > > wrote:
> > > > >
> > > > > Hi Harald,
> > >
gt; > > Hi Harald,
> > >
> > > thank you very much for ok'ing this large patch. Merged as
> > > gcc-15-1965-ge4f2f46e015
> > >
> > > Looking forward to get (no) bug reports ;-)
> >
> > This seems to break bootstrap with
> >
>
te:
>
> > On Thu, Jul 11, 2024 at 10:54 AM Richard Biener
> > wrote:
> > >
> > > On Thu, Jul 11, 2024 at 10:04 AM Andre Vehreschild
> > > wrote:
> > > >
> > > > Hi Harald,
> > > >
> > > > thank you very much
On Thu, Jul 11, 2024 at 10:54 AM Richard Biener
wrote:
>
> On Thu, Jul 11, 2024 at 10:04 AM Andre Vehreschild wrote:
> >
> > Hi Harald,
> >
> > thank you very much for ok'ing this large patch. Merged as
> > gcc-15-1965-ge4f2f46e015
> >
> >
On Thu, Jul 11, 2024 at 10:04 AM Andre Vehreschild wrote:
>
> Hi Harald,
>
> thank you very much for ok'ing this large patch. Merged as
> gcc-15-1965-ge4f2f46e015
>
> Looking forward to get (no) bug reports ;-)
This seems to break bootstrap with
../../gcc/gcc/fortran/t
Hi Harald,
thank you very much for ok'ing this large patch. Merged as
gcc-15-1965-ge4f2f46e015
Looking forward to get (no) bug reports ;-)
Thanks again,
Andre
On Wed, 10 Jul 2024 20:52:37 +0200
Harald Anlauf wrote:
> Hi Andre,
>
> Am 10.07.24 um 10:45 schrieb Andre Vehre
Hi Andre,
Am 10.07.24 um 10:45 schrieb Andre Vehreschild:
Hi Harald,
thanks for the review. I totally agree, that this patch has gotten bigger than
I expected (and wanted). But things are as they are.
About the coding style: I have worked in so many projects, that I consider a
consistent
Hi Harald,
thanks for the review. I totally agree, that this patch has gotten bigger than
I expected (and wanted). But things are as they are.
About the coding style: I have worked in so many projects, that I consider a
consistent coding style luxury. I esp. do not have my own one anymore. The
a UN-/PACK() is applied on a
class array is still to be done (as part of another PR).
Regtests fine on x86_64-pc-linux-gnu/ Fedora 39.
this is a really huge patch to review, and I am not sure that I can do
this without help from others. Paul? Anybody else?
As far as I can tell for now:
- pr9699
regular
un-/pack does not use the vptr's _copy routine for moving data and therefore
may produce bugs.
The un-/pack_class routines are yet only used for converting a derived type
array to a class array. Extending their use when a UN-/PACK() is applied on a
class array is still to be done (as
es those small knits the patch looks fine to me. I am wondering
> > though,
> > why gfortran is still using a non-class aware pack? To "move" the content
> > of a
> > class object the _copy function of the vtype is to be used, right? In my
> >
/
>
> Indeed!
>
> Besides those small knits the patch looks fine to me. I am wondering
> though,
> why gfortran is still using a non-class aware pack? To "move" the content
> of a
> class object the _copy function of the vtype is to be used, right? In my
> current PR
is still using a non-class aware pack? To "move" the content of a
class object the _copy function of the vtype is to be used, right? In my
current PR I try to implement a class aware internal pack (and unpack) to
correctly apply the element sequence as of F2018 15.5.2.11. But I am
struggling
Hi All,
This is one of those PRs where one thing led to another I think that
the patch is pretty complete and, while apparently quite heavy, is more or
less self explanatory through comments and the ChangeLog.
The first testcase concentrates on reshape in various guises, while the
second deal
On Jun 24 2024, Mikael Morin wrote:
> tree-pretty-print.cc's op_symbol_code handles them as:
>
> case TRUTH_AND_EXPR:
> case TRUTH_ANDIF_EXPR:
> return "&&";
>
> so no, I don't think they are differentiated.
Only because C does
argument
is not present, and pass a null pointer instead. This is straightforward.
Second, the case of a missing pointer optional dummy array should have worked,
but the presence check surprisingly did not work as expected at -O0 or -Og,
but at higher optimization levels. Interestingly, the dump-tree
instead. This is straightforward.
Second, the case of a missing pointer optional dummy array should have worked,
but the presence check surprisingly did not work as expected at -O0 or -Og,
but at higher optimization levels. Interestingly, the dump-tree looked right,
but running under gdb or
44 45
d3_2: -43 -44 -45
d3->: -43 46 49
full: -43 -44 -45 46 47
48 49 50
While the print properly handles f(1:m:k)%i, passing it as
actual argument to subroutine d3 does
mail: vehre ad gmx dot de
From c0c95afa95bb682385e47cc248f04e6eecd91e6d Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Fri, 14 Jun 2024 16:54:37 +0200
Subject: [PATCH] Fortran: Fix rejecting class arrays of different ranks as
storage association argument.
Removing the assert in trans-expr
ot; of the class array
as dummy argument was not initializing the dim 0 stride and with that grabbing
into the memory somewhere. This is now fixed and
regtests fine on x86_64 Fedora 39. Ok for mainline?
the patch fixes the testcase in your submission, but not the following
slight variation of the ma
Hi all,
I somehow got assigned to this PR so I fixed it. GFortran was ICEing because of
the ASSUME_RANK in a derived to class conversion. After fixing this, storage
association was producing segfaults. The "shape conversion" of the class array
as dummy argument was not initializing
On 4/8/24 2:53 AM, Tobias Burnus wrote:
Jerry D wrote:
See attached updated patch.
It turned rather quickly out that this patch – committed as
r14-9822-g93adf88cc6744a – caused regressions.
Namely, real-world code use tab(s) as separator instead of spaces.
[For instance, PR114304 which
Jerry D wrote:
See attached updated patch.
It turned rather quickly out that this patch – committed as
r14-9822-g93adf88cc6744a – caused regressions.
Namely, real-world code use tab(s) as separator instead of spaces.
[For instance, PR114304 which contains a named-list input file from SPEC
Hi Jerry, hello world,
Jerry D wrote:
On 4/5/24 10:47 AM, Jerry D wrote:
On 4/4/24 2:41 PM, Tobias Burnus wrote:
I think for the current testcases, I like the patch – the question
is only what's about:
',3' as input for 'comma' (or '.3' as inpu
On 4/5/24 10:47 AM, Jerry D wrote:
On 4/4/24 2:41 PM, Tobias Burnus wrote:
Hi Jerry,
I think for the current testcases, I like the patch – the question is
only what's about:
',3' as input for 'comma' (or '.3' as input for 'point')
For &
On 4/4/24 2:41 PM, Tobias Burnus wrote:
Hi Jerry,
I think for the current testcases, I like the patch – the question is
only what's about:
',3' as input for 'comma' (or '.3' as input for 'point')
For 'point' – 0.3 is read an
Hi Jerry,
I think for the current testcases, I like the patch – the question is
only what's about:
',3' as input for 'comma' (or '.3' as input for 'point')
For 'point' – 0.3 is read and ios = 0 (as expected)
But for 'comma
isreal = T , testinput = "3.3;"r= 3.2995 ios= 0
point, isreal = T , testinput = "3,3;"r= 3. ios= 0
--- snip ---
I have attached the modified testcase linked above; consider adding it
as well. - Changes to the one of the attachment:
- I a
spaces to see if it is a comma or semicolon.
If so, I change it to the valid separator for the given decimal mode,
point or comma. This allows the comma or semicolon to be interpreted
as a null read on the next effective item in the formatted read.
I chose a permissive approach here that allows
.
If so, I change it to the valid separator for the given decimal mode,
point or comma. This allows the comma or semicolon to be interpreted as
a null read on the next effective item in the formatted read.
I chose a permissive approach here that allows reads to proceed when the
input line is
the valid separator for the given decimal mode,
> point or comma. This allows the comma or semicolon to be interpreted as
> a null read on the next effective item in the formatted read.
>
> I chose a permissive approach here that allows reads to proceed when the
> input line is ma
change it to the valid separator for the given decimal mode,
point or comma. This allows the comma or semicolon to be interpreted as
a null read on the next effective item in the formatted read.
I chose a permissive approach here that allows reads to proceed when the
input line is mal-formed with an
On 2/29/24 12:56 PM, Harald Anlauf wrote:
Dear all,
here's a first patch addressing issues with NULL as actual argument:
if the dummy is assumed-rank or assumed length, MOLD shall be present.
There is also an interp on interoperability of c_sizeof and NULL
pointers, for which we h
Dear all,
here's a first patch addressing issues with NULL as actual argument:
if the dummy is assumed-rank or assumed length, MOLD shall be present.
There is also an interp on interoperability of c_sizeof and NULL
pointers, for which we have a partially incorrect testcase
(gfortran.dg/pr1
it instead.
> Otherwise I'll assume that I will and I hope that I can continue to rely
> on David Edelsohn and Thomas Schwinge to back me up and help me with
> some decision making along the way as my co-org-admins.
>
> The most important bit:
> fixes the issues you're describing?
>>
>> I believe that marking artificial symbols as such is obvious and i did
>> use the existing tests to verify that the changes do not regress but
>> behave as intended. I did check that the memory leak in
>> gfc_find_
Am 29.01.24 um 21:45 schrieb Bernhard Reutner-Fischer:
On Wed, 17 Nov 2021 21:32:14 +0100
Harald Anlauf wrote:
Do you have testcases/reproducers demonstrating that the patch actually
fixes the issues you're describing?
I believe that marking artificial symbols as such is obvious and
On Wed, 17 Nov 2021 21:32:14 +0100
Harald Anlauf wrote:
> Do you have testcases/reproducers demonstrating that the patch actually
> fixes the issues you're describing?
I believe that marking artificial symbols as such is obvious and i did
use the existing tests to verify that the cha
It affects the build, and if used as a static file, can reliably be
tracked using the `-MF` mechanism.
gcc/cp/:
* mapper-client.cc, mapper-client.h (open_module_client): Accept
dependency tracking and track module mapper files as
dependencies.
* module.cc
They affect the build, so report them via `-MF` mechanisms.
gcc/cp/
* module.cc (do_import): Report imported CMI files as
dependencies.
gcc/testsuite/
* g++.dg/modules/depreport-1_a.C: New test.
* g++.dg/modules/depreport-1_b.C: New test.
* g++.dg
pdate projectB after updating projectA (known to
all use the same compiler/flags so that CMI sharing is possible). The
build it still broken, but ideally they get notified in some useful way
when rebuilding the TU rather than…whatever ends up catching the problem
incidentally.
> I guess
naming the individual object files (or I think the could
be implemented as a static lib linked with --whole-archive path/to/libfoo.a
-no-whole-archive. But for this conversation consider them a bunch of separate
object files with a convenient group name.
Yes, `--whole-archive` would work great if it ha
ual object files (or I think the
> could
> be implemented as a static lib linked with --whole-archive path/to/libfoo.a
> -no-whole-archive. But for this conversation consider them a bunch of
> separate
> object files with a convenient group name.
Yes, `--whole-archive` would work gr
apper file"
(in CMake's case, this is only the modules that are needed; a single
massive mapper file for an entire project would have extra entries) or
"act as a proxy for the socket/program specified" for other
approaches);
This information is in the machine (&
mapper file"
> >(in CMake's case, this is only the modules that are needed; a single
> >massive mapper file for an entire project would have extra entries) or
> >"act as a proxy for the socket/program specified" for other
> >approaches);
know:
- what CMIs are actually imported (here, "read the module mapper file"
(in CMake's case, this is only the modules that are needed; a single
massive mapper file for an entire project would have extra entries) or
"act as a proxy for the socket/program specified" fo
e distributing tool
would need to know:
- what CMIs are actually imported (here, "read the module mapper file"
(in CMake's case, this is only the modules that are needed; a single
massive mapper file for an entire project would have extra entries) or
"act as a proxy fo
wrote:
On 1/25/23 16:06, Ben Boeckel wrote:
They affect the build, so report them via `-MF` mechanisms.
Why isn't this covered by the existing code in preprocessed_module?
It appears as though it is neutered in patch 3 where
`write_make_modules_deps` is used in `make_write` (or will use that
wrote:
> >>>> On 1/25/23 16:06, Ben Boeckel wrote:
> >>>>> They affect the build, so report them via `-MF` mechanisms.
> >>>>
> >>>> Why isn't this covered by the existing code in preprocessed_module?
> >>>
> >>
build, so report them via `-MF` mechanisms.
Why isn't this covered by the existing code in preprocessed_module?
It appears as though it is neutered in patch 3 where
`write_make_modules_deps` is used in `make_write` (or will use that name
Why do you want to record the transitive modules? I
.
Why isn't this covered by the existing code in preprocessed_module?
It appears as though it is neutered in patch 3 where
`write_make_modules_deps` is used in `make_write` (or will use that name
Why do you want to record the transitive modules? I would expect just noting the
ones with im
It affects the build, and if used as a static file, can reliably be
tracked using the `-MF` mechanism.
gcc/cp/:
* mapper-client.cc, mapper-client.h (open_module_client): Accept
dependency tracking and track module mapper files as
dependencies.
* module.cc
1 - 100 of 136 matches
Mail list logo
