[Bug rtl-optimization/98425] Superfluous sign-extend for constrained integer

[koenigni at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Nicolas Koenig  ---
The advantage of using mov over movs for known-positive integers would be that
32bit moves are also move-eliminated, while movs always has to be executed.

[Bug rtl-optimization/98425] New: Superfluous sign-extend for constrained integer

[koenigni at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 98425
   Summary: Superfluous sign-extend for constrained integer
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: koenigni at gcc dot gnu.org
  Target Milestone: ---

Hello everyone,

A small missed optimization I noticed while toying around with the difference
between signed and unsigned integers. The following code

int
baz(int *p, int i) {
  int j;
  if (i >= 0) {
j = i + 4;
return p[j];
  } else
__builtin_unreachable();
}

is compiled with `gcc -O3 -S` to

baz:
  addl  $4, %esi
  movslq  %esi, %rsi
  movl  (%rdi,%rsi,4), %eax
  ret

The movslq instruction is unnecessary since i is constrained to never be
negative and therefore no sign extension is needed. This probably also prevents
the addl instructions to be removed and the offset being put into the movl. 

For comparison, clang (with the same options) compiles the code to 

baz:
  movl %esi, %eax
  movl 16(%rdi, %rax, 4), %eax
  ret

Optimal would probably be

baz:
  movl 16(%rdi, %rsi, 4), %eax
  ret

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

  Attachment #46714|0   |1
is obsolete||

--- Comment #18 from Nicolas Koenig  ---
Created attachment 46723
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46723=edit
Compiler Diff

I accidentally attached an old patch, here is the right one :) And thanks for
helping, Jerry, what will you be working on?

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

--- Comment #14 from Nicolas Koenig  ---
Created attachment 46715
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46715=edit
Library Diff

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

  Attachment #45669|0   |1
is obsolete||

--- Comment #13 from Nicolas Koenig  ---
Created attachment 46714
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46714=edit
Compiler Diff

Yes, I'm still working on it (slowly, though, sorry :( ). Here is a diff of my
current trunk. I don't know what exactly changed since the last version, but
the biggest two things still missing are actually deallocating coarrays in
DEALLOCATE-statements or in types and all the intrinsics like CO_SUM. Locks
already work, though.

Here's an approximate list of features already in the patch (based on the test
cases I have lying around):

- coarray accesses (both implicit `ca` and explicit `ca[1]`)
- this_image/num_images (retrieving image numbers only, no arguments)
- statically allocated arrays
- dynamically allocated arrays
- syncing (SYNC ALL and SYNC IMAGES)
- locking (LOCK_TYPE)

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

  Attachment #45536|0   |1
is obsolete||

--- Comment #11 from Nicolas Koenig  ---
Created attachment 45670
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45670=edit
library v2

Here is the new version of the library. They should really add the ability to
attach more than one file. I will ask the mailing list about integration with
libgfortran.

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

  Attachment #45535|0   |1
is obsolete||

--- Comment #10 from Nicolas Koenig  ---
Created attachment 45669
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45669=edit
Proof-of-concept v2

Also, here is an updated version that adds (preliminary) support for implicit
coarray accesses and coarrays in modules as well as fixing some bugs in the old
one. It is now capable of compiling and running the following simple test:

module co
  integer:: a[*]
end module

program main
  use co, only: a
  implicit none
  a[next_image()] = this_image()
  sync all
  print *, 'Hi from', a, 'to', this_image()
contains
  function next_image()
integer:: next_image
next_image = mod(this_image(), num_images()) + 1
  end function
end program

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

--- Comment #9 from Nicolas Koenig  ---
Sorry for the late reply, there was a sad incidence with my laptop and ice
cream :D

