[Bug fortran/61615] Failure to resolve correct generic with TYPE(C_PTR) arguments

[thatcadguy at gmail dot com]

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

--- Comment #1 from Jacob Abel  ---
I was also told the following incorrect behavior is present from 4.8.1 and on.
I've tested with 4.8.1 and 4.8.2 and received the same behavior.

[Bug fortran/61615] New: Failure to resolve correct generic with TYPE(C_PTR) arguments

[thatcadguy at gmail dot com]

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

Bug ID: 61615
   Summary: Failure to resolve correct generic with TYPE(C_PTR)
arguments
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thatcadguy at gmail dot com

The following program does not produce the expected output (the line 'CALL
bar(a, b)' does not choose the subroutine bar_s as it should, it chooses
bar_a1d):

MODULE foo
  USE iso_c_binding
  IMPLICIT NONE
  INTERFACE bar
MODULE PROCEDURE bar_s
MODULE PROCEDURE bar_a1d
  END INTERFACE bar
CONTAINS
  SUBROUTINE bar_s(a, b)
TYPE(c_ptr) :: a, b
WRITE (0, *) 'in bar_s'
  END SUBROUTINE bar_s

  SUBROUTINE bar_a1d(a, b)
TYPE(c_ptr) :: a(:), b(:)
WRITE (0, *) 'in bar_a1d'
  END SUBROUTINE bar_a1d
END MODULE foo

PROGRAM cptr_array_vs_scalar_arg
  USE foo
  USE iso_c_binding
  IMPLICIT NONE
  INTEGER, TARGET :: i
  TYPE(c_ptr) :: a, b
  a = C_LOC(i)
  b = C_LOC(i)
  CALL bar(a, b)
END PROGRAM cptr_array_vs_scalar_arg

[Bug fortran/61429] New: SYSTEM_CLOCK used with non-default integer kind does not produce warning

[thatcadguy at gmail dot com]

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

Bug ID: 61429
   Summary: SYSTEM_CLOCK used with non-default integer kind does
not produce warning
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thatcadguy at gmail dot com

Compiling:

program main
implicit none
integer(kind=8) :: i
call system_clock(i)
end program main

with gfortran -std=f95 -pedantic -Wall -Wextra produces no warning. According
to the F95 standard (13.14.106), "COUNT (optional) shall be scalar and of type
default integer" (it's the same for COUNT_RATE and COUNT_MAX). It's not until
F2003 (13.7.117) that the wording is changed to "COUNT (optional) shall be
scalar and of type integer."

Summary: using any other kind but default integer with system_clock should not
be allowed or give a warning under -std=f95, but should be allowed for
-std=f2003 and later.

[Bug fortran/61261] [OOP] Segfault on source-allocating polymorphic variables

[thatcadguy at gmail dot com]

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

--- Comment #5 from Jacob Abel  ---
(In reply to Dominique d'Humieres from comment #4)
> Slightly reduced test
> 
> MODULE modu
> 
> IMPLICIT NONE
> 
> TYPE element
>  CLASS(*), ALLOCATABLE :: e
> END TYPE element
> 
> END MODULE modu
> 
> PROGRAM x
> 
> USE modu
> IMPLICIT NONE
> 
> CHARACTER(LEN=80), TARGET :: c80
> CLASS(*), POINTER :: p
> TYPE(element) :: el
> 
> c80 = 'the quick brown fox jumps over the lazy dog'
> p => c80
>   ALLOCATE(el%e, SOURCE = p)
> 
> END PROGRAM x
> 
> Could be related to pr51864(?).

Even further works too:

PROGRAM x

IMPLICIT NONE

CLASS(*), ALLOCATABLE :: e
CHARACTER(LEN=80), TARGET :: c80
CLASS(*), POINTER :: p

c80 = 'the quick brown fox jumps over the lazy dog'
p => c80
ALLOCATE(e, SOURCE = p)

END PROGRAM x

[Bug fortran/61261] [OOP] Segfault on source-allocating polymorphic variables

[thatcadguy at gmail dot com]

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

--- Comment #3 from Jacob Abel  ---
Created attachment 32838
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32838&action=edit
gfortran -v

[Bug fortran/61261] [OOP] Segfault on source-allocating polymorphic variables

[thatcadguy at gmail dot com]

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

--- Comment #2 from Jacob Abel  ---
Created attachment 32837
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32837&action=edit
valgrind output

[Bug fortran/61261] [OOP] Segfault on source-allocating polymorphic variables

[thatcadguy at gmail dot com]

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

--- Comment #1 from Jacob Abel  ---
Created attachment 32836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32836&action=edit
gdb output

[Bug fortran/61261] New: [OOP] Segfault on source-allocating polymorphic variables

[thatcadguy at gmail dot com]

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

Bug ID: 61261
   Summary: [OOP] Segfault on source-allocating polymorphic
variables
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thatcadguy at gmail dot com

Created attachment 32835
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32835&action=edit
Test source file

The attached code produces a segfault on Ubuntu 14.04 with gfortran 4.8.2. I
think this may be related to an existing bug, but not sure.

MODULE modu

IMPLICIT NONE

TYPE element
 CLASS(*), ALLOCATABLE :: e
END TYPE element

CONTAINS
 SUBROUTINE sub(el, p)
  TYPE(element), INTENT(INOUT)  :: el
  CLASS(*), POINTER, INTENT(IN) :: p
  ALLOCATE(el%e, SOURCE = p)
 END SUBROUTINE sub
END MODULE modu

PROGRAM x

USE modu
IMPLICIT NONE

CHARACTER(LEN=80), TARGET :: c80
CLASS(*), POINTER :: p
TYPE(element) :: el

c80 = 'the quick brown fox jumps over the lazy dog'
p => c80
CALL  sub(el, p)

END PROGRAM x

[Bug target/60088] Segfault when using quad precision and -march=native on gfortran

[thatcadguy at gmail dot com]

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

--- Comment #23 from Jacob Abel  ---
If it helps at all, the following produces the same problem under gcc:

#include 
#include 

int main(void)
{
__float128 *ptr = NULL;
int i;
if (ptr = malloc(100 * sizeof(__float128)))
for (i = 0; i < 100; i++)
ptr[i] = 0;
return 0;
}

segfault with -march=native, fine without.

[Bug target/60088] Segfault when using quad precision and -march=native on gfortran

[thatcadguy at gmail dot com]

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

--- Comment #19 from Jacob Abel  ---
jake@Jake-E1505:~/Desktop$ gfortran -static -march=native
-Wl,-uquadmath_snprintf newtest.f90 -o newtest
jake@Jake-E1505:~/Desktop$ gdb newtest
GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
Copyright (C) 2013 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 "i686-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/jake/Desktop/newtest...(no debugging symbols
found)...done.
(gdb) break *0x80493a5
Breakpoint 1 at 0x80493a5
(gdb) run
Starting program: /home/jake/Desktop/newtest 

