Re: Build problems: mpfr, mpc
I defined both CFLAGS and CXXFLAGS as -D_GNU_SOURCE and it did the trick. I see a number of unexpected failures in the log, so I will look into those. But the good news is that the procedure does work. Regards, Arjen Op vr 20 aug. 2021 om 15:17 schreef Arjen Markus : > Ah, thanks, I restarted the build with _GNU_SOURCE instead. > > Regards, > > Arjen > > Op vr 20 aug. 2021 om 15:11 schreef Jonathan Wakely >: > >> On Fri, 20 Aug 2021 at 14:09, Jonathan Wakely wrote: >> > >> > On Fri, 20 Aug 2021 at 13:59, Arjen Markus wrote: >> > > >> > > Going the WSL2 route (I am not all that familiar with WSL) or a Linux >> emulation may be the way to go, indeed, but your remark triggered me to do >> a bit of searching: there is some discussion about the secure_getenv() >> function wrt Cygwin but there actually is a prototype for it in Cygwin's >> stdlib.h. It is protected by a symbol __GNU_VISIBLE. I will try to define >> that and see what happens. >> > >> > Don't do that. Define _GNU_SOURCE to tell Cygwin you want the GNU >> > extensions like secure_getenv, and then will define >> > __GNU_VISIBLE. >> >> As it says in ... >> >> * The following private macros are used throughout the headers to control >> * which symbols should be exposed. They are for internal use only, as >> * indicated by the leading double underscore, and must never be used >> outside >> * of these headers. >> ... >> * __GNU_VISIBLE >> * GNU extensions; enabled with _GNU_SOURCE. >> >> >> > >> > I am curious why _GNU_SOURCE would be defined during configure but not >> > when compiling. >> >
[Patch] Fortran/OpenMP: strict modifier on grainsize/num_tasks + duplicate errors (was: [committed] openmp: Add support for strict modifier on grainsize/num_tasks clauses)
Hi Jakub, hi all,
On 23.08.21 10:25, Jakub Jelinek wrote:
The following patch implements it for C and C++.
The attached patch now adds Fortran support for it,
which is a small change - the two testcases (in 4 files) are
the converted C ones.
Additionally, the previous diagnostic for duplicate clauses
was suboptimal as gfortran simply stopped parsing them.
Thus, a generic "Failed to match clause" was shown instead of
a more explicit message such as "Duplicated 'filter' clause".
Additionally, it was often not quite clear whether the clause
itself or its expression was bogus (due to 'clause ( %e )'
matching).
Now I added a new function which handles those diagnostic.
I had to revert two clauses to avoid matching the shorter string
first - and it now shows 'if' - missing '(' for 'if_present' if
only 'if' but not 'if_present' is supported by the directive.
The error messages are still not optimal, but I think overall an
improvement.
OK? Comment?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
Fortran/OpenMP: strict modifier on grainsize/num_tasks + duplicate errors
This patch adds support for the 'strict' modifier on grainsize/num_tasks
clauses, an OpenMP 5.1 feature supported in C/C++ since commit
r12-3066-g3bc75533d1f87f0617be6c1af98804f9127ec637
Additionally, the duplicate-clause diagnostic has been improved.
gcc/fortran/ChangeLog:
* dump-parse-tree.c (show_omp_clauses): Handle 'strict' modifier
on grainsize/num_tasks
* gfortran.h (gfc_omp_clauses): Add grainsize_strict
and num_tasks_strict.
* trans-openmp.c (gfc_trans_omp_clauses, gfc_split_omp_clauses):
Handle 'strict' modifier on grainsize/num_tasks.
(gfc_match_dupl_check, gfc_match_dupl_memorder,
gfc_match_dupl_atomic): New.
(gfc_match_omp_clauses): Use them; handle 'strict' modified on
grainsize/num_tasks; remove duplicate 'release'/'relaxed' clause
matching; improve error dignostic for 'default'.
libgomp/ChangeLog:
* testsuite/libgomp.fortran/taskloop-4-a.f90: New test.
* testsuite/libgomp.fortran/taskloop-4.f90: New test.
* testsuite/libgomp.fortran/taskloop-5-a.f90: New test.
* testsuite/libgomp.fortran/taskloop-5.f90: New test.
gcc/testsuite/ChangeLog:
* gfortran.dg/goacc/asyncwait-1.f95: Update dg-error.
* gfortran.dg/goacc/default-2.f: Update dg-error.
* gfortran.dg/goacc/enter-exit-data.f95: Update dg-error.
* gfortran.dg/goacc/if.f95: Update dg-error.
* gfortran.dg/goacc/parallel-kernels-clauses.f95: Update dg-error.
* gfortran.dg/goacc/routine-6.f90: Update dg-error.
* gfortran.dg/goacc/sie.f95: Update dg-error.
* gfortran.dg/goacc/update-if_present-2.f90: Update dg-error.
* gfortran.dg/gomp/cancel-2.f90: Update dg-error.
* gfortran.dg/gomp/declare-simd-1.f90: Update dg-error.
* gfortran.dg/gomp/error-3.f90: Update dg-error.
* gfortran.dg/gomp/loop-2.f90: Update dg-error.
* gfortran.dg/gomp/masked-2.f90: Update dg-error.
gcc/fortran/dump-parse-tree.c | 4 +
gcc/fortran/gfortran.h | 2 +-
gcc/fortran/openmp.c | 643 +
gcc/fortran/trans-openmp.c | 8 +
gcc/testsuite/gfortran.dg/goacc/asyncwait-1.f95| 2 +-
gcc/testsuite/gfortran.dg/goacc/default-2.f| 32 +-
.../gfortran.dg/goacc/enter-exit-data.f95 | 4 +-
gcc/testsuite/gfortran.dg/goacc/if.f95 | 12 +-
.../gfortran.dg/goacc/parallel-kernels-clauses.f95 | 16 +-
gcc/testsuite/gfortran.dg/goacc/routine-6.f90 | 2 +-
gcc/testsuite/gfortran.dg/goacc/sie.f95| 20 +-
.../gfortran.dg/goacc/update-if_present-2.f90 | 10 +-
gcc/testsuite/gfortran.dg/gomp/cancel-2.f90| 4 +-
gcc/testsuite/gfortran.dg/gomp/declare-simd-1.f90 | 2 +-
gcc/testsuite/gfortran.dg/gomp/error-3.f90 | 18 +-
gcc/testsuite/gfortran.dg/gomp/loop-2.f90 | 2 +-
gcc/testsuite/gfortran.dg/gomp/masked-2.f90| 2 +-
libgomp/testsuite/libgomp.fortran/taskloop-4-a.f90 | 86 +++
libgomp/testsuite/libgomp.fortran/taskloop-4.f90 | 41 ++
libgomp/testsuite/libgomp.fortran/taskloop-5-a.f90 | 95 +++
libgomp/testsuite/libgomp.fortran/taskloop-5.f90 | 75 +++
21 files changed, 790 insertions(+), 290 deletions(-)
diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index c75a0a9d095..a1df47c2f82 100644
--- a/gcc/fortran/dump-parse-tree.c
+++ b/gcc/fortran/dump-parse-tree.c
@@ -1805,6 +1805,8 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
if (omp_clauses->grainsize)
{
fputs (" GRAINSIZE(", dumpfile);
+ if (omp_clauses->grainsize_strict)
+ fputs ("strict: ", dumpfile);
show_expr (omp_clauses->grainsize);
fputc (')', dumpfile);
}
@@ -1823,6 +1825,8 @@ show_omp_clauses (gfc_omp_cla
Re: [Patch] Fortran/OpenMP: strict modifier on grainsize/num_tasks + duplicate errors (was: [committed] openmp: Add support for strict modifier on grainsize/num_tasks clauses)
On Mon, Aug 23, 2021 at 02:14:46PM +0200, Tobias Burnus wrote: > --- a/gcc/fortran/gfortran.h > +++ b/gcc/fortran/gfortran.h > @@ -1490,7 +1490,7 @@ typedef struct gfc_omp_clauses >unsigned inbranch:1, notinbranch:1, nogroup:1; >unsigned sched_simd:1, sched_monotonic:1, sched_nonmonotonic:1; >unsigned simd:1, threads:1, depend_source:1, destroy:1, order_concurrent:1; > - unsigned capture:1; > + unsigned capture:1, grainsize_strict, num_tasks_strict; Missing :1 twice. Otherwise LGTM, though maybe it would be better to commit separately the change to handle duplicated clauses and the grainsize/num_tasks strict: modifier addition. Jakub
Re: [Patch] Fortran/OpenMP: strict modifier on grainsize/num_tasks + duplicate errors (was: [committed] openmp: Add support for strict modifier on grainsize/num_tasks clauses)
On 23.08.21 14:53, Jakub Jelinek wrote: On Mon, Aug 23, 2021 at 02:14:46PM +0200, Tobias Burnus wrote: + unsigned capture:1, grainsize_strict, num_tasks_strict; Missing :1 twice. Fixed. Well spotted! Otherwise LGTM, though maybe it would be better to commit separately the change to handle duplicated clauses and the grainsize/num_tasks strict: modifier addition. Done so: r12-3079-g57a9e63c96fca56299d7a52f6712e2d9290c197e Fortran/OpenMP: Improve duplicate errors r12-3078-gd4de7e32eff0a6363defa50b052d7a30548b6552 Fortran/OpenMP: strict modifier on grainsize/num_tasks Thanks, Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Re: F2018 C937
Hi Arjen, Don't know if you've made any progress with cygwin (yes, I saw the other thread). I lurk on the J3 Fortran mailing list, and have come to learn that C937 has been deleted in the draft for Fortran 202x. What this means is that the "gcc_error ()" statement will need to be changed to use the "gfc_notify_std()" method reporting errors. -- steve On Thu, Aug 19, 2021 at 08:59:05AM +0200, Arjen Markus wrote: > Hi Steve, > > I am willing to take up this challenge ;), as well as the patch for C949. > It would be my next attempt to get acquainted with the source code (a first > step hopefully to actively contribute). > > Regards, > > Arjen > > Op di 17 aug. 2021 om 21:02 schreef Steve Kargl via Fortran < > fortran@gcc.gnu.org>: > > > For those that might care, I draw your attention to > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101951 > > > > Good opportunity for a lurker to step forward and > > become a gfortran committer. Otherwise, this patch > > will fester in bugzilla the dozen or so other patches > > I've attached to PRs. > > > > -- > > Steve > > -- Steve
Re: F2018 C937
Hi Steve, yes, the extra macro did the job, so the testuite has run. So, this means the patch has to be adapted. I will report the unexpectedly failing tests in a separate mail. Regards, Arjen Op ma 23 aug. 2021 om 19:18 schreef Steve Kargl < s...@troutmask.apl.washington.edu>: > Hi Arjen, > > Don't know if you've made any progress with cygwin (yes, > I saw the other thread). I lurk on the J3 Fortran mailing > list, and have come to learn that C937 has been deleted in > the draft for Fortran 202x. What this means is that the > "gcc_error ()" statement will need to be changed to use > the "gfc_notify_std()" method reporting errors. > > -- > steve > > On Thu, Aug 19, 2021 at 08:59:05AM +0200, Arjen Markus wrote: > > Hi Steve, > > > > I am willing to take up this challenge ;), as well as the patch for C949. > > It would be my next attempt to get acquainted with the source code (a > first > > step hopefully to actively contribute). > > > > Regards, > > > > Arjen > > > > Op di 17 aug. 2021 om 21:02 schreef Steve Kargl via Fortran < > > fortran@gcc.gnu.org>: > > > > > For those that might care, I draw your attention to > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101951 > > > > > > Good opportunity for a lurker to step forward and > > > become a gfortran committer. Otherwise, this patch > > > will fester in bugzilla the dozen or so other patches > > > I've attached to PRs. > > > > > > -- > > > Steve > > > > > -- > Steve >
Failing tests after applying patches?
Hello, as promised, here is an overview of the unexpectedly failing tests. I got these after applying the patches by Steve Kargl for bug ID 101951 and 101967. The platform I used to build it is Cygwin on WIndows 10. FAIL: gfortran.dg/analyzer/pr96949.f90 -O (internal compiler error) FAIL: gfortran.dg/analyzer/pr96949.f90 -O (test for excess errors) I tried to reproduce this problem with version 10.2.0 but the program is compiled and runs without problems. The analyzer options (in the dg instructions) were not accepted, neither with the freshly built gfortran executable. Probably too naïve to try itlike that ;). Anyway, my question: is this a problem due to the patches or not? FAIL: gfortran.dg/round_4.f90 -O0 execution test and ditto with -O1, -O2, etc. When built with version 10.2.0, the program fails with error code 2.I guess this means this program is failing independently of these patches. Judging from the comments, I conclude that it is a tough one, as it depends on the implementation of strtod(). Regards, Arjen
Re: Failing tests after applying patches?
Hi Arjen, On 23.08.21 20:59, Arjen Markus via Fortran wrote: as promised, here is an overview of the unexpectedly failing tests. I got these after applying the patches by Steve Kargl for bug ID 101951 and 101967. The platform I used to build it is Cygwin on WIndows 10. FAIL: gfortran.dg/analyzer/pr96949.f90 -O (internal compiler error) FAIL: gfortran.dg/analyzer/pr96949.f90 -O (test for excess errors) I recommend: https://gcc.gnu.org/pipermail/gcc-testresults/current – it shows what others are getting. In particular, it helps: to ensure to look at the right branch (12.0 mainline), to look at x86-64 Linux (as others tend to have some additional issues) — and to make sure that that build actual does test Fortran. But the simplest test is to undo your patches - recompile GCC and then run (in the build directory): cd gcc; make check-fortran RUNTESTFLAGS="analyzer.exp=pr96949.f90" If the error still occurs, it is probably unrelated to the patch; if it is gone, the patch probably caused it. I also do note that many analyzer commits have been committed today, hence, it is a moving target. (It does work for me – with the current checkout. But this does not tell anything about when you did your tests, given that several commits were done this evening.) Tobias
Re: Failing tests after applying patches?
Hi Tobias, thanks for these tips - this should come in handy indeed. One thing though: when I tried to run my freshly built gfortran compiler on one of the test programs, I got the message that it could not find the file libgfortran.spec. Is there some environment variable that muist be set? Regards, Arjen Op ma 23 aug. 2021 om 21:36 schreef Tobias Burnus : > Hi Arjen, > > On 23.08.21 20:59, Arjen Markus via Fortran wrote: > > as promised, here is an overview of the unexpectedly failing tests. I got > > these after applying the patches by Steve Kargl for bug ID 101951 and > > 101967. The platform I used to build it is Cygwin on WIndows 10. > > > > FAIL: gfortran.dg/analyzer/pr96949.f90 -O (internal compiler error) > > FAIL: gfortran.dg/analyzer/pr96949.f90 -O (test for excess errors) > > I recommend: https://gcc.gnu.org/pipermail/gcc-testresults/current – it > shows what others are getting. > > In particular, it helps: to ensure to look at the right branch (12.0 > mainline), to look at x86-64 Linux (as others tend to have some > additional issues) — and to make sure that that build actual does test > Fortran. > > But the simplest test is to undo your patches - recompile GCC and then > run (in the build directory): > > cd gcc; make check-fortran RUNTESTFLAGS="analyzer.exp=pr96949.f90" > > If the error still occurs, it is probably unrelated to the patch; if it > is gone, the patch probably caused it. > > I also do note that many analyzer commits have been committed today, > hence, it is a moving target. (It does work for me – with the current > checkout. But this does not tell anything about when you did your tests, > given that several commits were done this evening.) > > Tobias > >
Re: [patch, libgfortran] Further fixes for GFC/CFI descriptor conversions
Hi Sandra,
On 19.08.21 05:57, Sandra Loosemore wrote:
This patch addresses several bugs in converting from GFC to CFI
descriptors and vice versa. [...]
The root of all the problems addressed here is that GFC descriptors
contain incomplete information; in particular, they only encode the
size of the data type and not its kind.
I think that's not a fundamental problem – but because the conversion
happens in libgfortran and not in FE generated code. In the FE, the data
type is known – hence, it could be handled properly.
We do definitely plan to move the descriptor conversion to the FE, which
also solves severe alias issues. However, until that patch is ready, we
rely on doing it in libgfortran ...
libgfortran: Further fixes for GFC/CFI descriptor conversions.
This patch is for:
PR100907 - Bind(c): failure handling wide character
PR100911 - Bind(c): failure handling C_PTR
PR100914 - Bind(c): errors handling complex
PR100915 - Bind(c): failure handling C_FUNPTR
PR100917 - Bind(c): errors handling long double real
[...]
The Fortran front end does not distinguish between C_PTR and
C_FUNPTR, mapping both onto BT_VOID. That is what this patch does also.
Looks like another thing to improve once we moved the conversion code to
the FE.
2021-08-18 Sandra Loosemore
José Rui Faustino de Sousa
gcc/testsuite/
PR fortran/100911
PR fortran/100915
PR fortran/100916
* gfortran.dg/PR100911.c: New file.
* gfortran.dg/PR100911.f90: New file.
* gfortran.dg/PR100914.c: New file.
* gfortran.dg/PR100914.f90: New file.
* gfortran.dg/PR100915.c: New file.
* gfortran.dg/PR100915.f90: New file.
libgfortran/
PR fortran/100907
PR fortran/100911
PR fortran/100914
PR fortran/100915
PR fortran/100917
* ISO_Fortran_binding.h (CFI_type_cfunptr): Make equivalent to
CFI_type_cptr.
* runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc): Fix
handling of CFI_type_cptr and CFI_type_cfunptr. Additional error
checking and code cleanup.
(gfc_desc_to_cfi_desc): Likewise. Also correct kind mapping
for character, complex, and long double types.
...
+++ b/libgfortran/runtime/ISO_Fortran_binding.c
@@ -37,15 +37,16 @@ export_proto(cfi_desc_to_gfc_desc);
void
cfi_desc_to_gfc_desc (gfc_array_void *d, CFI_cdesc_t **s_ptr)
{
+ signed char type;
...
+ GFC_DESCRIPTOR_TYPE (d) = (signed char)type;
No need for a cast.
+case CFI_type_Character:
+ /* FIXME: we can't distinguish between kind/len because
+ the GFC descriptor only encodes the elem_len..
+ Until PR92482 is fixed, assume elem_len refers to the
+ character size and not the string length. */
+ kind = (signed char)d->elem_len;
+ break;
I wonder what's more common – kind=4 or len > 1.
My gut feeling is that it is len > 1 but the issue will be gone once we
moved the code to the FE.
Your patch shows even more reasons for doing so ...
LGTM.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