(In reply to Damian Rouson from comment #8)
> (In reply to Nicolas Koenig from comment #7)
> 
> > I actually opted to use multiprocessing with shared memory (shm_open() & co)
> > instead of multithreading, since it will be much easier and faster with
> > static variables, of which gfortran makes extensive use. Also, it greatly
> > simplifies interoperability with OpenMP. 
> 
> This sounds like a great choice.  I have no prior familiarity with
> shm_open(),
> but I very much like the idea of simplifying interoperability with OpenMP. 
> 
> > The only real downsides I can think of are slower spinup times... 
> 
> It will be interesting to compare the performance with MPI.  I also wonder if
> this would also someday provide for a hybrid implementation wherein
> shm_open()
> is used within a node and MPI is used across nodes, e.g., maybe images within
> a TEAM could use shm_open() to communicate, while any communication between
> TEAMs could use MPI.
> 

I think that would be ideal. The only problem with this would be that we would
have to maintain 3 implementations, which would be quite work intensive.

>
> > 
> > I actually think it would be best not to turn it into a separate library but
> > instead integrate it into libgfortran. 
> 
> I agree. 
> 
> > This way, it will not be necessary to
> > install a seperate library and thereby make it easier for people to start
> > using coarrays. Therefore, it would make sense to use the libgfortran
> > descriptors.
> 
> > 
> > At the moment, sync_all() is called after image creation.
> 
> I think that will suffice.

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

--- Comment #7 from Nicolas Koenig  ---
(In reply to Damian Rouson from comment #5)
> This is an exciting idea.  When I gave some thought to writing a
> shared-memory alternative coarray ABI, it seemed to me that pthreads would
> be a better choice than OpenMP.  Part of the problem is that I was
> considering writing the implementation in Fortran, and OpenMP lacked support
> several modern Fortran features, including several object-oriented
> programming features.  That of course won't be an issue for you, however,
> assuming you're going to write the implementation in C.  I was going to
> leverage "forthreads," an open-source Fortran 20003 interface to pthreads. 
> One thing that I think would be a major benefit of having a Fortran
> implementation of the library is that it greatly expand the potential
> community of contributors to include more of the users of the compiler.
> 

I actually opted to use multiprocessing with shared memory (shm_open() & co)
instead of multithreading, since it will be much easier and faster with static
variables, of which gfortran makes extensive use. Also, it greatly simplifies
interoperability with OpenMP. The only real downsides I can think of are slower
spinup times (~1 cycles for processes vs. ~1000 for threads), far slower
context switches (only a problem if more more images than cores are used) and
slower allocation, since at the moment a mmap() call is needed for each one
(the allocator tracks the offset and size in the memfile instead of the
mmap()'ed memory regions. If this is to slow, I can just cache the pointers).
As for writting it in fortran, see below :)

>
> Another important consideration is whether to use the current gfortran
> descriptors as arguments in the library functions (as is currently used) or
> instead to use the Fortran 2018 CFI descriptors for which Paul recently
> committed support.  If you go with the current gfortran descriptors, then
> there could be a lot of code to rewrite if gfortran later adopts the
> standard descriptors internally.  Paul's recent commit adds functions that
> can translate between the gfortran and standard descriptors. I have a
> volunteer who I'm hoping will use the translation functions to develop a
> new, alternative coarray ABI that accepts the standard descriptors.
> 

I actually think it would be best not to turn it into a separate library but
instead integrate it into libgfortran. This way, it will not be necessary to
install a seperate library and thereby make it easier for people to start using
coarrays. Therefore, it would make sense to use the libgfortran descriptors.

>
> On another note mentioned earlier in this PR, I believe it will be necessary
> to fork all threads at the beginning of execution and not join them at the
> end.  Section 5.3.5 of the Fortran 2018 standard states, "Following the
> creation of a fixed number of images, execution begins on each image."
> Assuming there is a one-to-one correspondence between images and threads, I
> read that as implying that a fixed number of threads have to be set up
> before any one thread can execute.  (Possibly there could also be additional
> non-image threads that get forked later also though.) 

At the moment, sync_all() is called after image creation.

> I recall seeing several interesting papers from 10-15 years ago on SPMD-style
> programming using threads (OpenMP) so a literature search on this topic be 
> useful to read.

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

--- Comment #4 from Nicolas Koenig  ---
Created attachment 45536
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45536=edit
library

Here is the library. At the moment, it has an interprocess allocator and
handles the creation and reaping of images. It also has a very simple
synchroniziation function.

The library part still has to integrated with libgfortrans build system. I
would suggest to handle it the same way libcaf_single is handled at the moment
which is linked against if -fcoarray=native is specified. 

To compile the library at the moment, the Makefile has to edited to allow it to
find libgfortran.h and libgfortran's config.h. After that 'make' will build it.

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

--- Comment #3 from Nicolas Koenig  ---
Created attachment 45535
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45535=edit
Proof-of-concept

As a little update, here is a proof-of-concept patch. It adds a new coarray
option -fcoarray=native and allows (together with the library I will attach in
the next post) the compilation and execution of the following very simple
coarray program:

$ cat test.f90
program main
  implicit none
  integer:: a[*]
  a[next_image()] = this_image()
  sync all
  print *, 'Hi from', a[this_image()], 'to', this_image()
contains
  function next_image()
integer:: next_image
next_image = mod(this_image() + 1, num_images())
  end function
end program
$ gfortran -fcoarray=native -Lpath/to/native/coarray/library test.f90
-lcoarraynative -lrt
$ GFORTRAN_NUM_IMAGES=4 ./a.out
 Hi from   2 to   3
 Hi from   4 to   1
 Hi from   1 to   2
 Hi from   0 to   4

P.S.: I got a bit sidetracked the last few months, so this all took a bit
longer than expected :D

[Bug c/88729] ICE in libiberty during bootstrap with debug info

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Nicolas Koenig  ---
It still doesn't work, but the error is a new one

[Bug c/88729] ICE in libiberty during bootstrap with debug info

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

 CC||koenigni at gcc dot gnu.org

--- Comment #1 from Nicolas Koenig  ---
Forgot to add, it tested it with the current trunk (r267612)

[Bug c/88729] New: ICE in libiberty during bootstrap with debug info

[koenigni at gcc dot gnu.org]

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

Bug ID: 88729
   Summary: ICE in libiberty during bootstrap with debug info
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: koenigni at gcc dot gnu.org
  Target Milestone: ---

While trying to compile gcc with maximum debug info it ICE'd in
libiberty/d-demangle.c in expand_gimple_statement().

The error happens only on power (powerpc64le-unknown-linux-gnu), on x86-64 it
dies in a different way a bit later (Thomas will file the bug report for that).

Below is the way the compiler was configured and the command that caused the
ICE. 

$ CFLAGS="-Og -ggdb3" CXXFLAGS="-Og -ggdb3" ../trunk/configure
--snip--
$ make
--snip--
  gcc -c -DHAVE_CONFIG_H -Og -ggdb3 -save-temps  -I.
-I../../../trunk/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -Wshadow=local -pedantic  -D_GNU_SOURCE  
../../../trunk/libiberty/d-demangle.c -o noasan/d-demangle.o; \
else true; fi
gcc -c -DHAVE_CONFIG_H -Og -ggdb3 -save-temps  -I.
-I../../../trunk/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -Wshadow=local -pedantic  -D_GNU_SOURCE
../../../trunk/libiberty/d-demangle.c -o d-demangle.o
../../../trunk/libiberty/d-demangle.c: In function ‘dlang_value’:
../../../trunk/libiberty/d-demangle.c:1278:14: warning: this statement may fall
through [-Wimplicit-fallthrough=]
1278 |   mangled++;
 |   ~~~^~
../../../trunk/libiberty/d-demangle.c:1284:5: note: here
1284 | case '0': case '1': case '2': case '3': case '4':
 | ^~~~
../../../trunk/libiberty/d-demangle.c: In function ‘dlang_type’:
../../../trunk/libiberty/d-demangle.c:619:10: warning: this statement may fall
through [-Wimplicit-fallthrough=]
619 |   if (!dlang_call_convention_p (mangled))
|  ^
../../../trunk/libiberty/d-demangle.c:626:5: note: here
626 | case 'F': /* function T (D) */
| ^~~~
during RTL pass: expand
../../../trunk/libiberty/d-demangle.c: In function ‘dlang_identifier’:
../../../trunk/libiberty/d-demangle.c:850:8: internal compiler error: in
set_value_range, at tree-vrp.c:289
850 |if (strncmp (mangled, "__ctor", len) == 0)
|^~~~
0x10d620b3 set_value_range(value_range*, value_range_type, tree_node*,
tree_node*, bitmap_head*)
../../trunk-caf/gcc/tree-vrp.c:289
0x10d6c2d3 extract_range_from_binary_expr_1(value_range*, tree_code,
tree_node*, value_range*, value_range*)
../../trunk-caf/gcc/tree-vrp.c:1604
0x10d6e76b determine_value_range_1
../../trunk-caf/gcc/tree-vrp.c:6865
0x10d6eb43 determine_value_range(tree_node*,
generic_wide_int*, generic_wide_int*)
../../trunk-caf/gcc/tree-vrp.c:6900
0x10393243 get_size_range(tree_node*, tree_node**, bool)
../../trunk-caf/gcc/calls.c:1258
0x1039a00b maybe_warn_nonstring_arg(tree_node*, tree_node*)
../../trunk-caf/gcc/calls.c:1617
0x1039bafb initialize_argument_information
../../trunk-caf/gcc/calls.c:2197
0x1039cfdf expand_call(tree_node*, rtx_def*, int)
../../trunk-caf/gcc/calls.c:3577
0x10375c2f expand_builtin_strncmp
../../trunk-caf/gcc/builtins.c:4793
0x103861cb expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
../../trunk-caf/gcc/builtins.c:7445
0x1054ae3f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../trunk-caf/gcc/expr.c:10943
0x10564f53 expand_expr
../../trunk-caf/gcc/expr.h:279
0x10564f53 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../trunk-caf/gcc/expr.c:8456
0x1054733b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../trunk-caf/gcc/expr.c:11230
0x1055a9c7 expand_expr
../../trunk-caf/gcc/expr.h:279
0x1055a9c7 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../trunk-caf/gcc/expr.c:5556
0x1055c653 expand_assignment(tree_node*, tree_node*, bool)
../../trunk-caf/gcc/expr.c:5420
0x103b6c6f expand_call_stmt
../../trunk-caf/gcc/cfgexpand.c:2685
0x103b6c6f expand_gimple_stmt_1
../../trunk-caf/gcc/cfgexpand.c:3575
0x103b6c6f expand_gimple_stmt
../../trunk-caf/gcc/cfgexpand.c:3734
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Makefile:703: recipe for target 'd-demangle.o' failed
make[3]: *** [d-demangle.o] Error 1
make[3]: Leaving directory
'/home/gcc/trunk-bin/build-powerpc64le-unknown-linux-gnu/libiberty'
Makefile:2686: recipe for target 'all-build-libiberty' failed
make[2]: *** [all-build-libiberty] Error 2
make[2]: Leaving directory '/home/gcc/trunk-bi

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

--- Comment #2 from Nicolas Koenig  ---
> Once you are done on this, you might consider implementing a -parallel as in
> ifort.
> 
> This could conveniently be triggered in frontend-passes.c, I suspect. ie.
> this would be a good place to check for dependencies within a do loop and
> signal, if there are none, that the loop can be parallelised. Then, with
> everything that you have learned about trans-*.c in dealing with coarrays,
> you should be able to do what is needed for do loops (and scalarization
> loops).
> 

I have a few ideas how we could do that, but it might get quite interesting. Do
we spin up the threads once in the beginning or only when needed? And do we use
OpenMP (It might give problems if OpenMP is used by the code itself)? But I'll
think about that once the coarrays are done, which might take a bit :D

> Just a thought.
> 
> Paul

[Bug fortran/88076] Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-18
 Ever confirmed|0   |1

[Bug fortran/88076] New: Shared Memory implementation for Coarrays

[koenigni at gcc dot gnu.org]

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

Bug ID: 88076
   Summary: Shared Memory implementation for Coarrays
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: koenigni at gcc dot gnu.org
  Target Milestone: ---

At the moment, we only support coarrays using mpi (or if they only have single
image). Thomas & I are currently working on adding an implementation based upon
shared memory between processes that is maintained inside libgfortran. It will
be enabled by '-fcoarray=native'. This library will have to have a different
interface than '-fcoarray=lib'. 

At the moment, we have written a basic library with the necessary interprocess
allocator, simple synchronization routines and the functions for creating and
handling the image processes.

I am currently working on trans-* to emit the new initialization code and to
emit the direct memory accesses. Once this is done I will upload the first
prove-of-concept patch.

I have opened this bug to track the progress and provide a forum for discussion
:)

[Bug fortran/25829] [F03] Asynchronous IO support

[koenigni at gcc dot gnu.org]

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

--- Comment #55 from Nicolas Koenig  ---
Author: koenigni
Date: Tue Aug 21 18:48:59 2018
New Revision: 263750

URL: https://gcc.gnu.org/viewcvs?rev=263750=gcc=rev
Log:
2018-08-21  Nicolas Koenig  
Thomas Koenig 

PR fortran/25829
* gfortran.texi: Add description of asynchronous I/O.
* trans-decl.c (gfc_finish_var_decl): Treat asynchronous variables
as volatile.
* trans-io.c (gfc_build_io_library_fndecls): Rename st_wait to
st_wait_async and change argument spec from ".X" to ".w".
(gfc_trans_wait): Pass ID argument via reference.

2018-08-21  Nicolas Koenig  
Thomas Koenig 

PR fortran/25829
* gfortran.dg/f2003_inquire_1.f03: Add write statement.
* gfortran.dg/f2003_io_1.f03: Add wait statement.

2018-08-21  Nicolas Koenig  
Thomas Koenig 

PR fortran/25829
* Makefile.am: Add async.c to gfor_io_src.
Add async.h to gfor_io_headers.
* Makefile.in: Regenerated.
* gfortran.map: Add _gfortran_st_wait_async.
* io/async.c: New file.
* io/async.h: New file.
* io/close.c: Include async.h.
(st_close): Call async_wait for an asynchronous unit.
* io/file_pos.c (st_backspace): Likewise.
(st_endfile): Likewise.
(st_rewind): Likewise.
(st_flush): Likewise.
* io/inquire.c: Add handling for asynchronous PENDING
and ID arguments.
* io/io.h (st_parameter_dt): Add async bit.
(st_parameter_wait): Correct.
(gfc_unit): Add au pointer.
(st_wait_async): Add prototype.
(transfer_array_inner): Likewise.
(st_write_done_worker): Likewise.
* io/open.c: Include async.h.
(new_unit): Initialize asynchronous unit.
* io/transfer.c (async_opt): New struct.
(wrap_scalar_transfer): New function.
(transfer_integer): Call wrap_scalar_transfer to do the work.
(transfer_real): Likewise.
(transfer_real_write): Likewise.
(transfer_character): Likewise.
(transfer_character_wide): Likewise.
(transfer_complex): Likewise.
(transfer_array_inner): New function.
(transfer_array): Call transfer_array_inner.
(transfer_derived): Call wrap_scalar_transfer.
(data_transfer_init): Check for asynchronous I/O.
Perform a wait operation on any pending asynchronous I/O
if the data transfer is synchronous. Copy PDT and enqueue
thread for data transfer.
(st_read_done_worker): New function.
(st_read_done): Enqueue transfer or call st_read_done_worker.
(st_write_done_worker): New function.
(st_write_done): Enqueue transfer or call st_read_done_worker.
(st_wait): Document as no-op for compatibility reasons.
(st_wait_async): New function.
* io/unit.c (insert_unit): Use macros LOCK, UNLOCK and TRYLOCK;
add NOTE where necessary.
(get_gfc_unit): Likewise.
(init_units): Likewise.
(close_unit_1): Likewise. Call async_close if asynchronous.
(close_unit): Use macros LOCK and UNLOCK.
(finish_last_advance_record): Likewise.
(newunit_alloc): Likewise.
* io/unix.c (find_file): Likewise.
(flush_all_units_1): Likewise.
(flush_all_units): Likewise.
* libgfortran.h (generate_error_common): Add prototype.
* runtime/error.c: Include io.h and async.h.
(generate_error_common): New function.

2018-08-21  Nicolas Koenig  
Thomas Koenig 

PR fortran/25829
* testsuite/libgomp.fortran/async_io_1.f90: New test.
* testsuite/libgomp.fortran/async_io_2.f90: New test.
* testsuite/libgomp.fortran/async_io_3.f90: New test.
* testsuite/libgomp.fortran/async_io_4.f90: New test.
* testsuite/libgomp.fortran/async_io_5.f90: New test.
* testsuite/libgomp.fortran/async_io_6.f90: New test.
* testsuite/libgomp.fortran/async_io_7.f90: New test.


Added:
trunk/libgfortran/io/async.c
trunk/libgfortran/io/async.h
trunk/libgomp/testsuite/libgomp.fortran/async_io_1.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_2.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_3.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_4.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_5.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_6.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_7.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-io.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/f2003_inquire_1.f03
trunk/gcc/testsuite/gfortran.dg/f2003_io_1.f03
trunk/libgfortran/ChangeLog
trunk/libgfortran/Makefile.am
trunk/libgfortran/Makefile.in

[Bug fortran/25829] [F03] Asynchronous IO support

[koenigni at gcc dot gnu.org]

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

--- Comment #45 from Nicolas Koenig  ---
Author: koenigni
Date: Wed Jul 25 19:34:33 2018
New Revision: 262979

URL: https://gcc.gnu.org/viewcvs?rev=262979=gcc=rev
Log:
2018-07-25  Nicolas Koenig  
Thomas Koenig 

PR fortran/25829
* testsuite/libgomp.fortran/async_io_1.f90: Really commit.
* testsuite/libgomp.fortran/async_io_2.f90: Really commit.
* testsuite/libgomp.fortran/async_io_3.f90: Really commit.
* testsuite/libgomp.fortran/async_io_4.f90: Really commit.
* testsuite/libgomp.fortran/async_io_5.f90: Really commit.
* testsuite/libgomp.fortran/async_io_6.f90: Really commit.
* testsuite/libgomp.fortran/async_io_7.f90: Really commit.


Added:
trunk/libgomp/testsuite/libgomp.fortran/async_io_1.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_2.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_3.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_4.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_5.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_6.f90
trunk/libgomp/testsuite/libgomp.fortran/async_io_7.f90

[Bug fortran/25829] [F03] Asynchronous IO support

[koenigni at gcc dot gnu.org]

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

--- Comment #43 from Nicolas Koenig  ---
Author: koenigni
Date: Wed Jul 25 18:48:39 2018
New Revision: 262978

URL: https://gcc.gnu.org/viewcvs?rev=262978=gcc=rev
Log:
2018-07-25  Nicolas Koenig  
Thomas Koenig 

PR fortran/25829
* gfortran.texi: Add description of asynchronous I/O.
* trans-decl.c (gfc_finish_var_decl): Treat asynchronous variables
as volatile.
* trans-io.c (gfc_build_io_library_fndecls): Rename st_wait to
st_wait_async and change argument spec from ".X" to ".w".
(gfc_trans_wait): Pass ID argument via reference.

2018-07-25  Nicolas Koenig  
Thomas Koenig 

PR fortran/25829
* gfortran.dg/f2003_inquire_1.f03: Add write statement.
* gfortran.dg/f2003_io_1.f03: Add wait statement.

2018-07-25  Nicolas Koenig  
Thomas Koenig 

PR fortran/25829
* Makefile.am: Add async.c to gfor_io_src.
Add async.h to gfor_io_headers.
* Makefile.in: Regenerated.
* gfortran.map: Add _gfortran_st_wait_async.
* io/async.c: New file.
* io/async.h: New file.
* io/close.c: Include async.h.
(st_close): Call async_wait for an asynchronous unit.
* io/file_pos.c (st_backspace): Likewise.
(st_endfile): Likewise.
(st_rewind): Likewise.
(st_flush): Likewise.
* io/inquire.c: Add handling for asynchronous PENDING
and ID arguments.
* io/io.h (st_parameter_dt): Add async bit.
(st_parameter_wait): Correct.
(gfc_unit): Add au pointer.
(st_wait_async): Add prototype.
(transfer_array_inner): Likewise.
(st_write_done_worker): Likewise.
* io/open.c: Include async.h.
(new_unit): Initialize asynchronous unit.
* io/transfer.c (async_opt): New struct.
(wrap_scalar_transfer): New function.
(transfer_integer): Call wrap_scalar_transfer to do the work.
(transfer_real): Likewise.
(transfer_real_write): Likewise.
(transfer_character): Likewise.
(transfer_character_wide): Likewise.
(transfer_complex): Likewise.
(transfer_array_inner): New function.
(transfer_array): Call transfer_array_inner.
(transfer_derived): Call wrap_scalar_transfer.
(data_transfer_init): Check for asynchronous I/O.
Perform a wait operation on any pending asynchronous I/O
if the data transfer is synchronous. Copy PDT and enqueue
thread for data transfer.
(st_read_done_worker): New function.
(st_read_done): Enqueue transfer or call st_read_done_worker.
(st_write_done_worker): New function.
(st_write_done): Enqueue transfer or call st_read_done_worker.
(st_wait): Document as no-op for compatibility reasons.
(st_wait_async): New function.
* io/unit.c (insert_unit): Use macros LOCK, UNLOCK and TRYLOCK;
add NOTE where necessary.
(get_gfc_unit): Likewise.
(init_units): Likewise.
(close_unit_1): Likewise. Call async_close if asynchronous.
(close_unit): Use macros LOCK and UNLOCK.
(finish_last_advance_record): Likewise.
(newunit_alloc): Likewise.
* io/unix.c (find_file): Likewise.
(flush_all_units_1): Likewise.
(flush_all_units): Likewise.
* libgfortran.h (generate_error_common): Add prototype.
* runtime/error.c: Include io.h and async.h.
(generate_error_common): New function.

2018-07-25  Nicolas Koenig  
Thomas Koenig 

PR fortran/25829
* testsuite/libgomp.fortran/async_io_1.f90: New test.
* testsuite/libgomp.fortran/async_io_2.f90: New test.
* testsuite/libgomp.fortran/async_io_3.f90: New test.
* testsuite/libgomp.fortran/async_io_4.f90: New test.
* testsuite/libgomp.fortran/async_io_5.f90: New test.
* testsuite/libgomp.fortran/async_io_6.f90: New test.
* testsuite/libgomp.fortran/async_io_7.f90: New test.


Added:
trunk/libgfortran/io/async.c
trunk/libgfortran/io/async.h
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi
trunk/gcc/fortran/trans-decl.c
trunk/gcc/fortran/trans-io.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/f2003_inquire_1.f03
trunk/gcc/testsuite/gfortran.dg/f2003_io_1.f03
trunk/libgfortran/ChangeLog
trunk/libgfortran/Makefile.am
trunk/libgfortran/Makefile.in
trunk/libgfortran/gfortran.map
trunk/libgfortran/io/close.c
trunk/libgfortran/io/file_pos.c
trunk/libgfortran/io/inquire.c
trunk/libgfortran/io/io.h
trunk/libgfortran/io/open.c
trunk/libgfortran/io/read.c
trunk/libgfortran/io/transfer.c
trunk/libgfortran/io/unit.c
trunk/libgfortran/io/unix.c
trunk/libgfortran/libgfortran.h
trunk/libgfortran/runtime/error.c
trunk/libgomp/ChangeLog

[Bug fortran/25829] [F03] Asynchronous IO support

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

  Attachment #44106|0   |1
is obsolete||

--- Comment #41 from Nicolas Koenig  ---
Created attachment 44151
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44151=edit
Next version of patch.

Yet another patch version.

Error handling is partially implemented, iostat and iomsg work for WAIT.

This patch drops all pending I/O requests when an error occurs. Given that
trying to flush corrupted data almost always is a bad idea, this seems like the
only sensible way.

Timing data:

With

program main
  implicit none
  integer, parameter :: n = 10**7
  character(3), parameter :: yes = "no"
  real, dimension(n) :: a,b,c

  call random_number(a)
  call random_number(b)
  call random_number(c)
  open (10, file="a.dat",asynchronous=yes)
  open (20, file="b.dat",asynchronous=yes)
  open (30, file="c.dat",asynchronous=yes)
  write (10,*,asynchronous=yes) a
  write (20,*,asynchronous=yes) b
  write (30,*,asynchronous=yes) c
  wait (10)
  wait (20)
  wait (30)
end program main

real0m15.465s
user0m15.313s
sys 0m0.152s

With the "no" replaced by "yes":

real0m5.558s
user0m16.253s
sys 0m0.152s

If you ask me, that's quite nice :)

[Bug fortran/25829] [F03] Asynchronous IO support

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

  Attachment #44034|0   |1
is obsolete||

--- Comment #40 from Nicolas Koenig  ---
Created attachment 44106
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44106=edit
Next version of patch

This patch works for reading and writing, for simple data types and
for arrays.

Still missing are mixed synchronous/asynchronous statements, inquire,
flush, backspace, rewind etc  and error handling.

The reason why error handling is not implemented yet is that I do not
understand the standard, and I have not been able to find any
explanation for this:

9.7.1, paragraph 5:

If an error or end-of-file condition occurs during a wait operation for a unit,
the processor performs a wait
19 operation for all pending data transfer operations for that unit.

What does that mean? Does it mean that all pending transfers should be
thrown away, or that they should still be performed? I think the second
option is probably the right one, but it seems to make little sense since
trying to flush after and error results in loads and loads of corrupt
data.

[Bug fortran/25829] [F03] Asynchronous IO support

[koenigni at gcc dot gnu.org]

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

--- Comment #36 from Nicolas Koenig  ---
There seems to be a mismatch between the front end and the library.

For

program main
  integer :: id
  character(len=50) :: iomsg
  integer :: iostat
  id = 0
  open(10,file="wait.dat",iostat=iostat,iomsg=iomsg, asynchronous="yes")
  wait (10,id=id)
end program main

the front end generates

struct __st_parameter_wait wait_parm.1;

wait_parm.1.common.filename = &"wait.f90"[1]{lb: 1 sz: 1};
wait_parm.1.common.line = 7;
wait_parm.1.id = (integer(kind=4) *) (integer(kind=8)) id;
wait_parm.1.common.flags = 128;
wait_parm.1.common.unit = 10;
_gfortran_st_wait (_parm.1);

where the type conversions are strange. The library then receives

(gdb) p *wtp
$1 = {common = {flags = 128, unit = 10, filename = 0x428d70 "wait.f90", line =
7, iomsg_len = 50, iomsg = 0x7fffdc90 "\377\377\377\377", 
iostat = 0x7fffdc8c}, id = 0x0, id_len = 8}

so some adjustment of

typedef struct
{
  st_parameter_common common;
  CHARACTER1 (id);
}
st_parameter_wait;

is probably required.

[Bug fortran/25829] [F03] Asynchronous IO support

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

  Attachment #43877|0   |1
is obsolete||

--- Comment #35 from Nicolas Koenig  ---
Created attachment 44034
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44034=edit
Concept patch (works with read and simple wait for integers)

[Bug fortran/25829] [F03] Asynchronous IO support

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

  Attachment #42494|0   |1
is obsolete||

--- Comment #34 from Nicolas Koenig  ---
Created attachment 43877
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43877=edit
Proof of concept for transfer of a single integer

Here is a proof of concept patch which transfers a single integer:

$ cat foo.f90
program main
  integer :: i
  i = 42
  open(10,asynchronous="yes")
  write (10, *, asynchronous="yes") i
  close (10)
end program main
$ gfortran foo.f90 -lpthread
$ ./a.out
M: LOCK: lockprev: unlocked change_pdt():336
M: ACQ: lock
M: UNLOCK: lock change_pdt():345
M: SIGNAL: >workchange_pdt():346
T: LOCK: lockprev: unlocked async_io():164
T: ACQ: lock
T: UNLOCK: lock async_io():166
T: WAITING: >work   async_io():169
M: LOCK: lockprev: unlocked
enqueue_transfer():278
M: ACQ: lock
M: UNLOCK: lock
enqueue_transfer():287
M: SIGNAL: >work   
enqueue_transfer():288
T: LOCK: lockprev: unlocked async_io():170
T: ACQ: lock
T: UNLOCK: lock async_io():175
T: NOTE: Changing pdts  update_pdt():134
T: LOCK: lockprev: unlocked async_io():200
T: ACQ: lock
T: UNLOCK: lock async_io():175
T: NOTE: Starting transfer  async_io():189
M: LOCK: lockprev: unlocked enqueue_done():297
M: ACQ: lock
M: UNLOCK: lock enqueue_done():306
M: SIGNAL: >workenqueue_done():307
T: LOCK: lockprev: locked   async_io():200
T: ACQ: lock
T: UNLOCK: lock async_io():175
T: NOTE: Finalizing write   async_io():182
T: LOCK: lockprev: unlocked async_io():200
T: ACQ: lock
T: SIGNAL: >emptysignal async_io():215
T: UNLOCK: lock async_io():219
T: WAITING: >work   async_io():169
T: LOCK: lockprev: unlocked async_io():170
T: ACQ: lock
T: SIGNAL: >emptysignal async_io():215
T: UNLOCK: lock async_io():219
T: WAITING: >work   async_io():169
M: LOCK: lockprev: locked   async_close():388
M: ACQ: lock
M: UNLOCK: lock async_close():390
M: SIGNAL: &(au->work)  async_wait():375
M: LOCK: lockprev: unlocked async_wait():376
M: ACQ: lock
M: UNLOCK: lock async_wait():378
T: REC: >work   async_io():169
T: LOCK: lockprev: unlocked async_io():170
T: ACQ: lock
T: SIGNAL: >emptysignal async_io():215
T: UNLOCK: lock async_io():221
$ cat fort.10
  42

[Bug fortran/25829] [F03] Asynchronous IO support

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

 CC||koenigni at gcc dot gnu.org

--- Comment #30 from Nicolas Koenig  ---
Created attachment 42494
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42494=edit
Early patch

Hello everyone,

attached is a first patch that implements async io for integers. I will extend
it to work for everything and heavily optimize it before submitting, but I
would like some feedback on the overall structure.

[Bug fortran/25829] [F03] Asynchronous IO support

[koenigni at gcc dot gnu.org]

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

--- Comment #27 from Nicolas Koenig  ---
(In reply to Janne Blomqvist from comment #26)
> I though I wrote somewhere why I gave up on this, after thinking a lot about
> the problem in general. However, I can't find my writeup now, so I'll add a
> short version here so that others who are interested in this problem may
> benefit.
> 
> So, to begin with, non-blocking socket I/O is widely used on Linux and works
> well (select(), epoll() etc.). However, here we're talking about file IO,
> not sockets. For file IO, the non-blocking socket programming model doesn't
> work; files are always considered "fast" devices and thus always return
> ready if you try to poll them. Thus, asynchronous I/O. The choices are
> roughly:
> 
> 1) Linux native AIO: syscalls like io_submit() etc. This however works only
> on files opened with O_DIRECT, and all I/O must be 512-byte aligned. So
> clearly this disqualifies this solution for something general purpose like
> Fortran AIO.
> 
> 2) POSIX AIO (aio_read() etc.). This, in principle, could work. Except for
> 1) It uses signals for reporting completions, which is horrible. Also, some
> may consider it bad form if libgfortran uses (limited) signal numbers for
> its internal use, preventing applications from using them.  2) On Linux,
> glibc implements POSIX AIO using a userspace thread pool, with the further
> restriction that only a single outstanding I/O per file descriptor is
> possible (which may or may not matter for Fortran AIO). 
> 
> 3) Do it yourself with a thread pool. Similar to POSIX AIO on Linux/glibc,
> except you can use something more sane than signals for signaling completion
> (e.g. pipes or a pure userspace queue).
> 
> See also e.g. http://blog.libtorrent.org/2012/10/asynchronous-disk-io/
> 
> 
> So, the only solution that has the potential to work well and is portable is
> #3. It's a fair amount of work, though, and in the end I wasn't convinced it
> was worth the effort.

