[Bug fortran/112828] Abort with malloc(): corrupted top size

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #5 from Rich Townsend  ---
One more data point: I tried with gfortran 13.2.0 on Linux/Intel and get the
same result as for 13.1.0.

[Bug fortran/112828] Abort with malloc(): corrupted top size

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #4 from Rich Townsend  ---
Another data point for MacOS/Intel (10.13.6, High Sierra) -- with the character
vars set to length 64, the crash is as follows:

test(3287,0x7fff8fc11380) malloc: *** error for object 0x7fe44cc03b58:
incorrect checksum for freed object - object was probably modified after being
freed.
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x105c19a5e
#1  0x105c18c1d
#2  0x7fff57818f59
Abort trap: 6

Again, commenting out the allocate(..., STAT=stat) line makes the problem go
away. Reducing the length to <=24 also resolves the problem.

[Bug fortran/112828] Abort with malloc(): corrupted top size

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #3 from Rich Townsend  ---
I can get the MWE to barf on MacOS/Arm (Sonoma 14.1.1), gfortran 13.1.0, by
changing the length of the character vars in the main program from 64 to 16.
The error is now:

In file 'test.f90', around line 49: Error allocating 211106259502048 bytes:
Cannot allocate memory

Error termination. Backtrace:
#0  0x102d77617
#1  0x102d781b7
#2  0x102d78457
#3  0x10275f5bb
#4  0x10275fc37
#5  0x10275f84f
#6  0x10275fc87

Once again, commenting out the allocate w/ STAT line makes the problem go away.
It seems as though having two allocate invocations (one with stat, one without)
is causing some kind of memory corruption.

[Bug fortran/112828] Abort with malloc(): corrupted top size

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #2 from Rich Townsend  ---
The problem manifests with gfortran 13.1.0 on Linux/x86_64. I've run into
similar looking problems on MacOS/Arm, but the MWE I provided seems to work OK
on Arm.

[Bug fortran/112828] New: Abort with malloc(): corrupted top size

[townsend at astro dot wisc.edu via Gcc-bugs]

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

Bug ID: 112828
   Summary: Abort with malloc(): corrupted top size
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

Created attachment 56768
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56768=edit
MWE demonstrating problem

When I compile the attached MWE with

gfortran -o test test.f90

...I get the following runtime error:

malloc(): corrupted top size

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x7f13a2e7760f in ???
#1  0x7f13a2ec500c in ???
#2  0x7f13a2e77571 in raise
#3  0x7f13a2e614b1 in abort
#4  0x7f13a2e623b4 in ???
#5  0x7f13a2ece874 in ???
#6  0x7f13a2ed1fdf in ???
#7  0x7f13a2ed2b59 in __libc_malloc
#8  0x40191a in MAIN__
#9  0x401c8c in main
Aborted

If I comment out the first allocate statement (the one with the STAT argument),
then the program runs without problem (even though this statement isn't
actually executed). There are a number of other things that make the bug go
away; e.g., shrinking the length of the character variables in the main program
to 20 or smaller. Setting the length to 21 still runs without error, but the
second element of c_r ends up with some junk in it, viz:

 foo  fooA

cheers,

Rich

[Bug fortran/110877] New: Incorrect copy of allocatable component in polymorphic assignment from array dummy argument

[townsend at astro dot wisc.edu via Gcc-bugs]

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

Bug ID: 110877
   Summary: Incorrect copy of allocatable component in polymorphic
assignment from array dummy argument
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

I've run into a problem that's demonstrated by the following code:

--
module avs_m

   type :: foo_t
   end type foo_t

   type, extends(foo_t) :: bar_t
  real, allocatable :: a
   end type bar_t

end module avs_m

program assign_vs_source

   use avs_m

   implicit none

   class(foo_t), allocatable :: foo(:)

   allocate(bar_t::foo(1))
   select type(foo)
   class is (bar_t)
  allocate(foo(1)%a)
   end select

   call check_assign(foo)

contains

   subroutine check_assign(f)

  class(foo_t), intent(in)  :: f(:)
  class(foo_t), allocatable :: g(:)

  g = f

  select type(g)
  class is (bar_t)
 print *,'is allocated?', allocated(g(1)%a)
  end select

  deallocate(g)
  allocate(g, SOURCE=f)

  select type(g)
  class is (bar_t)
 print *,'is allocated?', allocated(g(1)%a)
  end select

   end subroutine check_assign

end program assign_vs_source
--

Expected output is 

 is allocated? T
 is allocated? T

but instead I get (gfortran 13.1.0, MacOS 13.4 x86_64):

 is allocated? F
 is allocated? T

It seems that the polymorphic assignment g=f is not correctly allocating the %a
component -- but the sourced allocation is. The problem seems to go away if (1)
I use scalars for foo, f and g, or (2) if I move the code from the check_assign
subroutine to the main program.

cheers,

Rich

