[Bug target/59888] Darwin linker error "illegal text-relocation" with -shared

[zbeekman at gmail dot com]

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

--- Comment #18 from Zaak  ---
(In reply to Iain Sandoe from comment #17)
> by the way, I haven't been able to find a C reproducer for this issue - if
> you feel we should have a testcase for it perhaps a link test for the
> fortran example would work?

It would be great to have a test to prevent future regressions here. I have no
experience contributing to GCC or using dejagnu but if people are having
trouble cooking up a C source to produce an object/library to link the Fortran
against, I can try to find something to trigger this.

As I mentioned previously this blocks gtk-fortran from linking on Darwin,
however both GTK and gtk-fortran are not adequately small reproducers.

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

[zbeekman at gmail dot com]

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

--- Comment #94 from Zaak  ---
OK, great. I was confused by the target changing from 9.1 to 9.2. Thanks!

On Fri, May 3, 2019 at 10:11 AM iains at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
>
> --- Comment #93 from Iain Sandoe  ---
> (In reply to Jakub Jelinek from comment #91)
> > GCC 9.1 has been released.
> (In reply to Zaak from comment #92)
> > Is my interpretation correct that the patch did not make it in time for
> GCC
> > 9.1? (I( want to make sure we're applying it in Homebrew if not.)
>
> the patch was applied before 9.1 branched, and is on the 9.1 branch.
> see: https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg00109.html
> which was bootstrapped with xc10.2 command line tools and SDK.
>
> it needs applying to 8.x and 7.x - which will happen soon.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

[zbeekman at gmail dot com]

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

--- Comment #92 from Zaak  ---
Is my interpretation correct that the patch did not make it in time for GCC
9.1? (I( want to make sure we're applying it in Homebrew if not.)

[Bug fortran/90133] [7/8/9/10 Regression] Linker error from accessing event_type via use association outside associate/block scope

[zbeekman at gmail dot com]

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

--- Comment #6 from Zaak  ---
Oh, I see, so the *bug* has been backported... sigh. Well thanks for localizing
it to the range r243909-r244868.

I may try to do a bisection search to find the culprit and work up a
fix/patch... I haven't contributed to GCC before though, if I need to sign a
CLA, etc. please point me in the right direction.

[Bug fortran/90133] [7/8/9/10 Regression] Linker error from accessing event_type via use association outside associate/block scope

[zbeekman at gmail dot com]

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

--- Comment #4 from Zaak  ---
Sure, I understand regresion, but perhaps I don't understand what you mean by
"has been backported to GCC6".

[Bug fortran/90133] [7/8/9/10 Regression] Linker error from accessing event_type via use association outside associate/block scope

[zbeekman at gmail dot com]

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

--- Comment #2 from Zaak  ---
Hi Dominique,

So this is fixed on GCC 6? But not Trunk? (Or more recent releases?)

[Bug fortran/88154] [F18] ICE: Intrinsic function '_gfortran_caf_get_team' (119) not recognized

[zbeekman at gmail dot com]

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

--- Comment #3 from Zaak  ---
Some additional test cases from the OC bug tracker. These fail using

gfortran -fcoarray=single

and when linking against opencoarrays, so it seems there is an issue on the GCC
side (possibly the OC side too, but let's get -fcoarray=single working first)

-8<

I get a compile error when trying to use the get_team() intrinsic:

program test_get_team
   use, intrinsic :: iso_fortran_env, only: team_type
   type(team_type) :: initial
   initial = get_team()
 end program test_get_team
Compiling the above, I get:

../get-team.f90:4:13:

initial = get_team()
 1
Error: Can't convert INTEGER(4) to TYPE(team_type) at (1)

So, it appears that get_team() returns an integer.

FURTHER...

I then changed the return type to an integer:

program test_get_team
   use, intrinsic :: iso_fortran_env, only: team_type
   integer :: tn
   tn = get_team()
 end program test_get_team

I then get a internal compiler error

[Bug fortran/88154] [F18] ICE: Intrinsic function '_gfortran_caf_get_team' (119) not recognized

[zbeekman at gmail dot com]

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

Zaak  changed:

   What|Removed |Added

 CC||zbeekman at gmail dot com

--- Comment #2 from Zaak  ---
xref to the OC bug tracker:
https://github.com/sourceryinstitute/OpenCoarrays/issues/545

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

[zbeekman at gmail dot com]

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

--- Comment #89 from Zaak  ---
Anyone have a patch for 4.9? A user wants one, but I can't build 4.9 from
source on Mojave.

[Bug target/59888] Darwin linker error "illegal text-relocation" with -shared

[zbeekman at gmail dot com]

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

Zaak  changed:

   What|Removed |Added

 CC||zbeekman at gmail dot com

--- Comment #15 from Zaak  ---
This is preventing gtk-fortran from compiling on macOS with GCC 8.3, AFAICT.

cd /tmp/gtk-fortran-20190424-36870-ggjnvc/gtk-fortran-19.04.gtk3.24.8/build/src
&& /usr/local/Cellar/cmake/3.14.3/bin/cmake -E cmake_link_script
CMakeFiles/gtk-fortran_shared.dir/link.txt --verbose=1
/usr/local/bin/gfortran -pthread -O2 -fPIC -dynamiclib
-Wl,-headerpad_max_install_names -compatibility_version 0.1.0 -current_version
0.1.0 -o libgtk-3-fortran.0.1.dylib -install_name
@rpath/libgtk-3-fortran.0.1.dylib
CMakeFiles/gtk-fortran_object.dir/atk-auto.f90.o
CMakeFiles/gtk-fortran_object.dir/cairo-auto.f90.o
CMakeFiles/gtk-fortran_object.dir/gdk-auto.f90.o
CMakeFiles/gtk-fortran_object.dir/gdk-pixbuf-auto.f90.o
CMakeFiles/gtk-fortran_object.dir/glib-auto.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-hl.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-hl-container.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-hl-button.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-hl-entry.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-hl-tree.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-hl-menu.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-hl-combobox.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-hl-spin-slider.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-hl-chooser.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-hl-dialog.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-hl-progress.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-hl-accelerator.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-hl-infobar.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-hl-assistant.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-hl-misc.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-draw-hl.f90.o
CMakeFiles/gtk-fortran_object.dir/gtk-sup.f90.o
CMakeFiles/gtk-fortran_object.dir/gdk-pixbuf-hl.f90.o
CMakeFiles/gtk-fortran_object.dir/pango-auto.f90.o
CMakeFiles/gtk-fortran_object.dir/gdkevents-auto3.f90.o
CMakeFiles/gtk-fortran_object.dir/unixonly-auto.f90.o 
-L/usr/local/Cellar/plplot/5.14.0_1/lib
-Wl,-rpath,/usr/local/Cellar/plplot/5.14.0_1/lib
/usr/local/lib/libatk-1.0.dylib /usr/local/lib/libcairo.dylib
/usr/local/lib/libgdk-3.0.dylib /usr/local/lib/libgdk_pixbuf-2.0.dylib
/usr/local/lib/libglib-2.0.dylib /usr/local/lib/libgio-2.0.dylib
/usr/local/lib/libgobject-2.0.dylib /usr/local/lib/libgtk-3.0.dylib
/usr/local/lib/libpango-1.0.dylib
ld: illegal text-relocation to '_hl_gtk_listn_edit_cb' in
CMakeFiles/gtk-fortran_object.dir/gtk-hl-tree.f90.o from 'lC72' in
CMakeFiles/gtk-fortran_object.dir/gtk-hl-tree.f90.o for architecture x86_64
collect2: error: ld returned 1 exit status
make[2]: *** [src/libgtk-3-fortran.0.1.dylib] Error 1
make[1]: *** [src/CMakeFiles/gtk-fortran_shared.dir/all] Error 2
make: *** [all] Error 2

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

[zbeekman at gmail dot com]

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

--- Comment #86 from Zaak  ---
> (In reply to fink from comment #85)
> 
> Zaak,
> I have patches for Fink for gcc5-gcc8 release tarballs. I'm waiting for the
> gcc5 build to finish before I make a public commit, which should be tonight.

Thanks! I'll keep an eye out for those, but please don't hesitate to ping me
when you push them out.

In the meantime, a user has adapted the patch for gcc-8 and can  be seen here:
https://github.com/androidports/homebrew-patch/blob/master/Formula/gcc.rb#L153-L255

I'm currently compiling and testing and have opened up a PR on homebrew-core: 
https://github.com/Homebrew/homebrew-core/pull/39041

[Bug bootstrap/89864] gcc fails to build/bootstrap with XCode 10.2

[zbeekman at gmail dot com]

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

--- Comment #84 from Zaak  ---
Ian, Jurgen, et al.,

Thanks for your hard work getting the patch created and validated!

I'm a mac Homebrew maintainer, and was hoping to get a patch into the GCC-8
formula sooner rather than later as this Xcode regression makes building
certain software e.g., libMesh[1], MOOSE[2] impossible (or difficult, requiring
patching that might be breaking things).

Is there a patch somewhere that resolves this and will apply cleanly to a GCC
8.3 tarball? I'd like to test the backport, and get the patch ready to include
in brewed GCCs.

If I revision bump the formula after including the patch, our CI system will
rebuild all dependent formulae which should be quite a thorough validation of
the patch.

Apologies if an 8.3 patch went by already, if so, please point me in the right
direction.

Cheers!
-Izaak "Zaak" Beekman

[Bug fortran/89830] intrinsic repeat() is completely broken

[zbeekman at gmail dot com]

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

--- Comment #5 from Zaak  ---
Sorry about the bad reproducer code (name conflict).

To create reproducible builds one must be able to strip or at least map source
file references from the source/build directory to something more generic or
universal.

For example, I usually create a build subdirectory of my source tree and
compile in there. Being able to omit directories in filenames is a critical
part of this.

In this particular example, I suppose that I can likely pass a relative path to
the compiler rather than the full path to the source file.

But, it would be nice if there were a mechanism to strip paths from
warning/error messages like this.

I have tried:

 -fno-working-directory
 -ffile-prefix-map=OLD=NEW
 -fdebug-prefix-map=OLD=NEW
 -fmacro-prefix-map=OLD=NEW

and the error message from `repeat()` stubbornly persists.

Also, given that my reproducer code was dumb, should we close this an open a
new issue to track the paths getting embedded? Or should this issue stay open
to discuss/resolve the paths? Personally I think it would be clearer if I
closed this as invalid and submitted a new issue demonstrating the path issue.

[Bug fortran/89830] New: intrinsic repeat() is completely broken

[zbeekman at gmail dot com]

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

Bug ID: 89830
   Summary: intrinsic repeat() is completely broken
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zbeekman at gmail dot com
  Target Milestone: ---

Created attachment 46026
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46026=edit
Broken repeat example

The non-elemental intrinsic string function REPEAT() is completely broken. With
GFortran 8.3.0 installed via macOS Homebrew the following program fails to
compile:

```Fortran
program repeat
  implicit none
  write(*,*) repeat('a',5)
end program
```

It was compiled with:

```
gfortran -o repeat repeat_deterministic.f90
```

and produces the following error message:

```
repeat_deterministic.f90:3:19:

   write(*,*) repeat('a',5)
   1
Error: Symbol at (1) is not appropriate for an expression
```

Furthermore, there is an error message embedded in the `REPEAT()` function
which breaks deterministic builds! It is unclear to me why the following
example compiles while the one above does not:

```Fortran
  subroutine co_broadcast_c_char(a,source_image,stat,errmsg)
character(kind=c_char,len=*), intent(inout), volatile, target :: a
integer(c_int), intent(in), optional :: source_image
integer(c_int), intent(out), optional:: stat
character(kind=1,len=*), intent(out), optional :: errmsg
! Local variables and constants:
integer(c_int), allocatable :: a_cast_to_integer_array(:)

! Convert "a" to an integer(c_int) array where each 32-bit integer element
holds four 1-byte characters
a_cast_to_integer_array = transfer(a,[0_c_int])
! Broadcast the integer(c_int) array
call co_broadcast_c_int(a_cast_to_integer_array,source_image, stat, errmsg)
! Recover the characters from the broadcasted integer(c_int) array
a = transfer(a_cast_to_integer_array,repeat(' ',len(a)))

  end subroutine
```

(This example is from OpenCoarrays 2.6.1, or you can find it at
https://github.com/sourceryinstitute/OpenCoarrays/blob/8ceb2ce8912f4f0d5317a6cce248d042b3942280/src/extensions/opencoarrays.F90#L590)

When compiled, even with the `-fno-working-directory` flag, the object file
still contains references to the full path to the source file:

```
$ strings
src/mpi/CMakeFiles/opencoarrays_mod.dir/__/extensions/opencoarrays.F90.o

Argument NCOPIES of REPEAT intrinsic is negative (its value is %ld)
At line 590 of file
/Users/ibeekman/Sandbox/OpenCoarrays/src/extensions/opencoarrays.F90
```

[Bug fortran/86863] [OOP][F2008] type-bound module procedure name not recognized

[zbeekman at gmail dot com]

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

Zaak  changed:

   What|Removed |Added

 CC||zbeekman at gmail dot com

--- Comment #2 from Zaak  ---
It appears that `module procedure` can also cause a link-time error that will
get resolved when switching to `module subroutine`. I haven't dug into this too
much, but I get missing/unresolved symbols, but if I switch the implementation
to `module subroutine` then the unresolved symbols go away.

The linker errors look like:

Undefined symbols for architecture x86_64:
  "___vtab_fgr_mesh_Fgr.5058", referenced from:
  ___timestep_MOD_store in Timestep_implementation.f90.o
  "___vtab_grid_index_Fd_grid.5056", referenced from:
  ___timestep_MOD_store in Timestep_implementation.f90.o
  "___vtab_material_type_Material.5041", referenced from:
  ___timestep_MOD_store in Timestep_implementation.f90.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

Changing `module procedure` to `module subroutine` and adding the interface
variables, variable declarations, etc. resolves this linker issue. So it seems
that the compiler generates code looking for the wrong symbols when `module
procedure` is used vs `module subroutine` inside of a submodule (maybe?)

I'm not entirely sure how to go about creating a minimally complete verifiable
example for this. Compilation was done with GFortran 8.2 (installed via
Homebrew) on macOS and the CMake based build system has the compiler drive the
linker, we don't call ld directly ourselves anywhere.

[Bug fortran/85507] [6/7/8/9 Regression] ICE in gfc_dep_resolver, at fortran/dependency.c:2258

[zbeekman at gmail dot com]

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

--- Comment #14 from Zaak  ---
Damn, it would have been nice if this patch made it in.

[Bug fortran/68933] ICE when mixing "-fprofile-arcs -ftest-coverage" and "-fcoarray=lib" on gcc-6 only

[zbeekman at gmail dot com]

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

--- Comment #6 from Zaak  ---
Thanks, I'll check it out.
On Sat, Apr 21, 2018 at 8:20 AM dominiq at lps dot ens.fr <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933
>
> --- Comment #5 from Dominique d'Humieres  ---
> It seems to work with 7.3.0.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/83021] [7 Regression] gfortran segfault

[zbeekman at gmail dot com]

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

Zaak  changed:

   What|Removed |Added

 CC||zbeekman at gmail dot com

--- Comment #2 from Zaak  ---
I suspect the source code in question is the same as
https://github.com/sourceryinstitute/OpenCoarrays/blob/8eab16936fb958746575f5c9580ba521320e0444/src/tests/integration/pde_solvers/coarrayBurgers/local_field.F90

[Bug fortran/71729] -Wl,-z,noexecstack Segmentation fault

[zbeekman at gmail dot com]

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

Zaak  changed:

   What|Removed |Added

 CC||zbeekman at gmail dot com

--- Comment #3 from Zaak  ---
> It means i have to submit the bug to mpich developers that add this flag in 
> the alias mpif90 ?

Well I'm guessing that it's the fedora package system that's adding the
-Wl,-z,noexecstack to the mpich wrapper... but I could be wrong, it could be
MPICH itself. But either way, the bug is with MPICH or the fedora package of
MPICH.

[Bug fortran/68933] ICE when mixing "-fprofile-arcs -ftest-coverage" and "-fcoarray=lib" on gcc-6 only

[zbeekman at gmail dot com]

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

--- Comment #4 from Zaak  ---
Fabulous, I'll verify soon (for my own satisfaction)
On Sun, Jan 22, 2017 at 12:31 PM vehre at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933
>
> vehre at gcc dot gnu.org changed:
>
>What|Removed |Added
>
> 
>   Known to work||7.0
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/78505] [F08] Coarray source allocation not synchronizing on oversubscribed cores

[zbeekman at gmail dot com]

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

Zaak  changed:

   What|Removed |Added

 CC||zbeekman at gmail dot com

--- Comment #9 from Zaak  ---
Will this fix get back ported to the 6 and 5 branches?

[Bug middle-end/68933] ICE when mixing "-fprofile-arcs -ftest-coverage" and "-fcoarray=lib"

[zbeekman at gmail dot com]

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

--- Comment #3 from Zaak  ---
I have confirmed this bug. Are has anyone else looked at this?

[Bug middle-end/68933] ICE when mixing "-fprofile-arcs -ftest-coverage" and "-fcoarray=lib"

[zbeekman at gmail dot com]

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

--- Comment #1 from Zaak  ---
I have confirmed this is a problem on OS X as well, although perhaps the
diagnostics are slightly different?

$ /usr/local/bin/gfortran -I/usr/local/homebrew/Cellar/mpich/3.2/include
-fcoarray=lib -fprofile-arcs -ftest-coverage coarray_distributed_transpose.F90
-c -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gfortran
Target: x86_64-apple-darwin14.5.0
Configured with: ../configure --build=x86_64-apple-darwin14.5.0
--prefix=/usr/local/homebrew/Cellar/gcc/5.3.0
--libdir=/usr/local/homebrew/Cellar/gcc/5.3.0/lib/gcc/5
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-5
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking
--enable-checking=release --enable-lto --with-build-config=bootstrap-debug
--disable-werror --with-pkgversion='Homebrew gcc 5.3.0'
--with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin
--disable-nls --enable-multilib
Thread model: posix
gcc version 5.3.0 (Homebrew gcc 5.3.0)
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.5' '-I'
'/usr/local/homebrew/Cellar/mpich/3.2/include' '-fcoarray=lib' '-fprofile-arcs'
'-ftest-coverage' '-c' '-v' '-mtune=core2'

/usr/local/homebrew/Cellar/gcc/5.3.0/libexec/gcc/x86_64-apple-darwin14.5.0/5.3.0/f951
coarray_distributed_transpose.F90
-cpp=/var/folders/4t/my3vyzsx7pg80tc_cxhyfc7hgp/T//ccN09K7q.f90 -quiet -v
-I /usr/local/homebrew/Cellar/mpich/3.2/include -D__DYNAMIC__
coarray_distributed_transpose.F90 -fPIC -quiet -dumpbase
coarray_distributed_transpose.F90 -mmacosx-version-min=10.10.5 -mtune=core2
-auxbase coarray_distributed_transpose -version -fcoarray=lib -fprofile-arcs
-ftest-coverage -fintrinsic-modules-path
/usr/local/homebrew/Cellar/gcc/5.3.0/lib/gcc/5/gcc/x86_64-apple-darwin14.5.0/5.3.0/finclude
-o /var/folders/4t/my3vyzsx7pg80tc_cxhyfc7hgp/T//ccK2CN3d.s
GNU Fortran (Homebrew gcc 5.3.0) version 5.3.0 (x86_64-apple-darwin14.5.0)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version
3.1.3-p2, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/homebrew/Cellar/gcc/5.3.0/lib/gcc/5/gcc/x86_64-apple-darwin14.5.0/5.3.0/../../../../../../x86_64-apple-darwin14.5.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/homebrew/Cellar/mpich/3.2/include

/usr/local/homebrew/Cellar/gcc/5.3.0/lib/gcc/5/gcc/x86_64-apple-darwin14.5.0/5.3.0/finclude

/usr/local/homebrew/Cellar/gcc/5.3.0/lib/gcc/5/gcc/x86_64-apple-darwin14.5.0/5.3.0/include
 /usr/local/include
 /usr/local/homebrew/Cellar/gcc/5.3.0/include

/usr/local/homebrew/Cellar/gcc/5.3.0/lib/gcc/5/gcc/x86_64-apple-darwin14.5.0/5.3.0/include-fixed
 /usr/include
End of search list.
GNU Fortran2008 (Homebrew gcc 5.3.0) version 5.3.0 (x86_64-apple-darwin14.5.0)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version
3.1.3-p2, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
coarray_distributed_transpose.F90:111:0:

   use run_size
 ^
internal compiler error: Segmentation fault: 11

coarray_distributed_transpose.F90:111:0: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug middle-end/68933] ICE when mixing "-fprofile-arcs -ftest-coverage" and "-fcoarray=lib"

[zbeekman at gmail dot com]

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

--- Comment #2 from Zaak  ---
I have confirmed this is a problem on OS X as well, although perhaps the
diagnostics are slightly different?

$ /usr/local/bin/gfortran -I/usr/local/homebrew/Cellar/mpich/3.2/include
-fcoarray=lib -fprofile-arcs -ftest-coverage coarray_distributed_transpose.F90
-c -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gfortran
Target: x86_64-apple-darwin14.5.0
Configured with: ../configure --build=x86_64-apple-darwin14.5.0
--prefix=/usr/local/homebrew/Cellar/gcc/5.3.0
--libdir=/usr/local/homebrew/Cellar/gcc/5.3.0/lib/gcc/5
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-5
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking
--enable-checking=release --enable-lto --with-build-config=bootstrap-debug
--disable-werror --with-pkgversion='Homebrew gcc 5.3.0'
--with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin
--disable-nls --enable-multilib
Thread model: posix
gcc version 5.3.0 (Homebrew gcc 5.3.0)
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.10.5' '-I'
'/usr/local/homebrew/Cellar/mpich/3.2/include' '-fcoarray=lib' '-fprofile-arcs'
'-ftest-coverage' '-c' '-v' '-mtune=core2'

/usr/local/homebrew/Cellar/gcc/5.3.0/libexec/gcc/x86_64-apple-darwin14.5.0/5.3.0/f951
coarray_distributed_transpose.F90
-cpp=/var/folders/4t/my3vyzsx7pg80tc_cxhyfc7hgp/T//ccN09K7q.f90 -quiet -v
-I /usr/local/homebrew/Cellar/mpich/3.2/include -D__DYNAMIC__
coarray_distributed_transpose.F90 -fPIC -quiet -dumpbase
coarray_distributed_transpose.F90 -mmacosx-version-min=10.10.5 -mtune=core2
-auxbase coarray_distributed_transpose -version -fcoarray=lib -fprofile-arcs
-ftest-coverage -fintrinsic-modules-path
/usr/local/homebrew/Cellar/gcc/5.3.0/lib/gcc/5/gcc/x86_64-apple-darwin14.5.0/5.3.0/finclude
-o /var/folders/4t/my3vyzsx7pg80tc_cxhyfc7hgp/T//ccK2CN3d.s
GNU Fortran (Homebrew gcc 5.3.0) version 5.3.0 (x86_64-apple-darwin14.5.0)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version
3.1.3-p2, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/homebrew/Cellar/gcc/5.3.0/lib/gcc/5/gcc/x86_64-apple-darwin14.5.0/5.3.0/../../../../../../x86_64-apple-darwin14.5.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/homebrew/Cellar/mpich/3.2/include

/usr/local/homebrew/Cellar/gcc/5.3.0/lib/gcc/5/gcc/x86_64-apple-darwin14.5.0/5.3.0/finclude

/usr/local/homebrew/Cellar/gcc/5.3.0/lib/gcc/5/gcc/x86_64-apple-darwin14.5.0/5.3.0/include
 /usr/local/include
 /usr/local/homebrew/Cellar/gcc/5.3.0/include

/usr/local/homebrew/Cellar/gcc/5.3.0/lib/gcc/5/gcc/x86_64-apple-darwin14.5.0/5.3.0/include-fixed
 /usr/include
End of search list.
GNU Fortran2008 (Homebrew gcc 5.3.0) version 5.3.0 (x86_64-apple-darwin14.5.0)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version
3.1.3-p2, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
coarray_distributed_transpose.F90:111:0:

   use run_size
 ^
internal compiler error: Segmentation fault: 11

coarray_distributed_transpose.F90:111:0: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/65144] Problems printing, reading and accessing substrings of ISO_10646 character variables

[zbeekman at gmail dot com]

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

--- Comment #9 from Zaak zbeekman at gmail dot com ---
I'm sorry for the duplicate commet and typo... it should be PR 65141 NOT 151

[Bug fortran/65144] Problems printing, reading and accessing substrings of ISO_10646 character variables

[zbeekman at gmail dot com]

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

--- Comment #7 from Zaak zbeekman at gmail dot com ---
(In reply to Dominique d'Humieres from comment #1)
 AFAICT the substring problem occurs for PARAMETER only:
 
 program test3
   INTEGER,PARAMETER :: ucs4 = selected_char_kind(ISO_10646)
   CHARACTER(3,UCS4),PARAMETER ::
 unip=CHAR(INT(Z'5e74'),UCS4)//CHAR(INT(Z'6708'),ucs4)//CHAR(INT(Z'65e5'),
 ucs4)
   character(3,UCS4) :: uni
   uni = unip
   open(6, encoding=utf-8)
   print *, uni
   print *, uni(2:2)
   print *, unip
   print *, ',unip(1:1),'
 end program test3
 
 gives at run time
 
  年月日
  月
  年月日
  't'

As Dominique noted a problem does exist with ISO 10646 characters with the
parameter attribute. Pleas see PR 65151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65141 for more details

[Bug fortran/65144] Problems printing, reading and accessing substrings of ISO_10646 character variables

[zbeekman at gmail dot com]

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

--- Comment #8 from Zaak zbeekman at gmail dot com ---
(In reply to Dominique d'Humieres from comment #1)
 AFAICT the substring problem occurs for PARAMETER only:
 
 program test3
   INTEGER,PARAMETER :: ucs4 = selected_char_kind(ISO_10646)
   CHARACTER(3,UCS4),PARAMETER ::
 unip=CHAR(INT(Z'5e74'),UCS4)//CHAR(INT(Z'6708'),ucs4)//CHAR(INT(Z'65e5'),
 ucs4)
   character(3,UCS4) :: uni
   uni = unip
   open(6, encoding=utf-8)
   print *, uni
   print *, uni(2:2)
   print *, unip
   print *, ',unip(1:1),'
 end program test3
 
 gives at run time
 
  年月日
  月
  年月日
  't'

As Dominique noted a problem does exist with ISO 10646 characters with the
parameter attribute. Pleas see PR 65151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65141 for more details

[Bug fortran/65144] Problems printing, reading and accessing substrings of ISO_10646 character variables

[zbeekman at gmail dot com]

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

--- Comment #2 from Zaak zbeekman at gmail dot com ---
Try this:

program test3
  INTEGER,PARAMETER :: ucs4 = selected_char_kind(ISO_10646)
  CHARACTER(3,UCS4),PARAMETER ::
unip=CHAR(INT(Z'5e74'),UCS4)//CHAR(INT(Z'6708'),ucs4)//CHAR(INT(Z'65e5'),ucs4)
  character(3,UCS4) :: uni
  uni = unip
  open(6, encoding=utf-8)
  print *, uni
  print *, uni(2:2)
  print *, unip
  print *, ',unip(1:1),'
  call write_it(unip(2:2))
contains
subroutine write_it(str)
character(len=*,kind=UCS4) ,intent(in) :: str
print *, str
end subroutine write_it
end program test3


I get this error message when I try to compile:

$ gfortran test3.f90
test3.f90:11.16:

  call write_it(unip(2:2))
1
Error: Type mismatch in argument 'str' at (1); passed CHARACTER(1) to
CHARACTER(4)

[Bug fortran/65144] Problems printing, reading and accessing substrings of ISO_10646 character variables

[zbeekman at gmail dot com]

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

--- Comment #3 from Zaak zbeekman at gmail dot com ---
Similarly if I try to use a substring in an if statement:

program test3
  INTEGER,PARAMETER :: ucs4 = selected_char_kind(ISO_10646)
  CHARACTER(3,UCS4),PARAMETER ::
unip=CHAR(INT(Z'5e74'),UCS4)//CHAR(INT(Z'6708'),ucs4)//CHAR(INT(Z'65e5'),ucs4)
  character(3,UCS4) :: uni
  uni = unip
  open(6, encoding=utf-8)
  print *, uni
  print *, uni(2:2)
  print *, unip
  print *, ',unip(1:1),'
  if ( unip(2:2) == CHAR(INT(Z'6708'),ucs4)) print*, unip(2:2) ! This SHOULD be
true
end program test3

I get the following error:

$ gfortran --version  gfortran ISO_10646.f90
GNU Fortran (Homebrew gcc 4.9.2_1) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

ISO_10646.f90:11.7:

  if ( unip(2:2) == CHAR(INT(Z'6708'),ucs4)) print*, unip(2:2) ! This SHOULD be
   1
Error: Operands of comparison operator '==' at (1) are
CHARACTER(1)/CHARACTER(4)

[Bug fortran/65144] Problems printing, reading and accessing substrings of ISO_10646 character variables

[zbeekman at gmail dot com]

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

--- Comment #4 from Zaak zbeekman at gmail dot com ---
My apologies, I responded too quickly to Dominique... I thought we were talking
about: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65125 and failed to realize
that this was something (related?) different that that bug. I'll work on a more
concise version of the reproducer I attached here, to try to illustrate this
issue more clearly. I might not get to it until later tonight or tomorrow,
however.

[Bug preprocessor/49150] Preprocessing fortran code with the `-M` flag to automatically resolve dependencies and produce makefile rules rendered useless by requiring .mod files be present

[zbeekman at gmail dot com]

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

Zaak zbeekman at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Zaak zbeekman at gmail dot com ---
Somehow I seem to have duplicated 49149. Furthermore, at least for gfortran
4.9.2, the issue referenced in comment 13 concerning the intrinsic modules has
been fixed, and a helpful person on a different forum taught me how to include
rules to generate dependency info, and that make will reattempt updating any
included makefiles for which there are rules whenever any of them change. This
lets make recurse through the dependencies and find those files that have no
other dependencies. The dependency rule for these files gets included in the
makefile, then make reattempts to build all the outstanding dependencies. The
fortran files that only depend on those files for which we now have rules get
their rules resolved and included in the makefile, and so on and so forth until
all the dependencies have been resolved. While it would be more convenient and
efficient to process the dependency directly from the source, without needing
.mod files to be present, this is an acceptable work around for me, so I have
closed both issues.

*** This bug has been marked as a duplicate of bug 49149 ***

[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files

[zbeekman at gmail dot com]

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

--- Comment #16 from Zaak zbeekman at gmail dot com ---
*** Bug 49150 has been marked as a duplicate of this bug. ***

[Bug fortran/65144] Problems printing, reading and accessing substrings of ISO_10646 character variables

[zbeekman at gmail dot com]

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

--- Comment #5 from Zaak zbeekman at gmail dot com ---
Alright, I agree with Dominique, this bug report was erroneous on my part. In
the two follow up programs I posted, (modifing Dominique's) I accidentally used
`unip` substrings instead of `uni` substrings.

In my original post the issue is that I didn't open stdout with
`encoding='utf-8'` and gfortran doesn't allow unicode/utf8 encoded source files
(trying to add `-finput-charset=utf8` to the gfortran flags results in an
error: f951: warning: command line option '-finput-charset=utf8' is valid for
C/C++/ObjC/ObjC++ but not for Fortran)

I think I'll close this unless anyone objects.

[Bug fortran/65144] Problems printing, reading and accessing substrings of ISO_10646 character variables

[zbeekman at gmail dot com]

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

Zaak zbeekman at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Zaak zbeekman at gmail dot com ---
See discussion below, especially my last comment for why this is an invalid
bug.

[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files

[zbeekman at gmail dot com]

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

Zaak zbeekman at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #15 from Zaak zbeekman at gmail dot com ---
Some very helpful person, on a different form, pointed out to me that there is
a way to use include statements in makefiles, to include each individual
dependency file output by the gfortran's -M option, and to set this up so that
it will attempt to generate all the includes, even if one fails. Then Make will
realize that the Makefile itself (via any successfuly included dependency) is
out of date, and try to rebuild all the included dependency files if they are
given as targets with build rules. This will recursively (and inefficiently)
automatically resolve the dependencies, and update the makefile. If I get
around to it, I'll post an example here.

It appears in gfortran 4.9.2 that the issue with the intrinsic modules comment
13 has also been fixed. Apparently someone else agreed with me that this was
indeed an issue.

As things seem to be fixed, and there is an acceptable work around for the main
issue, I'm going to mark this as resolved.

[Bug fortran/65125] ISO_10646 characters and transfer statement

[zbeekman at gmail dot com]

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

Zaak zbeekman at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Zaak zbeekman at gmail dot com ---
After mucking around some more and realizing that gfortran can't/won't handle
input source files with utf-8 encoding and non ascii files, I also discovered
the `-fbackslash` flag as a means of embedding non-ascii characters in strings.
When I use this approach things work as I would have expected and I'll be
closing this bug, as invalid, since it appears there is no bug here.

[Bug fortran/65141] New: ISO_10646 constant parameters convert kind when used with substring references

[zbeekman at gmail dot com]

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

Bug ID: 65141
   Summary: ISO_10646 constant parameters convert kind when used
with substring references
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zbeekman at gmail dot com

Substring references with ISO_10646 kind characters cause the resulting
expression to be DEFAULT kind rather than ISO_10646.

Reproducer:

program ISO_CONST_SUBST_PR
implicit none
integer, parameter :: UNICODE=selected_char_kind('ISO_10646')
integer, parameter :: DEFAULT=selected_char_kind('DEFAULT')
character(kind=UNICODE,len=*),parameter :: string='my string'

write(*,'(A, I0, A, I0)') 'Unicode and default character kinds are:
',UNICODE,', ',DEFAULT
write(*,'(A, I0)') 'kind(string) should be UNICODE and is UNICODE for me:
',kind(string)
write(*,'(A, I0)') 'kind(string(2:4)) should be UNICODE and is DEFAULT for
me: ',kind(string(2:4))
end program ISO_CONST_SUBST_PR

[Bug fortran/65144] New: Problems printing, reading and accessing substrings of ISO_10646 character variables

[zbeekman at gmail dot com]

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

Bug ID: 65144
   Summary: Problems printing, reading and accessing substrings of
ISO_10646 character variables
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zbeekman at gmail dot com

Created attachment 34820
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34820action=edit
reproducer program

This bug may be related to 65125,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65125 I’m not sure.

Basically it seems that 3 things are happening:

 - Unicode strings aren’t being output correctly to to stdout, it seems only
the first few characters are output. This *could* be an issue related to what
gfortran thinks the encoding of the tty is. Further testing reveals that it
seems to output to a file opened with uff-8 encoding OK
 - Unicode substrings retain the correct kind as long as they are not
parameters (see 65141 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65141) BUT
the resulting representation seems to be that of DEFAULT character kind. (i.e.
the characters change when a substring expression is used, characters 2-4 in
str(2:4) are different than characters 2-4 in str). This happens even when
writing to a file opened with uff-8 encoding.

[Bug fortran/65125] New: ISO_10646 characters and transfer statement

[zbeekman at gmail dot com]

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

Bug ID: 65125
   Summary: ISO_10646 characters and transfer statement
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zbeekman at gmail dot com

Created attachment 34810
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34810action=edit
reproducer program

I am on OS X Yosemite, 10.10.2 with a 64bit Intel CPU. 
Gfortran is version: NU Fortran (Homebrew gcc49 4.9.2_1 --enable-fortran) 4.9.2

I'm trying to make a portable json library that will behave gracefully when
encountering compilers whose ISO_10646 support is lacking. To achieve this, for
certain variables use the character kind defined as:

integer, parameter :: CK =
merge(tsource=selected_char_kind('ISO_10646'),fsource=selected_char_kind('DEFAULT'),mask=selected_char_kind('ISO_10646')
/= -1)

The error handling of the library needs a way to both DEFAULT and ISO_10646
characters, but overloading the error handling routine to have two interfaces
won't work because when ISO_10646 *isn't* supported the two specific routines
will have matching interfaces. As a work around, I would like to print the hex
representation of characters that are `kind=CK` that is possibly ISO_10646 or
DEFAULT. To accomplish this I have written a function `char_to_hex(c)` to try
to print the hex representation of the character. To do this, I am using
`transfer()` to puth the passed in single character into a sufficiently large
integer, and using the `z8.8` edit descriptor to convert to the function result
which is ALWAYS represented in `kind='DEFAULT'` characters (so that I can
safely pass it to the error handling routine).

The problem is that it appears the transfer statement is only writing 2 nibbles
(one byte) to the integer, or  the z8.8 is only fetching two nibbles of the
int32 integer. Forexample, the output for a Unicode SNOWFLAKE is 0x00E2
when it should be: 0x00E29d84. I think the problem is the transfer statement,
since I observe some strange behavior if I modify the char_to_hex() function to
accept len=4 character strings, and adjust the inputs to be the character in
question followed by 4 spaces, and adjust the storage container to int64 and
edit descriptor to z18.18. Now SNOWFLAKE prints out as 0x0x009D00E2:
two most significant nibbles are on the right, then 6 zero nibbles to the left,
the 3rd and 4th most significant nibbles, then more zeroes.

Am I missing something? If not, I think this is a bug.

[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files

[zbeekman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149

--- Comment #14 from Zaak zbeekman at gmail dot com 2011-09-03 14:46:57 UTC 
---
cricket

[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files

[zbeekman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149

--- Comment #3 from Zaak zbeekman at gmail dot com 2011-08-31 19:49:20 UTC ---
When I pass -E some strange behaviour occurs. First of all the code is
preprocessed with the c preprocessor and unless the -o flag is passed the
output is written to standard out, so this text will get included in the .d
dependency definition files which are to be included in the makefile. One can
avoid this issue if one passes -o /dev/null or does something clever with sed.
A second side effect of -E is that the module dependencies are no longer
included in the output which again renders this useless. After passing through
the sed command (as outlined in the GNU Make documentation) the last line of
modtypes.d went from:

modtypes.o types.mod: modtypes.f90

to

modtypes.o: modtypes.f90

[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files

[zbeekman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149

--- Comment #4 from Zaak zbeekman at gmail dot com 2011-08-31 19:58:41 UTC ---
Created attachment 25155
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25155
test case files with Makefile

The Makefile.alt is configured to pass -E and -o /dev/null when building the
dependency lists, while the original Makefile does not. In my opinion, the
original Makefile should build any object in the project IF gfortran were bug
free.

[Bug preprocessor/44526] libcpp should avoid circular dependencies

[zbeekman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44526

Zaak zbeekman at gmail dot com changed:

   What|Removed |Added

 CC||zbeekman at gmail dot com

--- Comment #2 from Zaak zbeekman at gmail dot com 2011-08-31 20:06:03 UTC ---
See also bug #49149: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149

[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files

[zbeekman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149

--- Comment #6 from Zaak zbeekman at gmail dot com 2011-08-31 22:01:06 UTC ---
I ma not saying gfortran is entirely broken, i'm merely claiming that there is
a bug in the dependency resolution feature. Please see GNU Make documentation
here for more information about Generating Prerequisites Automatically:
http://www.gnu.org/software/make/manual/make.html#Automatic-Prerequisites

There is nothing wrong with my makefile. GNU make looks for rules to build any
included makefiles and builds and updates them before running the rest of the
makefile. It is this very step that gives me problems too, but because it
requires the presence of types.mod before it can run the rule to make
modutils.d and myprog.d. The rule to make these files uses gfortran's
dependency resolution features which is where the problem is. The following
step is what is causing the failure:

gccbug $ gfortran -M -cpp  modutils.f90 | sed '1 s/^/modutils.d /'  modutils.d

This is perfectly reasonable thing to want to do and produces the following
output:

modutils.f90:2.11:

  USE types
   1
Fatal Error: Can't open module file 'types.mod' for reading at (1): No such
file or directory

The whole point, again, is that we should not need the binary .mod files to
accomplish dependency resolution because these .mod files have dependencies
which must be resolved in order to create them. The source code file should be
parsed for binary objects (.o and .mod) which it produces and which it depends
on. The parsing of these source codes and the extraction of this information
should not require dependencies and should be order agnostic.

I hope you are less confused now.

[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files

[zbeekman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149

--- Comment #8 from Zaak zbeekman at gmail dot com 2011-08-31 22:27:40 UTC ---
(In reply to comment #7)
 On Wed, Aug 31, 2011 at 10:01:06PM +, zbeekman at gmail dot com wrote:
  
  I hope you are less confused now.
  
 
 I'm not confused.  I do, however, use the grey matter
 between my ears to write my Makefiles.
 
 gfortran requires that the *.mod are present to
 parse your code.  Sorry if you cannot deal with 
 that fact.

I didn't mean any insult, I am not trying to troll or start a flame war. I'm
sorry if I offended you in any way. I would appreciate you telling me why you
think my makefile is wrong rather than just insulting me. Did you read the link
to the GNUmake manpage? Did you try executing the command outside of the
makefile?

The whole point of having dependency generation capabilities is to do EXACTLY
what I'm trying to do. The .mod files are the difficulty resolving Fortran
dependencies and I don't see what the use of a tool to resolve dependencies is,
if you need to already have those dependencies resolved apriori to use the
tool. If you can show me how to write a makefile with pattern rules that will
automatically resolve dependencies and uses only brief, terse, pattern rules
you will forever be my hero.

How would you write a makefile to automatically build fortran codes, and
resolve their dependencies without explicitly hand coding the dependencies?

[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files

[zbeekman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149

--- Comment #9 from Zaak zbeekman at gmail dot com 2011-08-31 22:34:46 UTC ---
Additionally, if my entire premise is wrong what do you anticipate the use of
the -M flag will be for? It's not hard to figure out that .o files depend on
the .f90 files with the same name. I don't need a tool to do that for me, so
how do you envision -M being used? Not the way listed on the GNUmake online
documentation?

[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files

[zbeekman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149

--- Comment #12 from Zaak zbeekman at gmail dot com 2011-09-01 01:14:40 UTC 
---

 Can you show me a specific passage in the GNU Make documentation
 that states -M can be used to generate dependencies for
 Fortran USE statements without the actual *.mod being
 present?

Bullet number 7 in the what's new in gfortran section for the current stable
release, 4.6.0: http://gcc.gnu.org/wiki/GFortran#GCC4.6

' Support the generation of Makefile dependencies via the `-M...` flags of GCC;
you may need to specify additionally the -cpp option. The dependencies take
modules, Fortran's include, and CPP's #include into account. Note: Using -M for
the module path is no longer supported, use -J instead.'

It seems that this is a new feature and the documentation lags the
implementation. Being a new feature I thought it was important to report what
appears to me to be an important new bug (if I am interpreting the above
statement correctly). Note also that Intel has recently added this capability
to their Fortran compiler and they too have (different) bugs.

[Bug fortran/49149] Dependency autogeneration with `-M` rendered useless by requiring .mod files

[zbeekman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149

--- Comment #13 from Zaak zbeekman at gmail dot com 2011-09-01 01:27:46 UTC 
---
As for intrinsic F2003 modules, like ISO_C_BINDING, ISO_FORTRAN_ENV, etc. I
would expect the compiler to be able to handle this appropriately, i.e. not
require the presence of a iso_c_binding module in the build directory. Modules
which are provided as compiler extensions to the Fortran standard should also
be handled appropriately. My preference would be to exclude such intrinsic and
compiler extension modules from the dependency list, but if a .mod file is
installed with the compiler, the dependency could be given with a full path to
its location. I can't think of an occasion when you would need a path to these
intrinsic/extension modules, unless, perhaps, the tool were used while
developing the compiler itself.

Also, every time I read 'The dependencies take modules, Fortran's include, and
CPP's #include into account.' I can't help but think that the creators of this
feature were trying to make a useful tool which could handle Fortran specific,
especially module, dependency resolution.

[Bug fortran/47720] problems with makefile dependency generation using -M

[zbeekman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47720

--- Comment #4 from Zaak zbeekman at gmail dot com 2011-05-25 19:56:38 UTC ---
I'm not a gfortran dev, but the duplicates are likely due to the fact the the
source code is being parsed and there is need to remove duplicates, since the
output is intended for consumption by make. The idea is to run gfortran -M -cpp
before running gfortran -c to compile the code. Then you can include the .d
files produced with the -M flag in your makefile. See for example:
http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_43.html

I suspect, however, that if you swapped the names of your two files, and
removed all of the .mod files, you will run into the bug posted here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149

(Or rename makegen1.f90 to makegen3.f90) You should be able to start with only
source files (no compiled or objects processed by gfortran) and do: 

$ gfortran-4.6 -cpp -M makegen?.f90

If the nighly build, or whatever you're using still has the same bug as 4.6.0
then the above command will complain about missing .mod files, which defeats
the purpose of having such a utility in the first place.

(The goal is to resolve dependencies, but to do this you need some .mod files.
Which ones? well go resolve some dependencies and find out. Oh...wait I can't
resolve dependencies unless I already have them in which case I don't need
to resolve them anymore)

[Bug fortran/47720] problems with makefile dependency generation using -M

[zbeekman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47720

--- Comment #5 from Zaak zbeekman at gmail dot com 2011-05-25 20:01:01 UTC ---
In comment 4, in the first sentence there is a typo. I meant: 

I'm not a gfortran dev, but the duplicates are likely due to the fact the the
source code is being parsed and there is *NO* need to remove duplicates, since
the
output is intended for consumption by make.

[Bug fortran/47720] problems with makefile dependency generation using -M

[zbeekman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47720

Zaak zbeekman at gmail dot com changed:

   What|Removed |Added

 CC||zbeekman at gmail dot com

--- Comment #1 from Zaak zbeekman at gmail dot com 2011-05-24 18:33:33 UTC ---
The page here: http://gcc.gnu.org/wiki/GFortran#GCC4.6 seems to suggest that
you need to specify -cpp. I must admit, however, the documentation for this
features is a bit murky.

I suspect that the module constants shows up three times because it is used in
three procedures in the second module. This is by no means a deficiency. If you
include this in your makefile it will not cause problems. In fact, make has
ways of removing duplicates. gfortran/cpp likely parse your source code and
every time they encounter a use statement ad the module(s) mentioned there to
the list of dependencies.

May I ask what version of gfortran this is? (Trunk build of gfortran from
yesterday is a bit ambiguous) 

The reason I ask is that I am not getting as far as you. on gfortran 4.6.0 if
have a program which uses two modules and dependency listing I get is myprog.0:
myprog.f90 which is less than helpful.

[Bug fortran/49149] New: Dependency autogeneration with `-M` rendered useless by requiring .mod files

[zbeekman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49149

   Summary: Dependency autogeneration with `-M` rendered useless
by requiring .mod files
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zbeek...@gmail.com


Here is some fortran code:

MODULE utils
  USE types, ONLY: WP
  IMPLICIT NONE

CONTAINS
  ELEMENTAL FUNCTION initPI() RESULT(PI)
REAL(WP) :: PI
PI = ATAN(1.0_WP)*4.0_WP
  END FUNCTION initpi
END MODULE utils

When I run the following command with gfortran 4.6 I get the following error.

$ gfortran -MG -cpp modutils.f90
modutils.f90:2.21:

  USE types, ONLY: WP
 1
Fatal Error: Can't open module file 'types.mod' for reading at (1): No such
file or directory

This entirely defeats the purpose of having a preprocessor spit out makefile
rules. If I want my dependencies resolved automatically, I should be able to
spit out .d files which are later included in my makefile *in an arbitrary
order.* GENERATION OF MAKEFILE RULES FOR AUTOMATIC DEPENDENCY RESOLUTION MUST
BE ABLE TO BE DONE IN ANY ORDER BY PARSING THE SOURCE. There should not be a
requirement to have .mod files present. These files are part of a separate
source file and contribute zero knowledge to the dependencies of the current
file. The need not be present for preprocessing, or dependency resolution. (But
yes, they are needed for syntax checking.)  With the `-M` feature added to
gfortran one should be able to follow the procedure outlined on the GNUmake
website for automatic dependency generation to build codes with a small set of
pattern rules. See this page for more info.
http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_43.html

If the procedure outlined on that page is attempted, the include statement in
the makefile will cause the makefile to about because the include statement
tries to build the files in arbitrary order (likely ascii collating sequence by
file name). The makefile code listed bellow should work but doesn't because of
the eroneously required .mod files:

FC=ifort
GFC = gfortran

%.o: %.f90 %.d
$(FC) $(FCFLAGS) $(FPPFLAGS) -c $ -o $@


%.d: %.f90
$(SHELL) -ec $(GFC) -M -cpp $(FPPFLAGS) $ | sed '1 s/^/$@ /'  $@

sources:=$(wildcard *.f90)
depends:=$(patsubst %.f90,%.d,$(wildcard *.f90))

include $(depends)

Dependency resolution is the bane of Fortran developers, and a huge headache.
Being able to implement Makefiles like the one listed above instead of
teadiously writing line after line of dependency resolutions by hand will be a
boon for the Fortran community as a whole. Please make it a priority to look
into this in the near future.

Many thanks, and keep up the great work.

[Bug preprocessor/49150] New: Preprocessing fortran code with the `-M` flag to automatically resolve dependencies and produce makefile rules rendered useless by requiring .mod files be present

[zbeekman at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49150

   Summary: Preprocessing fortran code with the `-M` flag to
automatically resolve dependencies and produce
makefile rules rendered useless by requiring .mod
files be present
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zbeek...@gmail.com


Here is some fortran code which can be put in it's own .f90 source file and
compiled into an object file and module file:

MODULE utils
  USE types, ONLY: WP
  IMPLICIT NONE

CONTAINS
  ELEMENTAL FUNCTION initPI() RESULT(PI)
REAL(WP) :: PI
PI = ATAN(1.0_WP)*4.0_WP
  END FUNCTION initpi
END MODULE utils

When I run the following command with gfortran 4.6 I get the following error.

$ gfortran -MG -cpp modutils.f90
modutils.f90:2.21:

  USE types, ONLY: WP
 1
Fatal Error: Can't open module file 'types.mod' for reading at (1): No such
file or directory

This entirely defeats the purpose of having a preprocessor spit out makefile
rules. If I want my dependencies resolved automatically, I should be able to
spit out .d files which are later included in my makefile *in an arbitrary
order.* GENERATION OF MAKEFILE RULES FOR AUTOMATIC DEPENDENCY RESOLUTION MUST
BE ABLE TO BE DONE IN ANY ORDER BY PARSING THE SOURCE. There should not be a
requirement to have .mod files present. These files are part of a separate
source file and contribute zero knowledge to the dependencies of the current
file. The need not be present for preprocessing, or dependency resolution. (But
yes, they are needed for syntax checking.)  With the `-M` feature added to
gfortran one should be able to follow the procedure outlined on the GNUmake
website for automatic dependency generation to build codes with a small set of
pattern rules. See this page for more info.
http://theory.uwinnipeg.ca/localfiles/infofiles/make/make_43.html

If the procedure outlined on that page is attempted, the include statement in
the makefile will cause the makefile to abort because the include statement
tries to build the files in arbitrary order (likely ascii collating sequence by
file name) and the -M flag won't allow this because it aborts if the required
.mod files are not present. The makefile code listed bellow should work but
doesn't because of the eroneously required .mod files:

FC=ifort
GFC = gfortran

%.o: %.f90 %.d
$(FC) $(FCFLAGS) $(FPPFLAGS) -c $ -o $@


%.d: %.f90
$(SHELL) -ec $(GFC) -M -cpp $(FPPFLAGS) $ | sed '1 s/^/$@ /'  $@

sources:=$(wildcard *.f90)
depends:=$(patsubst %.f90,%.d,$(wildcard *.f90))

include $(depends)

Dependency resolution is the bane of Fortran developers, and a huge headache.
Being able to implement Makefiles like the one listed above instead of
teadiously writing line after line of dependency resolutions by hand will be a
boon for the Fortran community as a whole. Please make it a priority to look
into this in the near future.

Many thanks, and keep up the great work.

I wasn't sure whether this was a fortran issue or a preprocessor issue so I
have more or less duplicated the bug I submitted as a fortran issue here.