At the moment I only plan on using the normal pthread-API. My Idea for an
algorythm would be something like this:

=> if a unit is opened with the "asynchronous" flag, a new thread is spun up
for this unit.
=> when a TRANSFER_* funktion is called, the buffer and all the other necessary
information is enqueued in a asynchronous work queue. (see below)
=> the thread is notified that work has been added
=> the thread takes care of the io
=> when the unit is closed pthread_join() is called

I plan to enqueue the pdt->transfer() calls with their respective arguments in
the work queue.

I actually already have a small prototype that implements the principal behind
this in c and it works :)

One of the problems I found up until now with this approach is for example the
following code snippet:

program main
implicit none
open (10, file='foo.dat', asynchronous='yes')
call s()
close(10)
contains
subroutine s()
integer, dimension (3)::i !presumably on the stack
i = [0, 1]
write(10,*) i
!Now the stack frame is dropped and the pointer that previously
!pointed to the array now points to nowhere, but it is still enqueued
end subroutine
end program

Do you see any fundamental problems with this approach or its integration with
libgfortran?

[Bug fortran/35339] Improve translation of implied do loop in transfer

[koenigni at gcc dot gnu.org]

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

--- Comment #12 from Nicolas Koenig  ---
Author: koenigni
Date: Mon Jun  5 12:35:11 2017
New Revision: 248877