[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #9 from Rich Townsend  ---
OK, I managed to get things working by setting

export LDFLAGS='-Wl,--no-eh-frame-hdr'

prior to configuring. I'm hoping this won't affect the functionality of the
built compiler.

[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #7 from Rich Townsend  ---
(In reply to Andrew Pinski from comment #6)
> GCC 13 won't build with anything older than GCC 4.8.x as documented at
> https://gcc.gnu.org/install/prerequisites.html (which is right now for the
> trunk but that requirement has not changed yet).

The plot thickens -- I misidentified the compiler, here's the correct id:

[user@0ec987449fdf gcc-build]$ x86_64-pc-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=x86_64-pc-linux-gnu-g++
COLLECT_LTO_WRAPPER=/opt/bootstrap/mesasdk/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/user/sdk2-tmp/build/gcc/configure CC= CXX=
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --prefix=/home/user/sdk2-tmp/mesasdk
--with-gmp=/home/user/sdk2-tmp/mesasdk --with-mpfr=/home/user/sdk2-tmp/mesasdk
--with-mpc=/home/user/sdk2-tmp/mesasdk --enable-languages=c,c++,fortran
--disable-multilib --disable-nls --disable-libsanitizer
--enable-clocale=generic
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (GCC) 

So, 12.1.0 should be perfectly capable of building 13.1, right?

[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #5 from Rich Townsend  ---
(In reply to Andrew Pinski from comment #2)
> What compiler did you start with?
> That is what is the output of `x86_64-pc-linux-gnu-g++ -v` ?

[user@60947d0cbd04 ~]$ x86_64-pc-linux-gnu-g++ -v
bash: x86_64-pc-linux-gnu-g++: command not found

[user@60947d0cbd04 ~]$ g++ -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --disable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-55)

[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #4 from Rich Townsend  ---
Someone else seems to have the same problem:

https://stackoverflow.com/questions/76375244/how-can-i-resolve-a-ld-eh-frame-hdr-refers-to-overlapping-fdes-error-during

...although there is no fix suggested.

[Bug middle-end/110659] Error from linker: .eh_frame_hdr refers to overlapping FDEs

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #1 from Rich Townsend  ---
I should add that this is on CentOS 5.11, running inside a Docker container.
This ships with a very old binutils, so before trying to compile gcc I
installed binutils 2.40 (built from source with --disable-gprofng).

[Bug bootstrap/110659] New: Error from linker: .eh_frame_hdr refers to overlapping FDEs

[townsend at astro dot wisc.edu via Gcc-bugs]

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

Bug ID: 110659
   Summary: Error from linker: .eh_frame_hdr refers to overlapping
FDEs
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

I'm running into the following problem during a build of the 13.1.0 release:

x86_64-pc-linux-gnu-g++ -std=c++11   -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H  -DGENERATOR_FILE
-static-libstdc++ -static-libgcc  -o build/genenums \
build/genenums.o build/read-md.o build/errors.o
../build-x86_64-pc-linux-gnu/libiberty/libiberty.a
/home/user/sdk2-tmp/mesasdk/bin/ld: .eh_frame_hdr refers to overlapping FDEs
/home/user/sdk2-tmp/mesasdk/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

This is on Linux with binutils-2.40. Configure as follows:

/home/user/sdk2-tmp/build/gcc/configure CC= CXX= --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--prefix=/home/user/sdk2-tmp/mesasdk --with-gmp=/home/user/sdk2-tmp/mesasdk
--with-mpfr=/home/user/sdk2-tmp/mesasdk --with-mpc=/home/user/sdk2-tmp/mesasdk
--enable-languages=c,c++,fortran --disable-multilib --disable-nls
--disable-libsanitizer --enable-clocale=generic

Wondering whether any of these config flags are what's causing the problem...

[Bug bootstrap/110650] collect2: fatal error: ld terminated with signal 11 [Segmentation fault]

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #3 from Rich Townsend  ---
Sure thing:

GNU ld version 2.17.50.0.6-26.el5 20061020

I'm deliberately working with an old toolchain, inside a Docker container, to
make sure that when I distribute the gcc executables they will work OK on older
systems.

[Bug bootstrap/110650] collect2: fatal error: ld terminated with signal 11 [Segmentation fault]

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #1 from Rich Townsend  ---
Oops, posted without any bug description!

I'm trying to build gcc 13.1.0 on Linux x86_64, and I get the following
segfault:

libtool: compile:  /home/user/sdk2-tmp/build/gcc-build/./gcc/xgcc
-shared-libgcc -B/home/user/sdk2-tmp/build/gcc-build/./gcc -nostdinc++
-L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-checking
-I/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/home/user/sdk2-tmp/build/gcc/libstdc++-v3/libsupc++ -std=gnu++98 -fPIC -DPIC
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=compatibility-thread-c++0x.lo -g -O2 -D_GNU_SOURCE -std=gnu++11
-c
/home/user/sdk2-tmp/build/gcc/libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc
-o compatibility-thread-c++0x.o >/dev/null 2>&1
/bin/sh ../libtool --tag CXX   --mode=link
/home/user/sdk2-tmp/build/gcc-build/./gcc/xgcc -shared-libgcc
-B/home/user/sdk2-tmp/build/gcc-build/./gcc -nostdinc++
-L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
   -fno-checking  -Wl,-O1 -Wl,-z,relro -Wl,--gc-sections  -std=gnu++98 -fPIC
-DPIC -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=libstdc++.la   -o libstdc++.la -version-info 6:31:0
-Wl,--version-script=libstdc++-symbols.ver -lm  -rpath
/home/user/sdk2-tmp/mesasdk/lib/../lib64 compatibility.lo
compatibility-debug_list.lo compatibility-debug_list-2.lo 
compatibility-atomic-c++0x.lo compatibility-c++0x.lo compatibility-chrono.lo
compatibility-condvar.lo compatibility-thread-c++0x.lo  
../libsupc++/libsupc++convenience.la ../src/c++98/libc++98convenience.la
../src/c++11/libc++11convenience.la ../src/c++17/libc++17convenience.la
../src/c++20/libc++20convenience.la 
libtool: link:  /home/user/sdk2-tmp/build/gcc-build/./gcc/xgcc -shared-libgcc
-B/home/user/sdk2-tmp/build/gcc-build/./gcc -nostdinc++
-L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
   -fno-checking  -fPIC -DPIC -D_GLIBCXX_SHARED -shared -nostdlib
/usr/lib/../lib64/crti.o /home/user/sdk2-tmp/build/gcc-build/./gcc/crtbeginS.o 
.libs/compatibility.o .libs/compatibility-debug_list.o
.libs/compatibility-debug_list-2.o .libs/compatibility-atomic-c++0x.o
.libs/compatibility-c++0x.o .libs/compatibility-chrono.o
.libs/compatibility-condvar.o .libs/compatibility-thread-c++0x.o 
-Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a
../src/c++98/.libs/libc++98convenience.a
../src/c++11/.libs/libc++11convenience.a
../src/c++17/.libs/libc++17convenience.a
../src/c++20/.libs/libc++20convenience.a -Wl,--no-whole-archive 
-L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-lm -L/home/user/sdk2-tmp/build/gcc-build/./gcc -L/lib/../lib64
-L/usr/lib/../lib64 -lc -lgcc_s
/home/user/sdk2-tmp/build/gcc-build/./gcc/crtendS.o /usr/lib/../lib64/crtn.o 
-Wl,-O1 -Wl,-z -Wl,relro -Wl,--gc-sections
-Wl,--version-script=libstdc++-symbols.ver   -Wl,-soname -Wl,libstdc++.so.6 -o
.libs/libstdc++.so.6.0.31
collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
compilation terminated.
make[6]: *** [libstdc++.la] Error 1
make[6]: Leaving directory
`/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src'
make[5]: *** [all-recursive] Error 1
make[5]: Leaving directory
`/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/src'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
`/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3'
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/home/user/sdk2-tmp/build/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3'
make[2]: *** [all-stage1-target-libstdc++-v3] Error 2
make[2]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build'
make: *** [all] Error 2
FAILED in make for gcc
Action install failed for package gcc/gcc-13.1.0

[Bug bootstrap/110650] New: collect2: fatal error: ld terminated with signal 11 [Segmentation fault]

[townsend at astro dot wisc.edu via Gcc-bugs]

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

Bug ID: 110650
   Summary: collect2: fatal error: ld terminated with signal 11
[Segmentation fault]
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

[Bug fortran/110629] Bug in assignment of derived type with deferred length character component

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #3 from Rich Townsend  ---
Thanks for the quick responses, folks. The problem persists in 12.3.0 release,
but is fixed in 13.1.0 release.

[Bug fortran/110629] New: Bug in assignment of derived type with deferred length character component

[townsend at astro dot wisc.edu via Gcc-bugs]

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

Bug ID: 110629
   Summary: Bug in assignment of derived type with deferred length
character component
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

I've run into a problem with intrinsic assignment of derived types with
allocatable character components. This seems to be a resurgence of PR105205, in
that only the first element of the character array is copied correctly; the
rest is filled with garbage.

Here's a demo:

--
module m

   type :: bar_t
  character(:), allocatable :: c(:)
   end type bar_t

end module m


program p

   use m

   implicit none

   type(bar_t) :: bar
   type(bar_t) :: biz

   integer :: i

   allocate(character(10)::bar%c(3))

   bar%c(1) = 'big'
   bar%c(2) = 'red'
   bar%c(3) = 'dog'

   biz = bar

   do i = 1, 3
  print *, i, '|'//biz%c(i)//'|'
   end do

end program p
--

Output compiling with gfortran 12.2.0 on MacOS 13.4:

   1 |big   |
   2 |>|
   3 ||

Unfortunately, this may be a heisenbug -- some code where I do this kind of
assignment is affected, other code is not.

[Bug fortran/105205] New: Incorrect assignment of derived type with allocatable, deferred-length character component

[townsend at astro dot wisc.edu via Gcc-bugs]

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

Bug ID: 105205
   Summary: Incorrect assignment of derived type with allocatable,
deferred-length character component
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

I've run into problems with assignment of derived types containing an
allocatable array of deferred-length strings. Example program:

---
program alloc_char_type
   implicit none
   type mytype
  character(:), allocatable :: c(:)
   end type mytype
   type(mytype) :: a
   type(mytype) :: b
   integer :: i
   a%c = ['foo','bar','biz','buz']
   b = a
   do i = 1, size(b%c)
  print *,b%c(i)
   end do
end
---

Running with gfortran 10.2.0 or 11.2.0, I get the output:

>>
 foo



<<

If I hard-code the length of the c component (to, say, 3), I get the expected
output:

>>
 foo
 bar
 biz
 buz
<<

It seems as if only the first element of c is being copied correctly.

cheers,

Rich

[Bug libfortran/102992] fortran: redirecting standard out to a file does not work on macOS 12.0

[townsend at astro dot wisc.edu via Gcc-bugs]

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

Rich Townsend  changed:

   What|Removed |Added

 CC||townsend at astro dot wisc.edu

--- Comment #11 from Rich Townsend  ---
I can confirm this issue on macOS 12.0.1 and gcc/gfortran 10.2.

[Bug fortran/99477] New: CONTIGUOUS assumed-shape dummy not working with associate construct

[townsend at astro dot wisc.edu via Gcc-bugs]

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

Bug ID: 99477
   Summary: CONTIGUOUS assumed-shape dummy not working with
associate construct
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

Created attachment 50335
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50335=edit
Example program

I think I've stumbled on a bug with gfortran's handling of the CONTIGUOUS
attribute in assumed-shape dummy arguments, when the actual argument is an
array slice set up using an ASSOCIATE construct.

The example program demonstrates the issue. When compiled with gfortran 10.2.0,
I get the following output:

   1   3   5   7   9
   1   3   5   7   9
   1   2   3   4   5
   1   3   5   7   9

(note the third line, which has only stride 1). Whereas, I believe the output
should be

   1   3   5   7   9
   1   3   5   7   9
   1   3   5   7   9
   1   3   5   7   9

The issue goes away if I remove the CONTIGUOUS attribute from the function
argument.

cheers,

Rich

[Bug fortran/99169] New: Segfault when passing allocatable scalar into intent(out) dummy argument

[townsend at astro dot wisc.edu via Gcc-bugs]

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

Bug ID: 99169
   Summary: Segfault when passing allocatable scalar into
intent(out) dummy argument
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

Created attachment 50222
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50222=edit
Minimal working example

I've encountered a problem when passing an allocatable (and alread allocated)
scalar as an actual argument to a procedure with an intent(out) (but not
allocatable) dummy argument. The attached code illustrates the problem. 

Compiling with gfortran 10.2.0 at optimization level -O1 or -O2 leads to a
segmentation fault at runtime. The segfault arises when the dummy is assigned
within set_i(). This problem does not arise at optimization level -O0, and the
program performs as expected (outputting '5' to the terminal).

The problem also seems to disappear when set_i() is a CONTAINed procedure in
the main program, rather than a module procedure.

cheers,

Rich

[Bug fortran/98445] Bogus error: derived type used as an actual argument

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #3 from Rich Townsend  ---
OK, my code isn't valid -- it's not permitted to pass a generic procedure name
as an actual argument. As such, gfortran is correct in its behavior.

Happy for this one to be closed -- sorry for the false alarm!

[Bug fortran/98445] Bogus error: derived type used as an actual argument

[townsend at astro dot wisc.edu via Gcc-bugs]

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

--- Comment #2 from Rich Townsend  ---
I know it's acceptable to overload a type name with one or more functions --
from 12.4.3.4.1 of the F2008 standard,

"A generic name may be the same as a derived-type name, in which case all of
the procedures in the interface block shall be functions."

In reading the rules for actual and dummy arguments (12.5.2), I don't see
anything prohibiting a function-overloaded type name being passed in. However,
I'm going to hit up comp.lang.fortran to see if I can get advice from one of
the Fortran congnescenti.

[Bug fortran/98445] New: Bogus error: derived type used as an actual argument

[townsend at astro dot wisc.edu via Gcc-bugs]

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

Bug ID: 98445
   Summary: Bogus error: derived type used as an actual argument
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

Created attachment 49844
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49844=edit
Minimal working example

I'm running into what I believe to be a bogus error, when passing a function
that (via interface overloading) has the same name as a derived type.

Attached is a MWE. When compiled, I get the error

passed_procedure_bug.f90:30:11:

   30 | call s(t)
  |   1
Error: Derived type 't' is used as an actual argument at (1)

cheers,

Rich

[Bug bootstrap/96492] : internal compiler error: Segmentation fault

[townsend at astro dot wisc.edu]

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

--- Comment #5 from Rich Townsend  ---
So, given that gcc 4.1.2 is really ancient, I've tried building 10.2 using gcc
9.3.0 instead (but still inside the Docker container). This builds fine, and in
fact I'm happy to go with this workaround.

However, might be worth noting somewhere that gcc 10.X cannot be built with gcc
4.1.2.

cheers,

Rich

[Bug bootstrap/96492] : internal compiler error: Segmentation fault

[townsend at astro dot wisc.edu]

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

--- Comment #4 from Rich Townsend  ---
(In reply to Jakub Jelinek from comment #3)
> Can you run
> gdb --args ./cc1 -quiet -fself-test=../../gcc/gcc/testsuite/selftests
> /dev/null -o /dev/null
> and do
> run
> bt
> ?

[user@6d6cb5609b91 gcc]$ gdb --args ./cc1 -quiet
-fself-test=../../gcc/gcc/testsuite/selftests /dev/null -o /dev/null
GNU gdb (GDB) CentOS (7.0.1-45.el5.centos)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/user/sdk2-tmp/build/gcc-build/gcc/cc1...done.
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in
module /home/user/sdk2-tmp/build/gcc-build/gcc/cc1]
/home/user/sdk2-tmp/build/gcc-build/gcc/.gdbinit:14: Error in sourced command
file:
/home/user/sdk2-tmp/build/gcc/gcc/gdbinit.in:311: Error in sourced command
file:
Undefined command: "alias".  Try "help".
(gdb) run
Starting program: /home/user/sdk2-tmp/build/gcc-build/gcc/cc1 -quiet
-fself-test=../../gcc/gcc/testsuite/selftests /dev/null -o /dev/null
warning: Error disabling address space randomization: Operation not permitted
warning: no loadable sections found in added symbol-file system-supplied DSO at
0x7ffe393bf000

Program received signal SIGSEGV, Segmentation fault.
0x7f10b4696ca0 in strlen () from /lib64/libc.so.6
(gdb) bt
#0  0x7f10b4696ca0 in strlen () from /lib64/libc.so.6
#1  0x00ac1e79 in get_identifier(char const*) ()
#2  0x009304fd in build_builtin_function(unsigned int, char const*,
tree_node*, int, built_in_class, char const*, tree_node*) ()
#3  0x00c5 in ?? ()
#4  0xb4547c00 in ?? ()
#5  0x01593374 in ix86_builtin_func_args ()
#6  0x0002 in ?? ()
#7  0x00ae in ?? ()
#8  0x0002 in ?? ()
#9  0x0001 in ?? ()
#10 0x in ?? ()

[Bug bootstrap/96492] : internal compiler error: Segmentation fault

[townsend at astro dot wisc.edu]

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

--- Comment #2 from Rich Townsend  ---
(In reply to Richard Biener from comment #1)
> Did GCC 10.1 work or any older version you tried to build this way in the
> past?

It's worked in 9.2, 9.3, and earlier releases; but not in 10.1.

If I try the build outside the Docker container, it works fine. So, there's
something about the Centos 5.11 toolchain/libraries that make it break.

[Bug bootstrap/96492] New: : internal compiler error: Segmentation fault

[townsend at astro dot wisc.edu]

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

Bug ID: 96492
   Summary: : internal compiler error: Segmentation
fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

I'm attempting to build 10.2 from within a Docker container based on Centos
5.11, which ships with glibc 2.5 and gcc 4.1.2. (The reason I'm doing this is
I'm building a gcc-based SDK that should be able to run on crusty old systems).

I'm configuring with the following options:

../gcc/configure --build=x86_64-pc-linux-gnu
--prefix=/home/user/sdk2-tmp/mesasdk --with-mpc=/home/user/sdk2-tmp/mesasdk
--with-mpfr=/home/user/sdk2-tmp/mesasdk --with-gmp=/home/user/sdk2-tmp/mesasdk
--disable-multilib --disable-nls --disable-libsanitizer
--enable-languages=c,c++,fortran

During the build (make -j), I get ICEs:

/home/user/sdk2-tmp/build/gcc-build/./gcc/xgcc
-B/home/user/sdk2-tmp/build/gcc-build/./gcc/ -xc -nostdinc /dev/null -S -o
/dev/null -fself-test=../../gcc/gcc/testsuite/selftests
: internal compiler error: Segmentation fault
: internal compiler error: Segmentation fault
/home/user/sdk2-tmp/build/gcc-build/./gcc/xgcc
-B/home/user/sdk2-tmp/build/gcc-build/./gcc/ -xc++ -nostdinc /dev/null -S -o
/dev/null -fself-test=../../gcc/gcc/testsuite/selftests
: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make[3]: *** [s-selftest-c] Error 1
make[3]: *** Waiting for unfinished jobs
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
/bin/sh ../../gcc/gcc/../move-if-change tmp-macro_list macro_list
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
make[3]: *** [s-selftest-c++] Error 1
echo timestamp > s-macro_list
rm gfortran.pod gcc.pod
make[3]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/user/sdk2-tmp/build/gcc-build'
make: *** [all] Error 2

Full build log is attached.

cheers,

Rich

[Bug fortran/93175] New: ICE involving nested parameterized derived types

[townsend at astro dot wisc.edu]

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

Bug ID: 93175
   Summary: ICE involving nested parameterized derived types
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

I get an ICE when compiling this example code (involving a PDT inside a PDT):


module pdt_test_m

  type :: matrix (k,n)
 integer, kind :: k
 integer, len  :: n
 real(k)   :: a(n,n)
  end type matrix

  type :: problem(n)
 integer, len   :: n
 type(matrix(kind(0.D0),n)) :: m
  end type problem

end module pdt_test_m

program pdt_test

  use pdt_test_m

  implicit none

  type(problem(2)) :: p

  p%m%a = 1.

  print *, p%n
  print *, p%m%n
  print *, p%m%a

end program pdt_test


The error is as follows (on Linux):

pdt-test.f90:30:0:

   30 | end program pdt_test
  | 
internal compiler error: Segmentation fault
0xad494f crash_signal
/root/sdk2/build/gcc/gcc/toplev.c:326
0x59e47f insert_parameter_exprs
/root/sdk2/build/gcc/gcc/fortran/decl.c:3491
0x59e47f insert_parameter_exprs
/root/sdk2/build/gcc/gcc/fortran/decl.c:3477
0x5bcced gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*,
gfc_symbol*, int*), int)
/root/sdk2/build/gcc/gcc/fortran/expr.c:5144
0x670ffa structure_alloc_comps
/root/sdk2/build/gcc/gcc/fortran/trans-array.c:9353
0x674a80 gfc_allocate_pdt_comp(gfc_symbol*, tree_node*, int,
gfc_actual_arglist*)
/root/sdk2/build/gcc/gcc/fortran/trans-array.c:9630
0x670924 structure_alloc_comps
/root/sdk2/build/gcc/gcc/fortran/trans-array.c:9428
0x674a80 gfc_allocate_pdt_comp(gfc_symbol*, tree_node*, int,
gfc_actual_arglist*)
/root/sdk2/build/gcc/gcc/fortran/trans-array.c:9630
0x6833e3 gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
/root/sdk2/build/gcc/gcc/fortran/trans-decl.c:4599
0x6859f9 gfc_generate_function_code(gfc_namespace*)
/root/sdk2/build/gcc/gcc/fortran/trans-decl.c:6851
0x6102e6 translate_all_program_units
/root/sdk2/build/gcc/gcc/fortran/parse.c:6134
0x6102e6 gfc_parse_file()
/root/sdk2/build/gcc/gcc/fortran/parse.c:6367
0x65aa5f gfc_be_parse_file
/root/sdk2/build/gcc/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.

(On OSX I also get a segfault, but the nice backtrace info is missing. Is there
a build flag for gcc to fix the lack of backtrace?)

cheers,

Rich

[Bug fortran/91690] New: Slow IEEE intrinsics

[townsend at astro dot wisc.edu]

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

Bug ID: 91690
   Summary: Slow IEEE intrinsics
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

Created attachment 46844
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46844=edit
Demo program

The intrinsics provided by the IEEE_ARITHMETIC module appear to be
significantly slower than an equivalent implementation based on inspecting
bits.

I attach a short program that demonstrates this. Compiling with

gfortran -O2 -o test_ieee test_ieee.f90

...I get the following output:

  Using IEEE
time:   16.1860008
 Using bits
time:  0.10104 

So, the IEEE_IS_NAN() intrinsic appears to be ~160 times slower than inspecting
bits directly. Other intrinsics seem to show similar issues.

cheers,

Rich

[Bug fortran/91584] New: Bogus warning from -Warray-bounds during string assignment

[townsend at astro dot wisc.edu]

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

Bug ID: 91584
   Summary: Bogus warning from -Warray-bounds during string
assignment
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

The following test program produces bogus -Warray-bounds warnings at compile
time:

program test_bounds

  character(256) :: foo

  foo = '1234'

  print *, foo

end program test_bounds

Compiling with 'gfortran -O2 -Warray-bounds -o test_bounds test_bounds.f90'
yields:

test_bounds.f90:5:0:

5 |   foo = '1234'
  | 
Warning: array subscript 0 is outside array bounds of
'character(kind=1)[1:256]' [-Warray-bounds]
test_bounds.f90:3:0:

3 |   character(256) :: foo
  | 
note: while referencing 'foo'

Compiling at a lower optimization level makes the warning go away.

cheers,

Rich

[Bug fortran/91537] Memory leak involving nested allocatable derived types

[townsend at astro dot wisc.edu]

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

--- Comment #3 from Rich Townsend  ---
(In reply to Thomas Koenig from comment #1)
> Comment on attachment 46748 [details]
> Leak demonstration program
> 
> Here's the output on current trunk:
> 
>   862548
>   872548
>   882548
>   892548
>   902548
>   912548
>   922548
>   932548
>   942548
>   952548
>   962548
>   972548
>   982548
>   992548
>  1002548
> 
> Same output with gcc 9.
> 
> So, I think the advice would be to upgrade to gcc 9.

Just tried upgrading, and the leak vanishes as you say. Also fixes the
production code that my example was based on.

Thanks for the quick response!

cheers,

Rich

[Bug fortran/91537] New: Memory leak involving nested allocatable derived types

[townsend at astro dot wisc.edu]

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

Bug ID: 91537
   Summary: Memory leak involving nested allocatable derived types
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

Created attachment 46748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46748=edit
Leak demonstration program

The attached test program demonstrates a memory leak on gfortran 8.3.0.
Intriguingly, valgrind reports no leak; but the memory usage grows steadily
over time, even though only ALLOCATABLE arrays are used. By the end of
execution, 4GB  is being used.

To demonstrate the memory growth, I use the routine system_mem_usage, which
looks at files inside /proc to find the current RSS. Of course, this only works
on Linux -- for those on other platforms, you may have to comment out (or
rework) the call.

Typical output is as follows (from ./test_leak_new | tail -10):

  91 3682816
  92 3722680
  93 3762808
  94 3802672
  95 3842800
  96 3882664
  97 3922792
  98 3962656
  99 4002784
 100 4042648

The first number is the iteration number, the second is the RSS. So, 4GB by the
end of execution, despite the fact that bp is explicitly deallocated at the end
of each loop.

The test program may seem a little contrived, but it's a cut-down version of
production code (which shows the same valgrind-invisible leak behavior).

cheers,

Rich

[Bug bootstrap/90558] '_Atomic does not name a type' error resurfaces when building with old headers on OSX Mojave

[townsend at astro dot wisc.edu]

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

--- Comment #7 from Rich Townsend  ---
(In reply to Rich Townsend from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Dup.
> > 
> > *** This bug has been marked as a duplicate of bug 89864 ***
> 
> Are you sure? The discussion in 89864 indicates that the patch to fix this
> bug should be in the 9.1 release. Also, IIRC I don't see the bug when
> configuring without the --with-sysroot and --with-build-sysroot flags
> (although I'm just rechecking that now).

Yep, confirmed that configuring without those flags allows the compile to
complete.

Now going to try out the patch mentioned by Iain in #5.

(In reply to Rich Townsend from comment #6)
> (In reply to Rich Townsend from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > Dup.
> > > 
> > > *** This bug has been marked as a duplicate of bug 89864 ***
> > 
> > Are you sure? The discussion in 89864 indicates that the patch to fix this
> > bug should be in the 9.1 release. Also, IIRC I don't see the bug when
> > configuring without the --with-sysroot and --with-build-sysroot flags
> > (although I'm just rechecking that now).
> 
> Yep, confirmed that configuring without those flags allows the compile to
> complete.
> 
> Now going to try out the patch mentioned by Iain in #5.

The patch successfully applied to the 9.1 release (with offsets), and the build
completed without hitch. Nice work, Iain!

[Bug bootstrap/90558] '_Atomic does not name a type' error resurfaces when building with old headers on OSX Mojave

[townsend at astro dot wisc.edu]

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

--- Comment #6 from Rich Townsend  ---
(In reply to Rich Townsend from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Dup.
> > 
> > *** This bug has been marked as a duplicate of bug 89864 ***
> 
> Are you sure? The discussion in 89864 indicates that the patch to fix this
> bug should be in the 9.1 release. Also, IIRC I don't see the bug when
> configuring without the --with-sysroot and --with-build-sysroot flags
> (although I'm just rechecking that now).

Yep, confirmed that configuring without those flags allows the compile to
complete.

Now going to try out the patch mentioned by Iain in #5.

[Bug bootstrap/90558] '_Atomic does not name a type' error resurfaces when building with old headers on OSX Mojave

[townsend at astro dot wisc.edu]

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

--- Comment #2 from Rich Townsend  ---
(In reply to Andrew Pinski from comment #1)
> Dup.
> 
> *** This bug has been marked as a duplicate of bug 89864 ***

Are you sure? The discussion in 89864 indicates that the patch to fix this bug
should be in the 9.1 release. Also, IIRC I don't see the bug when configuring
without the --with-sysroot and --with-build-sysroot flags (although I'm just
rechecking that now).

[Bug bootstrap/90558] New: '_Atomic does not name a type' error resurfaces when building with old headers on OSX Mojave

[townsend at astro dot wisc.edu]

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

Bug ID: 90558
   Summary: '_Atomic does not name a type' error resurfaces when
building with old headers on OSX Mojave
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

I'm running into a bug building on OSX Mojave, which seems to be tied into the
problems with _Atomic in Apple's system headers. The error itself is:

/Users/townsend/devel/sdk2/build/gcc-build/./prev-gcc/xg++
-B/Users/townsend/devel/sdk2/build/gcc-build/./prev-gcc/
-B/Applications/mesasdk-dev/x86_64-apple-darwin18.5.0/bin/ -nostdinc++
-B/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/src/.libs
-B/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/libsupc++/.libs

-I/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/include/x86_64-apple-darwin18.5.0

-I/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/include
 -I/Users/townsend/devel/sdk2/build/gcc/libstdc++-v3/libsupc++
-L/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/src/.libs
-L/Users/townsend/devel/sdk2/build/gcc-build/prev-x86_64-apple-darwin18.5.0/libstdc++-v3/libsupc++/.libs
-fno-PIE -c  -DSTANDARD_STARTFILE_PREFIX=\"../../../\"
-DSTANDARD_EXEC_PREFIX=\"/Applications/mesasdk-dev/lib/gcc/\"
-DSTANDARD_LIBEXEC_PREFIX=\"/Applications/mesasdk-dev/libexec/gcc/\"
-DDEFAULT_TARGET_VERSION=\"9.1.0\"
-DDEFAULT_REAL_TARGET_MACHINE=\"x86_64-apple-darwin18.5.0\"
-DDEFAULT_TARGET_MACHINE=\"x86_64-apple-darwin18.5.0\"
-DSTANDARD_BINDIR_PREFIX=\"/Applications/mesasdk-dev/bin/\"
-DTOOLDIR_BASE_PREFIX=\"../../../../\" -DACCEL_DIR_SUFFIX=\"\"
-DTARGET_SYSTEM_ROOT=\"/\"  -DENABLE_SHARED_LIBGCC -DCONFIGURE_SPECS="\"\""
-DTOOL_INCLUDE_DIR=\"/Applications/mesasdk-dev/lib/gcc/x86_64-apple-darwin18.5.0/9.1.0/../../../../x86_64-apple-darwin18.5.0/include\"
-DNATIVE_SYSTEM_HEADER_DIR=\"/usr/include\" -DIN_GCC_FRONTEND -g -O2 
-fno-checking  -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-I. -Ifortran -I/Users/townsend/devel/sdk2/build/gcc/gcc
-I/Users/townsend/devel/sdk2/build/gcc/gcc/fortran
-I/Users/townsend/devel/sdk2/build/gcc/gcc/../include
-I/Users/townsend/devel/sdk2/build/gcc/gcc/../libcpp/include
-I/Applications/mesasdk-dev/include -I/Applications/mesasdk-dev/include
-I/Applications/mesasdk-dev/include 
-I/Users/townsend/devel/sdk2/build/gcc/gcc/../libdecnumber
-I/Users/townsend/devel/sdk2/build/gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I/Users/townsend/devel/sdk2/build/gcc/gcc/../libbacktrace  
-o fortran/gfortranspec.o -MT fortran/gfortranspec.o -MMD -MP -MF
fortran/.deps/gfortranspec.TPo
/Users/townsend/devel/sdk2/build/gcc/gcc/fortran/gfortranspec.c
In file included from /usr/include/sys/sysctl.h:83,
 from
/Users/townsend/devel/sdk2/build/gcc/gcc/config/darwin-driver.c:30:
/usr/include/sys/ucred.h:94:2: error: '_Atomic' does not name a type
   94 |  _Atomic u_long  cr_ref;  /* reference count */
  |  ^~~
make[3]: *** [darwin-driver.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm gfortran.pod gcc.pod
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2

What makes this instance of the bug rather different than other bug reports
I've seen, is that I'm compiling using an old set of system headers (as
provided by the Xcode SDK for OSX 10.10). You can see this from my configure
invocation:

/Users/townsend/devel/sdk2/build/gcc/configure CC=
--build=x86_64-apple-darwin18.5.0 --prefix=/Applications/mesasdk-dev
--with-gmp=/Applications/mesasdk-dev --with-mpfr=/Applications/mesasdk-dev
--with-mpc=/Applications/mesasdk-dev --enable-languages=c,c++,fortran
--disable-multilib --disable-nls --disable-libsanitizer --with-sysroot=/
--with-build-sysroot=/Users/townsend/devel/sdk2/build/xcode

The messing around with --with-sysroot and --with-build-sysroot is so that the
resulting compiler can be used on older OSX versions, without any undefined
symbols cropping up. My understanding of these flags is that:

*) during the compiler and library build, system headers will be obtained from
/Users/townsend/devel/sdk2/build/xcode/usr/include -- here, the xcode subdir
contains the SDK for OSX 10.10, including headers

*) the built compiler, however, will obtain system he

[Bug fortran/90499] New: ICE during polymorphic assignment

[townsend at astro dot wisc.edu]

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

Bug ID: 90499
   Summary: ICE during polymorphic assignment
   Product: gcc
   Version: 8.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

The test program below causes an internal compiler error, that appears to be
linked to the polymorphic assignment:

--
program test

  implicit none

  type f_t
  end type f_t

  type, extends (f_t) :: g_t
  end type g_t

contains

  function func () result (f)

class(f_t), allocatable :: f

f = g_t()

  end function func

end program test
--

When compiling with gfortran -c test.f90, I get:

test.f90:17:0:

 f = g_t()

internal compiler error: in build_function_decl, at fortran/trans-decl.c:2242
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

cheers,

Rich

[Bug fortran/86148] parameterized type compile time error

[townsend at astro dot wisc.edu]

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

Rich Townsend  changed:

   What|Removed |Added

 CC||townsend at astro dot wisc.edu

--- Comment #3 from Rich Townsend  ---
Here's a related test case using a length-type parameter, that also fails for
apparently the same reason:

Module AA
  Type :: parent(k)
 Integer, len :: k
   contains
 procedure :: SubA1
  end type parent
contains
  Subroutine SubA1(this)
Class(parent(*)), Intent(In) :: this
  end Subroutine SubA1
end Module AA

$ gfortran -c AA.f90
foo.f90:5:14:

  procedure :: A1 => SubA1
  1
Error: Argument 'this' of 'suba1' with PASS(this) at (1) must be of the
derived-type 'parent'

cheers,

Rich

[Bug middle-end/90238] Bogus warning from -Warray-bounds, triggered by zero-length character literal

[townsend at astro dot wisc.edu]

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

--- Comment #5 from Rich Townsend  ---
(In reply to Steve Kargl from comment #4)

> It's certainly confusing.  gfortran.info includes
> -Warray-bounds as a warning option, but there is no
> description for the option.  Grepping the gfortran
> source code found the error was not coming from the
> Fortran frontend.  Grepping the GCC source finds
> two instances of the warning string tree-vrp.c.  I
> know nothing of the middle-end code and how Fortran
> strings are represented.  Hopeefully, one the
> middle-end developers can provide a clue to
> suppressing the warning for Fortran strings.


That might be nice. In the meantime, the workaround consists of passing blank
strings ' ' instead of zero-length strings '', since the production code
behaves the same either way. And for the write statement,

write(*,*)

does the same as

write(*,*) ''

cheers,

Rich

[Bug middle-end/90238] Bogus warning from -Warray-bounds, triggered by zero-length character literal

[townsend at astro dot wisc.edu]

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

--- Comment #3 from Rich Townsend  ---
(In reply to kargl from comment #2)
> -Warray-bounds is a generic GCC option, and is used in the
> middle end for reporting warnings.  When you use this option
> it does not recognize that a Fortran string is not an array.
> So, it gleefully reports an array bounds option.  In other
> words, either ignore the warning or stop using -Warray-bounds.

Thanks for the quick response, Steve. I think I can figure a workaround that
allows us to continue using -Warray-bounds.

cheers,

Rich

[Bug fortran/90238] Bogus warning from -Warray-bounds, triggered by zero-length character literal

[townsend at astro dot wisc.edu]

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

--- Comment #1 from Rich Townsend  ---
An even-simpler demo:

--
program test_str_2

  write(*,*) ''

end program test_str_2
--

Compile with -O2 -Warray-bounds gives

test_str_2.f90:3:0:

   write(*,*) ''

Warning: array subscript 1 is above array bounds of 'character(kind=1)[1:0]'
[-Warray-bounds]

cheers,

Rich

[Bug fortran/90238] New: Bogus warning from -Warray-bounds, triggered by zero-length character literal

[townsend at astro dot wisc.edu]

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

Bug ID: 90238
   Summary: Bogus warning from -Warray-bounds, triggered by
zero-length character literal
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

The zero-length character literal following example program triggers a bogus
array-bounds warning:

--
program test_str

  call foo('bar')
  call foo('')

contains

  subroutine foo (a)

character(*), intent(in) :: a

print *, a

  end subroutine foo

end program test_str
--

Compiling with -O2 -Warray-bounds, the warning is:

test_str.f90:4:0:

   call foo('')

Warning: array subscript 1 is above array bounds of 'character(kind=1)[1:0]'
[-Warray-bounds]

Compiling at -O1 or -O0 does not trigger the warning.

cheers,

Rich

[Bug fortran/90237] New: Bogus warning from -Wdo-subscript

[townsend at astro dot wisc.edu]

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

Bug ID: 90237
   Summary: Bogus warning from -Wdo-subscript
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

I'm encountering a bogus subscript-in-loop warning triggered by -Wdo-subscript

Example:

--
program do_subscript_bug

  implicit none

  real:: a(10)
  integer :: i

  a = 0.

  do i = 1, 10
 if (i > 1) then
print *, a(i-1)
 endif
  end do

end program do_subscript_bug
--

Compiling with -Wdo-subscript gives this error:

do_subscript_bug.f90:12:19:

do_subscript_bug.f90:10:14:

   do i = 1, 10
  2 
do_subscript_bug.f90:12:19:

 print *, a(i-1)
   1
Warning: Array reference at (1) out of bounds (0 < 1) in loop beginning at (2)
[-Wdo-subscript]

cheers,

Rich

[Bug fortran/86484] New: Undefined symbol when using polymorphic intrinsic assignment

[townsend at astro dot wisc.edu]

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

Bug ID: 86484
   Summary: Undefined symbol when using polymorphic intrinsic
assignment
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

I'm getting an undefined symbol at link time when compiling the following test
program, which involves intrinsic polymorphic assignment:

program test_assign

  implicit none

  type :: foo_t
 real :: a = 1.
  end type foo_t

  type, extends (foo_t) :: bar_t
 real :: b = 2.
  end type bar_t

  class(foo_t), allocatable :: f
  type(bar_t)   :: b

  f = b

  print *, f%a

end program test_assign

From compiling:

% gfortran -O2 -o test_assign test_assign.f90
Undefined symbols for architecture x86_64:
  "___copy_test_assign_Bar_t.3535", referenced from:
  _MAIN__ in ccPjl5CK.o
  ___vtab_test_assign_Bar_t.3533 in ccPjl5CK.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

This problem seems to exist on both 7.2 and 8.1, and on both Linux and OSX.

cheers,

Rich

[Bug fortran/86481] Memory leak with nested source allocations

[townsend at astro dot wisc.edu]

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

--- Comment #1 from Rich Townsend  ---
As addenda:

*) I also see the problem on gfortran 8.1

*) It doesn't seem to matter whether bar_t is a subclass of foo_t. This choice
was based on the code I developed the test case for, but removing the
extends(foo_t) clause from the definition of bar_t leads to the same outcome.

cheers,

Rich

[Bug fortran/86481] New: Memory leak with nested source allocations

[townsend at astro dot wisc.edu]

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

Bug ID: 86481
   Summary: Memory leak with nested source allocations
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

Created attachment 44380
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44380=edit
Example program showing the leak

I've come across a memory leak with gfortran 7.2.0 (running on Gentoo Linux
x86_64), that seems somehow to be related to nested sourced allocations (at
least, that's what I've been able to determine). I attach a simple test case
that demonstrates the problem. Compile this with

gfortran -O2 -g -o simple_leak simple_leak.f90

Then, running valgrind:

valgrind --leak-check=full ./simple_leak

...I get the following output:

==11555== Memcheck, a memory error detector
==11555== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==11555== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==11555== Command: ./simple_leak
==11555== 
==11555== 
==11555== HEAP SUMMARY:
==11555== in use at exit: 89,600 bytes in 400 blocks
==11555==   total heap usage: 515 allocs, 115 frees, 133,468 bytes allocated
==11555== 
==11555== 44,800 (4,800 direct, 40,000 indirect) bytes in 100 blocks are
definitely lost in loss record 4 of 4
==11555==at 0x4C29BFD: malloc (vg_replace_malloc.c:299)
==11555==by 0x4006CC: func_foo (simple_leak.f90:44)
==11555==by 0x4006CC: func_bar (simple_leak.f90:33)
==11555==by 0x4006CC: simple_leak (simple_leak.f90:23)
==11555==by 0x4006CC: main (simple_leak.f90:22)
==11555== 
==11555== LEAK SUMMARY:
==11555==definitely lost: 4,800 bytes in 100 blocks
==11555==indirectly lost: 40,000 bytes in 100 blocks
==11555==  possibly lost: 0 bytes in 0 blocks
==11555==still reachable: 44,800 bytes in 200 blocks
==11555== suppressed: 0 bytes in 0 blocks
==11555== Reachable blocks (those to which a pointer was found) are not shown.
==11555== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==11555== 
==11555== For counts of detected and suppressed errors, rerun with: -v
==11555== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

>From a bit of playing around, it seems the error may be related to the fact
that I'm doing a pair of nested sourced allocations -- one allocation (in
func_bar) has an expression for the SOURCE argument that involves a second
sourced allocation (in func_foo).

cheers,

Rich

[Bug fortran/81241] write end of file

[townsend at astro dot wisc.edu]

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

--- Comment #6 from Rich Townsend  ---
Jim's patch for pr81195 fixes all the issues we've been experiencing -- so yes,
this counts as a duplicate. Thanks to all for the quick response.

[Bug fortran/81241] write end of file

[townsend at astro dot wisc.edu]

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

--- Comment #2 from Rich Townsend  ---
Aha, given that MESA is multithreaded, this may well be linked to this issue:

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

Certainly, running with just 1 thread seems to make things behave.

[Bug fortran/81241] write end of file

[townsend at astro dot wisc.edu]

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

--- Comment #1 from Rich Townsend  ---
(Apologies for the initial blank description, my web-browser submitted before I
was ready).

I've recently upgraded to gfortran 7.1 from 5.3, and am seeing a large number
of breakages in a significant piece of software that I help maintain (the
"Modules for Experiments in Stellar Astrophysics" project -- MESA).

The breakages are unfortunately intermittent -- sometimes they occur, and
sometimes not. But they all share the similarity of being triggered by internal
write statements. Sometimes the code crashes with a segfault on the internal
write; and sometimes it stops with the error message:

Fortran runtime error: End of fileERROR STOP 1

The breakage occurs on both Linux and OSX 10.12.

As an example backtrace from a segfault:

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

Backtrace for this error:
#0  0x2b7af459555f in ???
#1  0x2b7af381f7d6 in write_decimal
at /root/mesasdk-src/gcc/libgfortran/io/write.c:852
#2  0x2b7af3816c9c in formatted_transfer_scalar_write
at /root/mesasdk-src/gcc/libgfortran/io/transfer.c:2043
#3  0x2b7af38170fc in formatted_transfer
at /root/mesasdk-src/gcc/libgfortran/io/transfer.c:2272
#4  0x859bca in setstr
at ../private/eosdt_load_tables.f90:220
#5  0x85b624 in __eosdt_load_tables_MOD_get_eosdt_table_filenames
at ../private/eosdt_load_tables.f90:192
#6  0x85e132 in read_one
at ../private/eosdt_load_tables.f90:172
#7  0x85e2bd in do_read
at ../private/eosdt_load_tables.f90:156
#8  0x85e2bd in __eosdt_load_tables_MOD_load_single_eosdt_table_by_id
at ../private/eosdt_load_tables.f90:149
#9  0x8242cf in __eosdt_eval_MOD_get_eosdt_xtable_results
at ../private/eosdt_eval.f90:1079
#10  0x825cc9 in do_interp2
at ../private/eosdt_eval.f90:797
#11  0x825cc9 in __eosdt_eval_MOD_get_opal_scvh_results
at ../private/eosdt_eval.f90:758
#12  0x826c51 in __eosdt_eval_MOD_get_eosdt_results
at ../private/eosdt_eval.f90:387
#13  0x828800 in f
at ../private/eosdt_eval.f90:2340
#14  0x9362d2 in __mod_root_MOD_do_safe_root_with_guess
at ../private/mod_root.f:102
#15  0x81ff7b in __eosdt_eval_MOD_do_safe_get_rho_t
at ../private/eosdt_eval.f90:2297
#16  0x820508 in __eosdt_eval_MOD_get_rho
at ../private/eosdt_eval.f90:2178
#17  0x829199 in __eospt_eval_MOD_get_pt_results_using_dt
at ../private/eospt_eval.f90:1127
#18  0x82c783 in __eospt_eval_MOD_get_eospt_results
at ../private/eospt_eval.f90:213
#19  0x8171c1 in __eos_lib_MOD_eospt_get
at ../public/eos_lib.f90:805
#20  0x4ae874 in eval_eospt
at ../private/micro.f90:678
#21  0x4ae874 in __micro_MOD_do_eos_for_cell
at ../private/micro.f90:381
#22  0x4293d4 in __star_utils_MOD_foreach_cell._omp_fn.1
at ../private/star_utils.f90:68
#23  0x2b7af3cd48cd in gomp_thread_start
at /root/mesasdk-src/gcc/libgomp/team.c:120
#24  0x2b7af434c65c in ???
#25  0x2b7af4633ecc in ???
./rn: line 8:  5111 Segmentation fault  (core dumped) ./star

The offending line of code which triggered the segfault was this:

write(str, '(a,i1)') '0', floor(100d0 * v + 0.5)

I realize that this is an unconventional bug report -- I'm unable to provide a
test case which demonstrates the problem, since it comes and goes. However, I'm
hoping the backtrace above may be helpful, and I'd appreciate any suggestions
on how to proceed in tracking this down.

cheers,

Rich

[Bug fortran/81241] New: write end of file

[townsend at astro dot wisc.edu]

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

Bug ID: 81241
   Summary: write end of file
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

[Bug fortran/79446] Passing internal procedure as argument causes segfault at runtime

[townsend at astro dot wisc.edu]

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

--- Comment #2 from Rich Townsend  ---
(In reply to Dominique d'Humieres from comment #1)
> > Also, I don't experience the segfault on other Linux distros
> > (e.g., Gentoo/3.16.5) or Mac OS.
> 
> Confirmed on x86_64-apple-darwin16, even using an instrumented gfortran and
> -fsanitize=address,undefined.
> 
> What is the output of gfortran -v?

Using built-in specs.
COLLECT_GCC=/var/lib/condor/execute/slot1/dir_727203/mesasdk/bin/gfortran.exec
COLLECT_LTO_WRAPPER=/var/lib/condor/execute/slot1/dir_727203/mesasdk/bin/../libexec/gcc/x86_64-pc-linux-gnu/5.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/lib/condor/execute/slot1/dir_460062/mesasdk-src/gcc/configure CC=gcc
--build=x86_64-pc-linux-gnu
--prefix=/var/lib/condor/execute/slot1/dir_460062/mesasdk
--with-gmp=/var/lib/condor/execute/slot1/dir_460062/mesasdk
--with-mpfr=/var/lib/condor/execute/slot1/dir_460062/mesasdk
--with-mpc=/var/lib/condor/execute/slot1/dir_460062/mesasdk
--enable-languages=c,c++,fortran --disable-multilib --disable-nls
--disable-libsanitizer --enable-clocale=generic
Thread model: posix
gcc version 5.3.1 20160216 (GCC) 

Also, this is svn 245289.

[Bug fortran/79446] New: Passing internal procedure as argument causes segfault at runtime

[townsend at astro dot wisc.edu]

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

Bug ID: 79446
   Summary: Passing internal procedure as argument causes segfault
at runtime
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

Created attachment 40709
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40709=edit
Example program

Attached program demonstrates my problem. Compiling with:

gfortran -std=f2008 -g -o test_mem test_mem.f90

Running on RHEL (2.6.32-642.13.1.el6.x86_64), I get the following segfault:

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

Backtrace for this error:
#0  0x14E10ED8FBB7
#1  0x14E10ED8EDB0
#2  0x354523269F
#3  0x7FFC67EF9B00
Segmentation fault (core dumped)

In gdb:

(gdb) where
#0  0x7ffe250e7390 in ?? ()
#1  0x00400865 in test_mem_m::do (a=3, theirproc=0x7ffe250e7390) at
test_mem.f90:17
#2  0x00400928 in test_mem () at test_mem.f90:29
#3  0x0040095f in main (argc=1, argv=0x7ffe250e9110) at test_mem.f90:25
#4  0x00354521ed5d in __libc_start_main () from /lib64/libc.so.6
#5  0x00400709 in _start ()

If I change the internal procedure to a non-internal one, the segfault goes
away. Also, I don't experience the segfault on other Linux distros (e.g.,
Gentoo/3.16.5) or Mac OS.

cheers,

Rich

[Bug fortran/72798] Module (.mod) file changes even when interface does not

[townsend at astro dot wisc.edu]

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

--- Comment #2 from Rich Townsend  ---
Hmm, I can understand why having an internal pure attribute makes sense from an
optimiser point of view. But it results in having lots of compilation cascades
during debugging, which sucks.

Is there a way to force gfortran to treat all routines as being (internally)
impure, unless explicitly declared as pure?

[Bug fortran/72798] New: Module (.mod) file changes even when interface does not

[townsend at astro dot wisc.edu]

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

Bug ID: 72798
   Summary: Module (.mod) file changes even when interface does
not
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

Created attachment 39054
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39054=edit
Test case demonstrating problem

In a big project I'm involved in, we take advantage of the fact that gfortran's
.mod files don't change across a recompilation, if the public interface of the
module is unchanged. This allows us to avoid very time-consuming compilation
cascades.

However, I've run into a case where this desirable behavior doesn't seem to
work. If I compile the attached module ('gfortran -c test_mod.f90') with and
without the print statement commented out, I get .mod files which not only
differ in contents, but also in size.

Is this correct behavior? If so, how might I go about judging whether the
public interface of a module has or hasn't changed?

[Bug fortran/70705] New: Associate construct with array section causes ICE

[townsend at astro dot wisc.edu]

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

Bug ID: 70705
   Summary: Associate construct with array section causes ICE
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

Created attachment 38298
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38298=edit
Example program

In the example program attached, compilation (gfortran -o ice ice.f90) causes
the following ICE:

ice.f90:16:0:

 x = 0.
 1
internal compiler error: in gfc_get_element_type, at fortran/trans-types.c:1201

ice.f90:16:0: internal compiler error: Abort trap: 6
gfortran.exec: internal compiler error: Abort trap: 6 (program f951)

cheers,

Rich

[Bug fortran/69268] [5 Regression] Sourced allocation calls function twice

[townsend at astro dot wisc.edu]

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

--- Comment #3 from Rich Townsend  ---
Proposed patch appears to work in the real-world case I'm focused on. Thanks!

[Bug fortran/69268] New: Sourced allocation calls function twice

[townsend at astro dot wisc.edu]

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

Bug ID: 69268
   Summary: Sourced allocation calls function twice
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

Created attachment 37338
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37338=edit
Source code of program reproducing the problem

The attached program demonstrates that, in a sourced allocation based on a
function call, the function is called twice. Example output:

 called:   1
 called:   2

I believe this may gave been fixed in 6.0, but 5.3 seems to still have the
problem.

[Bug fortran/69185] bounds-check gives false positive on assignment to allocatable array

[townsend at astro dot wisc.edu]

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

--- Comment #2 from Rich Townsend  ---
(In reply to Dominique d'Humieres from comment #1)
> It looks like a duplicate of pr52162. Unless you object I'll mark this PRas
> a duplicate in the coming days.

Agreed!

[Bug fortran/69185] New: bounds-check gives false positive on assignment to allocatable array

[townsend at astro dot wisc.edu]

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

Bug ID: 69185
   Summary: bounds-check gives false positive on assignment to
allocatable array
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

Created attachment 37255
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37255=edit
Source code of program reproducing the problem

Compile the attached code with:

gfortran -fbounds-check -std=f2003 -o foo foo.f90

On execution, the assignment to b should be OK, since b will be allocated to
match the shape of the RHS (as per F2003). However, the following run-time
error instead occurs:

At line 8 of file foo.f90
Fortran runtime error: Array bound mismatch for dimension 1 of array 'b' (20/4)

The problem does not arise if I use, e.g., 'a' on the RHS instead of 'exp(a)'.

[Bug bootstrap/64320] Missing config.h during findcomp.cc compilation

[townsend at astro dot wisc.edu]

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

--- Comment #1 from Rich Townsend townsend at astro dot wisc.edu ---
OK, it seems that this bug comes from building with srcdir == objdir. If I
build in a separate directory, then the problem goes away.

As an aside, I hadn't realized that using srcdir == objdir is generally
discouraged (see, e.g., https://gcc.gnu.org/install/configure.html). Is this a
recent change, or have I always been doing it wrong?

[Bug bootstrap/64320] New: Missing config.h during findcomp.cc compilation

[townsend at astro dot wisc.edu]

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

Bug ID: 64320
   Summary: Missing config.h during findcomp.cc compilation
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu

I'm trying to build the latest trunk (rev. 218759) on Linux. Configuring with:

 ./configure CC=gcc --build=x86_64-pc-linux-gnu --prefix=/root/madsdk
--with-gmp=/root/madsdk --with-mpfr=/root/madsdk --with-mpc=/root/madsdk
--enable-languages=c,c++,fortran --disable-multilib --disable-nls
--disable-libsanitizer

...I get the following error during make:

libtool: compile:  /root/madsdk-src/gcc/host-x86_64-pc-linux-gnu/gcc/xg++
-B/root/madsdk-src/gcc/host-x86_64-pc-linux-gnu/gcc/ -nostdinc++ -nostdinc++
-I/root/madsdk-src/gcc/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/root/madsdk-src/gcc/x86_64-pc-linux-gnu/libstdc++-v3/include
-I/root/madsdk-src/gcc/libstdc++-v3/libsupc++
-I/root/madsdk-src/gcc/libstdc++-v3/include/backward
-I/root/madsdk-src/gcc/libstdc++-v3/testsuite/util
-L/root/madsdk-src/gcc/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/root/madsdk-src/gcc/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/root/madsdk-src/gcc/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/root/madsdk-src/gcc/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/root/madsdk-src/gcc/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/root/madsdk/x86_64-pc-linux-gnu/bin/ -B/root/madsdk/x86_64-pc-linux-gnu/lib/
-isystem /root/madsdk/x86_64-pc-linux-gnu/include -isystem
/root/madsdk/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I../.././libcc1 -I ../.././libcc1/../include -I ../.././libcc1/../libgcc -I
../host-x86_64-pc-linux-gnu/gcc -I../.././libcc1/../gcc -I
../.././libcc1/../gcc/c -I ../.././libcc1/../gcc/c-family -I
../.././libcc1/../libcpp/include -I/root/madsdk/include -I/root/madsdk/include
-I/root/madsdk/include -W -Wall -fvisibility=hidden -g -O2 -D_GNU_SOURCE -MT
findcomp.lo -MD -MP -MF .deps/findcomp.Tpo -c ../.././libcc1/findcomp.cc  -fPIC
-DPIC -o .libs/findcomp.o
../.././libcc1/findcomp.cc:20:20: fatal error: config.h: No such file or
directory
compilation terminated.
make[3]: *** [findcomp.lo] Error 1
make[3]: Leaving directory
`/root/madsdk-src/gcc/host-x86_64-pc-linux-gnu/libcc1'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/root/madsdk-src/gcc/host-x86_64-pc-linux-gnu/libcc1'
make[1]: *** [all-libcc1] Error 2
make[1]: Leaving directory `/root/madsdk-src/gcc'
make: *** [all] Error 2

When attempting to build on OS X (10.6), I get the exact same error.

[Bug fortran/64173] New: ICE involving derived type function pointers

[townsend at astro dot wisc.edu]

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

Bug ID: 64173
   Summary: ICE involving derived type function pointers
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu

Created attachment 34184
  -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34184action=edit
Code to reproduce the crash

I'm encountering an ICE when compiling the attached code with 4.9.2 on OS X
Yosemite (the error also occurs on 10.0/Linux). The error is as follows:

gyre_r_magnus_ivp.f90: In function 'doinit':
gyre_r_magnus_ivp.f90:36:0: internal compiler error: in
gfc_conv_descriptor_data_set, at fortran/trans-array.c:172
  end function doinit
 ^

gyre_r_magnus_ivp.f90:36:0: internal compiler error: Abort trap: 6
gfortran.exec: internal compiler error: Abort trap: 6 (program f951)

The code is a pruned down version of some production code; I've tried to remove
as much superfluous stuff as possible. It seems that the combination of a
procedure pointer and a derived type component, in the definition of
r_magnus_ivp_t, is responsible for the crash -- but note that the crash
disappears if I comment out the doinit routine. Weird!

[Bug fortran/56218] [OOP] Segfault with allocatable intent(out) derived type argument having allocatable component

[townsend at astro dot wisc.edu]

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

--- Comment #4 from Rich Townsend townsend at astro dot wisc.edu ---
Seems to work fine on 4.10 (20140710).

[Bug libfortran/60324] Handle arbitrarily long path names

[townsend at astro dot wisc.edu]

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

Rich Townsend townsend at astro dot wisc.edu changed:

   What|Removed |Added

 CC||townsend at astro dot wisc.edu

--- Comment #6 from Rich Townsend townsend at astro dot wisc.edu ---
This change introduces a dependency on strndup -- which, alas, is absent from
libSystem in OS X 10.6 (Snow Leopard), although later releases of OS X include
it. This isn't a problem per se, as it appears that an internal strndup will be
built if a system one can't be found.

Howver, today, I've run into the problem that when I build gcc/gfortran (trunk)
on 10.9, I can't then use the compiler on 10.6 due to the reference in
libgfortran (and perhaps elsewhere) to the (missing) system strndup. Any
suggestions for workarounds? Can I hack libgfortran/configure.ac to force the
internal strndup to be used?

cheers,

Rich

[Bug fortran/60370] New: TRANSPOSE on rhs of allocatable array assignment gives bounds error

[townsend at astro dot wisc.edu]

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

Bug ID: 60370
   Summary: TRANSPOSE on rhs of allocatable array assignment gives
bounds error
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu

The following code:

program foo

  real, allocatable :: a(:,:)
  real, allocatable :: b(:,:)

  allocate(a(10,5))

  a = 0.

  b = TRANSPOSE(a)

end program foo

...produces this error message at runtime, when compiled with -fcheck=all:

At line 10 of file foo.f90
Fortran runtime error: Array bound mismatch for dimension 1 of array 'b' (1/5)

This is on OS X:

Using built-in specs.
COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec
COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0'
--build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk
--with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk
--with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran
--disable-multilib --disable-nls --disable-libsanitizer
Thread model: posix
gcc version 4.9.0 20140201 (experimental) (GCC)

[Bug fortran/59589] [4.9 Regression] Memory leak when deallocating polymorphic

[townsend at astro dot wisc.edu]

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

--- Comment #10 from Rich Townsend townsend at astro dot wisc.edu ---
(In reply to Dominique d'Humieres from comment #9)
  So it's actually a regression.
 
 Marking as a regression, even if I am not fully convinced.

Further support from valgrind on x86_64-pc-linux-gnu:

==28614== HEAP SUMMARY:
==28614== in use at exit: 40,000,000 bytes in 10 blocks
==28614==   total heap usage: 57 allocs, 47 frees, 40,004,263 bytes allocated
==28614== 
==28614== 8,000,000 bytes in 2 blocks are possibly lost in loss record 1 of 2
==28614==at 0x4C2C66D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==28614==by 0x400E7F: MAIN__ (in /home/townsend/test_leak)
==28614==by 0x401153: main (in /home/townsend/test_leak)
==28614== 
==28614== 32,000,000 bytes in 8 blocks are definitely lost in loss record 2 of
2
==28614==at 0x4C2C66D: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==28614==by 0x400E7F: MAIN__ (in /home/townsend/test_leak)
==28614==by 0x401153: main (in /home/townsend/test_leak)
==28614== 
==28614== LEAK SUMMARY:
==28614==definitely lost: 32,000,000 bytes in 8 blocks
==28614==indirectly lost: 0 bytes in 0 blocks
==28614==  possibly lost: 8,000,000 bytes in 2 blocks
==28614==still reachable: 0 bytes in 0 blocks
==28614== suppressed: 0 bytes in 0 blocks

townsend@chell ~ $ gfortran -v
Using built-in specs.
COLLECT_GCC=/home/townsend/madsdk/bin/gfortran.exec
COLLECT_LTO_WRAPPER=/home/townsend/madsdk/bin/../libexec/gcc/x86_64-pc-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure CC=gcc --build=x86_64-pc-linux-gnu
--prefix=/root/madsdk --with-gmp=/root/madsdk --with-mpfr=/root/madsdk
--with-mpc=/root/madsdk --enable-languages=c,c++,fortran --disable-multilib
--disable-nls --disable-libsanitizer
Thread model: posix
gcc version 4.9.0 20131223 (experimental) (GCC)

[Bug fortran/59589] New: Memory leak when deallocating polymorphic

[townsend at astro dot wisc.edu]

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

Bug ID: 59589
   Summary: Memory leak when deallocating polymorphic
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu

Created attachment 31507
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31507action=edit
Test code demonstrating leak

The attached code leaks memory, as indicated by the 'ps' call.

[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[townsend at astro dot wisc.edu]

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

--- Comment #11 from Rich Townsend townsend at astro dot wisc.edu ---
#6 fails with 4.9.0 (svn rev. 206179), on both OS X and Linux.

[Bug fortran/59589] Memory leak when deallocating polymorphic

[townsend at astro dot wisc.edu]

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

--- Comment #1 from Rich Townsend townsend at astro dot wisc.edu ---
Oops, missed out details. This is with rev. 206179, on both OS X and Linux.

[Bug fortran/59589] Memory leak when deallocating polymorphic

[townsend at astro dot wisc.edu]

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

--- Comment #3 from Rich Townsend townsend at astro dot wisc.edu ---
(In reply to Dominique d'Humieres from comment #2)
 Works for me on OS X for 4.8.2 or trunk. What command are you using?

townsend@talos ~ $ gfortran -v
Using built-in specs.
COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec
COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0'
--build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk
--with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk
--with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran
--disable-multilib --disable-nls --disable-libsanitizer
Thread model: posix
gcc version 4.9.0 20131223 (experimental) (GCC) 

townsend@talos ~ $ gfortran -o test_leak test_leak.f90 

townsend@talos ~ $ ./test_leak 
./test_leak  39688
./test_leak  78764
./test_leak 117828
./test_leak 156908
./test_leak 195972
./test_leak 235036
./test_leak 274100
./test_leak 313164
./test_leak 352228
./test_leak 391292

...so, the memory usage grows on each iteration of the loop; this suggests a
leak.

[Bug fortran/58007] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix

[townsend at astro dot wisc.edu]

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

Rich Townsend townsend at astro dot wisc.edu changed:

   What|Removed |Added

 CC||townsend at astro dot wisc.edu

--- Comment #9 from Rich Townsend townsend at astro dot wisc.edu ---
(In reply to Mikael Morin from comment #8)
 Created attachment 30656 [details]
 tentative hack
 
 For some reason this patch fixes the internal error on comment #6, but not
 on comment #4.

I can conform that this patch works to fix the bug on trunk (rev. 202487)
running on OS X 10.7. Without the patch, the test case in #6 fails with the
usual unresolved fixup issue.

However, *with* Mikael's patch I'm no longer able to build the HDF5 libraries
(1.8.10-patch1). During compilation of the Fortran API, I get the following:

tH5L_F03.f90:125.6:

  USE liter_cb_mod
  1
Internal Error at (1):
free_pi_tree(): Unresolved fixup
make[2]: *** [tH5L_F03.o] Error 1

I configured thusly:

./configure --build=x86_64-apple-darwin11.4.2 --prefix=/Applications/mesasdk
--enable-fortran --enable-fortran2003

This has become a showstopper for me: I need Mikael's patch to fix unresolved
fixup issues with my own codes (with a similar trigger to the examples given
above), but I also need the HDF5 libraries for the codes. Unresolved fixups are
the #1 bug I've encountered with gfortran over the past year, yet due to their
very temperamental nature they're difficult to report and thus difficult to
make the gfortran developers sit up and take notice of.

So, I'd like to make a earnest plea to the devs: please get to the bottom of
this! I'm happy to work closely with you in coming up with test cases that
trigger the bug. But this really needs to be fixed; it basically kills gfortran
as a viable compiler.

[Bug fortran/53309] Unnecessary temporary array creation in subroutine call

[townsend at astro dot wisc.edu]

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

--- Comment #3 from Rich Townsend townsend at astro dot wisc.edu ---
Thanks for the explanation about -Warray-temporaries vs.
-fcheck-array-temporaries -- got it!

Might be worth changing the output text from the former to something like
Warning: Array temporary might be created at (1)

[Bug c/57956] missing 'msgstr' section errors when building

[townsend at astro dot wisc.edu]

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

--- Comment #1 from Rich Townsend townsend at astro dot wisc.edu ---
Temporary workaround: add --disable-nls to ./configure args.

[Bug c/57956] New: missing 'msgstr' section errors when building

[townsend at astro dot wisc.edu]

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

Bug ID: 57956
   Summary: missing 'msgstr' section errors when building
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu

When compiling trunk on x86_64 Fedora Core 6, I encounter the following after
configuring and running make:

make[3]: Entering directory
`/home/townsend/mesasdk-src/gcc/host-x86_64-pc-linux-gnu/gcc'
/bin/sh ../.././gcc/../mkinstalldirs po
/bin/sh ../.././gcc/../mkinstalldirs po
/bin/sh ../.././gcc/../mkinstalldirs po
mkdir -p -- po
mkdir -p -- po
/usr/bin/msgfmt --statistics -o po/be.gmo ../.././gcc/po/be.po
/usr/bin/msgfmt --statistics -o po/da.gmo ../.././gcc/po/da.po
mkdir -p -- po
/usr/bin/msgfmt --statistics -o po/de.gmo ../.././gcc/po/de.po
/bin/sh ../.././gcc/../mkinstalldirs po
/usr/bin/msgfmt --statistics -o po/el.gmo ../.././gcc/po/el.po
/bin/sh ../.././gcc/../mkinstalldirs po
/usr/bin/msgfmt --statistics -o po/es.gmo ../.././gcc/po/es.po
/bin/sh ../.././gcc/../mkinstalldirs po
/usr/bin/msgfmt --statistics -o po/fi.gmo ../.././gcc/po/fi.po
106 translated messages, 1754 fuzzy translations, 7787 untranslated messages.
/bin/sh ../.././gcc/../mkinstalldirs po
/usr/bin/msgfmt --statistics -o po/fr.gmo ../.././gcc/po/fr.po
74 translated messages, 3070 fuzzy translations, 6503 untranslated messages.
/bin/sh ../.././gcc/../mkinstalldirs po
/usr/bin/msgfmt --statistics -o po/hr.gmo ../.././gcc/po/hr.po
2333 translated messages, 1813 fuzzy translations, 5511 untranslated messages.
/bin/sh ../.././gcc/../mkinstalldirs po
/usr/bin/msgfmt --statistics -o po/id.gmo ../.././gcc/po/id.po
1299 translated messages, 4496 fuzzy translations, 3852 untranslated messages.
/bin/sh ../.././gcc/../mkinstalldirs po
/usr/bin/msgfmt --statistics -o po/ja.gmo ../.././gcc/po/ja.po
9657 translated messages.
/bin/sh ../.././gcc/../mkinstalldirs po
/usr/bin/msgfmt --statistics -o po/nl.gmo ../.././gcc/po/nl.po
8976 translated messages, 498 fuzzy translations, 173 untranslated messages.
/bin/sh ../.././gcc/../mkinstalldirs po
/usr/bin/msgfmt --statistics -o po/ru.gmo ../.././gcc/po/ru.po
162 translated messages, 13 fuzzy translations, 9472 untranslated messages.
/bin/sh ../.././gcc/../mkinstalldirs po
/usr/bin/msgfmt --statistics -o po/sr.gmo ../.././gcc/po/sr.po
1697 translated messages, 4485 fuzzy translations, 3465 untranslated messages.
/bin/sh ../.././gcc/../mkinstalldirs po
4050 translated messages, 1526 fuzzy translations, 4071 untranslated messages.
/usr/bin/msgfmt --statistics -o po/sv.gmo ../.././gcc/po/sv.po
/bin/sh ../.././gcc/../mkinstalldirs po
/usr/bin/msgfmt --statistics -o po/tr.gmo ../.././gcc/po/tr.po
5584 translated messages, 2893 fuzzy translations, 1170 untranslated messages.
/bin/sh ../.././gcc/../mkinstalldirs po
/usr/bin/msgfmt --statistics -o po/vi.gmo ../.././gcc/po/vi.po
707 translated messages, 3992 fuzzy translations, 4948 untranslated messages.
/bin/sh ../.././gcc/../mkinstalldirs po
/usr/bin/msgfmt --statistics -o po/zh_CN.gmo ../.././gcc/po/zh_CN.po
3407 translated messages, 3726 fuzzy translations, 2524 untranslated messages.
/bin/sh ../.././gcc/../mkinstalldirs po
/usr/bin/msgfmt --statistics -o po/zh_TW.gmo ../.././gcc/po/zh_TW.po
4495 translated messages, 3387 fuzzy translations, 1765 untranslated messages.
TARGET_CPU_DEFAULT= \
HEADERS=auto-host.h ansidecl.h DEFINES= \
/bin/sh ../.././gcc/mkconfig.sh config.h
TARGET_CPU_DEFAULT= \
HEADERS=options.h insn-constants.h config/vxworks-dummy.h
config/i386/biarch64.h config/i386/i386.h config/linux-android.h
config/i386/unix.h config/i386/att.h config/dbxelf.h config/elfos.h
config/gnu-user.h config/glibc-stdint.h config/i386/x86-64.h
config/i386/gnu-user-common.h config/i386/gnu-user64.h config/linux.h
config/i386/linux-common.h config/i386/linux64.h config/initfini-array.h
defaults.h DEFINES=LIBC_GLIBC=1 LIBC_UCLIBC=2 LIBC_BIONIC=3
DEFAULT_LIBC=LIBC_GLIBC ANDROID_DEFAULT=0 \
/bin/sh ../.././gcc/mkconfig.sh tm.h
gawk -f ../.././gcc/opt-gather.awk ../.././gcc/ada/gcc-interface/lang.opt
../.././gcc/fortran/lang.opt ../.././gcc/go/lang.opt ../.././gcc/java/lang.opt
../.././gcc/lto/lang.opt ../.././gcc/c-family/c.opt ../.././gcc/common.opt
../.././gcc/config/fused-madd.opt ../.././gcc/config/i386/i386.opt
../.././gcc/config/gnu-user.opt ../.././gcc/config/linux.opt
../.././gcc/config/linux-android.opt  tmp-optionlist
3894 translated messages, 870 fuzzy translations, 4893 untranslated messages.
9657 translated messages.
TARGET_CPU_DEFAULT= \
HEADERS=auto-host.h ansidecl.h DEFINES= \
/bin/sh ../.././gcc/mkconfig.sh bconfig.h
4074 translated messages, 3568 fuzzy translations, 2005 untranslated messages.
flex  -ogengtype-lex.c ../.././gcc/gengtype-lex.l  { \
  echo '#include bconfig.h'  gengtype-lex.c.tmp; \
  cat gengtype-lex.c

[Bug fortran/57922] New: Memory leak with allocatable polymorphics

[townsend at astro dot wisc.edu]

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

Bug ID: 57922
   Summary: Memory leak with allocatable polymorphics
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu

Created attachment 30520
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30520action=edit
Example program

I'm experiencing a problem with:

Using built-in specs.
COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec
COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0'
--build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk
--with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk
--with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
gcc version 4.9.0 20130404 (experimental) (GCC) 

The attached example program demonstrates the problem. When f is deallocated,
it seems that f%x is not getting deallocated, causing the memory footprint of
the program (as reported by the ps syscall) to grow without bound.

[Bug fortran/56872] New: Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize

[townsend at astro dot wisc.edu]

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



 Bug #: 56872

   Summary: Incorrect SUM evaluation, involving implied-do loop,

with -ffrontend-optimize

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: towns...@astro.wisc.edu





The attached code gives the incorrect results when compiled with

-ffrontend-optimize (either explicitly, or via use of one of the -O flags).



Correct behavior:



$ gfortran -o sum_bug sum_bug.f90

$ ./sum_bug 

   1.   1000.0

   1001.0



Incorrect behavior (i):



$ gfortran -O2 -o sum_bug sum_bug.f90

$ ./sum_bug 

   1.   1000.0

   1.0005E-03



Incorrect behavior (ii):



$ gfortran -ffrontend-optimize -o sum_bug sum_bug.f90

$ ./sum_bug 

   1.   1000.0

 Infinity



gfortran -v gives:



Using built-in specs.

COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec

COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/lto-wrapper

Target: x86_64-apple-darwin11.4.2

Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0'

--build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk

--with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk

--with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran

--disable-multilib

Thread model: posix

gcc version 4.9.0 20130404 (experimental) (GCC)

[Bug fortran/56872] Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize

[townsend at astro dot wisc.edu]

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



--- Comment #1 from Rich Townsend townsend at astro dot wisc.edu 2013-04-08 
06:02:42 UTC ---

Created attachment 29821

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29821

Test program to reproduce the error

[Bug fortran/50269] Wrongly rejects element of assumed-shape array in C_LOC

[townsend at astro dot wisc.edu]

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



Rich Townsend townsend at astro dot wisc.edu changed:



   What|Removed |Added



 CC||townsend at astro dot

   ||wisc.edu



--- Comment #5 from Rich Townsend townsend at astro dot wisc.edu 2013-04-01 
15:30:54 UTC ---

(In reply to comment #4)

 FIXED on the 4.9 trunk.



Is this going to be ported back to earlier releases? It's kind of a biggie for

me...

[Bug fortran/50269] Wrongly rejects element of assumed-shape array in C_LOC

[townsend at astro dot wisc.edu]

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



--- Comment #6 from Rich Townsend townsend at astro dot wisc.edu 2013-04-01 
22:24:35 UTC ---

(In reply to comment #4)

 FIXED on the 4.9 trunk.



Are we sure? When running the code example given in comment #1, I get a

segfault.



Moreover, the following subroutine won't compile when using the '-std=f2008'

flag:



subroutine test_contig (a)

  use ISO_C_BINDING

  real, intent(in), contiguous, target :: a(:)

  type(C_PTR) :: b

  b = C_LOC(a)

end subroutine test_contig



The error message is:



test_contig.f90:9.12:



  b = C_LOC(a)

1

Error: TS 29113: Noninteroperable array at (1) as argument to C_LOC: Only

explicit-size and assumed-size arrays are interoperable



My understanding of the F2008 standard is that assumed-shape arrays with the

contiguous attribute are interoperable -- hence, I'm not sure this error

message is correct. If I change the std flag to f2008ts, then the routine

compiles OK; but the TS extension shouldn't be required here.



gfortran -v:



Using built-in specs.

COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec

COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/lto-wrapper

Target: x86_64-apple-darwin11.4.2

Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0'

--build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk

--with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk

--with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran

--disable-multilib

Thread model: posix

gcc version 4.9.0 20130401 (experimental) (GCC)

[Bug fortran/56748] New: STOP statement + array optional variable causes bogus uninitialized warning

[townsend at astro dot wisc.edu]

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

 Bug #: 56748
   Summary: STOP statement + array optional variable causes bogus
uninitialized warning
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: towns...@astro.wisc.edu


Created attachment 29736
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29736
Sample code producing bogus warning

In the attached code, compilation with the following args:

gfortran -O2 -fcheck=all -Wall -c test_uninit.f90

...produces the following warning:

test_uninit.f90: In function ‘mysub’:
test_uninit.f90:13:0: warning: ‘b.0’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
  print *, b
 ^

The warning goes away if any of the following modifications are made:

*) any of the compilation flags is omitted
*) the stop statement in the code is commented out
*) the variable 'b' is made non-optional (and the PRESENT check is removed)
*) the variable 'b' is made a scalar

gfortran -v:
Using built-in specs.
COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec
COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.8.0/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0'
--build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk
--with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk
--with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
gcc version 4.8.0 20130314 (experimental) (GCC)

[Bug bootstrap/56656] Suffix or operands invalid for 'movq'

[townsend at astro dot wisc.edu]

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



--- Comment #12 from Rich Townsend townsend at astro dot wisc.edu 2013-03-20 
12:56:53 UTC ---

(In reply to comment #9)

 So I guess an important question is if the svn-fetched 4.8.0 wasn't actually

 svn-fetched trunk instead, Uros' changes have been committed only for 4.9 
 and

 not on the 4.8 branch.



It was indeed trunk. I wasn't aware that 4.8 is now a proper branch, so I was

still fetching the trunk.

[Bug fortran/56655] Associate construct with OpenMP triggers ICE

[townsend at astro dot wisc.edu]

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



--- Comment #2 from Rich Townsend townsend at astro dot wisc.edu 2013-03-20 
13:25:15 UTC ---

(In reply to comment #1)

 (In reply to comment #0)

  Created attachment 29692 [details]

  Test source file to reproduce the error

  

  Attempting to compile the attached file with

  

  gfortran -fopenmp -c openmp_ice.f90

 

 The file in the attachment is called 'test_h5_attr.f90' and I don't find any

 ASSOCIATE construct in there. Wrong file attached?



(In reply to comment #1)

 (In reply to comment #0)

  Created attachment 29692 [details]

  Test source file to reproduce the error

  

  Attempting to compile the attached file with

  

  gfortran -fopenmp -c openmp_ice.f90

 

 The file in the attachment is called 'test_h5_attr.f90' and I don't find any

 ASSOCIATE construct in there. Wrong file attached?



Ooops -- wrong test case. Here it is:



subroutine sub (x)



  implicit none



  real, intent(in) :: x



  !$omp single

  associate(x_a = x)

  end associate

  !$omp end single 



end subroutine sub

[Bug fortran/56670] New: Allocatable-length character var causes bogus warning with -Wall

[townsend at astro dot wisc.edu]

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

 Bug #: 56670
   Summary: Allocatable-length character var causes bogus warning
with -Wall
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: towns...@astro.wisc.edu


Compiling this short test case with the -Wall option:

program uninit_test

  implicit none

  character(LEN=:), allocatable :: name_format

  name_format = ''

end program uninit_test

...causes the following bogus warning:

uninit_test.f90: In function ‘uninit_test’:
uninit_test.f90:7:0: warning: ‘.name_format’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
   name_format = ''
 ^

(Note also that the warning arises in the main program, and not in a function
as the message suggests).

gfortran -v:

Using built-in specs.
COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec
COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.8.0/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0'
--build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk
--with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk
--with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
gcc version 4.8.0 20130314 (experimental) (GCC)

[Bug fortran/56655] New: Associate construct with OpenMP triggers ICE

[townsend at astro dot wisc.edu]

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

 Bug #: 56655
   Summary: Associate construct with OpenMP triggers ICE
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: towns...@astro.wisc.edu


Created attachment 29692
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29692
Test source file to reproduce the error

Attempting to compile the attached file with

gfortran -fopenmp -c openmp_ice.f90

...gives the following result:

openmp_ice.f90: In function ‘sub’:
openmp_ice.f90:8:0: internal compiler error: in omp_add_variable, at
gimplify.c:5894
   associate(x_a = x)
 ^

openmp_ice.f90:8:0: internal compiler error: Abort trap: 6
gfortran.exec: internal compiler error: Abort trap: 6 (program f951)
/Applications/madsdk/bin/gfortran: line 7: 16428 Abort trap: 6  
/Applications/madsdk/bin/gfortran.exec -fopenmp -c openmp_ice.f90

This may be related to PR 56062. My system:

Using built-in specs.
COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec
COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.8.0/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0'
--build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk
--with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk
--with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran
--disable-multilib
Thread model: posix
gcc version 4.8.0 20130307 (experimental) (GCC)

[Bug libgcc/56656] New: Suffix or operands invalid for 'movq'

[townsend at astro dot wisc.edu]

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



 Bug #: 56656

   Summary: Suffix or operands invalid for 'movq'

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libgcc

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: towns...@astro.wisc.edu





When attempting to compile the svn-fetched 4.8.0, I get the following error

during configuration:



/Volumes/Kleiner-Data/madsdk-src/gcc/host-x86_64-apple-darwin11.4.2/gcc/xgcc

-B/Volumes/Kleiner-Data/madsdk-src/gcc/host-x86_64-apple-darwin11.4.2/gcc/   -g

-O2 -O2  -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual

-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem

./include   -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc

-fno-stack-protector   -pipe -fno-common -I. -I.

-I../../host-x86_64-apple-darwin11.4.2/gcc -I../.././libgcc -I../.././libgcc/.

-I../.././libgcc/../gcc -I../.././libgcc/../include  -DHAVE_CC_TLS -DUSE_EMUTLS

-o extenddftf2_s.o -MT extenddftf2_s.o -MD -MP -MF extenddftf2_s.dep -DSHARED 

-c ../.././libgcc/soft-fp/extenddftf2.c

../.././libgcc/soft-fp/extenddftf2.c:35:8: warning: no previous prototype for

'__extenddftf2' [-Wmissing-prototypes]

 TFtype __extenddftf2(DFtype a)

^

:47:suffix or operands invalid for `movq'

:50:suffix or operands invalid for `movq'

make[3]: *** [extenddftf2_s.o] Error 1

make[2]: *** [all-stage1-target-libgcc] Error 2

make[1]: *** [stage1-bubble] Error 2

make: *** [all] Error 2



The configure uses the following:



./configure CC=gcc -D_FORTIFY_SOURCE=0 --build=x86_64-apple-darwin11.4.2

--prefix=/Applications/madsdk --with-gmp=/Applications/madsdk

--with-mpfr=/Applications/madsdk --with-mpc=/Applications/madsdk

--enable-languages=c,c++,fortran --disable-multilib



This is running on OS X Lion (10.7.5).

[Bug libgcc/56656] Suffix or operands invalid for 'movq'

[townsend at astro dot wisc.edu]

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



--- Comment #2 from Rich Townsend townsend at astro dot wisc.edu 2013-03-20 
02:11:30 UTC ---

(In reply to comment #1)

 Can you try to compile it out of the src directory in another directory?  I

 think that is what is causing it.



Could you clarify what you mean -- are you saying, for instance, make a

separate directory gcc.build, and from within that directory run 'make -C

../gcc'?

[Bug libgcc/56656] Suffix or operands invalid for 'movq'

[townsend at astro dot wisc.edu]

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



--- Comment #4 from Rich Townsend townsend at astro dot wisc.edu 2013-03-20 
04:20:56 UTC ---

(In reply to comment #3)

 svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch gcc-src

 mkdir gcc-objdir

 cd gcc-objdir

 ../gcc-src/configure 

 make



No change



 

 

 If that does not work then can you try adding the following to configure

 command line:

 --host=x86_64-apple-darwin11.4.2 --target=x86_64-apple-darwin11.4.2

 



No change



 

  --disable-multilib

 

 Also why do you do that?



I forget ;)

[Bug fortran/56218] New: Segfault with allocatable intent(out) derived type argument having allocatable component

[townsend at astro dot wisc.edu]

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



 Bug #: 56218

   Summary: Segfault with allocatable intent(out) derived type

argument having allocatable component

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: towns...@astro.wisc.edu





When using a subroutine with an allocatable intent(out) argument which is a

derived type, and this derived type itself contains an allocatable argument, a

segfault occurs on subroutine entry. The segfault disappears if the argument is

declared intent(inout).



Example code (compiled with gfortran 4.8.0 20121215 on OS X 10.7.5):



--

program test_poly



  implicit none



  type :: foo_t

 real, allocatable :: a(:)

  end type foo_t



  class(foo_t), allocatable :: f



  call do_stuff(f)



contains



  subroutine do_stuff (f)



class(foo_t), intent(out), allocatable :: f



allocate(f)



allocate(f%a(3))



f%a = [1.,2.,3.]



  end subroutine do_stuff



end program test_poly

--



Output from gdb:



--

(gdb) run

Starting program: /Users/townsend/test_poly 

Reading symbols for shared libraries  done



Program received signal EXC_BAD_ACCESS, Could not access memory.

Reason: KERN_INVALID_ADDRESS at address: 0x

0x000115dd in do_stuff (f=Invalid F77 type code 3 in symbol table.

) at test_poly.f90:15

15  subroutine do_stuff (f)

(gdb) 

--

[Bug other/55387] New: Build problem: malloc error in genautomata

[townsend at astro dot wisc.edu]

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



 Bug #: 55387

   Summary: Build problem: malloc error in genautomata

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: other

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: towns...@astro.wisc.edu





When attempting to build the latest SVN gcc (4.8.0, rev. 193610), I get the

following error:



build/genautomata ../.././gcc/config/i386/i386.md \

  insn-conditions.md  tmp-automata.c

genautomata(1500) malloc: *** error for object 0xc1e8b60252d64: pointer being

freed was not allocated

*** set a breakpoint in malloc_error_break to debug

/bin/sh: line 1:  1500 Abort trap: 6   build/genautomata

../.././gcc/config/i386/i386.md insn-conditions.md  tmp-automata.c

make[3]: *** [s-automata] Error 134

make[2]: *** [all-stage1-gcc] Error 2

make[1]: *** [stage1-bubble] Error 2

make: *** [all] Error 2



This is on OS X 10.7.5, with the following config options:



./configure CC=gcc -D_FORTIFY_SOURCE=0 \

  --build=x86_64-apple-darwin11.4.2 \

  --prefix=/Applications/madsdk \

  --with-gmp=/Applications/madsdk \

  --with-mpfr=/Applications/madsdk \

  --with-mpc=/Applications/madsdk \

  --enable-languages=c,c++,fortran --disable-multilib

[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function

[townsend at astro dot wisc.edu]

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



--- Comment #9 from Rich Townsend townsend at astro dot wisc.edu 2012-11-04 
18:01:53 UTC ---

(In reply to comment #8)

 Fixed with r193136. Closing.

 

 Thanks for reporting this!



Hey, thanks for fixing it so quickly -- you never cease to amaze me!

[Bug fortran/55199] New: Equivalenced variable has wrong type when used with generic member function

[townsend at astro dot wisc.edu]

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



 Bug #: 55199

   Summary: Equivalenced variable has wrong type when used with

generic member function

Classification: Unclassified

   Product: gcc

   Version: 4.7.3

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: fortran

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: towns...@astro.wisc.edu





Created attachment 28606

  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28606

Test program to reproduce the error



The attached program fails to compile, with the following error:



assoc_err.f90:49.8:



a = a + b

1

Error: Operands of binary numeric operator '+' at (1) are REAL(4)/TYPE(foo_t)



However, the equivalence statement has b = f%func(1.), which has a type of

REAL(4) and not TYPE(foo_t).



The problem goes away if I replace the generic function reference with a

specific one: b = f%func_1(1.)

[Bug fortran/53945] New: Scalar element of assumed-shape dummy array not recognized as C interoperable

[townsend at astro dot wisc.edu]

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

 Bug #: 53945
   Summary: Scalar element of assumed-shape dummy array not
recognized as C interoperable
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: towns...@astro.wisc.edu


(Reposting from an initial question in comp.lang.fortran):

I'm having trouble getting the following to compile with gfortran 4.7.2:

--SNIP--
program foo

  USE ISO_C_BINDING

  implicit none

contains

  subroutine bar (a)

real, intent(in), target :: a(:,:)

type(C_PTR) :: a_ptr

a_ptr = C_LOC(a(1,1))

  end subroutine bar

end program foo
--SNIP--

The error message is:

Error: Assumed-shape array 'a' at (1) cannot be an argument to the
procedure 'c_loc' because it is not C interoperable

This isn't right; although the array 'a' is not
interoperable because it is assumed-shape (but not allocatable), the
*element* a(1,1) is a scalar and thus should be interoperable.

Looks like the same problem as 50269, in a slightly different context.

[Bug fortran/53544] New: Derived-type components in namelist group declaration produces error

[townsend at astro dot wisc.edu]

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

 Bug #: 53544
   Summary: Derived-type components in namelist group declaration
produces error
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: towns...@astro.wisc.edu


Created attachment 27533
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27533
Example program illustrating namelist problem

In the attached example program, the use of derived-type components in the
namelist group declaration causes the following errors:

foo.f90:12.19:

  namelist /bar/ ct%a, ct%b
   1
Error: Syntax error in NAMELIST statement at (1)
foo.f90:14.17:

  read(*, NML=bar)
 1
Error: Symbol 'bar' at (1) must be a NAMELIST group name

It is my understanding that the variables in a namelist group declaration must
not be a dummy array with non-constant bound, a variable with non-constant
character length, an automatic object, an allocatable array, a pointer, or have
a component at any depth that is a pointer or is inaccessible. The case in the
example program falls into none of these categories, and therefore should be
accepted by the compiler as valid code.

[Bug fortran/53309] New: Unnecessary temporary array creation in subroutine call

[townsend at astro dot wisc.edu]

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

 Bug #: 53309
   Summary: Unnecessary temporary array creation in subroutine
call
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: towns...@astro.wisc.edu


Created attachment 27367
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27367
Example program

I'm encountering a situation where an unnecessary array is being created when
passing an assumed-shape dummy argument as the argument to a routine without an
explicit interface.

The attached example program illustrates the problem; when compiled with
-Warray-temporaries, I get the warning:

test_array_temp.f90:19.25:

call sub_set_a(3, 3, a)
 1
Warning: Creating array temporary at (1)

At compile time, there is no way of determining whether a is contiguous, and so
it would seem an array temporary is necessary. However, is it possible to do a
*runtime* check on whether a is contiguous, and if so avoid the copy? Intel
Fortran seems to manage this.

BTW, this issue arises when calling many of the LAPACK and BLAS routines from
Fortran 9x; it seems array temporaries are being created all over the place,
doubtless with a performance impact.

[Bug fortran/52153] New: REAL128 gives extended precision, not quad precision

[townsend at astro dot wisc.edu]

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

 Bug #: 52153
   Summary: REAL128 gives extended precision, not quad precision
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: towns...@astro.wisc.edu


The REAL128 parameter defined in ISO_FORTRAN_ENV has the value 10, which
corresponds to extended precision. Should it not have a value 16, corresponding
to quad precision? 

As things currently stand, to obtain quad precision reals, I have to use
REAL(16) or REAL*16, which is non-portable; I'd rather use REAL(REAL128).

[Bug fortran/48351] [OOP] Realloc on assignment fails if parent component is CLASS

[townsend at astro dot wisc.edu]

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

Rich Townsend townsend at astro dot wisc.edu changed:

   What|Removed |Added

 CC||townsend at astro dot
   ||wisc.edu

--- Comment #3 from Rich Townsend townsend at astro dot wisc.edu 2011-07-07 
02:34:41 UTC ---
(In reply to comment #0)
 http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b7a36eba5ef7f68b
  by Nasser M. Abbasi
 
 In the following program %u is allocatable. For
 
 this%u = u
 
 the LHS should be allocated, but this only happens if this is a TYPE and not
 a CLASS - but that should be completely unrelated to (re)alloc on assignment.
 
 The program works with ifort 11.1.
 
 
 module foo
 implicit none
 type :: foo_t
 !  private
   DOUBLE PRECISION , ALLOCATABLE :: u(:)
   contains
 PROCEDURE :: make  ! or procedure, pass, same effect
 end type foo_t
 
 contains
 subroutine make(this,u)
 implicit none
 CLASS(foo_t) :: this
 DOUBLE PRECISION, intent(in) :: u(:)  ! must be CLASS
 !   allocate(this%u(size(u)))  ! Must allocate now, else crash
 this%u = u
 end subroutine make
 end module foo
 
 program main2
  use foo
  implicit none
  TYPE(foo_t) :: o
  DOUBLE PRECISION , ALLOCATABLE :: u(:)
 
  u=[1,2,3,4]
  CALL o%make(u)
  print *, o%u
 end program main2

I've run into what appears to be this bug with 4.7 (Mac OS 10.6). My sample
code is as follows:

module realloc_lhs_m

  implicit none

  type mytype
 real, allocatable :: a(:)
   contains
 procedure :: set_a
  end type mytype

contains

  subroutine set_a (this, a)
class(mytype), intent(out) :: this
real, intent(in)   :: a(:)
this%a = a
  end subroutine set_a

end module realloc_lhs_m

program realloc_lhs

  use realloc_lhs_m
  implicit none

  real, allocatable :: a(:)
  type(mytype)  :: m

  a = [1.,2.,3.,4.,5.]

  call m%set_a(a)
  print *, m%a

end program realloc_lhs

This can be easily worked around -- but of course should nevertheless be fixed.

cheers,

Rich

[Bug fortran/49466] Memory leak with assignment of extended derived types

[townsend at astro dot wisc.edu]

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

--- Comment #2 from Rich Townsend townsend at astro dot wisc.edu 2011-06-19 
15:39:28 UTC ---
(In reply to comment #1)
 (In reply to comment #0)
  In the attached sample code, which is a reduced test case from the full 
  code,
  the assignment as_b = as_a leaks memory from the U(:) allocatable 
  component
  (which is defined in state_t, the parent type), but not from the W(:)
  allocatable component (which is defined in astate_t).
 
 Sorry, I'm not able to reproduce the memory leak with gfortran version 4.5 and
 valgrind. Could you please tell me which gfortran version you use and how you
 detect the memory leak?

This is 4.7.0 (svn) running on OS X 10.6.7. valgrind output:


==32629== Memcheck, a memory error detector
==32629== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==32629== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==32629== Command: ./evolve_aflow
==32629== 
--32629-- ./evolve_aflow:
--32629-- dSYM directory is missing; consider using --dsymutil=yes
==32629== 
==32629== HEAP SUMMARY:
==32629== in use at exit: 4,004,088 bytes in 1,002 blocks
==32629==   total heap usage: 2,019 allocs, 1,017 frees, 8,012,001 bytes
allocated
==32629== 
==32629== 3,996,000 bytes in 999 blocks are definitely lost in loss record 4 of
4
==32629==at 0x10001079F: malloc (vg_replace_malloc.c:236)
==32629==by 0x10C27: MAIN__ (in ./evolve_aflow)
==32629==by 0x10DA2: main (in ./evolve_aflow)
==32629== 
==32629== LEAK SUMMARY:
==32629==definitely lost: 3,996,000 bytes in 999 blocks
==32629==indirectly lost: 0 bytes in 0 blocks
==32629==  possibly lost: 0 bytes in 0 blocks
==32629==still reachable: 8,088 bytes in 3 blocks
==32629== suppressed: 0 bytes in 0 blocks
==32629== Reachable blocks (those to which a pointer was found) are not shown.
==32629== To see them, rerun with: --leak-check=full --show-reachable=yes
==32629== 
==32629== For counts of detected and suppressed errors, rerun with: -v
==32629== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types

[townsend at astro dot wisc.edu]

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

--- Comment #6 from Rich Townsend townsend at astro dot wisc.edu 2011-06-19 
18:57:40 UTC ---
(In reply to comment #5)
  In the first assignment b.U is allocated, in the second assignment it is not
  freed, before being allocated again.
 
 I don't think it should be freed then allocated for the second assignment in
 the code in comment#4.

Certainly, given that the lhs array component is the same shape as the rhs
array component, an optimization would be not to free and then allocate the
array prior to the copy.

However, that doesn't alter the fact that the behavior should be *as if* the
lhs array component were freed and then allocated with the appropriate shape.
This behavior has been in Fortran since TR 15581, which first introduced 
allocatable derived-type components as an extension to Fortran 95.

[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found

[townsend at astro dot wisc.edu]

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

--- Comment #34 from Rich Townsend townsend at astro dot wisc.edu 2011-06-19 
21:18:47 UTC ---
Thanks, Janus -- you rock!

On Jun 19, 2011, at 4:16 PM, janus at gcc dot gnu.org wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601
 
 --- Comment #33 from janus at gcc dot gnu.org 2011-06-19 21:16:06 UTC ---
 Ok, the backport has landed on the 4.6 branch and should be just in time for
 the 4.6.1 release.
 
 -- 
 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
 --- You are receiving this mail because: ---
 You reported the bug.