Breakpoint 1, 0x080493a5 in test_ ()
(gdb) info registers
eax0x81325c8135472584
ecx0x812c780135448448
edx0x81325c8135472584
ebx0x80481d8134513112
esp0xb2e00xb2e0
ebp0xb3080xb308
esi0x00
edi0x812c00c135446540
eip0x80493a50x80493a5 
eflags 0x286[ PF SF IF ]
cs 0x73115
ss 0x7b123
ds 0x7b123
es 0x7b123
fs 0x00
gs 0x3351
(gdb)

[Bug target/60088] Segfault when using quad precision and -march=native on gfortran

[thatcadguy at gmail dot com]

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

--- Comment #16 from Jacob Abel  ---
Still segfaults, at least on MinGW:

C:\Users\Jake\Downloads>gfortran -march=native -Wl,-uquadmath_snprintf
newtest.f
90

C:\Users\Jake\Downloads>a

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

Backtrace for this error:
#0  6f610f4e
#1  6f6913eb
#2  004010f8

C:\Users\Jake\Downloads>

[Bug target/60088] Segfault when using quad precision and -march=native on gfortran

[thatcadguy at gmail dot com]

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

--- Comment #13 from Jacob Abel  ---
The following file:

SUBROUTINE test(N)
IMPLICIT NONE
INTEGER, INTENT(IN) :: N
REAL(KIND=16) :: array(N)
array = 0
END SUBROUTINE test

PROGRAM main
IMPLICIT NONE
CALL test(10)
END PROGRAM main

Creates the same problem. Segfault occurs on 'array = 0'. Will provide more
info when I get home.

[Bug target/60088] Segfault when using quad precision and -march=native on gfortran

[thatcadguy at gmail dot com]

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

--- Comment #12 from Jacob Abel  ---
Created attachment 32074
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32074&action=edit
NEW smaller simpler file to create the segfault

[Bug target/60088] Segfault when using quad precision and -march=native on gfortran

[thatcadguy at gmail dot com]

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

--- Comment #11 from Jacob Abel  ---
The culprit that -march=native activates on my Core i7 laptop is -mavx.
Compiling with -mavx causes the segfault, without is fine. Unfortunately, that
flag was not set on my other laptop, so might be multiple issues here.

[Bug target/60088] Segfault when using quad precision and -march=native on gfortran

[thatcadguy at gmail dot com]

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

--- Comment #8 from Jacob Abel  ---
Seriously? Look, you falsely assumed it was mingw only. Jerry reproduced the
problem on linux as well. Excuse me for not knowing to post the backtrace. I
come here to post a legitimate bug and all you've done is been hasty and
unhelpful.

No wonder clang is going to win in the long run. Fucking twat.

[Bug target/60088] Segfault when using quad precision and -march=native on gfortran

[thatcadguy at gmail dot com]

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