URL: https://gcc.gnu.org/viewcvs?rev=248877=gcc=rev
Log:

2017-06-05  Nicolas Koenig  

PR fortran/35339
* frontend-passes.c (traverse_io_block): New function.
(simplify_io_impl_do): New function.
(optimize_namespace): Invoke gfc_code_walker with
simplify_io_impl_do.

2017-06-05  Nicolas Koenig  

PR fortran/35339
* gfortran.dg/implied_do_io_1.f90: New Test.
* gfortran.dg/implied_do_io_2.f90: New Test.



Added:
trunk/gcc/testsuite/gfortran.dg/implied_do_io_1.f90
trunk/gcc/testsuite/gfortran.dg/implied_do_io_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/80945] New: Invalid code with allocatable character array in READ/WRITE statement

[koenigni at gcc dot gnu.org]

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

Bug ID: 80945
   Summary: Invalid code with allocatable character array in
READ/WRITE statement
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: koenigni at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41446
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41446=edit
Test Case

Trying to compile the testcase with "-O" produces invalid code, while compiling
it without leads to a segfault.

gcc@dcm-linux:~/pr/35339> gfortran -O z5.f90
gcc@dcm-linux:~/pr/35339> ./a.out   
 c  foo   bar   xyzzy   
 ca xyzzy   
