[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534
Bug 78534 depends on bug 83344, which changed state.

Bug 83344 Summary: Use of uninitialized memory with ASSOCIATE and strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83344

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #28 from Janne Blomqvist  ---
Author: jb
Date: Thu Feb 22 16:14:21 2018
New Revision: 257903

URL: https://gcc.gnu.org/viewcvs?rev=257903=gcc=rev
Log:
PR 78534, 84509 Fix libgfortran API for PAUSE statement

This patch changes the libgfortran API for the PAUSE statement. By
passing a GFC_INTEGER_8 it handles -fdefault-integer-8, and for the
character version passing the length as a size_t.

Regtested on x86_64-pc-linux-gnu, committed as obvious.

gcc/fortran/ChangeLog:

2018-02-22  Janne Blomqvist  

PR 78534
PR 84509
* trans-decl.c (gfc_build_builtin_function_decls): Pass
gfc_int8_type node to pause_numeric, size_type_node to
pause_string.
* trans-stmt.c (gfc_trans_pause): Likewise.

libgfortran/ChangeLog:

2018-02-22  Janne Blomqvist  

PR 78534
PR 84509
* runtime/pause.c (pause_numeric): Modify to take GFC_INTEGER_8
argument.
(pause_string): Modify to take size_t character length argument.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-stmt.c
trunk/libgfortran/ChangeLog
trunk/libgfortran/runtime/pause.c

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

Janne Blomqvist  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #27 from Janne Blomqvist  ---
Fixed on trunk, closing.

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #26 from Janne Blomqvist  ---
Author: jb
Date: Wed Jan 31 13:23:20 2018
New Revision: 257233

URL: https://gcc.gnu.org/viewcvs?rev=257233=gcc=rev
Log:
PR 78534 Reinstate better string copy algorithm

As part of the change to larger character lengths, the string copy
algorithm was temporarily pessimized to get around some spurious
-Wstringop-overflow warnings.  Having tried a number of variations of
this algorithm I have managed to get it down to one spurious warning,
only with -O1 optimization, in the testsuite.  This patch reinstates
the optimized variant and modifies this one testcase to ignore the
warning.

Regtested on x86_64-pc-linux-gnu.

gcc/fortran/ChangeLog:

2018-01-31  Janne Blomqvist  

PR fortran/78534
* trans-expr.c (fill_with_spaces): Use memset instead of
generating loop.
(gfc_trans_string_copy): Improve opportunity to use builtins with
constant lengths.

gcc/testsuite/ChangeLog:

2018-01-31  Janne Blomqvist  

PR fortran/78534
* gfortran.dg/allocate_deferred_char_scalar_1.f03: Prune
-Wstringop-overflow warnings due to spurious warning with -O1.
* gfortran.dg/char_cast_1.f90: Update dump scan pattern.
* gfortran.dg/transfer_intrinsic_1.f90: Likewise.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
trunk/gcc/testsuite/gfortran.dg/char_cast_1.f90
trunk/gcc/testsuite/gfortran.dg/transfer_intrinsic_1.f90

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #25 from Janne Blomqvist  ---
Author: jb
Date: Mon Jan 22 13:31:08 2018
New Revision: 256944

URL: https://gcc.gnu.org/viewcvs?rev=256944=gcc=rev
Log:
PR 78534, 83704 Large character lengths

This patch fixes various parts of the code to use a larger type than
int for the character length. Depending on the situation,
HOST_WIDE_INT, size_t, or gfc_charlen_t is appropriate.

Regtested on x86_64-pc-linux-gnu and i686-pc-linux-gnu.

gcc/fortran/ChangeLog:

2018-01-22  Janne Blomqvist  

PR 78534
PR 83704
* arith.c (gfc_arith_concat): Use size_t for string length.
(gfc_compare_string): Likewise.
(gfc_compare_with_Cstring): Likewise.
* array.c (gfc_resolve_character_array_constructor): Use
HOST_WIDE_INT, gfc_mpz_get_hwi.
* check.c (gfc_check_fe_runtime_error): Use size_t.
* data.c (create_character_initializer): Use HOST_WIDE_INT,
gfc_extract_hwi.
* decl.c (gfc_set_constant_character_len): Use gfc_charlen_t.
(add_init_expr_to_sym): Use HOST_WIDE_INT.
* expr.c (gfc_build_init_expr): Use HOST_WIDE_INT,
gfc_extract_hwi.
(gfc_apply_init): Likewise.
* match.h (gfc_set_constant_character_len): Update prototype.
* primary.c (match_string_constant): Use size_t.
* resolve.c (resolve_ordinary_assign): Use HOST_WIDE_INT,
gfc_mpz_get_hwi.
* simplify.c (init_result_expr): Likewise.
(gfc_simplify_len_trim): Use size_t.
* target-memory.c (gfc_encode_character): Use size_t.
(gfc_target_encode_expr): Use HOST_WIDE_INT, gfc_mpz_get_hwi.
(interpret_array): Use size_t.
(gfc_interpret_character): Likewise.
* target-memory.h (gfc_encode_character): Update prototype.
(gfc_interpret_character): Likewise.
(gfc_target_interpret_expr): Likewise.
* trans-const.c (gfc_build_string_const): Use size_t for length
argument.
(gfc_build_wide_string_const): Likewise.
* trans-const.h (gfc_build_string_const): Likewise.
(gfc_build_wide_string_const): Likewise.

2018-01-22  Janne Blomqvist  

PR 78534
PR 83704
* gfortran.dg/string_1.f90: Remove printing the length.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/arith.c
trunk/gcc/fortran/array.c
trunk/gcc/fortran/check.c
trunk/gcc/fortran/data.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/match.h
trunk/gcc/fortran/primary.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/simplify.c
trunk/gcc/fortran/target-memory.c
trunk/gcc/fortran/target-memory.h
trunk/gcc/fortran/trans-const.c
trunk/gcc/fortran/trans-const.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/string_1.f90

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #24 from Janne Blomqvist  ---
Author: jb
Date: Mon Jan  8 12:12:05 2018
New Revision: 256337

URL: https://gcc.gnu.org/viewcvs?rev=256337=gcc=rev
Log:
PR 78534 Regression on 32-bit targets

By switching from int to size_t in order to handle larger values,
r256322 introduced a bug that manifested itself on 32-bit
targets. Fixed by using the correct type to store the result of a
next_array_record call.

Regtested on x86_64-pc-linux-gnu and i686-pc-linux-gnu, committed to
trunk as obvious.

libgfortran/ChangeLog:

2018-01-08  Janne Blomqvist  

PR 78534, bugfix for r256322
* io/transfer.c (next_record_w): Use correct type for return value
of next_array_record.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #23 from Janne Blomqvist  ---
Author: jb
Date: Sun Jan  7 10:17:52 2018
New Revision: 256322

URL: https://gcc.gnu.org/viewcvs?rev=256322=gcc=rev
Log:
PR 78534, 83704 Handle large formatted I/O

In order to handle large characters when doing formatted I/O, use
size_t and ptrdiff_t for lengths.  Compared to the previous patch,
based on discussions on IRC use size_t for sizes that don't need to be
negative rather than ptrdiff_t everywhere.

Regtested on x86_64-pc-linux-gnu, approved as part of the PR 78534
approval, committed to trunk.

libgfortran/ChangeLog:

2018-01-07  Janne Blomqvist  

PR fortran/78534
PR fortran/83704
* io/fbuf.c (fbuf_init): Use size_t instead of int for length.
(fbuf_debug): Convert debug output to unsigned long.
(fbuf_reset): Use ptrdiff_t for return value.
(fbuf_alloc): Use size_t for length argument.
(fbuf_flush): Handle large buffers.
(fbuf_flush_list): Likewise.
(fbuf_seek): Use ptrdiff_t for offset and return value.
(fbuf_read): Use size_t for length argument.
(fbuf_getc_refill): Use size_t to match fbuf_read.
* io/fbuf.h (struct fbuf): Use size_t for lengths.
(fbuf_init): Use size_t instead of int for length.
(fbuf_reset): Use ptrdiff_t for return value.
(fbuf_alloc): Use size_t for length argument.
(fbuf_seek): Use ptrdiff_t for offset and return value.
(fbuf_read): Use size_t for length argument.
* io/io.h (read_block_form): Likewise.
(read_block_form4): Likewise.
(write_block): Likewise.
(read_a): Likewise.
(read_a_char4): Likewise.
(read_x): Likewise.
(write_a): Likewise.
(write_a_char4): Likewise.
* io/list_read.c (list_formatted_read_scalar): Use size_t to
handle large buffers.
* io/read.c (read_l): Likewise.
(read_utf8): Likewise.
(read_utf8_char1): Likewise.
(read_default_char1): Likewise.
(read_utf8_char4): Likewise.
(read_default_char4): Likewise.
(read_a): Likewise.
(read_a_char4): Likewise.
(eat_leading_spaces): Likewise.
(next_char): Likewise.
(read_decimal): Likewise.
(read_radix): Likewise.
(read_f): Likewise.
(read_x): Likewise.
* io/transfer.c (read_sf_internal): Likewise.
(read_sf): Likewise.
(read_block_form): Likewise.
(read_block_form4): Likewise.
(write_block): Likewise.
(formatted_transfer_scalar_write): Likewise.
(next_record_w): Likewise.
* io/unix.c (mem_alloc_r): Likewise.
(mem_alloc_r4): Likewise.
(mem_alloc_w): Likewise.
(mem_alloc_w4): Likewise.
(mem_read): Likewise.
(mem_read4): Likewise.
(mem_write): Likewise.
(mem_write4): Likewise.
(open_internal): Likewise.
(open_internal4): Likewise.
* io/unix.h (open_internal): Likewise.
(open_internal4): Likewise.
(mem_alloc_w): Likewise.
(mem_alloc_r): Likewise.
(mem_alloc_w4): Likewise.
(mem_alloc_r4): Likewise.
* io/write.c (write_check_cc): Likewise.
(write_cc): Likewise.
(write_a): Likewise.
(write_a_char4): Likewise.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/fbuf.c
trunk/libgfortran/io/fbuf.h
trunk/libgfortran/io/io.h
trunk/libgfortran/io/list_read.c
trunk/libgfortran/io/read.c
trunk/libgfortran/io/transfer.c
trunk/libgfortran/io/unix.c
trunk/libgfortran/io/unix.h
trunk/libgfortran/io/write.c

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #22 from Janne Blomqvist  ---
Author: jb
Date: Sat Jan  6 10:42:57 2018
New Revision: 256311

URL: https://gcc.gnu.org/viewcvs?rev=256311=gcc=rev
Log:
PR 78534 libgfortran ChangeLog

The libgfortran/ChangeLog entry was accidentally not included in
r256284.

Modified:
trunk/libgfortran/ChangeLog

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #21 from Jerry DeLisle  ---
Regrssion tested on x86_64-pc-freeBSD, no failures

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #20 from Janne Blomqvist  ---
Author: jb
Date: Fri Jan  5 19:01:12 2018
New Revision: 256284

URL: https://gcc.gnu.org/viewcvs?rev=256284=gcc=rev
Log:
PR 78534 Change character length from int to size_t

In order to handle large character lengths on (L)LP64 targets, switch
the GFortran character length from an int to a size_t.

This is an ABI change, as procedures with character arguments take
hidden arguments with the character length.

I also changed the _size member in vtables from int to size_t, as
there were some cases where character lengths and sizes were
apparently mixed up and caused regressions otherwise. Although I
haven't tested, this might enable very large derived types as well.

Also, as there are some places in the frontend were negative character
lengths are used as special flag values, in the frontend the character
length is handled as a signed variable of the same size as a size_t,
although in the runtime library it really is size_t.

I haven't changed the character length variables for the co-array
intrinsics, as this is something that may need to be synchronized with
OpenCoarrays.

This is v5 of the patch. v4 was applied but caused breakage on big
endian targets. These have been fixed and tested, thanks to access to
the GCC compile farm.

Overview of v4 of the patch: v3 was applied but had to reverted due to
breaking bootstrap. The fix is in resolve.c:resolve_charlen, where
it's necessary to check that an expression is constant before using
mpz_sgn.

Overview of v3 of the patch: All the issues pointed out by FX's review
of v2 have been fixed. In particular, there are now new functions
gfc_mpz_get_hwi and gfc_mpz_set_hwi, similar to the GMP functions
mpz_get_si and mpz_set_si, except that they get/set a HOST_WIDE_INT
instead of a long value. Similarly, gfc_get_int_expr now takes a
HOST_WIDE_INT instead of a long, gfc_extract_long is replaced by
gfc_extract_hwi. Also, the preliminary work to handle
gfc_charlen_type_node being unsigned has been removed.

Regtested on x86_64-pc-linux-gnu, i686-pc-linux-gnu and
powerpc64-unknown-linux-gnu. Also regtested all three targets by
modifying gfortran-dg.exp to also test with "-g -flto", no new
failures observed.

frontend:

2018-01-05  Janne Blomqvist  

PR fortran/78534
PR fortran/66310
* array.c (got_charlen): Use gfc_charlen_int_kind.
* class.c (gfc_find_derived_vtab): Use gfc_size_kind instead of
hardcoded kind.
(find_intrinsic_vtab): Likewise.
* decl.c (match_char_length): Use gfc_charlen_int_kind.
(add_init_expr_to_sym): Use gfc_charlen_t and gfc_charlen_int_kind.
(gfc_match_implicit): Use gfc_charlen_int_kind.
* dump-parse-tree.c (show_char_const): Use gfc_charlen_t and size_t.
(show_expr): Use HOST_WIDE_INT_PRINT_DEC.
* expr.c (gfc_get_character_expr): Length parameter of type
gfc_charlen_t.
(gfc_get_int_expr): Value argument of type HOST_WIDE_INT.
(gfc_extract_hwi): New function.
(simplify_const_ref): Make string_len of type gfc_charlen_t.
(gfc_simplify_expr): Use HOST_WIDE_INT for substring refs.
* frontend-passes.c (optimize_trim): Use gfc_charlen_int_kind.
* gfortran.h (gfc_mpz_get_hwi): New prototype.
(gfc_mpz_set_hwi): Likewise.
(gfc_charlen_t): New typedef.
(gfc_expr): Use gfc_charlen_t for character lengths.
(gfc_size_kind): New extern variable.
(gfc_extract_hwi): New prototype.
(gfc_get_character_expr): Use gfc_charlen_t for character length.
(gfc_get_int_expr): Use HOST_WIDE_INT type for value argument.
* gfortran.texi: Update description of hidden string length argument.
* iresolve.c (check_charlen_present): Use gfc_charlen_int_kind.
(gfc_resolve_char_achar): Likewise.
(gfc_resolve_repeat): Pass string length directly without
temporary, use gfc_charlen_int_kind.
(gfc_resolve_transfer): Use gfc_charlen_int_kind.
* match.c (select_intrinsic_set_tmp): Use HOST_WIDE_INT for charlen.
* misc.c (gfc_mpz_get_hwi): New function.
(gfc_mpz_set_hwi): New function.
* module.c (atom_int): Change type from int to HOST_WIDE_INT.
(parse_integer): Don't complain about large integers.
(write_atom): Use HOST_WIDE_INT for integers.
(mio_integer): Handle integer type mismatch.
(mio_hwi): New function.
(mio_intrinsic_op): Use HOST_WIDE_INT.
(mio_array_ref): Likewise.
(mio_expr): Likewise.
* primary.c (match_substring): Use gfc_charlen_int_kind.
* resolve.c (resolve_substring_charlen): Use gfc_charlen_int_kind.
(resolve_character_operator): Likewise.
(resolve_assoc_var): Likewise.
(resolve_select_type): Use HOST_WIDE_INT for charlen, use snprintf.
(resolve_charlen): Use mpz_sgn to 

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

Janne Blomqvist  changed:

   What|Removed |Added

 Depends on||83344

--- Comment #19 from Janne Blomqvist  ---
It seems that PR 83344 makes my patch changing the character length to fail on
big endian targets.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83344
[Bug 83344] Use of uninitialized memory with ASSOCIATE and strings

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #18 from Janne Blomqvist  ---
Author: jb
Date: Fri Jan 13 17:05:48 2017
New Revision: 28

URL: https://gcc.gnu.org/viewcvs?rev=28=gcc=rev
Log:
PR 78534 Change character length from int to size_t

In order to handle large character lengths on (L)LP64 targets, switch
the GFortran character length from an int to a size_t.

This is an ABI change, as procedures with character arguments take
hidden arguments with the character length.

I also changed the _size member in vtables from int to size_t, as
there were some cases where character lengths and sizes were
apparently mixed up and caused regressions otherwise. Although I
haven't tested, this might enable very large derived types as well.

Also, as there are some places in the frontend were negative character
lengths are used as special flag values, in the frontend the character
length is handled as a signed variable of the same size as a size_t,
although in the runtime library it really is size_t.

I haven't changed the character length variables for the co-array
intrinsics, as this is something that may need to be synchronized with
OpenCoarrays.

This is v4 of the patch. v3 was applied but had to reverted due to
breaking bootstrap. The fix is in resolve.c:resolve_charlen, where
it's necessary to check that an expression is constant before using
mpz_sgn.

Overview of v3 of the patch: All the issues pointed out by FX's review
of v2 have been fixed. In particular, there are now new functions
gfc_mpz_get_hwi and gfc_mpz_set_hwi, similar to the GMP functions
mpz_get_si and mpz_set_si, except that they get/set a HOST_WIDE_INT
instead of a long value. Similarly, gfc_get_int_expr now takes a
HOST_WIDE_INT instead of a long, gfc_extract_long is replaced by
gfc_extract_hwi. Also, the preliminary work to handle
gfc_charlen_type_node being unsigned has been removed.

Regtested on x86_64-pc-linux-gnu and i686-pc-linux-gnu.

frontend:

2017-01-13  Janne Blomqvist  

PR fortran/78534
PR fortran/66310
* class.c (gfc_find_derived_vtab): Use gfc_size_kind instead of
hardcoded kind.
(find_intrinsic_vtab): Likewise.
* expr.c (gfc_get_character_expr): Length parameter of type
gfc_charlen_t.
(gfc_get_int_expr): Value argument of type HOST_WIDE_INT.
(gfc_extract_hwi): New function.
(simplify_const_ref): Make string_len of type gfc_charlen_t.
(gfc_simplify_expr): Use HOST_WIDE_INT for substring refs.
* gfortran.h (gfc_mpz_get_hwi): New prototype.
(gfc_mpz_set_hwi): Likewise.
(gfc_charlen_t): New typedef.
(gfc_expr): Use gfc_charlen_t for character lengths.
(gfc_size_kind): New extern variable.
(gfc_extract_hwi): New prototype.
(gfc_get_character_expr): Use gfc_charlen_t for character length.
(gfc_get_int_expr): Use HOST_WIDE_INT type for value argument.
* iresolve.c (gfc_resolve_repeat): Pass string length directly without
temporary, use gfc_charlen_int_kind.
* match.c (select_intrinsic_set_tmp): Use HOST_WIDE_INT for charlen.
* misc.c (gfc_mpz_get_hwi): New function.
(gfc_mpz_set_hwi): New function.
* module.c (atom_int): Change type from int to HOST_WIDE_INT.
(parse_integer): Don't complain about large integers.
(write_atom): Use HOST_WIDE_INT for integers.
(mio_integer): Handle integer type mismatch.
(mio_hwi): New function.
(mio_intrinsic_op): Use HOST_WIDE_INT.
(mio_array_ref): Likewise.
(mio_expr): Likewise.
* resolve.c (resolve_select_type): Use HOST_WIDE_INT for charlen,
use snprintf.
(resolve_substring_charlen): Use gfc_charlen_int_kind.
(resolve_charlen): Use mpz_sgn to determine sign.
* simplify.c (gfc_simplify_repeat): Use HOST_WIDE_INT/gfc_charlen_t
instead of long.
* target-memory.c (size_character): Length argument of type
gfc_charlen_t.
(gfc_encode_character): Likewise.
(gfc_interpret_character): Use gfc_charlen_t.
* target-memory.h (gfc_encode_character): Modify prototype.
* trans-array.c (get_array_ctor_var_strlen): Use
gfc_conv_mpz_to_tree_type.
* trans-const.c (gfc_conv_mpz_to_tree_type): New function.
* trans-const.h (gfc_conv_mpz_to_tree_type): New prototype.
* trans-expr.c (gfc_class_len_or_zero_get): Build const of type
gfc_charlen_type_node.
(gfc_conv_intrinsic_to_class): Use gfc_charlen_int_kind instead of
4, fold_convert to correct type.
(gfc_conv_class_to_class): Build const of type size_type_node for
size.
(gfc_copy_class_to_class): Likewise.
(gfc_conv_string_length): Use same type in expression.
(gfc_conv_substring): Likewise, use HOST_WIDE_INT for charlen.
(gfc_conv_string_tmp): Make sure len is of the right type.
 

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #17 from Janne Blomqvist  ---
Author: jb
Date: Wed Jan  4 08:06:54 2017
New Revision: 244048

URL: https://gcc.gnu.org/viewcvs?rev=244048=gcc=rev
Log:
PR 78796 Modify testcases due to gfc_trans_string_copy change

As r244011 had to be reverted, this change adds back the testcase
changes that are needed due to r244003.

2017-01-04  Janne Blomqvist  

PR fortran/78534
PR fortran/78976
* gfortran.dg/dependency_49.f90: Change scan-tree-dump-times
due to gfc_trans_string_copy change to avoid -Wstringop-overflow.
* gfortran.dg/transfer_intrinsic_1.f90: Change
scan-tree-dump-times due to gfc_trans_string_copy change to
avoid -Wstringop-overflow.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dependency_49.f90
trunk/gcc/testsuite/gfortran.dg/transfer_intrinsic_1.f90

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #16 from Janne Blomqvist  ---
Author: jb
Date: Tue Jan  3 18:01:30 2017
New Revision: 244027

URL: https://gcc.gnu.org/viewcvs?rev=244027=gcc=rev
Log:
PR 78534 Revert r244011

r244011 caused regressions on 32-bit hosts.

Removed:
trunk/gcc/testsuite/gfortran.dg/repeat_7.f90
trunk/gcc/testsuite/gfortran.dg/string_1_lp64.f90
trunk/gcc/testsuite/gfortran.dg/string_3_lp64.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/dump-parse-tree.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/gfortran.texi
trunk/gcc/fortran/iresolve.c
trunk/gcc/fortran/match.c
trunk/gcc/fortran/misc.c
trunk/gcc/fortran/module.c
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/simplify.c
trunk/gcc/fortran/target-memory.c
trunk/gcc/fortran/target-memory.h
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-const.c
trunk/gcc/fortran/trans-const.h
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-intrinsic.c
trunk/gcc/fortran/trans-io.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/fortran/trans-types.c
trunk/gcc/fortran/trans-types.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dependency_49.f90
trunk/gcc/testsuite/gfortran.dg/repeat_4.f90
trunk/gcc/testsuite/gfortran.dg/scan_2.f90
trunk/gcc/testsuite/gfortran.dg/string_1.f90
trunk/gcc/testsuite/gfortran.dg/string_3.f90
trunk/gcc/testsuite/gfortran.dg/transfer_intrinsic_1.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/args.c
trunk/libgfortran/intrinsics/chmod.c
trunk/libgfortran/intrinsics/env.c
trunk/libgfortran/intrinsics/extends_type_of.c
trunk/libgfortran/intrinsics/gerror.c
trunk/libgfortran/intrinsics/getlog.c
trunk/libgfortran/intrinsics/hostnm.c
trunk/libgfortran/intrinsics/string_intrinsics_inc.c
trunk/libgfortran/io/transfer.c
trunk/libgfortran/io/unit.c
trunk/libgfortran/io/write.c
trunk/libgfortran/libgfortran.h

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #14 from Janne Blomqvist  ---
Author: jb
Date: Mon Jan  2 20:00:18 2017
New Revision: 244003

URL: https://gcc.gnu.org/viewcvs?rev=244003=gcc=rev
Log:
PR 78534 Modify string copy to avoid -Wstringop-overflow warning

When the character length is changed from int to size_t the existing
algorithm causes a -Wstringop-overflow warning with -O1 on the
gfortran.dg/allocate_deferred_char_scalar_1.f03 testcase. This change
is committed separately from the character length size change in order
to make bisecting potential performance issues easier.

2017-01-02  Janne Blomqvist  

PR fortran/78534
* trans-expr.c (gfc_trans_string_copy): Rework string copy
algorithm to avoid -Wstringop-overflow warning.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #13 from Jerry DeLisle  ---
Note: PR66310 is a related issue.

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

Janne Blomqvist  changed:

   What|Removed |Added

  Attachment #40154|0   |1
is obsolete||

--- Comment #12 from Janne Blomqvist  ---
Created attachment 40243
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40243=edit
Updated patch

Updated patch with a few more improvements. Still fails the char_result_8.f90
testcase with -O1, though.

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #11 from Janne Blomqvist  ---
(In reply to Dominique d'Humieres from comment #10)
> BTW did you test the patch in comment 4 with -m32?

No, though I did test by reverting the few lines changing the definitions of
gfc_charlen_type_node and gfc_charlen_t. The rest of the patch (i.e. the vast
majority) deals with fixing situations where we accidentally have used the
wrong types and it happened to work because the character length and plain
integer were the same thing. So this test showed that the patch didn't break
anything else.

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #10 from Dominique d'Humieres  ---
BTW did you test the patch in comment 4 with -m32?

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #9 from Janne Blomqvist  ---
(In reply to Dominique d'Humieres from comment #8)
> Will it help for pr66310?

Probably yes, to the extent that with 64-bit indices the repeat count can be a
lot larger than you can afford to buy RAM. :)

I ran into a similar issues as in that PR, and put in an arbitrary limit in the
frontend simplicitation function of 4 MB.

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #8 from Dominique d'Humieres  ---
Will it help for pr66310?

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #7 from Janne Blomqvist  ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Janne Blomqvist from comment #5)
> > (In reply to Jakub Jelinek from comment #2)
> > > So are you going to do everything that is in the wiki (or most of it)?
> > > Also, I couldn't find in the list, I think some descriptor changes were
> > > considered (to use 15 dimensions instead of 7, etc.).
> > 
> > The array descriptor changes are on the fortran-dev branch, which apparently
> > isn't ready for merging yet. So it seems we'll bump the ABI both for GCC 7
> > and for GCC 8.. :(
> 
> Which exact change broke the ABI, couldn't it be adjusted to be backwards
> ABI compatible and do the full ABI break in GCC 8?

It was the DTIO (derived type I/O) stuff (which certainly is a major feature,
so I'm not suggesting that it should be backed out). Subsequently there has
AFAICS been other patches that have changed the ABI too, IIRC the DEC
compatibility stuff at least.

I tried to suggest trying to fix it here:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01987.html . But nobody (except
me, apparently?) took it seriously, and with me having extremely limited time
for GFortran these days, it seems we'll have an ABI break for both GCC 7 and 8.

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #6 from Jakub Jelinek  ---
(In reply to Janne Blomqvist from comment #5)
> (In reply to Jakub Jelinek from comment #2)
> > So are you going to do everything that is in the wiki (or most of it)?
> > Also, I couldn't find in the list, I think some descriptor changes were
> > considered (to use 15 dimensions instead of 7, etc.).
> 
> The array descriptor changes are on the fortran-dev branch, which apparently
> isn't ready for merging yet. So it seems we'll bump the ABI both for GCC 7
> and for GCC 8.. :(

Which exact change broke the ABI, couldn't it be adjusted to be backwards ABI
compatible and do the full ABI break in GCC 8?

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #5 from Janne Blomqvist  ---
(In reply to Jakub Jelinek from comment #2)
> So are you going to do everything that is in the wiki (or most of it)?
> Also, I couldn't find in the list, I think some descriptor changes were
> considered (to use 15 dimensions instead of 7, etc.).

The array descriptor changes are on the fortran-dev branch, which apparently
isn't ready for merging yet. So it seems we'll bump the ABI both for GCC 7 and
for GCC 8.. :(

The plan was to do all the changes at once so we don't have to bump the ABI
many times, but it was accidentally broken for GCC 7 before fortran-dev was
ready.

As for the rest of the list, we'll see. I don't have that much time myself, but
maybe if the other maintainers would take an interest.

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

--- Comment #4 from Janne Blomqvist  ---
Created attachment 40154
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40154=edit
Preliminary patch

Preliminary patch changing gfc_charlen_t from int to ptrdiff_t. Fails the
char_result_8.f90 testcase.

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

Janne Blomqvist  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jb at gcc dot gnu.org

--- Comment #3 from Janne Blomqvist  ---
(In reply to Jerry DeLisle from comment #1)
> (In reply to Janne Blomqvist from comment #0)
> > Currently GFortran uses a plain C int for character lengths. This prevents
> > longer characters on 64-bit targets. We should change to use size_t instead,
> > similar to the C string functions (str*(), mem*()), malloc(), etc. Also
> > Intel Fortran does this nowadays.
> > 
> > Now that the libgfortran ABI version has been bumped, it is the right time
> > to do this.
> > 
> > See also https://gcc.gnu.org/wiki/LibgfortranAbiCleanup
> 
> Agree, Are you going to do this?

I'm working on a patch. I have managed to make it work except for the
char_result_8.f90 testcase, which fails with an internal compiler error in the
middle end when optimization is enabled. So it seems I'm passing the middle-end
some nonsensical data.

Also the patch so far changes the charlen type to ptrdiff_t, there are some
places in the frontend where we use a negative charlen as a flag value. I
though I'd get the size change working first before tackling the
signed->unsigned change.

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
So are you going to do everything that is in the wiki (or most of it)?
Also, I couldn't find in the list, I think some descriptor changes were
considered (to use 15 dimensions instead of 7, etc.).

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-25
 CC||jvdelisle at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jerry DeLisle  ---
(In reply to Janne Blomqvist from comment #0)
> Currently GFortran uses a plain C int for character lengths. This prevents
> longer characters on 64-bit targets. We should change to use size_t instead,
> similar to the C string functions (str*(), mem*()), malloc(), etc. Also
> Intel Fortran does this nowadays.
> 
> Now that the libgfortran ABI version has been bumped, it is the right time
> to do this.
> 
> See also https://gcc.gnu.org/wiki/LibgfortranAbiCleanup

Agree, Are you going to do this?