Fw: Today's build of trunk with --disable-bootstrap fails for me...
As I could not find any way to proceed, I submitted my findings as PR112643 and hope to get feedback. Harald > Gesendet: Montag, 20. November 2023 um 21:01 Uhr > Von: "Harald Anlauf" > An: "fortran" > Betreff: Today's build of trunk with --disable-bootstrap fails for me... > > Hi, > > does anybody else have the same issue? > > I usually build trunk with --disable-bootstrap, e.g. 14-trunk using > gcc-13, and rarely encounter problems. Some change between yesterday > and today (likely r14-5607-g2f8f7ee2db82a3, Initial support for AVX10.1) > leads to the following problem: > > When building aatree.o, I get: > > In file included from /work/gnu/git/build-trunk/gcc/include/immintrin.h:103, > from /work/gnu/git/build-trunk/gcc/include/x86intrin.h:32, > from ../../../gcc-trunk/libitm/config/x86/target.h:26, > from ../../../gcc-trunk/libitm/libitm_i.h:74, > from ../../../gcc-trunk/libitm/aatree.cc:28: > /work/gnu/git/build-trunk/gcc/include/avx512vp2intersectvlintrin.h: In > function 'void _mm_2intersect_epi32(__m128i, __m128i, __mmask8*, __mmask8*)': > /work/gnu/git/build-trunk/gcc/include/avx512vp2intersectvlintrin.h:42:3: > error: '__builtin_ia32_2intersectd128' was not declared in this scope; did > you mean '__builtin_ia32_2intersectd512'? >42 | __builtin_ia32_2intersectd128 (__U, __M, (__v4si) __A, (__v4si) > __B); > | ^ > | __builtin_ia32_2intersectd512 > /work/gnu/git/build-trunk/gcc/include/avx512vp2intersectvlintrin.h: In > function 'void _mm256_2intersect_epi32(__m256i, __m256i, __mmask8*, > __mmask8*)': > /work/gnu/git/build-trunk/gcc/include/avx512vp2intersectvlintrin.h:50:3: > error: '__builtin_ia32_2intersectd256' was not declared in this scope; did > you mean '__builtin_ia32_2intersectd512'? >50 | __builtin_ia32_2intersectd256 (__U, __M, (__v8si) __A, (__v8si) > __B); > | ^ > | __builtin_ia32_2intersectd512 > > etc. > > What am I missing? > > Harald >
Today's build of trunk with --disable-bootstrap fails for me...
Hi, does anybody else have the same issue? I usually build trunk with --disable-bootstrap, e.g. 14-trunk using gcc-13, and rarely encounter problems. Some change between yesterday and today (likely r14-5607-g2f8f7ee2db82a3, Initial support for AVX10.1) leads to the following problem: When building aatree.o, I get: In file included from /work/gnu/git/build-trunk/gcc/include/immintrin.h:103, from /work/gnu/git/build-trunk/gcc/include/x86intrin.h:32, from ../../../gcc-trunk/libitm/config/x86/target.h:26, from ../../../gcc-trunk/libitm/libitm_i.h:74, from ../../../gcc-trunk/libitm/aatree.cc:28: /work/gnu/git/build-trunk/gcc/include/avx512vp2intersectvlintrin.h: In function 'void _mm_2intersect_epi32(__m128i, __m128i, __mmask8*, __mmask8*)': /work/gnu/git/build-trunk/gcc/include/avx512vp2intersectvlintrin.h:42:3: error: '__builtin_ia32_2intersectd128' was not declared in this scope; did you mean '__builtin_ia32_2intersectd512'? 42 | __builtin_ia32_2intersectd128 (__U, __M, (__v4si) __A, (__v4si) __B); | ^ | __builtin_ia32_2intersectd512 /work/gnu/git/build-trunk/gcc/include/avx512vp2intersectvlintrin.h: In function 'void _mm256_2intersect_epi32(__m256i, __m256i, __mmask8*, __mmask8*)': /work/gnu/git/build-trunk/gcc/include/avx512vp2intersectvlintrin.h:50:3: error: '__builtin_ia32_2intersectd256' was not declared in this scope; did you mean '__builtin_ia32_2intersectd512'? 50 | __builtin_ia32_2intersectd256 (__U, __M, (__v8si) __A, (__v8si) __B); | ^ | __builtin_ia32_2intersectd512 etc. What am I missing? Harald
Re: [PATCH, v2] Fortran: restrictions on integer arguments to SYSTEM_CLOCK [PR112609]
Harald,
Sorry about delayed response. Got side-tracked by Family this weekend.
On Sun, Nov 19, 2023 at 09:46:46PM +0100, Harald Anlauf wrote:
>
> On 11/19/23 01:04, Steve Kargl wrote:
> > On Sat, Nov 18, 2023 at 11:12:55PM +0100, Harald Anlauf wrote:
> > > Regtested on x86_64-pc-linux-gnu. OK for mainline?
> > >
> >
> > Not in its current form.
> >
> > > {
> > > + int first_int_kind = -1;
> > > + bool f2023 = ((gfc_option.allow_std & GFC_STD_F2023) != 0
> > > + && (gfc_option.allow_std & GFC_STD_GNU) == 0);
> > > +
> >
> > If you use the gfc_notify_std(), then you should not need the
> > above check on GFC_STD_GNU as it should include GFC_STD_F2023.
>
> this is actually the question (and problem). For all new features,
> -std=gnu shall include everything allowed by -std=f2023.
Yes.
> Here we have the problem that the testcase is valid F2018 and is
> silently accepted by gfortran-13 for -std=gnu and -std=f2018.
F2023 is the Fortran standard and supercedes previous Fortran standards.
If there is a conflict between the standing standard and an old standard,
then the standing standard should take precedence unless one specifically
uses, for example, -std=f2018.
After 20+ years of contributing to gfortran, I've come to believe
that the default -std= should be the current standard, and -std=gnu
should be deprecated. All GNU extensions should require an option
to active. For example,
write(*,*), 'hello'
end
gfortran12 -o z a.f90
a.f90:1:10:
1 | write(*,*), 'hello'
| 1
Warning: Legacy Extension: Comma before i/o item list at (1)
This should be an error unless the -fallow-write-stmt-comma is used.
The option would simply degrade the error to a warning. Why, you ask?
To encourage people to write standard conforming code. Unfortunately,
that horse has left the barn.
> I prefer to keep it that way also for gfortran-14, and apply the
> new restrictions only for -std=f2023. Do we agree on this?
If gfortran wants to maintain the status quo for 14, then
it should probably remove the -std=f2023 patch and wait for
the branch to 15.
> Now that should happen for -std=gnu -pedantic (-w)?
-pedantic is not a very effective option and should be ignored.
> I have thought some more and came up with the revised attached
> patch, which still has the above condition. It now marks the
> diagnostics as GNU extensions beyond F2023 for -std=f2023.
>
> The mask f2023 in the above form suppresses new warnings even
> for -pedantic; one would normally use -w to suppress them.
>
> Now if you remove the second part of the condition, we will
> regress on testcases system_clock_1.f90 and system_clock_3.f90
> because they would emit GNU extension warnings because the
> testsuite runs with -pedantic.
It seems that the solution is to fix the code in the testsuite.
With -std=f2023 or -std=gnu, the code should error. With
-std=f2018 (or older?), the code should compile.
It's been too long for my memory, doesn't the use of
'{ dg-options "-std=f023" }' supercede the set of predefined options
such as -pedantic?
> The options I see:
>
> - use patch-V1 (although diagnostics are better in V2),
>
> - use patch-V2,
>
> - use patch-V2, but enable -pedantic warnings for previously
> valid code, and adjust the failing testcases
I suppose that this last one is the best option.
>
> - ???
>
> > Elsewhere in the FE, gfortran uses gfc_notify_std() to enforce
> > requirements of a Fortran standard. The above would be
> >
> >if (count->ts.kind < gfc_default_integer_kind
> >&& gfc_notify_std (GFC_STD_F2023, "COUNT argument to
> > SYSTEM_CLOCK "
> > "at %L must have kind of at least default
> > integer",
> > >where))
>
> I tried this first, and it did not do the job.
>
> The logic in gfc_notify_std is:
>
> estd = std & ~gfc_option.allow_std; /* Standard to error about. */
> error = (estd != 0);
> if (error)
> msg = notify_std_msg (estd);
> ...
>
> So for -std=f2023 we get estd=0, error=false, and *NO* error.
> For -std=f2018 we get error=true and an error message.
> This is the opposite of what is needed.
>
> Can you please try yourself?
>
I was afraid you were going to say this. :-) :-)
The holidays draw near. I can probably find the time to
poke at gfortran.
> > Note, gfc_notify_std() should add the 'Fortran 2023: ' string,
> > if not, that should be fixed.
>
> This I did fix.
Thanks.
> > Of course, I seldom provide patches if others don't have a comment
> > then do as you like.
>
> Thanks for your feedback!
No, thank you for continuing to peck away at gfortran issue.
--
steve
Re: [PATCH] Fortran: fix reallocation on assignment of polymorphic variables [PR110415]
Hi Andrew,
On 20.11.23 14:56, Andrew Jenner wrote:
This patch adds the testcase from PR110415 and fixes the bug.
Thanks. I can confirm experimentally that it fixes the original PR. However,
if I extend
the original testcase (-2), it fails with run with valgrind or when run with
-fsanitize=address.
The array testcase (-3) seems to be fine with and without your patch.
I think it makes sense to include both extended testcases and put them under
gcc/testsuite/gfortran.dg/asan/ to ensure ASAN checks for leaks and some
invalid memory access.
I still should have a closer look at the -ftree-dump-original and at the patch
itself.
* * *
For the '-2' testcase, ASAN (-fsanitize=undefined) shows:
==11823==ERROR: AddressSanitizer: heap-use-after-free on address 0x60800220
at pc 0x00405d39 bp 0x7ffcfa6eef50 sp 0x7ffcfa6eef48
WRITE of size 96 at 0x60800220 thread T0
#0 0x405d38 in __copy_MAIN___D gcc/testsuite/gfortran.dg/pr110415.f90:5
#1 0x404dc0 in MAIN__ gcc/testsuite/gfortran.dg/pr110415.f90:24
#2 0x40a82b in main gcc/testsuite/gfortran.dg/pr110415.f90:28
#3 0x7f1e2a4281af in __libc_start_call_main (/lib64/libc.so.6+0x281af)
(BuildId: bbeee08e5f56966e641c4f3ba4ea1da9d730d0ab)
#4 0x7f1e2a428278 in __libc_start_main@@GLIBC_2.34
(/lib64/libc.so.6+0x28278) (BuildId: bbeee08e5f56966e641c4f3ba4ea1da9d730d0ab)
#5 0x402274 in _start ../sysdeps/x86_64/start.S:115
0x60800220 is located 0 bytes inside of 96-byte region
[0x60800220,0x60800280)
freed by thread T0 here:
#0 0x7f1e2b4daf35 (/lib64/libasan.so.8+0xdaf35) (BuildId:
3e1694ad218c99a8b1b69231666a27df63cf19d0)
#1 0x404d1c in MAIN__ gcc/testsuite/gfortran.dg/pr110415.f90:24
#2 0x40a82b in main gcc/testsuite/gfortran.dg/pr110415.f90:28
#3 0x7f1e2a4281af in __libc_start_call_main (/lib64/libc.so.6+0x281af)
(BuildId: bbeee08e5f56966e641c4f3ba4ea1da9d730d0ab)
previously allocated by thread T0 here:
#0 0x7f1e2b4dc03f in malloc (/lib64/libasan.so.8+0xdc03f) (BuildId:
3e1694ad218c99a8b1b69231666a27df63cf19d0)
#1 0x4042d2 in MAIN__ gcc/testsuite/gfortran.dg/pr110415.f90:22
#2 0x40a82b in main gcc/testsuite/gfortran.dg/pr110415.f90:28
#3 0x7f1e2a4281af in __libc_start_call_main (/lib64/libc.so.6+0x281af)
(BuildId: bbeee08e5f56966e641c4f3ba4ea1da9d730d0ab)
* * *
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
! { dg-do run }
!
! Contributed by Brad Richardson
!
implicit none
type, abstract :: p
integer :: a = 4
end type p
type, extends(p) :: c
integer :: b = 7
character(len=:), allocatable :: str, str2(:)
end type c
type, extends(p) :: d
integer :: ef = 7
character(len=:), allocatable :: str, str2(:)
end type d
class(p), allocatable :: a
a = func()
a = func2()
a = func()
deallocate(a)
contains
function func2() result(a)
class(p), allocatable :: a
a = d()
end function func2
function func() result(a)
class(p), allocatable :: a
a = c()
select type(a)
type is (c)
a%str = 'abcd'
a%str2 = ['abcd','efgh']
end select
end function func
end program
! { dg-do run }
!
! Contributed by Brad Richardson
!
implicit none
type, abstract :: p
integer :: a = 4
end type p
type, extends(p) :: c
integer :: b = 7
character(len=:), allocatable :: str, str2(:)
end type c
type, extends(p) :: d
integer :: ef = 7
character(len=:), allocatable :: str, str2(:)
end type d
class(p), allocatable :: a(:)
a = func()
a = func2()
a = func()
deallocate(a)
contains
function func2() result(a)
class(p), allocatable :: a(:)
a = [d(),d()]
end function func2
function func() result(a)
class(p), allocatable :: a(:)
a = [c(),c(),c()]
select type(a)
type is (c)
a(1)%str = 'abcd'
a(2)%str = 'abc'
a(3)%str = 'abcd4'
a(1)%str2 = ['abcd','efgh']
a(2)%str2 = ['bcd','fgh']
a(3)%str2 = ['abcd6','efgh7']
end select
end function func
end program
[PATCH] Fortran: fix reallocation on assignment of polymorphic variables [PR110415]
(I sent this to gcc-patches on Wednesday - didn't realise until today
that I needed to send it here too.)
This patch adds the testcase from PR110415 and fixes the bug.
The problem is that in a couple of places in trans_class_assignment in
trans-expr.cc, we need to get the run-time size of the polymorphic
object from the vtbl, but we are currently getting that vtbl from the
lhs of the assignment rather than the rhs. This gives us the old value
of the size but we need to pass the new size to __builtin_malloc and
__builtin_realloc.
I'm fixing this by adding a parameter to trans_class_vptr_len_assignment
to retrieve the tree corresponding the vptr from the object on the rhs
of the assignment, and then passing this where it is needed. In the case
where trans_class_vptr_len_assignment returns NULL_TREE for the rhs vptr
we use the lhs vptr as before.
To get this to work I also needed to change the implementation of
trans_class_vptr_len_assignment to create a temporary for the assignment
in more circumstances. Currently, the "a = func()" assignment in MAIN__
doesn't hit the "Create a temporary for complication expressions" case
on line 9951 because "DECL_P (rse->expr)" is true - the expression has
already been placed into a temporary. That means we don't hit the "if
(temp_rhs ..." case on line 10038 and go on to get the vptr_expr from
"gfc_lval_expr_from_sym (gfc_find_vtab (>ts))" on line 10057 which
is the vtbl of the static type rather than the dynamic one from the rhs.
So with this fix we create an extra temporary, but that should be
optimised away in the middle-end so there should be no run-time effect.
I'm not sure if this is the best way to fix this (the Fortran front-end
is new territory for me) but I've verified that the testcase passes with
this change, fails without it, and that the change does not introduce
any FAILs when running the gfortran testcases on x86_64-pc-linux-gnu.
Is this OK for mainline, GCC 13 and OG13?
Thanks,
Andrew
gcc/fortran/
* trans-expr.cc (trans_class_vptr_len_assignment): Add
from_vptrp parameter. Populate it. Don't check for DECL_P
when deciding whether to create temporary.
(trans_class_pointer_fcn, gfc_trans_pointer_assignment): Add
NULL argument to trans_class_vptr_len_assignment calls.
(trans_class_assignment): Get rhs_vptr from
trans_class_vptr_len_assignment and use it for determining size
for allocation/reallocation.
gcc/testsuite/
* gfortran.dg/pr110415.f90: New test.diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 50c4604a025..f1618b55add 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -9936,7 +9936,8 @@ trans_get_upoly_len (stmtblock_t *block, gfc_expr *expr)
static tree
trans_class_vptr_len_assignment (stmtblock_t *block, gfc_expr * le,
gfc_expr * re, gfc_se *rse,
-tree * to_lenp, tree * from_lenp)
+tree * to_lenp, tree * from_lenp,
+tree * from_vptrp)
{
gfc_se se;
gfc_expr * vptr_expr;
@@ -9944,10 +9945,11 @@ trans_class_vptr_len_assignment (stmtblock_t *block,
gfc_expr * le,
bool set_vptr = false, temp_rhs = false;
stmtblock_t *pre = block;
tree class_expr = NULL_TREE;
+ tree from_vptr = NULL_TREE;
/* Create a temporary for complicated expressions. */
if (re->expr_type != EXPR_VARIABLE && re->expr_type != EXPR_NULL
- && rse->expr != NULL_TREE && !DECL_P (rse->expr))
+ && rse->expr != NULL_TREE)
{
if (re->ts.type == BT_CLASS && !GFC_CLASS_TYPE_P (TREE_TYPE (rse->expr)))
class_expr = gfc_get_class_from_expr (rse->expr);
@@ -10044,6 +10046,7 @@ trans_class_vptr_len_assignment (stmtblock_t *block,
gfc_expr * le,
tmp = rse->expr;
se.expr = gfc_class_vptr_get (tmp);
+ from_vptr = se.expr;
if (UNLIMITED_POLY (re))
from_len = gfc_class_len_get (tmp);
@@ -10065,6 +10068,7 @@ trans_class_vptr_len_assignment (stmtblock_t *block,
gfc_expr * le,
gfc_free_expr (vptr_expr);
gfc_add_block_to_block (block, );
gcc_assert (se.post.head == NULL_TREE);
+ from_vptr = se.expr;
}
gfc_add_modify (pre, lhs_vptr, fold_convert (TREE_TYPE (lhs_vptr),
se.expr));
@@ -10093,11 +10097,13 @@ trans_class_vptr_len_assignment (stmtblock_t *block,
gfc_expr * le,
}
}
- /* Return the _len trees only, when requested. */
+ /* Return the _len and _vptr trees only, when requested. */
if (to_lenp)
*to_lenp = to_len;
if (from_lenp)
*from_lenp = from_len;
+ if (from_vptrp)
+*from_vptrp = from_vptr;
return lhs_vptr;
}
@@ -10166,7 +10172,7 @@ trans_class_pointer_fcn (stmtblock_t *block, gfc_se
*lse, gfc_se *rse,
{
expr1_vptr =
[patch] OpenMP: Add uses_allocators support
This adds middle end support for uses_allocators, wires Fortran to use it and add C/C++ parsing support. This is based on Chung-Lin's patch at https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596412.html There is a known firstprivate/private issue for C/C++, see: https://gcc.gnu.org/PR110347 but that one is unrelated. Tested on x86-64-gnu-linux w/o offloading; with offloading still running. Comments, suggestions? 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 OpenMP: Add uses_allocators support 2023-11-19 Tobias Burnus Chung-Lin Tang gcc/ChangeLog: * builtin-types.def (BT_FN_VOID_PTRMODE): (BT_FN_PTRMODE_PTRMODE_INT_PTR): Add. * gimplify.cc (gimplify_bind_expr): Diagnose missing uses_allocators clause. (gimplify_scan_omp_clauses, gimplify_adjust_omp_clauses, gimplify_omp_workshare): Handle uses_allocators. * omp-builtins.def (BUILT_IN_OMP_INIT_ALLOCATOR, BUILT_IN_OMP_DESTROY_ALLOCATOR): Add. * omp-low.cc (scan_sharing_clauses): * tree-core.h (enum omp_clause_code): Add OMP_CLAUSE_USES_ALLOCATORS. * tree.cc (omp_clause_num_ops, omp_clause_code_name): Likewise. * tree-pretty-print.cc (dump_omp_clause): Handle it. * tree.h (OMP_CLAUSE_USES_ALLOCATORS_ALLOCATOR, OMP_CLAUSE_USES_ALLOCATORS_MEMSPACE, OMP_CLAUSE_USES_ALLOCATORS_TRAITS): New. gcc/c-family/ChangeLog: * c-omp.cc (c_omp_split_clauses): Hande uses_allocators. * c-pragma.h (enum pragma_omp_clause): Add PRAGMA_OMP_CLAUSE_USES_ALLOCATORS. gcc/c/ChangeLog: * c-parser.cc (c_parser_omp_clause_uses_allocators): New. (c_parser_omp_clause_name, c_parser_omp_all_clauses, OMP_TARGET_CLAUSE_MASK): Handle uses_allocators. * c-typeck.cc (c_finish_omp_clauses): Likewise. gcc/cp/ChangeLog: * parser.cc (cp_parser_omp_clause_uses_allocators): New. (cp_parser_omp_clause_name, cp_parser_omp_all_clauses, OMP_TARGET_CLAUSE_MASK): Handle uses_allocators. * semantics.cc (finish_omp_clauses): Likewise. gcc/fortran/ChangeLog: * trans-array.cc (gfc_conv_array_initializer): Set PURPOSE when building constructor for get_initialized_tmp_var. * trans-openmp.cc (gfc_trans_omp_clauses): Handle uses_allocators. * types.def (BT_FN_VOID_PTRMODE, BT_FN_PTRMODE_PTRMODE_INT_PTR): Add. libgomp/ChangeLog: * testsuite/libgomp.c++/c++.exp (check_effective_target_c, check_effective_target_c++): Add. * testsuite/libgomp.c/c.exp (check_effective_target_c, check_effective_target_c++): Add. * testsuite/libgomp.fortran/uses_allocators_2.f90: Remove 'sorry'. * testsuite/libgomp.c-c++-common/uses_allocators-1.c: New test. * testsuite/libgomp.c-c++-common/uses_allocators-2.c: New test. * testsuite/libgomp.c-c++-common/uses_allocators-3.c: New test. * testsuite/libgomp.c-c++-common/uses_allocators-4.c: New test. * testsuite/libgomp.fortran/uses_allocators_3.f90: New test. * testsuite/libgomp.fortran/uses_allocators_4.f90: New test. * testsuite/libgomp.fortran/uses_allocators_5.f90: New test. * testsuite/libgomp.fortran/uses_allocators_6.f90: New test. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/allocate-1.f90: Add uses_allocators. * gfortran.dg/gomp/scope-6.f90: Update dg-scan-tree-dump. * c-c++-common/gomp/uses_allocators-1.c: New test. * c-c++-common/gomp/uses_allocators-2.c: New test. * gfortran.dg/gomp/uses_allocators-1.f90: New test. Co-authored-by: Chung-Lin Tang gcc/builtin-types.def | 3 + gcc/c-family/c-omp.cc | 1 + gcc/c-family/c-pragma.h| 1 + gcc/c/c-parser.cc | 216 ++- gcc/c/c-typeck.cc | 105 + gcc/cp/parser.cc | 237 - gcc/cp/semantics.cc| 95 + gcc/fortran/trans-array.cc | 5 +- gcc/fortran/trans-openmp.cc| 42 +++- gcc/fortran/types.def | 3 + gcc/gimplify.cc| 183 +++- gcc/omp-builtins.def | 4 + gcc/omp-low.cc | 32 +++ .../c-c++-common/gomp/uses_allocators-1.c | 46 .../c-c++-common/gomp/uses_allocators-2.c | 33 +++ gcc/testsuite/gfortran.dg/gomp/allocate-1.f90 | 7 +- gcc/testsuite/gfortran.dg/gomp/scope-6.f90 | 2 +- .../gfortran.dg/gomp/uses_allocators-1.f90 | 23 ++ gcc/tree-core.h| 3 + gcc/tree-pretty-print.cc | 14 ++ gcc/tree.cc| 2 + gcc/tree.h | 9 + libgomp/testsuite/libgomp.c++/c++.exp |