gcc@dcm-linux:~/pr/35339> gfortran z5.f90   
gcc@dcm-linux:~/pr/35339> ./a.out   

Program received signal SIGSEGV: Segmentation fault - invalid memory reference. 

Backtrace for this error:   
#0  0x7f37dee45adf in ???   
#1  0x7f37dee97d15 in ???   
#2  0x7f37dfb03a50 in read_default_char1
at ../../../trunk/libgfortran/io/read.c:429 
#3  0x7f37dfb0809c in formatted_transfer_scalar_read
at ../../../trunk/libgfortran/io/transfer.c:1591
#4  0x7f37dfb08f2c in formatted_transfer
at ../../../trunk/libgfortran/io/transfer.c:2270
#5  0x400cb3 in ??? 
#6  0x400e43 in ??? 
#7  0x7f37dee31469 in ???   
#8  0x400909 in ??? 
at ../sysdeps/x86_64/start.S:120
#9  0x in ???
Segmentation fault (core dumped)

[Bug fortran/35339] Improve translation of implied do loop in transfer

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

  Attachment #41420|0   |1
is obsolete||

--- Comment #9 from Nicolas Koenig  ---
Created attachment 41430
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41430=edit
Proposed patch for simplifying impl do loops

Fixed the bugs, it works now. I will submit it later this day.