--- Comment #6 from Jacob Abel  ---
(In reply to Steve Kargl from comment #5)
> What output file?  gcc_flags.txt does not show a segfault
> or a debugger backtrace.

It shows that I was not using MinGW, as you assumed. Here's the gdb output:

jake@Jake-E1505:~/Downloads$ gdb sip_test
GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
Copyright (C) 2013 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 "i686-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/jake/Downloads/sip_test...done.
(gdb) start
Temporary breakpoint 1 at 0x8048ec0: file sip_test.f90, line 1.
Starting program: /home/jake/Downloads/sip_test 

Temporary breakpoint 1, MAIN__ () at sip_test.f90:1
1PROGRAM main
(gdb) continue
Continuing.


Program received signal SIGSEGV, Segmentation fault.
0x0804a9bb in sip (as=..., aw=..., ao=..., ae=..., an=..., s=..., x=..., n=40, 
k=1600, alp=, tol=, 
lim=200, show=.TRUE., fail=.FALSE.) at sip.f90:19
19b = zero; c = zero; d = zero; e = zero; f = zero
(gdb) 


And the normal output:
jake@Jake-E1505:~/Downloads$ ./sip_test 


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

Backtrace for this error:
#0  0xB76C3CAB
#1  0xB76C42FC
#2  0xB77C33FF
#3  0x804A9BB in sip_ at sip.f90:19 (discriminator 6)
#4  0x804A411 in MAIN__ at sip_test.f90:45
Segmentation fault (core dumped)


As I stated, if you take away the -march=native compile flag, it's fine.

[Bug target/60088] [MingW] Segfault when using quad precision and -march=native on gfortran

[thatcadguy at gmail dot com]

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

--- Comment #3 from Jacob Abel  ---
If you bothered to look at the gcc output file, you'd see that I tested it on
Linux as well. This is a GCC and MinGW problem. The code segfaults on both
platforms with both compilers.

[Bug fortran/60088] New: Segfault when using quad precision and -march=native on gfortran

[thatcadguy at gmail dot com]

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

Bug ID: 60088
   Summary: Segfault when using quad precision and -march=native
on  gfortran
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thatcadguy at gmail dot com

Created attachment 32061
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32061&action=edit
zip file of the code, makefile, and gcc output

I went to test the attached code with quad precision by changing
SELECTED_REAL_KIND to 33 digits in precision.f90; I got a segfault when trying
to run the compiled sip_test executable. Everything runs fine with double
precision (SELECTED_REAL_KIND @ 15 digits).

This same behavior also occurs with MinGW gfortran 4.8.1 on Windows 7 64-bit.

I noticed that if I take away '-march=native' that the segfault goes away. My
laptop at work with MinGW is a Core i7, this laptop with linux is a Core Duo.

I've attached the code and the gcc -v output as well as the -march=native
flags.

[Bug fortran/60088] Segfault when using quad precision and -march=native on gfortran

[thatcadguy at gmail dot com]

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

--- Comment #1 from Jacob Abel  ---
Created attachment 32062
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32062&action=edit
gcc -v output and march=native flags

[Bug fortran/48937] Discrepancy in computation between 32 and 64-bit builds

[thatcadguy at gmail dot com]

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

Jacob Abel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME

--- Comment #4 from Jacob Abel  2011-05-09 
18:20:49 UTC ---
Thank you both. Mingw32 shows the same behavior when I compiled with
"-ffloatstore". Had no idea that 32-bit systems still used separate math
co-processors or that they had 80-bit precision.

[Bug fortran/48937] New: Discrepancy in computation between 32 and 64-bit builds

[thatcadguy at gmail dot com]

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

   Summary: Discrepancy in computation between 32 and 64-bit
builds
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: thatcad...@gmail.com


Created attachment 24214
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24214
zip file of the two source files in question and a makefile

I have created a subroutine to solve pentadiagonal systems of equations
according to H.L. Stone's 1968 paper. I have tested this subroutine on a
homework problem requiring such a system and observed similar results from
gfortran and MATLAB. For thoroughness, I have made a test program that creates
a random matrix to solve. Basically, in solving Ax = B, it creates a random A
and adds a fixed number to the diagonal to ensure the matrix is
well-conditioned. Exact x is hardcoded in the program and B is computed. Then,
A and B are given to the subroutine to find x iteratively and finally it prints
the absolute error between the iteratively solved x and the exact x.

I have compiled these files without error on both 32 and 64-bit versions of
mingw, both running under Windows 7. The 32-bit system is an Intel Atom
processor and the 64-bit system is an Intel CORE i7.

When run on the 32-bit system, the solution converges within 23 iterations
every time and shows an absolute error of zero, as should be expected. When run
on the 64-bit system, it almost never converges and seems to stay at a constant
residual around 1e-11 or will alternate between two or three values. Basically,
the same exact code converges on one system and fails to solve on the other.

These files are very simple in nature and only use simple loops and arithmetic.
About the only thing special that's used is the RANDOM_NUMBER intrinsic.

Note: I obtained these binaries from TDM-GCC. That may be to blame, or perhaps
mingw; anyone with a 64-bit Windows build should be able to quickly confirm
this bug or disprove it.