Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514
Hi Tobias,
> LGTM – I am fine with either variant, but I am slightly inclined to
> removing the gcc_assert*
> – as I believe that the existing checks come early enough and do seem to
> work well.
I played some more and found additional cases that we hadn't discussed
before. (At least I hadn't thought of them because of the focus on
deferred length strings.)
- automatic string variables / arrays
- assumed length strings
- PDTs with character components.
The last one actually turned out sort of "hopeless" for now, so I opened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102003
to track this.
I added the other cases to testcase pr100950.f90 and reduced the checks
and code within "substring_has_constant_len" to the bare minimum.
See the attached follow-up patch.
> Can you check ('grep') whether we already have sufficient coverage of
> substring out of bounds?
> We presumably have, but if you spot something, I think it makes sense to
> add those to the testsuite.
We do have some checks on substring indices (e.g. substr_10.f90),
but not really extensive coverage.
> Tobias
> *I think GCC won't complain but if ENABLE_ASSERT_CHECKING is not defined,
> there is then a pointless 'length =' assignment, overridden before it is
> ever used.
Yes. This is fixed below.
I guess I have to apologize for things getting a bit out of control for
this PR, but the results are on the other hand way beyond my initial
expectations...
Re-regtested on x86_64-pc-linux-gnu. Should be safe elsewhere...
OK?
Thanks,
Harald
Fortran - extend set of substring expressions handled in length simplification
gcc/fortran/ChangeLog:
PR fortran/100950
* simplify.c (substring_has_constant_len): Minimize checks for
substring expressions being allowed.
gcc/testsuite/ChangeLog:
PR fortran/100950
* gfortran.dg/pr100950.f90: Extend coverage.
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 4cb73e836c7..b46cbfa90ab 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -4533,14 +4533,7 @@ substring_has_constant_len (gfc_expr *e)
|| !ref->u.ss.start
|| ref->u.ss.start->expr_type != EXPR_CONSTANT
|| !ref->u.ss.end
- || ref->u.ss.end->expr_type != EXPR_CONSTANT
- || !ref->u.ss.length)
-return false;
-
- /* For non-deferred strings the given length shall be constant. */
- if (!e->ts.deferred
- && (!ref->u.ss.length->length
- || ref->u.ss.length->length->expr_type != EXPR_CONSTANT))
+ || ref->u.ss.end->expr_type != EXPR_CONSTANT)
return false;
/* Basic checks on substring starting and ending indices. */
@@ -4551,27 +4544,7 @@ substring_has_constant_len (gfc_expr *e)
iend = gfc_mpz_get_hwi (ref->u.ss.end->value.integer);
if (istart <= iend)
-{
- if (istart < 1)
- {
- gfc_error ("Substring start index (%wd) at %L below 1",
- istart, >u.ss.start->where);
- return false;
- }
-
- /* For deferred strings use end index as proxy for length. */
- if (e->ts.deferred)
- length = iend;
- else
- length = gfc_mpz_get_hwi (ref->u.ss.length->length->value.integer);
- if (iend > length)
- {
- gfc_error ("Substring end index (%wd) at %L exceeds string length",
- iend, >u.ss.end->where);
- return false;
- }
- length = iend - istart + 1;
-}
+length = iend - istart + 1;
else
length = 0;
diff --git a/gcc/testsuite/gfortran.dg/pr100950.f90 b/gcc/testsuite/gfortran.dg/pr100950.f90
index cb9d126bc18..a19409c2507 100644
--- a/gcc/testsuite/gfortran.dg/pr100950.f90
+++ b/gcc/testsuite/gfortran.dg/pr100950.f90
@@ -46,6 +46,18 @@ program p
integer, parameter :: l9 = len (r(1)%u(:)(3:4))
if (l9 /= 2) stop 13
end block
+
+ call sub (42, "abcde")
+contains
+ subroutine sub (m, c)
+integer, intent(in) :: m
+character(len=*), intent(in) :: c
+character(len=m):: p, o(3)
+integer, parameter :: l10 = len (p(6:7))
+integer, parameter :: l11 = len (o(:)(6:7))
+integer, parameter :: l12 = len (c(2:3))
+if (l10 /= 2 .or. l11 /= 2 .or. l12 /= 2) stop 14
+ end subroutine sub
end
! { dg-final { scan-tree-dump-times "_gfortran_stop_numeric" 2 "original" } }
[Patch] Fortran: Fix Bind(C) char-len check, add ptr-contiguous check
The following is about interoperability (BIND(C)) only.
* The patch adds a missing check for pointer + contiguous.
(Rejected to avoid copy-in issues? Or checking issues?)
* And it corrects an issue regarding len > 1 characters. While
subroutine foo(x)
character(len=2) :: x(*)
is valid Fortran code (the argument can be "abce" or ['a','b','c','d'] or ...)
– and would work also with bind(C) as the len=2 does not need to be passed
as hidden argument as len is a constant.
However, it is not valid nonetheless.
OK? Comments?
Tobias
PS: Referenced locations in the standard (F2018):
C1554 If proc-language-binding-spec is specified for a procedure,
each of its dummy arguments shall be an interoperable procedure (18.3.6)
or a variable that is interoperable (18.3.4, 18.3.5), assumed-shape,
assumed-rank, assumed-type, of type CHARACTER with assumed length,
or that has the ALLOCATABLE or POINTER attribute.
18.3.1: "... If the type is character, the length type parameter is
interoperable if and only if its value is one. ..."
"18.3.4 Interoperability of scalar variables":
"... A named scalar Fortran variable is interoperable ... if it
is of type character12its length is not assumed or declared by
an expression that is not a constant expression."
18.3.5: Likewise but for arrays.
18.3.6 "... Fortran procedure interface is interoperable with a C function prototype
..."
"(5) any dummy argument without the VALUE attribute corresponds
to a formal parameter of the prototype that is of a pointer type, and
either
• the dummy argument is interoperable with an entity of the referenced type
..."
(Remark: those are passed as byte stream)
"• the dummy argument is a nonallocatable nonpointer variable of type
CHARACTER with assumed character length and the formal parameter is
a pointer to CFI_cdesc_t,
• the dummy argument is allocatable, assumed-shape, assumed-rank, or
a pointer without the CONTIGUOUS attribute, and the formal parameter
is a pointer to CFI_cdesc_t, or
(Remark: those two use an array descriptor, also for explicit-size/assumed-size
arrays or for scalars.)
• the dummy argument is assumed-type ..."
-
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: Fix Bind(C) char-len check, add ptr-contiguous check
Add F2018, 18.3.6 (5), pointer + contiguous is not permitted
check for dummies in BIND(C) procs.
Fix misreading of F2018, 18.3.4/18.3.5 + 18.3.6 (5) regarding
character dummies passed as byte stream to a bind(C) dummy arg:
Per F2018, 18.3.1 only len=1 is interoperable (since F2003).
F2008 added 'constant expression' for vars (F2018, 18.3.4/18.3.5),
applicable to dummy args per F2018, C1554. I misread this such
that len > 1 is permitted if len is a constant expr.
While the latter would work as character len=1 a(10) and len=2 a(5)
have the same storage sequence and len is fixed, it is still invalid.
Hence, it is now rejected again.
gcc/fortran/ChangeLog:
* decl.c (gfc_verify_c_interop_param): Reject pointer with
CONTIGUOUS attributes as dummy arg. Reject character len > 1
when passed as byte stream.
gcc/testsuite/ChangeLog:
* gfortran.dg/bind_c_char_6.f90:
* gfortran.dg/bind_c_char_7.f90:
* gfortran.dg/bind_c_char_8.f90:
* gfortran.dg/bind_c_char_9.f90:
* gfortran.dg/iso_c_binding_char_1.f90:
* gfortran.dg/pr32599.f03:
* gfortran.dg/bind_c_contiguous.f90: New test.
gcc/fortran/decl.c | 39 ++---
gcc/testsuite/gfortran.dg/bind_c_char_6.f90| 22 ++-
gcc/testsuite/gfortran.dg/bind_c_char_7.f90| 15 +-
gcc/testsuite/gfortran.dg/bind_c_char_8.f90| 12 +-
gcc/testsuite/gfortran.dg/bind_c_char_9.f90| 161 -
gcc/testsuite/gfortran.dg/bind_c_contiguous.f90| 33 +
gcc/testsuite/gfortran.dg/iso_c_binding_char_1.f90 | 1 +
gcc/testsuite/gfortran.dg/pr32599.f03 | 2 +-
8 files changed, 164 insertions(+), 121 deletions(-)
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 05081c40f1e..3ecffe79d9f 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -1551,11 +1551,15 @@ gfc_verify_c_interop_param (gfc_symbol *sym)
sym->ns->proc_name->name);
}
+ /* Per F2018, 18.3.6 (5), pointer + contiguous is not permitted. */
+ if (sym->attr.pointer && sym->attr.contiguous)
+ gfc_error ("Dummy argument %qs at %L may not be a pointer with "
+ "CONTIGUOUS attribute as procedure %qs is BIND(C)",
+ sym->name, >declared_at, sym->ns->proc_name->name);
+
/* Character strings are only C interoperable if they have a
- length of 1. However, as argument they are either iteroperable
- when passed as descriptor (which requires len=: or len=*) or
- when
Re: [Patch] c-format.c/Fortran: Support %wd / host-wide integer in gfc_error (Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514)
On Fri, Aug 20, 2021 at 03:47:54PM +0200, Tobias Burnus wrote: > On 20.08.21 13:56, Jakub Jelinek wrote: > > > On Fri, Aug 20, 2021 at 01:50:00PM +0200, Tobias Burnus wrote: > > > Comments? OK? > > LGTM (except that the last hunk won't apply anymore). > > Now applied as r12-3044; I have now changed it to %wd ... > > ... but as discussed in another email in the thread, I think the > gfc_error should be removed (as unused); possibly with some additional > testcases running into the resolve errors for those (out of bound). Yeah, it makes sense that if there are errors in user code, they are diagnosed during resolve, no matter whether simplification is possible or not and simplification either asserts the errors aren't there or just punts on the simplification, but doesn't repeat those diagnostics. Jakub
Re: [Patch] c-format.c/Fortran: Support %wd / host-wide integer in gfc_error (Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514)
On 20.08.21 13:56, Jakub Jelinek wrote:
On Fri, Aug 20, 2021 at 01:50:00PM +0200, Tobias Burnus wrote:
Comments? OK?
LGTM (except that the last hunk won't apply anymore).
Now applied as r12-3044; I have now changed it to %wd ...
... but as discussed in another email in the thread, I think the
gfc_error should be removed (as unused); possibly with some additional
testcases running into the resolve errors for those (out of bound).
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
commit 1b507b1e3c58c063b9cf803dff80c28d4626cb5d
Author: Tobias Burnus
Date: Fri Aug 20 15:43:32 2021 +0200
c-format.c/Fortran: Support %wd / host-wide integer in gfc_error
This patch adds support for the 'll' (long double)
and 'w' (HOST_WIDE_INT) length modifiers to the
Fortran FE diagnostic function (gfc_error, gfc_warning, ...)
gcc/c-family/ChangeLog:
* c-format.c (gcc_gfc_length_specs): Add 'll' and 'w'.
(gcc_gfc_char_table): Add T9L_LL and T9L_ULL to
"di" and "u", respecitively; fill with BADLEN to match
size of 'types'.
(get_init_dynamic_hwi): Split off from ...
(init_dynamic_diag_info): ... here. Call it.
(init_dynamic_gfc_info): Call it.
gcc/fortran/ChangeLog:
* error.c
(error_uinteger): Take 'long long unsigned' instead
of 'long unsigned' as argumpent.
(error_integer): Take 'long long' instead of 'long'.
(error_hwuint, error_hwint): New.
(error_print): Update to handle 'll' and 'w'
length modifiers.
* simplify.c (substring_has_constant_len): Use '%wd'
in gfc_error.
---
gcc/c-family/c-format.c | 142 +---
gcc/fortran/error.c | 106 +---
gcc/fortran/simplify.c | 11 ++--
3 files changed, 178 insertions(+), 81 deletions(-)
diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
index 6fd0bb33d21..b4cb765a9d3 100644
--- a/gcc/c-family/c-format.c
+++ b/gcc/c-family/c-format.c
@@ -546,10 +546,11 @@ static const format_length_info strfmon_length_specs[] =
};
-/* For now, the Fortran front-end routines only use l as length modifier. */
+/* Length modifiers used by the fortran/error.c routines. */
static const format_length_info gcc_gfc_length_specs[] =
{
- { "l", FMT_LEN_l, STD_C89, NO_FMT, 0 },
+ { "l", FMT_LEN_l, STD_C89, "ll", FMT_LEN_ll, STD_C89, 0 },
+ { "w", FMT_LEN_w, STD_C89, NO_FMT, 0 },
{ NO_FMT, NO_FMT, 0 }
};
@@ -821,10 +822,10 @@ static const format_char_info gcc_cxxdiag_char_table[] =
static const format_char_info gcc_gfc_char_table[] =
{
/* C89 conversion specifiers. */
- { "di", 0, STD_C89, { T89_I, BADLEN, BADLEN, T89_L, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
- { "u", 0, STD_C89, { T89_UI, BADLEN, BADLEN, T89_UL, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
- { "c", 0, STD_C89, { T89_I, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
- { "s", 1, STD_C89, { T89_C, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "cR", NULL },
+ { "di", 0, STD_C89, { T89_I, BADLEN, BADLEN, T89_L, T9L_LL, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
+ { "u", 0, STD_C89, { T89_UI, BADLEN, BADLEN, T89_UL, T9L_ULL, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
+ { "c", 0, STD_C89, { T89_I, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
+ { "s", 1, STD_C89, { T89_C, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "cR", NULL },
/* gfc conversion specifiers. */
@@ -4843,12 +4844,73 @@ init_dynamic_asm_fprintf_info (void)
}
}
+static const format_length_info*
+get_init_dynamic_hwi (void)
+{
+ static tree hwi;
+ static format_length_info *diag_ls;
+
+ if (!hwi)
+{
+ unsigned int i;
+
+ /* Find the underlying type for HOST_WIDE_INT. For the 'w'
+ length modifier to work, one must have issued: "typedef
+ HOST_WIDE_INT __gcc_host_wide_int__;" in one's source code
+ prior to using that modifier. */
+ if ((hwi = maybe_get_identifier ("__gcc_host_wide_int__")))
+ {
+ hwi = identifier_global_value (hwi);
+ if (hwi)
+ {
+ if (TREE_CODE (hwi) != TYPE_DECL)
+ {
+ error ("%<__gcc_host_wide_int__%> is not defined as a type");
+ hwi = 0;
+ }
+ else
+ {
+ hwi = DECL_ORIGINAL_TYPE (hwi);
+ gcc_assert (hwi);
+ if (hwi != long_integer_type_node
+
Re: Build problems: mpfr, mpc
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. >
Re: Build problems: mpfr, mpc
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. I am curious why _GNU_SOURCE would be defined during configure but not when compiling.
Re: Build problems: mpfr, mpc
On Fri, Aug 20, 2021 at 12:55 PM Arjen Markus wrote:
>
> Okay, that solved that error, now I get:
>
> -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
> -fdiagnostics-show-location=once -ffunction-sections -fdata-sections
> -frandom-seed=fs_ops.lo -fimplicit-templates -g -O2 -c
> ../../../../../../libstdc++-v3/src/c++17/fs_ops.cc -o fs_ops.o
> In file included from ../../../../../../libstdc++-v3/src/c++17/fs_ops.cc:58:
> ../../../../../../libstdc++-v3/src/c++17/../filesystem/ops-common.h: In
> function 'const char*
> std::filesystem::get_temp_directory_from_env(std::error_code&)':
> ../../../../../../libstdc++-v3/src/c++17/../filesystem/ops-common.h:601:25:
> error: '::secure_getenv' has not been declared
> 601 | auto tmpdir = ::secure_getenv(env);
> | ^
>
> and there is a weird subdirectory under the build directory: gccd: - the
> colon cannot be part of a directory name under Windows. I guess this is my
> mistake, as I set the install directory to "d:/gfortran/work" - that should
> become "/cygdrive/d/gfortran/work". Easily fixed, but I do not know what to
> do about the first error.
Possibly secure_getenv is not available in cygwin and for some reason
AC_CHECK_FUNCS (secure_getenv) as done by
libstdc++ configury misdetects it and/or the use site has a different
set of includes. Jonathan might know.
Note using cygwin (or mingw for that) might make GCC development more
painful than necessary. It might be
that using a WSL2 based setup is easier if you're stuck to a Windows
host. Using Linux in a virtual machine
might be another option of course.
Richard.
> Regards,
>
> Arjen
>
> Op vr 20 aug. 2021 om 12:10 schreef Arjen Markus :
>>
>>
>>
>> Op vr 20 aug. 2021 om 11:54 schreef Richard Biener:
>>>
>>>
>>>
>>> The easiest is probably to build them in-tree by means of
>>> executing ./contrib/download_prerequesites which will download
>>> and unpack them into your source tree.
>>>
>>
>> Well, I do have the libraries (source and all) and I copied the built
>> libraries (that is the content of mpfr/,libs and mpc/.libs to the locations
>> that are referred to in the link statement, so I assumed that would enable
>> the linker to find them.
>>
>>> Other than that you are likely either missing some of the requirements
>>> or lack the appropriate --with-{gmp,mpc,mpfr}[-lib] configury.
>>>
>>
>> The odd thing is that the link statement as presented in the command window
>> knows where to find the libraries. Here is the (hopefully) relevant part:
>>
>> g++ -std=c++11 -no-pie -g -DIN_GCC -fno-exceptions -fno-rtti
>> -fasynchronous-unwind-tables -W -Wall
>> (...) ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a
>> -L/cygdrive/d/gfortran/gcc/build-gcc/./gmp/.libs
>> -L/cygdrive/d/gfortran/gcc/build-gcc/./mpfr/src/.libs
>> -L/cygdrive/d/gfortran/gcc/build-gcc/./mpc/src/.libs -lmpc -lmpfr -lgmp
>> -L./../zlib -lz libcommon.a ../libcpp/libcpp.a -liconv
>> ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
>> ../libdecnumber/libdecnumber.a
>> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: cannot
>> find -lmpc
>> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: cannot
>> find -lmpc
>> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: cannot
>> find -lmpfr
>> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: cannot
>> find -lmpfr
>> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: cannot
>> find -lmpc
>> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld: cannot
>> find -lmpfr
>>
>>
>>> What host operating system are you using?
>>>
>> Cygwin on Windows 10
>>
>> Oops, now that I copied the relevant bit of the link command, I see what I
>> did wrong: the libraries are under mpfr/./libs, not mpfr/src/.libs (and
>> ditto for mpc).
>>
>> Okay, trying again!
>>
>> Thanks for the reply. This ought to do it.
>>
>> Regards,
>>
>> Arjen
Aw: Re: Re: Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514
> Gesendet: Freitag, 20. August 2021 um 14:01 Uhr
> Von: "Tobias Burnus"
> On 20.08.21 12:53, Harald Anlauf wrote:
>
> > I played with variations of the testcase by specifying illegal
> > substring bounds, but all these cases were caught in a different
> > spot with similar error messages.
>
> I can confirm this. – I think in order to reduce the clutter, the
> diagnostic probably should be removed.
I am unable to prove that we will never that check. So how about:
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index eaabbffca4d..04722a8640c 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -4552,27 +4552,13 @@ substring_has_constant_len (gfc_expr *e)
if (istart <= iend)
{
- char buffer[21];
- if (istart < 1)
- {
- sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, istart);
- gfc_error ("Substring start index (%s) at %L below 1",
-buffer, >u.ss.start->where);
- return false;
- }
-
/* For deferred strings use end index as proxy for length. */
if (e->ts.deferred)
length = iend;
else
length = gfc_mpz_get_hwi (ref->u.ss.length->length->value.integer);
- if (iend > length)
- {
- sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, iend);
- gfc_error ("Substring end index (%s) at %L exceeds string length",
-buffer, >u.ss.end->where);
- return false;
- }
+
+ gcc_assert (istart >= 1 && iend <= length);
length = iend - istart + 1;
}
else
Or skip the gcc_assert and cross fingers... (we then would not even need to
verify ref->u.ss.length in that depth).
Harald
Re: Aw: Re: Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514
On 20.08.21 12:53, Harald Anlauf wrote: I have verified it fixes i686-linux bootstrap. But the new testcase doesn't trigger any of those new errors, is something else in the testsuite covering those or do you have some short snippet that could verify the errors work properly? The testcase was designed to verify correct simplification of substring length for a variety of cases. I played with variations of the testcase by specifying illegal substring bounds, but all these cases were caught in a different spot with similar error messages. I can confirm this. – I think in order to reduce the clutter, the diagnostic probably should be removed. 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: [Patch] c-format.c/Fortran: Support %wd / host-wide integer in gfc_error (Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514)
On Fri, Aug 20, 2021 at 01:50:00PM +0200, Tobias Burnus wrote:
> On 20.08.21 11:16, Jakub Jelinek wrote:
>
> > Now, the non-Fortran FE diagnostic code actually has %wd for this (w
> > modifier like l modifier), which takes HOST_WIDE_INT/unsigned HOST_WIDE_INT
> > argument and prints it.
> >
> > So, either you get through the hops to support that, unfortunately it isn't
> > just adding support for that in fortran/error.c (error_print) and some
> > helper functions, which wouldn't be that hard, just add 'w' next to 'l'
> > handling, TYPE_* for that and union member etc., but one needs to modify
> > c-family/c-format.c too to register the modifier so that gcc doesn't warn
> > about it and knows the proper argument type etc.
>
> That's what the attached patch does.
>
> Build on x86-64 GNU Linux; I tried to build it with -m32 (cf. my
> previous email) but as I did not run into the original issue, this does
> not proof much.
>
> Comments? OK?
LGTM (except that the last hunk won't apply anymore).
> c-format.c/Fortran: Support %wd / host-wide integer in gfc_error
>
> This patch adds support for the 'll' (long double)
> and 'w' (HOST_WIDE_INT) length modifiers to the
> Fortran FE diagnostic function (gfc_error, gfc_warning, ...)
>
> gcc/c-family/ChangeLog:
>
> * c-format.c (gcc_gfc_length_specs): Add 'll' and 'w'.
> (gcc_gfc_char_table): Add T9L_LL and T9L_ULL to
> "di" and "u", respecitively; fill with BADLEN to match
> size of 'types'.
> (get_init_dynamic_hwi): Split off from ...
> (init_dynamic_diag_info): ... here. Call it.
> (init_dynamic_gfc_info): Call it.
>
> gcc/fortran/ChangeLog:
>
> * error.c
> (error_uinteger): Take 'long long unsigned' instead
> of 'long unsigned' as argumpent.
> (error_integer): Take 'long long' instead of 'long'.
> (error_hwuint, error_hwint): New.
> (error_print): Update to handle 'll' and 'w'
> length modifiers.
> * simplify.c (substring_has_constant_len): Replace
> HOST_WIDE_INT_PRINT_DEC by '%wd'.
>
> diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
> index 6fd0bb33d21..b4cb765a9d3 100644
> --- a/gcc/c-family/c-format.c
> +++ b/gcc/c-family/c-format.c
> @@ -546,10 +546,11 @@ static const format_length_info strfmon_length_specs[] =
> };
>
>
> -/* For now, the Fortran front-end routines only use l as length modifier. */
> +/* Length modifiers used by the fortran/error.c routines. */
> static const format_length_info gcc_gfc_length_specs[] =
> {
> - { "l", FMT_LEN_l, STD_C89, NO_FMT, 0 },
> + { "l", FMT_LEN_l, STD_C89, "ll", FMT_LEN_ll, STD_C89, 0 },
> + { "w", FMT_LEN_w, STD_C89, NO_FMT, 0 },
>{ NO_FMT, NO_FMT, 0 }
> };
>
> @@ -821,10 +822,10 @@ static const format_char_info gcc_cxxdiag_char_table[] =
> static const format_char_info gcc_gfc_char_table[] =
> {
>/* C89 conversion specifiers. */
> - { "di", 0, STD_C89, { T89_I, BADLEN, BADLEN, T89_L, BADLEN,
> BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
> - { "u", 0, STD_C89, { T89_UI, BADLEN, BADLEN, T89_UL, BADLEN,
> BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
> - { "c", 0, STD_C89, { T89_I, BADLEN, BADLEN, BADLEN, BADLEN,
> BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
> - { "s", 1, STD_C89, { T89_C, BADLEN, BADLEN, BADLEN, BADLEN,
> BADLEN, BADLEN, BADLEN, BADLEN }, "q", "cR", NULL },
> + { "di", 0, STD_C89, { T89_I, BADLEN, BADLEN, T89_L, T9L_LL,
> BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
> + { "u", 0, STD_C89, { T89_UI, BADLEN, BADLEN, T89_UL, T9L_ULL,
> BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
> + { "c", 0, STD_C89, { T89_I, BADLEN, BADLEN, BADLEN, BADLEN,
> BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
> + { "s", 1, STD_C89, { T89_C, BADLEN, BADLEN, BADLEN, BADLEN,
> BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "cR", NULL
> },
>
>/* gfc conversion specifiers. */
>
> @@ -4843,12 +4844,73 @@ init_dynamic_asm_fprintf_info (void)
> }
> }
>
> +static const format_length_info*
> +get_init_dynamic_hwi (void)
> +{
> + static tree hwi;
> + static format_length_info *diag_ls;
> +
> + if (!hwi)
> +{
> + unsigned int i;
> +
> + /* Find the underlying type for HOST_WIDE_INT. For the 'w'
> + length modifier to work, one must have issued: "typedef
> + HOST_WIDE_INT __gcc_host_wide_int__;" in one's source code
> + prior to using that modifier. */
> + if ((hwi = maybe_get_identifier ("__gcc_host_wide_int__")))
> + {
> + hwi = identifier_global_value (hwi);
> + if (hwi)
> + {
> + if (TREE_CODE (hwi) != TYPE_DECL)
> + {
> + error ("%<__gcc_host_wide_int__%> is not defined as a type");
> + hwi = 0;
> + }
> + else
[Patch] c-format.c/Fortran: Support %wd / host-wide integer in gfc_error (Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514)
On 20.08.21 11:16, Jakub Jelinek wrote:
Now, the non-Fortran FE diagnostic code actually has %wd for this (w
modifier like l modifier), which takes HOST_WIDE_INT/unsigned HOST_WIDE_INT
argument and prints it.
So, either you get through the hops to support that, unfortunately it isn't
just adding support for that in fortran/error.c (error_print) and some
helper functions, which wouldn't be that hard, just add 'w' next to 'l'
handling, TYPE_* for that and union member etc., but one needs to modify
c-family/c-format.c too to register the modifier so that gcc doesn't warn
about it and knows the proper argument type etc.
That's what the attached patch does.
Build on x86-64 GNU Linux; I tried to build it with -m32 (cf. my
previous email) but as I did not run into the original issue, this does
not proof much.
Comments? OK?
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
c-format.c/Fortran: Support %wd / host-wide integer in gfc_error
This patch adds support for the 'll' (long double)
and 'w' (HOST_WIDE_INT) length modifiers to the
Fortran FE diagnostic function (gfc_error, gfc_warning, ...)
gcc/c-family/ChangeLog:
* c-format.c (gcc_gfc_length_specs): Add 'll' and 'w'.
(gcc_gfc_char_table): Add T9L_LL and T9L_ULL to
"di" and "u", respecitively; fill with BADLEN to match
size of 'types'.
(get_init_dynamic_hwi): Split off from ...
(init_dynamic_diag_info): ... here. Call it.
(init_dynamic_gfc_info): Call it.
gcc/fortran/ChangeLog:
* error.c
(error_uinteger): Take 'long long unsigned' instead
of 'long unsigned' as argumpent.
(error_integer): Take 'long long' instead of 'long'.
(error_hwuint, error_hwint): New.
(error_print): Update to handle 'll' and 'w'
length modifiers.
* simplify.c (substring_has_constant_len): Replace
HOST_WIDE_INT_PRINT_DEC by '%wd'.
diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
index 6fd0bb33d21..b4cb765a9d3 100644
--- a/gcc/c-family/c-format.c
+++ b/gcc/c-family/c-format.c
@@ -546,10 +546,11 @@ static const format_length_info strfmon_length_specs[] =
};
-/* For now, the Fortran front-end routines only use l as length modifier. */
+/* Length modifiers used by the fortran/error.c routines. */
static const format_length_info gcc_gfc_length_specs[] =
{
- { "l", FMT_LEN_l, STD_C89, NO_FMT, 0 },
+ { "l", FMT_LEN_l, STD_C89, "ll", FMT_LEN_ll, STD_C89, 0 },
+ { "w", FMT_LEN_w, STD_C89, NO_FMT, 0 },
{ NO_FMT, NO_FMT, 0 }
};
@@ -821,10 +822,10 @@ static const format_char_info gcc_cxxdiag_char_table[] =
static const format_char_info gcc_gfc_char_table[] =
{
/* C89 conversion specifiers. */
- { "di", 0, STD_C89, { T89_I, BADLEN, BADLEN, T89_L, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
- { "u", 0, STD_C89, { T89_UI, BADLEN, BADLEN, T89_UL, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
- { "c", 0, STD_C89, { T89_I, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
- { "s", 1, STD_C89, { T89_C, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "cR", NULL },
+ { "di", 0, STD_C89, { T89_I, BADLEN, BADLEN, T89_L, T9L_LL, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
+ { "u", 0, STD_C89, { T89_UI, BADLEN, BADLEN, T89_UL, T9L_ULL, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
+ { "c", 0, STD_C89, { T89_I, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "", NULL },
+ { "s", 1, STD_C89, { T89_C, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "q", "cR", NULL },
/* gfc conversion specifiers. */
@@ -4843,12 +4844,73 @@ init_dynamic_asm_fprintf_info (void)
}
}
+static const format_length_info*
+get_init_dynamic_hwi (void)
+{
+ static tree hwi;
+ static format_length_info *diag_ls;
+
+ if (!hwi)
+{
+ unsigned int i;
+
+ /* Find the underlying type for HOST_WIDE_INT. For the 'w'
+ length modifier to work, one must have issued: "typedef
+ HOST_WIDE_INT __gcc_host_wide_int__;" in one's source code
+ prior to using that modifier. */
+ if ((hwi = maybe_get_identifier ("__gcc_host_wide_int__")))
+ {
+ hwi = identifier_global_value (hwi);
+ if (hwi)
+ {
+ if (TREE_CODE (hwi) != TYPE_DECL)
+ {
+ error ("%<__gcc_host_wide_int__%> is not defined as a type");
+ hwi = 0;
+ }
+ else
+ {
+ hwi = DECL_ORIGINAL_TYPE (hwi);
+ gcc_assert (hwi);
+ if (hwi != long_integer_type_node
+ && hwi != long_long_integer_type_node)
+ {
+ error ("%<__gcc_host_wide_int__%> is not defined"
+ " as % or %");
+ hwi = 0;
+ }
[PATCH, committed] Fix bootstrap breakage caused by r12-3033 (PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514)
Dear all,
I've just pushed the fix for the bootstrap breakage as confirmed by Jakub.
commit r12-3043-g12f22906d3c025e7edb60e3264dc9cd27a49e3e1
Author: Harald Anlauf
Date: Fri Aug 20 13:38:00 2021 +0200
Fortran - use temporary char buffer for passing HOST_WIDE_INT to gfc_error
gcc/fortran/ChangeLog:
PR fortran/100950
* simplify.c (substring_has_constant_len): Fix format string of
gfc_error, pass HOST_WIDE_INT bounds values via char buffer.
Sorry for the inconvenience.
Harald
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 492867e12cb..eaabbffca4d 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -4552,11 +4552,12 @@ substring_has_constant_len (gfc_expr *e)
if (istart <= iend)
{
+ char buffer[21];
if (istart < 1)
{
- gfc_error ("Substring start index (" HOST_WIDE_INT_PRINT_DEC
- ") at %L below 1",
- istart, >u.ss.start->where);
+ sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, istart);
+ gfc_error ("Substring start index (%s) at %L below 1",
+ buffer, >u.ss.start->where);
return false;
}
@@ -4567,9 +4568,9 @@ substring_has_constant_len (gfc_expr *e)
length = gfc_mpz_get_hwi (ref->u.ss.length->length->value.integer);
if (iend > length)
{
- gfc_error ("Substring end index (" HOST_WIDE_INT_PRINT_DEC
- ") at %L exceeds string length",
- iend, >u.ss.end->where);
+ sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, iend);
+ gfc_error ("Substring end index (%s) at %L exceeds string length",
+ buffer, >u.ss.end->where);
return false;
}
length = iend - istart + 1;
Re: Re: Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514
On Fri, Aug 20, 2021 at 12:53:33PM +0200, Harald Anlauf wrote: > > Gesendet: Freitag, 20. August 2021 um 12:12 Uhr > > Von: "Jakub Jelinek" > > > I have verified it fixes i686-linux bootstrap. > > But the new testcase doesn't trigger any of those new errors, is something > > else in the testsuite covering those or do you have some short snippet that > > could verify the errors work properly? > > The testcase was designed to verify correct simplification of > substring length for a variety of cases. > > I played with variations of the testcase by specifying illegal > substring bounds, but all these cases were caught in a different > spot with similar error messages. > > I put those checks into substring_has_constant_len as sanity checks. > Do you want me to remove them? > > Or are you trying to say that it is important to exercise them? Not a big deal, just wanted to verify that it actually works on i686-linux. Please just go ahead and commit the patch to avoid the bootstrap failures. Thanks. Jakub
Re: Build problems: mpfr, mpc
Okay, that solved that error, now I get:
-Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=fs_ops.lo -fimplicit-templates -g -O2 -c
../../../../../../libstdc++-v3/src/c++17/fs_ops.cc -o fs_ops.o
In file included from ../../../../../../libstdc++-v3/src/c++17/fs_ops.cc:58:
../../../../../../libstdc++-v3/src/c++17/../filesystem/ops-common.h: In
function 'const char*
std::filesystem::get_temp_directory_from_env(std::error_code&)':
../../../../../../libstdc++-v3/src/c++17/../filesystem/ops-common.h:601:25:
error: '::secure_getenv' has not been declared
601 | auto tmpdir = ::secure_getenv(env);
| ^
and there is a weird subdirectory under the build directory: gccd: - the
colon cannot be part of a directory name under Windows. I guess this is my
mistake, as I set the install directory to "d:/gfortran/work" - that should
become "/cygdrive/d/gfortran/work". Easily fixed, but I do not know what to
do about the first error.
Regards,
Arjen
Op vr 20 aug. 2021 om 12:10 schreef Arjen Markus :
>
>
> Op vr 20 aug. 2021 om 11:54 schreef Richard Biener:
>
>>
>>
>> The easiest is probably to build them in-tree by means of
>> executing ./contrib/download_prerequesites which will download
>> and unpack them into your source tree.
>>
>>
> Well, I do have the libraries (source and all) and I copied the built
> libraries (that is the content of mpfr/,libs and mpc/.libs to the locations
> that are referred to in the link statement, so I assumed that would enable
> the linker to find them.
>
> Other than that you are likely either missing some of the requirements
>> or lack the appropriate --with-{gmp,mpc,mpfr}[-lib] configury.
>>
>>
> The odd thing is that the link statement as presented in the command
> window knows where to find the libraries. Here is the (hopefully) relevant
> part:
>
> g++ -std=c++11 -no-pie -g -DIN_GCC -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall
> (...) ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a
> -L/cygdrive/d/gfortran/gcc/build-gcc/./gmp/.libs
> -L/cygdrive/d/gfortran/gcc/build-gcc/./mpfr/src/.libs
> -L/cygdrive/d/gfortran/gcc/build-gcc/./mpc/src/.libs -lmpc -lmpfr -lgmp
> -L./../zlib -lz libcommon.a ../libcpp/libcpp.a -liconv
> ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
> ../libdecnumber/libdecnumber.a
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpc
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpc
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpfr
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpfr
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpc
> /usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
> cannot find -lmpfr
>
>
> What host operating system are you using?
>>
>> Cygwin on Windows 10
>
> Oops, now that I copied the relevant bit of the link command, I see what I
> did wrong: the libraries are under mpfr/./libs, not mpfr/src/.libs (and
> ditto for mpc).
>
> Okay, trying again!
>
> Thanks for the reply. This ought to do it.
>
> Regards,
>
> Arjen
>
Aw: Re: Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514
> Gesendet: Freitag, 20. August 2021 um 12:12 Uhr > Von: "Jakub Jelinek" > I have verified it fixes i686-linux bootstrap. > But the new testcase doesn't trigger any of those new errors, is something > else in the testsuite covering those or do you have some short snippet that > could verify the errors work properly? The testcase was designed to verify correct simplification of substring length for a variety of cases. I played with variations of the testcase by specifying illegal substring bounds, but all these cases were caught in a different spot with similar error messages. I put those checks into substring_has_constant_len as sanity checks. Do you want me to remove them? Or are you trying to say that it is important to exercise them? Thanks, Harald
Re: Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514
On Fri, Aug 20, 2021 at 11:45:33AM +0200, Harald Anlauf wrote:
> Hi Jakob,
>
> thanks for the detailed explanation!
>
> > The other much easier but uglier option is to use a temporary buffer:
> > char buffer[21];
> > sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, hwint_val);
> > gfc_error ("... %s ...", ... buffer ...);
> > This works, as it uses the host sprintf i.e. *printf family for which
> > HOST_WIDE_INT_PRINT_DEC macro is designed.
>
> The attached followup patch implements this.
>
> Can anybody affected by current HEAD confirm that this fixes bootstrap?
I have verified it fixes i686-linux bootstrap.
But the new testcase doesn't trigger any of those new errors, is something
else in the testsuite covering those or do you have some short snippet that
could verify the errors work properly?
> diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
> index 492867e12cb..eaabbffca4d 100644
> --- a/gcc/fortran/simplify.c
> +++ b/gcc/fortran/simplify.c
> @@ -4552,11 +4552,12 @@ substring_has_constant_len (gfc_expr *e)
>
>if (istart <= iend)
> {
> + char buffer[21];
>if (istart < 1)
> {
> - gfc_error ("Substring start index (" HOST_WIDE_INT_PRINT_DEC
> - ") at %L below 1",
> - istart, >u.ss.start->where);
> + sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, istart);
> + gfc_error ("Substring start index (%s) at %L below 1",
> + buffer, >u.ss.start->where);
> return false;
> }
>
> @@ -4567,9 +4568,9 @@ substring_has_constant_len (gfc_expr *e)
> length = gfc_mpz_get_hwi (ref->u.ss.length->length->value.integer);
>if (iend > length)
> {
> - gfc_error ("Substring end index (" HOST_WIDE_INT_PRINT_DEC
> - ") at %L exceeds string length",
> - iend, >u.ss.end->where);
> + sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, iend);
> + gfc_error ("Substring end index (%s) at %L exceeds string length",
> + buffer, >u.ss.end->where);
> return false;
> }
>length = iend - istart + 1;
Jakub
Re: Build problems: mpfr, mpc
Op vr 20 aug. 2021 om 11:54 schreef Richard Biener:
>
>
> The easiest is probably to build them in-tree by means of
> executing ./contrib/download_prerequesites which will download
> and unpack them into your source tree.
>
>
Well, I do have the libraries (source and all) and I copied the built
libraries (that is the content of mpfr/,libs and mpc/.libs to the locations
that are referred to in the link statement, so I assumed that would enable
the linker to find them.
Other than that you are likely either missing some of the requirements
> or lack the appropriate --with-{gmp,mpc,mpfr}[-lib] configury.
>
>
The odd thing is that the link statement as presented in the command window
knows where to find the libraries. Here is the (hopefully) relevant part:
g++ -std=c++11 -no-pie -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall
(...) ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a
-L/cygdrive/d/gfortran/gcc/build-gcc/./gmp/.libs
-L/cygdrive/d/gfortran/gcc/build-gcc/./mpfr/src/.libs
-L/cygdrive/d/gfortran/gcc/build-gcc/./mpc/src/.libs -lmpc -lmpfr -lgmp
-L./../zlib -lz libcommon.a ../libcpp/libcpp.a -liconv
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpc
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpc
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpfr
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpfr
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpc
/usr/lib/gcc/x86_64-pc-cygwin/10/../../../../x86_64-pc-cygwin/bin/ld:
cannot find -lmpfr
What host operating system are you using?
>
> Cygwin on Windows 10
Oops, now that I copied the relevant bit of the link command, I see what I
did wrong: the libraries are under mpfr/./libs, not mpfr/src/.libs (and
ditto for mpc).
Okay, trying again!
Thanks for the reply. This ought to do it.
Regards,
Arjen
Re: [Patch] Fortran: Add OpenMP's error directive (was: [committed] openmp: Implement the error directive)
On Fri, Aug 20, 2021 at 12:00:10PM +0200, Tobias Burnus wrote: > gcc/fortran/ChangeLog: > > * dump-parse-tree.c (show_omp_clauses): Handle 'at', 'severity' > and 'message' clauses. > (show_omp_node, show_code_node): Handle EXEC_OMP_ERROR. > * gfortran.h (gfc_statement): Add ST_OMP_ERROR. > (gfc_omp_severity_type, gfc_omp_at_type): New. > (gfc_omp_clauses): Add 'at', 'severity' and 'message' clause; > use more bitfields + ENUM_BITFIELD. > (gfc_exec_op): Add EXEC_OMP_ERROR. > * match.h (gfc_match_omp_error): New. > * openmp.c (enum omp_mask1): Add OMP_CLAUSE_(AT,SEVERITY,MESSAGE). > (gfc_match_omp_clauses): Handle new clauses. > (OMP_ERROR_CLAUSES, gfc_match_omp_error): New. > (resolve_omp_clauses): Resolve new clauses. > (omp_code_to_statement, gfc_resolve_omp_directive): Handle > EXEC_OMP_ERROR. > * parse.c (decode_omp_directive, next_statement, > gfc_ascii_statement): Handle 'omp error'. > * resolve.c (gfc_resolve_blocks): Likewise. > * st.c (gfc_free_statement): Likewise. > * trans-openmp.c (gfc_trans_omp_error): Likewise. > (gfc_trans_omp_directive): Likewise. > * trans.c (trans_code): Likewise. > > libgomp/ChangeLog: > > * testsuite/libgomp.fortran/error-1.f90: New test. > > gcc/testsuite/ChangeLog: > > * gfortran.dg/gomp/error-1.f90: New test. > * gfortran.dg/gomp/error-2.f90: New test. > * gfortran.dg/gomp/error-3.f90: New test. LGTM, thanks. Jakub
[Patch] Fortran: Add OpenMP's error directive (was: [committed] openmp: Implement the error directive)
Hi Jakub, hi all,
On 20.08.21 11:45, Jakub Jelinek wrote:
This patch implements the error directive. Depending on clauses it is either
a compile time diagnostics (in that case diagnosed right away) or runtime
diagnostics (libgomp API call that diagnoses at runtime),
The attached patch does likewise for Fortran. Compared to yesterday, _()
was replaced by G_().
There are some clarifications in the works ATM, so this patch doesn't yet
require that for compile time diagnostics the user message must be a constant
string literal,[...]
For Fortran, it does require a constant character expression; I think we
did converge on this. With at(execution), it is regarded as execution
expression - otherwise, as it belongs to 'untility' and can be placed
everywhere (ST_NONE).
There is on-going discussion/wordsmithing regarding the PURE restriction
with 'at(compilation)' – currently, it is rejected in pure procedures.
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: Add OpenMP's error directive
Fortran part to the C/C++ implementation of
commit r12-3040-g0d973c0a0d90a0a302e7eda1a4d9709be3c5b102
gcc/fortran/ChangeLog:
* dump-parse-tree.c (show_omp_clauses): Handle 'at', 'severity'
and 'message' clauses.
(show_omp_node, show_code_node): Handle EXEC_OMP_ERROR.
* gfortran.h (gfc_statement): Add ST_OMP_ERROR.
(gfc_omp_severity_type, gfc_omp_at_type): New.
(gfc_omp_clauses): Add 'at', 'severity' and 'message' clause;
use more bitfields + ENUM_BITFIELD.
(gfc_exec_op): Add EXEC_OMP_ERROR.
* match.h (gfc_match_omp_error): New.
* openmp.c (enum omp_mask1): Add OMP_CLAUSE_(AT,SEVERITY,MESSAGE).
(gfc_match_omp_clauses): Handle new clauses.
(OMP_ERROR_CLAUSES, gfc_match_omp_error): New.
(resolve_omp_clauses): Resolve new clauses.
(omp_code_to_statement, gfc_resolve_omp_directive): Handle
EXEC_OMP_ERROR.
* parse.c (decode_omp_directive, next_statement,
gfc_ascii_statement): Handle 'omp error'.
* resolve.c (gfc_resolve_blocks): Likewise.
* st.c (gfc_free_statement): Likewise.
* trans-openmp.c (gfc_trans_omp_error): Likewise.
(gfc_trans_omp_directive): Likewise.
* trans.c (trans_code): Likewise.
libgomp/ChangeLog:
* testsuite/libgomp.fortran/error-1.f90: New test.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/error-1.f90: New test.
* gfortran.dg/gomp/error-2.f90: New test.
* gfortran.dg/gomp/error-3.f90: New test.
gcc/fortran/dump-parse-tree.c | 27 +-
gcc/fortran/gfortran.h| 58
gcc/fortran/match.h | 1 +
gcc/fortran/openmp.c | 124 +-
gcc/fortran/parse.c | 10 ++-
gcc/fortran/resolve.c | 2 +
gcc/fortran/st.c | 1 +
gcc/fortran/trans-openmp.c| 34 +++
gcc/fortran/trans.c | 1 +
gcc/testsuite/gfortran.dg/gomp/error-1.f90| 51 +++
gcc/testsuite/gfortran.dg/gomp/error-2.f90| 15
gcc/testsuite/gfortran.dg/gomp/error-3.f90| 88 ++
libgomp/testsuite/libgomp.fortran/error-1.f90 | 78
13 files changed, 465 insertions(+), 25 deletions(-)
diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index 92d9f9e054d..c75a0a9d095 100644
--- a/gcc/fortran/dump-parse-tree.c
+++ b/gcc/fortran/dump-parse-tree.c
@@ -1908,6 +1908,26 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
fputc (' ', dumpfile);
fputs (memorder, dumpfile);
}
+ if (omp_clauses->at != OMP_AT_UNSET)
+{
+ if (omp_clauses->at != OMP_AT_COMPILATION)
+ fputs (" AT (COMPILATION)", dumpfile);
+ else
+ fputs (" AT (EXECUTION)", dumpfile);
+}
+ if (omp_clauses->severity != OMP_SEVERITY_UNSET)
+{
+ if (omp_clauses->severity != OMP_SEVERITY_FATAL)
+ fputs (" SEVERITY (FATAL)", dumpfile);
+ else
+ fputs (" SEVERITY (WARNING)", dumpfile);
+}
+ if (omp_clauses->message)
+{
+ fputs (" ERROR (", dumpfile);
+ show_expr (omp_clauses->message);
+ fputc (')', dumpfile);
+}
}
/* Show a single OpenMP or OpenACC directive node and everything underneath it
@@ -1950,8 +1970,9 @@ show_omp_node (int level, gfc_code *c)
case EXEC_OMP_DISTRIBUTE_SIMD: name = "DISTRIBUTE SIMD"; break;
case EXEC_OMP_DO: name = "DO"; break;
case EXEC_OMP_DO_SIMD: name = "DO SIMD"; break;
-case EXEC_OMP_LOOP: name = "LOOP"; break;
+case EXEC_OMP_ERROR: name = "ERROR"; break;
case EXEC_OMP_FLUSH: name = "FLUSH"; break;
+case EXEC_OMP_LOOP: name = "LOOP"; break;
case EXEC_OMP_MASKED: name = "MASKED"; break;
case EXEC_OMP_MASKED_TASKLOOP: name = "MASKED TASKLOOP"; break;
case
Re: Build problems: mpfr, mpc
On Fri, Aug 20, 2021 at 9:59 AM Arjen Markus via Fortran
wrote:
>
> I am trying to build the compiler suite to test the two patches Steve Kargl
> posted. But I run into a problem with the mpfr and mpc libraries: the
> linker claims it cannot find them.
>
> I checked this, in fist instance they were not present in the location they
> were assumed to be, but I had copies from an earlier build, so I copied
> them into the location indicated by the -L option. That does not help
> though: same error messages.
>
> How do I solve this?
The easiest is probably to build them in-tree by means of
executing ./contrib/download_prerequesites which will download
and unpack them into your source tree.
Other than that you are likely either missing some of the requirements
or lack the appropriate --with-{gmp,mpc,mpfr}[-lib] configury.
What host operating system are you using?
Richard.
> Regards,
>
> Arjen
Aw: Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514
Hi Jakob,
thanks for the detailed explanation!
> The other much easier but uglier option is to use a temporary buffer:
> char buffer[21];
> sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, hwint_val);
> gfc_error ("... %s ...", ... buffer ...);
> This works, as it uses the host sprintf i.e. *printf family for which
> HOST_WIDE_INT_PRINT_DEC macro is designed.
The attached followup patch implements this.
Can anybody affected by current HEAD confirm that this fixes bootstrap?
Thanks,
Harald
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 492867e12cb..eaabbffca4d 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -4552,11 +4552,12 @@ substring_has_constant_len (gfc_expr *e)
if (istart <= iend)
{
+ char buffer[21];
if (istart < 1)
{
- gfc_error ("Substring start index (" HOST_WIDE_INT_PRINT_DEC
- ") at %L below 1",
- istart, >u.ss.start->where);
+ sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, istart);
+ gfc_error ("Substring start index (%s) at %L below 1",
+ buffer, >u.ss.start->where);
return false;
}
@@ -4567,9 +4568,9 @@ substring_has_constant_len (gfc_expr *e)
length = gfc_mpz_get_hwi (ref->u.ss.length->length->value.integer);
if (iend > length)
{
- gfc_error ("Substring end index (" HOST_WIDE_INT_PRINT_DEC
- ") at %L exceeds string length",
- iend, >u.ss.end->where);
+ sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, iend);
+ gfc_error ("Substring end index (%s) at %L exceeds string length",
+ buffer, >u.ss.end->where);
return false;
}
length = iend - istart + 1;
Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514
On 20.08.21 02:21, H.J. Lu wrote:
This may have broken bootstrap on 32-bit hosts:
https://gcc.gnu.org/pipermail/gcc-regression/2021-August/075209.html
The latter has:
../../src-master/gcc/fortran/simplify.c:4557:22: error: unknown conversion type
character ‘l’ in format [-Werror=format=]
4557 | gfc_error ("Substring start index (" HOST_WIDE_INT_PRINT_DEC
| ^
HOST_WIDE_INT_PRINT_DEC is:
#define HOST_WIDE_INT_PRINT_DEC "%" PRId64
and the latter is something like:
"ld" or "lld"
I fail to see why that shouldn't work – and also building with:
CC="gcc-10 -m32 -fno-lto -O2" CXX="g++-10 -m32 -fno-lto -O2" .../configure
--prefix=... --disable-multilib --disable-libstdcxx-pch --enable-multiarch
--enable-languages=c,c++,fortran --disable-lto
did succeed.
Looking at the format checking:
gfortran.h:void gfc_error (const char *, ...) ATTRIBUTE_GCC_GFC(1,2);
with
gfortran.h:#define ATTRIBUTE_GCC_GFC(m, n) __attribute__ ((__format__
(__gcc_gfc__, m, n))) ATTRIBUTE_NONNULL(m)
I do see that the C/C++ part (which also uses
HOST_WIDE_INT_PRINT_DEC) have some special code
for HWI, which is used for via
init_dynamic_diag_info
contains support for hwi not for gfc_{error,warning} via
init_dynamic_gfc_info
I did wonder whether that causes the differences (→ attached patch).
On the other hand, %ld and %lld are pretty standard – and the
comment in the function talks about %w – which is not used
(except in spec files and in 'go').
Hence: No idea what's the problem or goes wrong.
Maybe the patch is still useful – at least it gives an
error when HWI is neither long nor long long ...
(Build with and without that patch with the options
shown aboved (and 'error:' in stage 1, 2, 3 plus
the usual bootstrap on x86-64.)
Comments?
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
c-family/c-format.c: Support HOST_WIDE_INT in __gcc_gfc__
This patch fixes x86 -m32 builds as gcc/fortran now uses HOST_WIDE_INT
with gfc_error.
gcc/c-family/ChangeLog:
* c-format.c (init_dynamic_diag_hwi): New. Moved from ...
(init_dynamic_diag_info): ... here; call it.
(init_dynamic_gfc_info): Call it.
gcc/c-family/c-format.c | 135 ++--
1 file changed, 74 insertions(+), 61 deletions(-)
diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
index 6fd0bb33d21..1db4fd33dbc 100644
--- a/gcc/c-family/c-format.c
+++ b/gcc/c-family/c-format.c
@@ -4843,12 +4843,85 @@ init_dynamic_asm_fprintf_info (void)
}
}
+/* Called by init_dynamic_gfc_info and init_dynamic_diag_info.
+ Determine the type of "HOST_WIDE_INT" in the code being compiled for
+ use in GCC's diagnostic custom format attributes. You
+ must have set dynamic_format_types before calling this function. */
+static void
+init_dynamic_diag_hwi (void)
+{
+ static tree hwi;
+
+ if (!hwi)
+{
+ static format_length_info *diag_ls;
+ unsigned int i;
+
+ /* Find the underlying type for HOST_WIDE_INT. For the 'w'
+ length modifier to work, one must have issued: "typedef
+ HOST_WIDE_INT __gcc_host_wide_int__;" in one's source code
+ prior to using that modifier. */
+ if ((hwi = maybe_get_identifier ("__gcc_host_wide_int__")))
+ {
+ hwi = identifier_global_value (hwi);
+ if (hwi)
+ {
+ if (TREE_CODE (hwi) != TYPE_DECL)
+ {
+ error ("%<__gcc_host_wide_int__%> is not defined as a type");
+ hwi = 0;
+ }
+ else
+ {
+ hwi = DECL_ORIGINAL_TYPE (hwi);
+ gcc_assert (hwi);
+ if (hwi != long_integer_type_node
+ && hwi != long_long_integer_type_node)
+ {
+ error ("%<__gcc_host_wide_int__%> is not defined"
+ " as % or %");
+ hwi = 0;
+ }
+ }
+ }
+ }
+
+ /* Assign the new data for use. */
+
+ /* All the GCC diag formats use the same length specs. */
+ if (!diag_ls)
+ dynamic_format_types[gcc_diag_format_type].length_char_specs =
+ dynamic_format_types[gcc_tdiag_format_type].length_char_specs =
+ dynamic_format_types[gcc_cdiag_format_type].length_char_specs =
+ dynamic_format_types[gcc_cxxdiag_format_type].length_char_specs =
+ dynamic_format_types[gcc_dump_printf_format_type].length_char_specs =
+ diag_ls = (format_length_info *)
+ xmemdup (gcc_diag_length_specs,
+ sizeof (gcc_diag_length_specs),
+ sizeof (gcc_diag_length_specs));
+ if (hwi)
+ {
+ /* HOST_WIDE_INT must be one of 'long' or 'long long'. */
+ i = find_length_info_modifier_index (diag_ls, 'w');
+ if (hwi == long_integer_type_node)
+ diag_ls[i].index = FMT_LEN_l;
+ else if (hwi == long_long_integer_type_node)
+ diag_ls[i].index = FMT_LEN_ll;
+ else
+ gcc_unreachable ();
+ }
+}
Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514
On Fri, Aug 20, 2021 at 08:48:57AM +0200, Harald Anlauf via Gcc-patches wrote:
> Hi!
>
> > Gesendet: Freitag, 20. August 2021 um 02:21 Uhr
> > Von: "H.J. Lu"
>
> > This may have broken bootstrap on 32-bit hosts:
> >
> > https://gcc.gnu.org/pipermail/gcc-regression/2021-August/075209.html
>
> I do not understand the error message:
>
> ../../src-master/gcc/fortran/simplify.c: In function ‘bool
> substring_has_constant_len(gfc_expr*)’:
> ../../src-master/gcc/fortran/simplify.c:4557:22: error: unknown conversion
> type character ‘l’ in format [-Werror=format=]
> 4557 | gfc_error ("Substring start index (" HOST_WIDE_INT_PRINT_DEC
> | ^
> 4558 | ") at %L below 1",
> | ~
> ../../src-master/gcc/fortran/simplify.c:4557:22: error: format ‘%L’ expects
> argument of type ‘locus*’, but argument 2 has type ‘long long int’
> [-Werror=format=]
> 4557 | gfc_error ("Substring start index (" HOST_WIDE_INT_PRINT_DEC
> | ^
> 4558 | ") at %L below 1",
> | ~
> 4559 | istart, >u.ss.start->where);
> | ~~
> | |
> | long long int
> ../../src-master/gcc/fortran/simplify.c:4557:22: error: too many arguments
> for format [-Werror=format-extra-args]
>
> Is there an issue with HOST_WIDE_INT_PRINT_DEC on 32-bit hosts?
> What is the right way to print a HOST_WIDE_INT?
>
> It works on 64-bit without any warning.
gfc_error etc. aren't *printf family, it has its own format specifier
handling (e.g. it handles %L and %C), and it is even different
from the error/warning handling in middle-end/c-family FEs/backends.
HOST_WIDE_INT_PRINT_DEC is wrong in the above spot for 2 reasons:
1) gfc_error etc. argument is automatically marked for translation
and translated, having a macro in there that expands to various things
depending on host makes it impossible to mark for translation and
a lottery for translation.
2) hwint.h defines:
#define HOST_LONG_FORMAT "l"
#define HOST_LONG_LONG_FORMAT "ll"
#if INT64_T_IS_LONG
# define GCC_PRI64 HOST_LONG_FORMAT
#else
# define GCC_PRI64 HOST_LONG_LONG_FORMAT
#endif
#define PRId64 GCC_PRI64 "d"
#define HOST_WIDE_INT_PRINT_DEC "%" PRId64
but xm-mingw32.h overrides
#define HOST_LONG_LONG_FORMAT "I64"
so effectively HOST_WIDE_INT_PRINT_DEC is "%ld", "%lld" or "%I64d"
Now, gfc_error does handle %d or %ld, but doesn't handle %lld nor
%I64d, so even if the 1) issue didn't exist, this explains why
it works only on some hosts (e.g. x86_64-linux where %ld is used).
But e.g. on i686-linux or many other hosts it is %lld which
gfc_error doesn't handle and on Windows that %I64d.
Now, the non-Fortran FE diagnostic code actually has %wd for this (w
modifier like l modifier), which takes HOST_WIDE_INT/unsigned HOST_WIDE_INT
argument and prints it.
So, either you get through the hops to support that, unfortunately it isn't
just adding support for that in fortran/error.c (error_print) and some
helper functions, which wouldn't be that hard, just add 'w' next to 'l'
handling, TYPE_* for that and union member etc., but one needs to modify
c-family/c-format.c too to register the modifier so that gcc doesn't warn
about it and knows the proper argument type etc.
The other much easier but uglier option is to use a temporary buffer:
char buffer[21];
sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, hwint_val);
gfc_error ("... %s ...", ... buffer ...);
This works, as it uses the host sprintf i.e. *printf family for which
HOST_WIDE_INT_PRINT_DEC macro is designed.
Jakub
Re: [PATCH] libgfortran : Use the libtool macro to determine libm availability.
> On 20 Aug 2021, at 08:52, Tobias Burnus wrote: > > On 20.08.21 09:34, Richard Biener via Fortran wrote: > >> On Thu, Aug 19, 2021 at 10:10 PM Iain Sandoe wrote: >>> libm is not needed on Darwin, and should not be added unconditionally >>> even if that is (mostly) harmless since it is a symlink to libc. >>> >>> tested on x86_64, i686-darwin, x86_64-linux, >>> OK for master? >> OK. >> Richard. > > Looks also good to me – but for completeness and as background, I also > want to remark the following. > > (At least as I understand it, I did not dig deeper.) > >> --- a/libgfortran/configure.ac >> +++ b/libgfortran/configure.ac >> ... >> +AC_CHECK_LIBM > > This CHECK_LIBM has a hard-coded list of targets and for some (like > Darwin) it simply does not set $LIBM. however, it’s one place to make changes (and, probably, I suppose a table is about the only way to do it, reliably)? >>> +++ b/libgfortran/Makefile.am >>> @@ -42,7 +42,7 @@ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS) >>> libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' >>> $(srcdir)/libtool-version` \ >>> $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \ >>> $(HWCAP_LDFLAGS) \ >>> - -lm $(extra_ldflags_libgfortran) \ >>> + $(LIBM) $(extra_ldflags_libgfortran) \ > > I think usage like this one do not actually link '-lm' as > gcc/config/darwin.h contains: > > #define LINK_SPEC \ > ... > %:remove-outfile(-lm) \ right, I have tried to be defensive w.r.t unneeded libs in the Darwin specs, but as you note it doesn’t work for libraries added as infiles… It’s also consistent to use the configure-discovered value, right? > However, this spec change comes too early for: >> --- a/libgfortran/libgfortran.spec.in >> +++ b/libgfortran/libgfortran.spec.in >> @@ -5,4 +5,4 @@ >> # >> >> %rename lib liborig >> -*lib: @LIBQUADSPEC@ -lm %(libgcc) %(liborig) >> +*lib: @LIBQUADSPEC@ @LIBM@ %(libgcc) %(liborig) > NIT: There are two spaces instead of one before @LIBM@. … thanks. > > Thus, it makes sense to the unconditional '-lm' from the .spec file. I’ll hold off committing until this evening in case there are other comments. thanks Iain > > 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
Build problems: mpfr, mpc
I am trying to build the compiler suite to test the two patches Steve Kargl posted. But I run into a problem with the mpfr and mpc libraries: the linker claims it cannot find them. I checked this, in fist instance they were not present in the location they were assumed to be, but I had copies from an earlier build, so I copied them into the location indicated by the -L option. That does not help though: same error messages. How do I solve this? Regards, Arjen
Re: [PATCH] libgfortran : Use the libtool macro to determine libm availability.
On 20.08.21 09:34, Richard Biener via Fortran wrote: On Thu, Aug 19, 2021 at 10:10 PM Iain Sandoe wrote: libm is not needed on Darwin, and should not be added unconditionally even if that is (mostly) harmless since it is a symlink to libc. tested on x86_64, i686-darwin, x86_64-linux, OK for master? OK. Richard. Looks also good to me – but for completeness and as background, I also want to remark the following. (At least as I understand it, I did not dig deeper.) --- a/libgfortran/configure.ac +++ b/libgfortran/configure.ac ... +AC_CHECK_LIBM This CHECK_LIBM has a hard-coded list of targets and for some (like Darwin) it simply does not set $LIBM. +++ b/libgfortran/Makefile.am @@ -42,7 +42,7 @@ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS) libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` \ $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \ $(HWCAP_LDFLAGS) \ - -lm $(extra_ldflags_libgfortran) \ + $(LIBM) $(extra_ldflags_libgfortran) \ I think usage like this one do not actually link '-lm' as gcc/config/darwin.h contains: #define LINK_SPEC \ ... %:remove-outfile(-lm) \ However, this spec change comes too early for: --- a/libgfortran/libgfortran.spec.in +++ b/libgfortran/libgfortran.spec.in @@ -5,4 +5,4 @@ # %rename lib liborig -*lib: @LIBQUADSPEC@ -lm %(libgcc) %(liborig) +*lib: @LIBQUADSPEC@ @LIBM@ %(libgcc) %(liborig) NIT: There are two spaces instead of one before @LIBM@. Thus, it makes sense to the unconditional '-lm' from the .spec file. 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: [PATCH] libgfortran : Use the libtool macro to determine libm availability.
On Thu, Aug 19, 2021 at 10:10 PM Iain Sandoe wrote: > > Hi, > > A while ago had a report of build failure against a Darwin branch on > the latest OS release. This was because (temporarily) the symlink > from libm.dylib => libSystem.dylib had been removed/omitted. > > libm is not needed on Darwin, and should not be added unconditionally > even if that is (mostly) harmless since it is a symlink to libc. > > There could be cases where the addition was not completely harmless > because the presentation of the symlink would cause the symbols exposed > in libSystem to be considered ahead of ones presented in convenience > libraries. > > tested on x86_64, i686-darwin, x86_64-linux, > OK for master? OK. Richard. > thanks > Iain > > libgfortran/ChangeLog: > > * Makefile.am: Use configured libm availability. > * Makefile.in: Regenerate. > * configure: Regenerate. > * configure.ac: Use libtool macro to find libm availability. > * libgfortran.spec.in: Use configured libm availability. > --- > libgfortran/Makefile.am | 2 +- > libgfortran/Makefile.in | 3 +- > libgfortran/configure | 142 > libgfortran/configure.ac| 1 + > libgfortran/libgfortran.spec.in | 2 +- > 5 files changed, 147 insertions(+), 3 deletions(-) > > diff --git a/libgfortran/Makefile.am b/libgfortran/Makefile.am > index 8d104321567..6fc4b465c6e 100644 > --- a/libgfortran/Makefile.am > +++ b/libgfortran/Makefile.am > @@ -42,7 +42,7 @@ libgfortran_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS) > libgfortran_la_LDFLAGS = -version-info `grep -v '^\#' > $(srcdir)/libtool-version` \ > $(LTLDFLAGS) $(LIBQUADLIB) ../libbacktrace/libbacktrace.la \ > $(HWCAP_LDFLAGS) \ > - -lm $(extra_ldflags_libgfortran) \ > + $(LIBM) $(extra_ldflags_libgfortran) \ > $(version_arg) -Wc,-shared-libgcc > libgfortran_la_DEPENDENCIES = $(version_dep) libgfortran.spec > $(LIBQUADLIB_DEP) > > diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac > index 523eb24bca1..513fd80b936 100644 > --- a/libgfortran/configure.ac > +++ b/libgfortran/configure.ac > @@ -260,6 +260,7 @@ AC_PROG_INSTALL > #AC_MSG_NOTICE([== Starting libtool configuration]) > AC_LIBTOOL_DLOPEN > AM_PROG_LIBTOOL > +AC_CHECK_LIBM > ACX_LT_HOST_FLAGS > AC_SUBST(enable_shared) > AC_SUBST(enable_static) > diff --git a/libgfortran/libgfortran.spec.in b/libgfortran/libgfortran.spec.in > index 95aa3f842a3..b870e78c151 100644 > --- a/libgfortran/libgfortran.spec.in > +++ b/libgfortran/libgfortran.spec.in > @@ -5,4 +5,4 @@ > # > > %rename lib liborig > -*lib: @LIBQUADSPEC@ -lm %(libgcc) %(liborig) > +*lib: @LIBQUADSPEC@ @LIBM@ %(libgcc) %(liborig) > -- > 2.24.3 (Apple Git-128) > >
Re: F2018 C937
Yes, I already had arranged for that copyright one and a half years ago, but my first attempts failed (learning curve, real life getting in the way etc.) Op vr 20 aug. 2021 om 08:47 schreef Steve Kargl < s...@troutmask.apl.washington.edu>: > Feel free to ask questions. I forgot to point to > the contributing page > > https://gcc.gnu.org/contribute.html > > At one time, you need to assign copyright to the FSF. > That is no longer required. Scan the above page for > details. > > -- > steve > > On Fri, Aug 20, 2021 at 08:36:42AM +0200, Arjen Markus wrote: > > Hi Steve, > > > > thanks for this detailed workflow. I am familiar enough with git to know > > that there are myriads of procedures possible ;). Like you said, the > first > > three steps have been done. I will get working on step 4 and work my way > > down the list. > > > > Regards, > > > > Arjen > > > > Op do 19 aug. 2021 om 18:23 schreef Steve Kargl < > > s...@troutmask.apl.washington.edu>: > > > > > Arjen, > > > > > > If this is your first go around with patching gfortran, > > > I'll suggest running the testsuite (if you haven't, see > > > step 5. below; if you have see step 6.). I suspect you > > > already know much of what I enumerate below, but it may > > > help others. > > > > > > With a bug report, the workflow for me is/was > > > > > > 1. Check versions of the standard to determine if it is > > >a bug, and what is the expected result. > > > > > > 2. Identify where the problem can be addressed in source. > > > > > >For you (or anyone else interested in gfortran development), > > >I suspect there a lot of question about how to do this > > >step and the structure of the gfortran source code. I can > > >answer some of those questions in follow-up emails. Send > > >them to fortran@ and CC me. > > > > > > 3. Develop patch. > > > > > >I've done the first 3 steps. You are now at testing the patch. > > > > > > 4. Build gfortran with the patch. Assuming a Unix-like system, > > >I have gcc/gccx with the source and gcc/objx is the build > > >directory. So, for a first time build on an N cpu system do > > > > > >% cd gcc/objx > > >% ../gcc/gccx/configure --prefix=$HOME/work/x \ > > > --enable-languages=c,c++,fortran,lto \ > > > --enable-bootstrap --disable-nls --enable-checking > > >% make -j N-1 bootstrap && make install > > > > > >Otherwise, > > > > > >% cd gcc/objx > > >% make -j N-1 && make install > > > > > >This installs everything in $HOME/work/x. > > > > > > 5. Run the testsuite to check for regressions. If any occur, > > >fix regressions or fix the patch. > > > > > >% make -j N-1 check-fortran > > >% tail gcc/testsuite/gfortran/gfortran.sum > > > > > > === gfortran Summary === > > > > > ># of expected passes58647 > > ># of expected failures 253 > > ># of unsupported tests 92 > > >objx/gcc/gfortran version 12.0.0 20210816 (experimental) (GCC) > > > > > >With the C937 and C949 patches, I changed "typespec" to > > >"type-spec" in nearby unrelated error messages. Both are > > >being used and type-spec matches the standard. This may > > >cause a regression, so one or more testcases may need a change. > > >The C937 patch did not cause a regression. The C949 one > > >did. You'll see a line like > > > > > ># of unexpected failures 7 > > > > > >The file gcc/testsuite/gfortran/gfortran.log contains the > > >buildlog, which is huge. You can find the failures with > > >a search for lines containing ^FAIL. > > > > > > 6. Prepare ChangeLog. > > > > > >This has changed with git so you'll need to ask Tobias, > > >Thomas, Harald, or on the gcc@ list for guidance. > > > > > > 7. Submit patch to fortran@gcc and gcc-patches@gcc asking > > >for review. > > > > > > 8. Wait a few days. Ping fortran@gcc and gcc-patches@gcc. > > > > > > 9. Wait a few days. Ping fortran@gcc and gcc-patches@gcc. > > > > > >As I developed, the original patch and presumably you reviewed > > >it for correctness, you can probably skip step 9. > > > > > > 10. Wait a few days. Commit patch with or without a review. > > > > > > I do not know if you need any explicit access/permission to > > > commit a patch. I iknow very little about git and how it > > > works. > > > > > > At this point, you can either backport the patch to release > > > branches or close the PR. For me, I always did a backport > > > if it was a trivial task. At some point, HEAD will diverge > > > sufficiently from a branch, I would then stop backporting. > > > > > > -- > > > steve > > > > > > On Thu, Aug 19, 2021 at 05:10:47PM +0200, Arjen Markus wrote: > > > > I have applied the patches locally (take care to restore the tabs > ;)). > > > > Should I now commit these changes or is there a more formal procedure > > > > involved? > > > > > > > > Regards, > > > > > > > > Arjen > > > > > > > > Op do
Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514
Hi!
> Gesendet: Freitag, 20. August 2021 um 02:21 Uhr
> Von: "H.J. Lu"
> This may have broken bootstrap on 32-bit hosts:
>
> https://gcc.gnu.org/pipermail/gcc-regression/2021-August/075209.html
I do not understand the error message:
../../src-master/gcc/fortran/simplify.c: In function ‘bool
substring_has_constant_len(gfc_expr*)’:
../../src-master/gcc/fortran/simplify.c:4557:22: error: unknown conversion type
character ‘l’ in format [-Werror=format=]
4557 | gfc_error ("Substring start index (" HOST_WIDE_INT_PRINT_DEC
| ^
4558 | ") at %L below 1",
| ~
../../src-master/gcc/fortran/simplify.c:4557:22: error: format ‘%L’ expects
argument of type ‘locus*’, but argument 2 has type ‘long long int’
[-Werror=format=]
4557 | gfc_error ("Substring start index (" HOST_WIDE_INT_PRINT_DEC
| ^
4558 | ") at %L below 1",
| ~
4559 | istart, >u.ss.start->where);
| ~~
| |
| long long int
../../src-master/gcc/fortran/simplify.c:4557:22: error: too many arguments for
format [-Werror=format-extra-args]
Is there an issue with HOST_WIDE_INT_PRINT_DEC on 32-bit hosts?
What is the right way to print a HOST_WIDE_INT?
It works on 64-bit without any warning.
Harald
Re: F2018 C937
Feel free to ask questions. I forgot to point to the contributing page https://gcc.gnu.org/contribute.html At one time, you need to assign copyright to the FSF. That is no longer required. Scan the above page for details. -- steve On Fri, Aug 20, 2021 at 08:36:42AM +0200, Arjen Markus wrote: > Hi Steve, > > thanks for this detailed workflow. I am familiar enough with git to know > that there are myriads of procedures possible ;). Like you said, the first > three steps have been done. I will get working on step 4 and work my way > down the list. > > Regards, > > Arjen > > Op do 19 aug. 2021 om 18:23 schreef Steve Kargl < > s...@troutmask.apl.washington.edu>: > > > Arjen, > > > > If this is your first go around with patching gfortran, > > I'll suggest running the testsuite (if you haven't, see > > step 5. below; if you have see step 6.). I suspect you > > already know much of what I enumerate below, but it may > > help others. > > > > With a bug report, the workflow for me is/was > > > > 1. Check versions of the standard to determine if it is > >a bug, and what is the expected result. > > > > 2. Identify where the problem can be addressed in source. > > > >For you (or anyone else interested in gfortran development), > >I suspect there a lot of question about how to do this > >step and the structure of the gfortran source code. I can > >answer some of those questions in follow-up emails. Send > >them to fortran@ and CC me. > > > > 3. Develop patch. > > > >I've done the first 3 steps. You are now at testing the patch. > > > > 4. Build gfortran with the patch. Assuming a Unix-like system, > >I have gcc/gccx with the source and gcc/objx is the build > >directory. So, for a first time build on an N cpu system do > > > >% cd gcc/objx > >% ../gcc/gccx/configure --prefix=$HOME/work/x \ > > --enable-languages=c,c++,fortran,lto \ > > --enable-bootstrap --disable-nls --enable-checking > >% make -j N-1 bootstrap && make install > > > >Otherwise, > > > >% cd gcc/objx > >% make -j N-1 && make install > > > >This installs everything in $HOME/work/x. > > > > 5. Run the testsuite to check for regressions. If any occur, > >fix regressions or fix the patch. > > > >% make -j N-1 check-fortran > >% tail gcc/testsuite/gfortran/gfortran.sum > > > > === gfortran Summary === > > > ># of expected passes58647 > ># of expected failures 253 > ># of unsupported tests 92 > >objx/gcc/gfortran version 12.0.0 20210816 (experimental) (GCC) > > > >With the C937 and C949 patches, I changed "typespec" to > >"type-spec" in nearby unrelated error messages. Both are > >being used and type-spec matches the standard. This may > >cause a regression, so one or more testcases may need a change. > >The C937 patch did not cause a regression. The C949 one > >did. You'll see a line like > > > ># of unexpected failures 7 > > > >The file gcc/testsuite/gfortran/gfortran.log contains the > >buildlog, which is huge. You can find the failures with > >a search for lines containing ^FAIL. > > > > 6. Prepare ChangeLog. > > > >This has changed with git so you'll need to ask Tobias, > >Thomas, Harald, or on the gcc@ list for guidance. > > > > 7. Submit patch to fortran@gcc and gcc-patches@gcc asking > >for review. > > > > 8. Wait a few days. Ping fortran@gcc and gcc-patches@gcc. > > > > 9. Wait a few days. Ping fortran@gcc and gcc-patches@gcc. > > > >As I developed, the original patch and presumably you reviewed > >it for correctness, you can probably skip step 9. > > > > 10. Wait a few days. Commit patch with or without a review. > > > > I do not know if you need any explicit access/permission to > > commit a patch. I iknow very little about git and how it > > works. > > > > At this point, you can either backport the patch to release > > branches or close the PR. For me, I always did a backport > > if it was a trivial task. At some point, HEAD will diverge > > sufficiently from a branch, I would then stop backporting. > > > > -- > > steve > > > > On Thu, Aug 19, 2021 at 05:10:47PM +0200, Arjen Markus wrote: > > > I have applied the patches locally (take care to restore the tabs ;)). > > > Should I now commit these changes or is there a more formal procedure > > > involved? > > > > > > Regards, > > > > > > Arjen > > > > > > Op do 19 aug. 2021 om 08:59 schreef Arjen Markus < > > arjen.markus...@gmail.com > > > >: > > > > > > > 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>: > > > > >
Re: F2018 C937
Hi Steve, thanks for this detailed workflow. I am familiar enough with git to know that there are myriads of procedures possible ;). Like you said, the first three steps have been done. I will get working on step 4 and work my way down the list. Regards, Arjen Op do 19 aug. 2021 om 18:23 schreef Steve Kargl < s...@troutmask.apl.washington.edu>: > Arjen, > > If this is your first go around with patching gfortran, > I'll suggest running the testsuite (if you haven't, see > step 5. below; if you have see step 6.). I suspect you > already know much of what I enumerate below, but it may > help others. > > With a bug report, the workflow for me is/was > > 1. Check versions of the standard to determine if it is >a bug, and what is the expected result. > > 2. Identify where the problem can be addressed in source. > >For you (or anyone else interested in gfortran development), >I suspect there a lot of question about how to do this >step and the structure of the gfortran source code. I can >answer some of those questions in follow-up emails. Send >them to fortran@ and CC me. > > 3. Develop patch. > >I've done the first 3 steps. You are now at testing the patch. > > 4. Build gfortran with the patch. Assuming a Unix-like system, >I have gcc/gccx with the source and gcc/objx is the build >directory. So, for a first time build on an N cpu system do > >% cd gcc/objx >% ../gcc/gccx/configure --prefix=$HOME/work/x \ > --enable-languages=c,c++,fortran,lto \ > --enable-bootstrap --disable-nls --enable-checking >% make -j N-1 bootstrap && make install > >Otherwise, > >% cd gcc/objx >% make -j N-1 && make install > >This installs everything in $HOME/work/x. > > 5. Run the testsuite to check for regressions. If any occur, >fix regressions or fix the patch. > >% make -j N-1 check-fortran >% tail gcc/testsuite/gfortran/gfortran.sum > > === gfortran Summary === > ># of expected passes58647 ># of expected failures 253 ># of unsupported tests 92 >objx/gcc/gfortran version 12.0.0 20210816 (experimental) (GCC) > >With the C937 and C949 patches, I changed "typespec" to >"type-spec" in nearby unrelated error messages. Both are >being used and type-spec matches the standard. This may >cause a regression, so one or more testcases may need a change. >The C937 patch did not cause a regression. The C949 one >did. You'll see a line like > ># of unexpected failures 7 > >The file gcc/testsuite/gfortran/gfortran.log contains the >buildlog, which is huge. You can find the failures with >a search for lines containing ^FAIL. > > 6. Prepare ChangeLog. > >This has changed with git so you'll need to ask Tobias, >Thomas, Harald, or on the gcc@ list for guidance. > > 7. Submit patch to fortran@gcc and gcc-patches@gcc asking >for review. > > 8. Wait a few days. Ping fortran@gcc and gcc-patches@gcc. > > 9. Wait a few days. Ping fortran@gcc and gcc-patches@gcc. > >As I developed, the original patch and presumably you reviewed >it for correctness, you can probably skip step 9. > > 10. Wait a few days. Commit patch with or without a review. > > I do not know if you need any explicit access/permission to > commit a patch. I iknow very little about git and how it > works. > > At this point, you can either backport the patch to release > branches or close the PR. For me, I always did a backport > if it was a trivial task. At some point, HEAD will diverge > sufficiently from a branch, I would then stop backporting. > > -- > steve > > On Thu, Aug 19, 2021 at 05:10:47PM +0200, Arjen Markus wrote: > > I have applied the patches locally (take care to restore the tabs ;)). > > Should I now commit these changes or is there a more formal procedure > > involved? > > > > Regards, > > > > Arjen > > > > Op do 19 aug. 2021 om 08:59 schreef Arjen Markus < > arjen.markus...@gmail.com > > >: > > > > > 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 >