@Jerry: This isn't the entire solution, I fear there will have to be changes in
trans-io.c to completely fix this PR ;)

[Bug fortran/35339] Improve translation of implied do loop in transfer

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

  Attachment #41419|0   |1
is obsolete||

--- Comment #7 from Nicolas Koenig  ---
Created attachment 41420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41420=edit
Early patch for simplifying impl do loops - 2

Sorry, wrong patch _and_ wrong testcase... Still fails for mysterious reasons,
though.

gcc@dcm-linux:~/pr/35339> cat z3.f90
program main
implicit none
integer:: i
integer, parameter:: k = 2
integer, dimension(4):: a = [(i, i=1,4)]
write (*,*) (a(k), i=1,4) 
end program
gcc@dcm-linux:~/pr/35339> gfortran -O z3.f90
z3.f90:6:0:

 write (*,*) (a(k), i=1,4)

internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:6792
0x73175d gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../trunk/gcc/fortran/trans-array.c:6792
0x7a811b gfc_trans_transfer(gfc_code*)
../../trunk/gcc/fortran/trans-io.c:2581
0x71dffb trans_code
../../trunk/gcc/fortran/trans.c:2017
0x71e164 gfc_trans_code_cond(gfc_code*, tree_node*)
../../trunk/gcc/fortran/trans.c:2120
0x7c4fa2 gfc_trans_simple_do
../../trunk/gcc/fortran/trans-stmt.c:1942
0x7c5473 gfc_trans_do(gfc_code*, tree_node*)
../../trunk/gcc/fortran/trans-stmt.c:2075
0x71ddf4 trans_code
../../trunk/gcc/fortran/trans.c:1917
0x71e164 gfc_trans_code_cond(gfc_code*, tree_node*)
../../trunk/gcc/fortran/trans.c:2120
0x7a6bad build_dt
../../trunk/gcc/fortran/trans-io.c:2017
0x7a6c88 gfc_trans_write(gfc_code*)
../../trunk/gcc/fortran/trans-io.c:2056
0x71df71 trans_code
../../trunk/gcc/fortran/trans.c:1989
0x71e183 gfc_trans_code(gfc_code*)
../../trunk/gcc/fortran/trans.c:2128
0x7590ed gfc_generate_function_code(gfc_namespace*)
../../trunk/gcc/fortran/trans-decl.c:6332
0x71e1c7 gfc_generate_code(gfc_namespace*)
../../trunk/gcc/fortran/trans.c:2145
0x6b0646 translate_all_program_units
../../trunk/gcc/fortran/parse.c:6074
0x6b0c56 gfc_parse_file()
../../trunk/gcc/fortran/parse.c:6274
0x706d3f gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/35339] Improve translation of implied do loop in transfer

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

 CC||koenigni at gcc dot gnu.org

--- Comment #6 from Nicolas Koenig  ---
Created attachment 41419
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41419=edit
Early patch for simplifying impl do loops

Attached is a patch that simplifies implied do loops in the way suggested by
Thomas. There are, however, still a few problems with this patch that I have a
hard time understanding. For example:

gcc@dcm-linux:~/pr/35339> cat z1.f90
program main
implicit none
integer:: i
integer, dimension(2,2):: a = reshape([1, 2, 3, 4], shape(a))
write (*,*) (a(i, 1), i=1,2)
end program
gcc@dcm-linux:~/pr/35339> gfortran -O z1.f90
z1.f90:5:0:

 write (*,*) (a(i, 1), i=1,4)

internal compiler error: Segmentation fault
0xbe58af crash_signal
../../trunk/gcc/toplev.c:337
0x6bea8d gfc_conv_scalarized_array_ref
../../trunk/gcc/fortran/trans-array.c:3228
0x6bfb1c gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*)
../../trunk/gcc/fortran/trans-array.c:3382
0x6f95cd gfc_conv_variable
../../trunk/gcc/fortran/trans-expr.c:2680
0x6f529a gfc_conv_expr(gfc_se*, gfc_expr*)
../../trunk/gcc/fortran/trans-expr.c:7815
0x6fd41e gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../trunk/gcc/fortran/trans-expr.c:7915
0x724862 gfc_trans_transfer(gfc_code*)
../../trunk/gcc/fortran/trans-io.c:2539
0x6b3d37 trans_code
../../trunk/gcc/fortran/trans.c:2017
0x7214f2 build_dt
../../trunk/gcc/fortran/trans-io.c:2017
0x6b3d57 trans_code
../../trunk/gcc/fortran/trans.c:1989
0x6e5498 gfc_generate_function_code(gfc_namespace*)
../../trunk/gcc/fortran/trans-decl.c:6332
0x66c576 translate_all_program_units
../../trunk/gcc/fortran/parse.c:6074
0x66c576 gfc_parse_file()
../../trunk/gcc/fortran/parse.c:6274
0x6afe9f gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


probably because the new 'transfer'-statement isn't properly inserted in the
code tree.

[Bug fortran/80442] Rejects DATA statement with array slice

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Nicolas Koenig  ---
Fixed on trunk.

[Bug fortran/80442] Rejects DATA statement with array slice

[koenigni at gcc dot gnu.org]

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

--- Comment #2 from Nicolas Koenig  ---
Author: koenigni
Date: Sat May 13 23:38:36 2017
New Revision: 248012

URL: https://gcc.gnu.org/viewcvs?rev=248012=gcc=rev
Log:

2017-05-09  Nicolas Koenig  

PR fortran/80442
* array.c (gfc_ref_dimen_size): Simplify stride
expression
* data.c (gfc_advance_section): Simplify start,
end and stride expressions
(gfc_advance_section): Simplify start and end
expressions
(gfc_get_section_index): Simplify start expression 

2017-05-09  Nicolas Koenig  

PR fortran/80442
* gfortran.dg/impl_do_var_data.f90: New Test


Added:
trunk/gcc/testsuite/gfortran.dg/impl_do_var_data.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/data.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/80442] Rejects DATA statement with array slice

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-16
 Ever confirmed|0   |1

[Bug fortran/80442] New: Rejects DATA statement with array slice

[koenigni at gcc dot gnu.org]

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

Bug ID: 80442
   Summary: Rejects DATA statement with array slice
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: koenigni at gcc dot gnu.org
  Reporter: koenigni at gcc dot gnu.org
  Target Milestone: ---

The following code is rejected, even though it is, as far as I can see, valid
Fortran.

$ cat test.f90
program main
implicit none
integer:: i
integer, dimension(4):: j
data (j(i:i), i=1,4) /1, 2, 3, 4/
end program
$ gfortran test.f90
test.f90:5:10:

 data (j(i:i), i=1,4) /1, 2, 3, 4/
  1
Error: Data element below array lower bound at (1)

[Bug fortran/68569] ICE with automatic character object and DATA

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |koenigni at gcc dot 
gnu.org

[Bug fortran/69498] ICE on disjunct cases with displaced or incomplete embedded statement

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Nicolas Koenig  ---
Fixed on trunk (this time for real), closing (again).

[Bug fortran/69498] ICE on disjunct cases with displaced or incomplete embedded statement

[koenigni at gcc dot gnu.org]

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

--- Comment #10 from Nicolas Koenig  ---
Author: koenigni
Date: Mon Apr 10 20:58:21 2017
New Revision: 246826

URL: https://gcc.gnu.org/viewcvs?rev=246826=gcc=rev
Log:

2017-04-10  Nicolas Koenig  
Paul Thomas  

PR fortran/69498 
* module.c (gfc_match_submodule): Add error
if function is called in the wrong state.

2017-04-10  Nicolas Koenig  

PR fortran/69498 
* gfortran.dg/submodule_unexp.f90: Modified test
to account for new error.
* gfortran.dg/submodule_twice.f90: New Test


Added:
trunk/gcc/testsuite/gfortran.dg/submodule_twice.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/submodule_unexp.f90

[Bug fortran/68569] ICE with automatic character object and DATA

[koenigni at gcc dot gnu.org]

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

--- Comment #4 from Nicolas Koenig  ---
And here is a fix for the first test case (z2a.f90), already regression tested
on x86_64-pc-linux-gnu:

Index: resolve.c
===
--- resolve.c   (revision 246743)
+++ resolve.c   (working copy)
@@ -14947,6 +14947,12 @@ check_data_variable (gfc_data_variable *var, locus
  }
 }

+  if (e->ts.type == BT_CHARACTER && e->ts.u.cl->length
+&& e->ts.u.cl->length->expr_type == EXPR_VARIABLE)
+gfc_error("Nonconstant length character at %L in DATA statement",
+  >where);
+  
+
   if (e->rank == 0 || has_pointer)
 {
   mpz_init_set_ui (size, 1);

[Bug fortran/68569] ICE with automatic character object and DATA

[koenigni at gcc dot gnu.org]

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

koenigni at gcc dot gnu.org changed:

   What|Removed |Added

 CC||koenigni at gcc dot gnu.org

--- Comment #3 from koenigni at gcc dot gnu.org ---
Some more fun with characters & data :)

gcc@dcm-linux:~/boi/new> cat z3.f90
subroutine s()
implicit none
type t
character(:):: c
end type
type(t):: tp
data tp%c /'a'/
end subroutine
gcc@dcm-linux:~/boi/new> gfortran z3.f90
z3.f90:4:24:

 character(:):: c
1
Error: Character component ‘c’ of ‘t’ at (1) with deferred length must be a
POINTER or ALLOCATABLE
f951: internal compiler error: Segmentation fault
0xbdb69f crash_signal
../../trunk/gcc/toplev.c:337
0x5f97bb gfc_constructor_append_expr(splay_tree_s**, gfc_expr*, locus*)
../../trunk/gcc/fortran/constructor.c:135
0x5fb4ec formalize_structure_cons
../../trunk/gcc/fortran/data.c:618
0x5fb4ec formalize_init_expr
../../trunk/gcc/fortran/data.c:655
0x69a182 do_traverse_symtree
../../trunk/gcc/fortran/symbol.c:4009
0x675793 resolve_types
../../trunk/gcc/fortran/resolve.c:16050
0x679d8c gfc_resolve(gfc_namespace*)
../../trunk/gcc/fortran/resolve.c:16135
0x669004 resolve_all_program_units
../../trunk/gcc/fortran/parse.c:6013
0x669004 gfc_parse_file()
../../trunk/gcc/fortran/parse.c:6260
0x6acb4f gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
gcc@dcm-linux:~/boi/new> cat z4.f90
subroutine s()
implicit none
type t
character(:), allocatable :: c
end type
type(t):: tp
data tp%c /'a'/
end subroutine
gcc@dcm-linux:~/boi/new> gfortran z4.f90
z4.f90:1:0:

 subroutine s()

internal compiler error: Segmentation fault
0xbdb69f crash_signal
../../trunk/gcc/toplev.c:337
0x6f94bc gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../trunk/gcc/fortran/trans-expr.c:7658
0x6f8f51 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../trunk/gcc/fortran/trans-expr.c:6828
0x6dd780 gfc_get_symbol_decl(gfc_symbol*)
../../trunk/gcc/fortran/trans-decl.c:1800
0x6e0ee7 generate_local_decl
../../trunk/gcc/fortran/trans-decl.c:5403
0x69a182 do_traverse_symtree
../../trunk/gcc/fortran/symbol.c:4009
0x6e1d82 generate_local_vars
../../trunk/gcc/fortran/trans-decl.c:5603
0x6e1d82 gfc_generate_function_code(gfc_namespace*)
../../trunk/gcc/fortran/trans-decl.c:6267
0x6691a6 translate_all_program_units
../../trunk/gcc/fortran/parse.c:6074
0x6691a6 gfc_parse_file()
../../trunk/gcc/fortran/parse.c:6274
0x6acb4f gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
gcc@dcm-linux:~/boi/new> cat z5.f90
character(:), pointer :: a
data a /'foo'/
end
gcc@dcm-linux:~/boi/new> gfortran z5.f90
f951: internal compiler error: Segmentation fault
0xbdb69f crash_signal
../../trunk/gcc/toplev.c:337
0x682a87 check_data_variable
../../trunk/gcc/fortran/resolve.c:14951
0x682a87 traverse_data_var
../../trunk/gcc/fortran/resolve.c:15187
0x675751 resolve_data
../../trunk/gcc/fortran/resolve.c:15242
0x675751 resolve_types
../../trunk/gcc/fortran/resolve.c:16047
0x679d8c gfc_resolve(gfc_namespace*)
../../trunk/gcc/fortran/resolve.c:16135
0x669004 resolve_all_program_units
../../trunk/gcc/fortran/parse.c:6013
0x669004 gfc_parse_file()
../../trunk/gcc/fortran/parse.c:6260
0x6acb4f gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug fortran/69498] ICE on disjunct cases with displaced or incomplete embedded statement

[koenigni at gcc dot gnu.org]

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

koenigni at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from koenigni at gcc dot gnu.org ---
Fixed on trunk, closing.

[Bug fortran/69498] ICE on disjunct cases with displaced or incomplete embedded statement

[koenigni at gcc dot gnu.org]

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

--- Comment #7 from koenigni at gcc dot gnu.org ---
Author: koenigni
Date: Tue Apr  4 13:41:41 2017
New Revision: 246679

URL: https://gcc.gnu.org/viewcvs?rev=246679=gcc=rev
Log:

2017-03-18  Nicolas Koenig  <koeni...@student.ethz.ch> 
PR fortran/69498
* symbol.c (gfc_delete_symtree): If there is a period in the
name, ignore
everything before it.

2017-03-18  Nicolas Koenig  <koeni...@student.ethz.ch>
PR fortran/69498
* gfortran.dg/submodule_unexp.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/submodule_unexp.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/69498] ICE on disjunct cases with displaced or incomplete embedded statement

[koenigni at gcc dot gnu.org]

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

--- Comment #6 from koenigni at gcc dot gnu.org ---
> +  p = strchr(name, '.');   

s/strchr/strrchr

Also, regression tested for x86_64-pc-linux-gnu

[Bug fortran/69498] ICE on disjunct cases with displaced or incomplete embedded statement

[koenigni at gcc dot gnu.org]

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

koenigni at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||koenigni at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |koenigni at gcc dot 
gnu.org

--- Comment #5 from koenigni at gcc dot gnu.org ---
Proposed fix for z2.f90 and z3.f90.

Index: symbol.c 
=== 
--- symbol.c(Revision 246320)   
+++ symbol.c(Arbeitskopie)  
@@ -2782,10 +2782,20 @@ void
 gfc_delete_symtree (gfc_symtree **root, const char *name)  
 {  
   gfc_symtree st, *st0;
+  const char *p;   

-  st0 = gfc_find_symtree (*root, name);
+  /* Submodules are marked as mod.submod.  When freeing a submodule
+ symbol, the symtree only has "submod", so adjust that here.  */   

-  st.name = gfc_get_string ("%s", name);   
+  p = strchr(name, '.');   
+  if (p)   
+p++;   
+  else 
+p = name;  
+   
+  st0 = gfc_find_symtree (*root, p);   
+
+  st.name = gfc_get_string ("%s", p);
   gfc_delete_bbt (root, , compare_symtree);

   free (st0);

[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

[koenigni at gcc dot gnu.org]

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

--- Comment #14 from koenigni at gcc dot gnu.org ---
Author: koenigni
Date: Wed Mar 22 19:12:24 2017
New Revision: 246406

URL: https://gcc.gnu.org/viewcvs?rev=246406=gcc=rev
Log:
2017-03-12 Nicolas Koenig <koeni...@student.ethz.ch>

PR fortran/39239
fortran/Changelog:  Add entry for rev. 246284.

Modified:
trunk/gcc/fortran/ChangeLog

[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

[koenigni at gcc dot gnu.org]

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

--- Comment #13 from koenigni at gcc dot gnu.org ---
Author: koenigni
Date: Wed Mar 22 19:08:36 2017
New Revision: 246405

URL: https://gcc.gnu.org/viewcvs?rev=246405=gcc=rev
Log:
2017-03-22 Nicolas Koenig <koeni...@student.ethz.ch>

PR fortran/39239
* gfortran.dg/equiv_constraint_bind_c.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/equiv_constraint_bind_c.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/69498] ICE on disjunct cases with displaced or incomplete embedded statement

[koenigni at gcc dot gnu.org]

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

--- Comment #4 from koenigni at gcc dot gnu.org ---
Author: koenigni
Date: Tue Mar 21 14:49:21 2017
New Revision: 246322

URL: https://gcc.gnu.org/viewcvs?rev=246322=gcc=rev
Log:

2017-03-18  Nicolas Koenig  <koeni...@student.ethz.ch>

PR fortran/69498
* decl.c (add_hidden_procptr_result): Fixed Refs count of the
created "ppr@" symbol.

2017-03-18  Nicolas Koenig  <koeni...@student.ethz.ch>

PR fortran/69498
* gfortran.dg/unexp_attribute.f90: New test


Added:
trunk/gcc/testsuite/gfortran.dg/unexp_attribute.f90
Modified:
trunk/gcc/fortran/decl.c

[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

[koenigni at gcc dot gnu.org]

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

--- Comment #12 from koenigni at gcc dot gnu.org ---
Author: koenigni
Date: Mon Mar 20 16:50:00 2017
New Revision: 246284

URL: https://gcc.gnu.org/viewcvs?rev=246284=gcc=rev
Log:

2017-03-12 Nicolas Koenig <koeni...@student.ethz.ch>

PR fortran/39239
* symbol.c (check_conflict): report an error if an EQUIVALENCE variable
is BIND(C).

2017-03-12 Nicolas Koenig <koeni...@student.ethz.ch>

PR fortran/39239
* gfortran.dg/equiv_constraint_bind_c.f90: New test.


Modified:
trunk/gcc/fortran/symbol.c

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

[koenigni at gcc dot gnu.org]

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

koenigni at gcc dot gnu.org changed:

   What|Removed |Added

 CC||koenigni at gcc dot gnu.org

--- Comment #12 from koenigni at gcc dot gnu.org ---
I just rerun the test and -to my horror- discovered that the test case I tried
to fix is not one from this bug, it must have slipped in the wrong folder when
I sorted the test cases. I'll make sure that won't happen again, sorry :(

For me only z4.f90 fails on trunk as well.