--
Summary: DATE_AND_TIME returns GMT hour sometimes with OpenMP
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
R
--
Summary: DATE_AND_TIME returns GMT hour sometimes with OpenMP
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
R
MP private variable referenced in a statement
function
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
Reporte
.f90
--
Summary: !$omp collapse(m) with non-constant m should give error
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot
--- Comment #2 from longb at cray dot com 2009-07-28 13:47 ---
The text at [75:19-20] of the OpenMP 2.5 standard, May 2008, says:
"Variables that appear in namelist statements, in variable format expressions,
and in Fortran expressions for statement function definitions, may not a
ot; POINTS AT END-
OF-LINE RATHER THAN AT Q.
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb a
RMA/BASEATTRWINF90.F90
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build triplet: x86_64-sus
--- Comment #2 from longb at cray dot com 2007-09-08 01:03 ---
Subject: Re: GFORTRAN OPTIMIZATION ERROR ABOVE -O0 FOR
MPICH2 TEST F90_RMA/BASEATTRWINF90.F90
kargl at gcc dot gnu dot org wrote:
> --- Comment #1 from kargl at gcc dot gnu dot org 2007-09-07 21:03 ---
&g
--- Comment #4 from longb at cray dot com 2007-09-10 16:03 ---
Subject: Re: GFORTRAN OPTIMIZATION ERROR ABOVE -O0 FOR
MPICH2 TEST F90_RMA/BASEATTRWINF90.F90
sgk at troutmask dot apl dot washington dot edu wrote:
> --- Comment #3 from sgk at troutmask dot apl dot washington
2
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build triplet: x86_64-suse-linux
GCC
--- Comment #6 from longb at cray dot com 2007-09-12 21:05 ---
Subject: Re: GFORTRAN OPTIMIZATION ERROR ABOVE -O0 FOR
MPICH2 TEST F90_RMA/BASEATTRWINF90.F90
sgk at troutmask dot apl dot washington dot edu wrote:
> --- Comment #5 from sgk at troutmask dot apl dot washington
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33439
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-li
--- Comment #2 from longb at cray dot com 2007-10-03 19:44 ---
Subject: Re: _gfortran_copy_string missing in libgfortran.a
I suspected this might be the case, but did not find it documented.
Thanks for the quick reply.
Cheers,
Bill
pinskia at gcc dot gnu dot org wrote
: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
We have a customer who complained that the Fortran 2018 feature for
allowing w=0 in E-like format descriptors is not working with
gfortran version 9.2. I pointed them to the table at
https://gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94411
--- Comment #2 from Bill Long ---
Thanks for the quick reply. Is there a predicted release date for 10.1?
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
> cat main.c
#include
#include
#include "ISO_Fortran_binding.h"
int main (int argc, char *argv[]) {
int
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
> cat test.f90
subroutine my_random_seed_v (size, put, get)
integer, optional :: size
integer, optional :: put(1)
inte
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
Original test case from user:
> cat test.f90
real(4) function x (a)
real(kind(x)) a(:)
interface if1
subroutine sub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038
--- Comment #1 from Bill Long ---
Note that for the greatly simplified test case
> cat test3.f90
real(4) function x (a)
real(kind(x)) a(:)
print *, kind(x)
end function x
gfortran compiles with no error. So maybe th
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
> cat test.f90
program test
wait (10, iostat=ios)
print *, ios
close (10)
end program test
> gfortran test.f90
> ./a.out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
--- Comment #1 from Bill Long ---
The program appears to be legal and should execute and print 0.
The last paragraph of 12.7.2 WAIT statement (current Fortran standard) is
Execution of a WAIT statement specifying a unit that does not exist,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
--- Comment #3 from Bill Long ---
A comment from the original user: gfortran 8.3.0 appears to do the right
thing. So perhaps a regression somewhere in the 9.x line?
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
> cat test3.f90
program test
integer,external :: omp_get_num_threads
character(len=16) my_status
open (unit=10, file='
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
--- Comment #1 from Bill Long ---
Appears to be a regression.
The original submitter thinks it is hanging in __lll_lock_wait inside CLOSE.
Th same hang can be observed if the references to omp_get_num_threads are
removed, but you still compi
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
> cat test.f90
program test
real a(1)
integer my_id
integer bad_id
data my_id
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
gfortran poorly handles a program error of writing a namelist to an unformatted
file.
> cat test.f90
prog
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
> cat test.f90
program test
use,intrinsic :: ieee_arithmetic
print *, " selected_real_kind(16) = ", selected_real_kind(16)
print *, "ieee_sel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #1 from Bill Long ---
The main problem here is that selected_real_kind and ieee_selected_real_kind
have different specifications. The ieee_selected_real_kind requires a KIND
value corresponding to an IEEE floating format, whereas sele
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #5 from Bill Long ---
The same user also submitted a bug about IEEE_FMA not being supported. Is
there already a bug/rfe for that in the gcc bugzilla?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #6 from Bill Long ---
(In reply to kargl from comment #3)
> (In reply to Bill Long from comment #0)
> > > cat test.f90
>
> > Gfortran:
> >
> > > module swap PrgEnv-intel PrgEnv-gnu
> > > gfortran test.f90
> > > ./a.out
> > se
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
> cat test2.f90
program test
use, intrinsic :: ieee_arithmetic, only : ieee_fma
implicit none
end program test
Intel:
> ifort test2.f90
Cray:
> mo
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
> cat test.f90
program test
use, intrinsic :: ieee_arithmetic, only : &
&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #11 from Bill Long ---
I checked with the Intel docs and the ia64 version of the compiler (what HPC
users use) does not support x87.
Is there a gfortran compiler option to disable x87 use (i.e. REAL(10) is an
error), to match the ot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248
--- Comment #5 from Bill Long ---
Any progress on this?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54247
Bug #: 54247
Summary: OpenMP code fails at execution in AMD Interlagos
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54247
Bill Long changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
--- Comment #9 from longb at cray dot com 2009-09-21 21:31 ---
The OpenMP spec does require (requirement is on the user):
"chunk_size must be a loop invariant integer expression with a positive value",
so detection of a chunk size of -7 at run time would be a user-friendly t
--- Comment #5 from longb at cray dot com 2009-11-13 22:19 ---
I tried 4.4.2 and do not any longer see the segfault on the Cray XT system. I
suspect this was fixed by addressing the problem noted in Comment #3.
The original problem of not issuing the error message at compile time
uct: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42041
: 4.4.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target
--- Comment #2 from longb at cray dot com 2009-11-16 16:58 ---
I posed this question to the Cray OpenMP committee member:
Jim @ ISU submitted a bug against gfortran noting that some parameters
defined in the omp_lib Fortran module are missing from the corresponding
omp_lib.h include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876
--- Comment #8 from Bill Long 2010-12-27 01:42:20 UTC
---
I am out of the office until Monday, January 3, 2011. Send technical questions
to spsl...@cray.com.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47886
Summary: ICE: OpenMP !$omp task if(omp_get_num_threads() > 0)
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assigne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201
Bug #: 50201
Summary: gfortran with -static causes seg fault at runtime for
writing double prec array with precision increased to
kind=16
Classification: Unclassified
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201
--- Comment #2 from Bill Long 2011-08-26 21:00:04 UTC
---
OS is Linux SLES 11.
>From the output in the test, it looks like you tried only the scalar case,
which I agree works. The array case (second test code) is the one the fails.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50570
Bug #: 50570
Summary: Incorrect error for assignment to intent(in) pointer
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50692
Bug #: 50692
Summary: option -finstrument-functions causes ICE
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52075
Bug #: 52075
Summary: OpenMP atomic update failing if -fbounds-check
specified
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52403
Bug #: 52403
Summary: coarray component gives error with CLASS( )
declaration
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501
--- Comment #14 from Bill Long ---
Just a note that I'm now using
$ gf --version
GNU Fortran (MacPorts gcc49 4.9-20130609_0) 4.9.0 20130609 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.
and the original test case works with th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51591
Bug #: 51591
Summary: Strange output from STOP statement in OpenMP region
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51815
Bug #: 51815
Summary: confusing substring syntax with array section for
character coarray
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51815
--- Comment #1 from Bill Long 2012-01-10 19:34:58 UTC
---
The "(coindexed )" bit at the end of the last line of the
Description does not apply here. It's just a here as the
.
(1) ISN'T SAVED"
INCORRECT IN MAIN PGM
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
Reported
igned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32360
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32361
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
APPEARS IN
COPYIN CLAUSE
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build triplet: x86_64-suse-linux
GCC host triplet:
--- Comment #7 from longb at cray dot com 2007-06-26 18:20 ---
Subject: Re: structure containing allocatable array is
accepted in COPYIN clause
burnus at gcc dot gnu dot org wrote:
> --- Comment #4 from burnus at gcc dot gnu dot org 2007-06-22 21:06
> ---
> Thank
THAT
IS SERIALIZED
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build
Summary: THE COPYPRIVATE CLAUSE FAILS TO COPY THE PTR AT THE END
OF A 'SINGLE' CONSTRUCT
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unass
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
> cat modu6.f90
module test_module
implicit none
public :: func_1
integer :: string_length = 3
character(len=*),parameter :: fixed_string = &
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248
--- Comment #1 from Bill Long ---
Possibly related to 44265.
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
> cat test.f90
subroutine sub (a1, i1, f1, i2, i3, i4, out)
implicit none
character(30),intent(in) :: a1
integer,intent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948
--- Comment #1 from Bill Long ---
The same code compiles and executes OK at 20 threads with other compilers. The
size of the internal file is small (700 bytes).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948
--- Comment #3 from Bill Long ---
What happens with 16 threads?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948
--- Comment #5 from Bill Long ---
I tried on my Mac laptop (gcc version 6.3.0) and it also works there. Evidently
not a representative test. The differences I see between that environment and
the original customer's is that they are running 7.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83948
--- Comment #7 from Bill Long ---
Thanks - very helpful information. I'll try to find out what version of gcc
was used to build their library.
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
Simple test case from site:
> cat test.f90
program test
implicit none
integer :: i
do i= 1,1
call backtrace()
enddo
end program test
Tracing memory usage with gfortran 4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501
Bug #: 55501
Summary: ICE using MERGE in constant expr
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501
--- Comment #1 from Bill Long 2012-11-28 00:37:14 UTC
---
Plain integers in MERGE seem to be OK, so the problem appears to be with using
constants of derived type as arguments to MERGE here.
nent: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
Created attachment 39767
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39767&action=edit
Source files module.F90 and pushe.f90 (in bug.tar)
As a basic sanity ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77897
--- Comment #1 from Bill Long ---
Compiling these files appears to have a problem when the target is set to Intel
KNL. The compiler appears to be generating incorrect register and instruction
names, leading to assembler messages. See with gfort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77897
--- Comment #3 from Bill Long ---
It would appear the customer system has
> /usr/bin/as --version
GNU assembler (GNU Binutils; SUSE Linux Enterprise 12) 2.25.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77897
--- Comment #4 from Bill Long ---
Confirmation from the customer system:
GNU assembler (GNU Binutils; SUSE Linux Enterprise 12) 2.25.0
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under
---
> integer :: i, row
--
Summary: ICE: in lookup_decl_in_outer_ctx, at omp-low.c:2103
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassign
rce if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE: in single_pred_edge, at basic-block.h:658
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
As
expected -1 )
--
Summary: Incorrect output for pgm checking data sharing
attributes
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedT
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_
e.f90
> ./a.out
Beginning of string improperly continued
>
At this point, I gave up on trying to reduce the original test case that caused
the ICE.
--
Summary: ICE on improperly continued character constant
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
--- Comment #2 from longb at cray dot com 2010-04-09 22:20 ---
OK, no need to worry about the simple.f90 case. The original test.f90 problem
is the only issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43712
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
> cat test.f90
subroutine foo(nnn, aaa, bbb, ccc)
implicit none
integer :: nnn, aaa, bbb(nnn)
integer :: i
do i=1,nnn
aaa = aaa + bbb(ccc(i))
end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64925
--- Comment #2 from Bill Long ---
The error message in Comment 1 provides correct information, and the
compilation does not cause an ICE, so this is a definite improvement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52075
--- Comment #4 from Bill Long ---
With this version:
> gfortran --version
GNU Fortran (GCC) 4.9.1 20140716 (Cray Inc.)
Copyright (C) 2014 Free Software Foundation, Inc.
I see the following:
> gfortran -fopenmp -fbounds-check test.f90
> ./a.ou
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Created attachment 33056
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33056&action=edit
test3.f90
Bad result:
> gfortran -march=corei7-avx -O3
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
> cat test.f90
program test
use,intrinsic :: iso_c_binding
real,target :: x(1000)
real,pointer :: p (:)
type(c_ptr) :: cp
p =>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68927
--- Comment #1 from Bill Long ---
The DEALLOCATE statement in subroutine SUB is attempting to deallocate
a static array with the SAVE attribute. The standard requires that a
non-zero status be returned in cases like this, and execution continues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68927
--- Comment #3 from Bill Long ---
Possibly related to pr59796, bun not a duplicate. In this example, the pointer
being deallocated is associated. The problem is that it is associated with a
target that cannot be deallocated. The standard says t
enMP threadprivate allocatable saved variable -> seg
fault
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
list item must not be deallocated and/or allocated
within the region."
--
Summary: ICE for REDUCTION with ALLOCATABLE array as variable on
SECTIONS
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Pri
tting
value
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build triplet:
--- Comment #3 from longb at cray dot com 2010-02-05 23:49 ---
This bug was filed because it appeared that the test worked with the Cray, PGI,
and Intel compilers. However, based on the notes in Comments 1 and 2, more
tests were written which uncovered that the Cray compiler seems to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48117
Summary: ICE: OpenMP; in build_int_cst_wide, at tree.c:1178
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48174
Summary: DWARF for subroutine with no args indicates 'varargs'
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48174
--- Comment #4 from Bill Long 2011-03-18 16:08:37 UTC
---
Additional comment from originator of the bug at Cray:
The DIE tag DW_TAG_unspecified_parameters indicates that a variable argument
list starts. Try a simple C program for contrast. Just
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858
--- Comment #1 from Bill Long 2011-05-03 21:51:29 UTC
---
As an aside, the code in the Description is a "work-around" to avoid using the
TR 29113 feature that allows Optional arguments. This would be the preferred
code in the future:
> cat ckne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858
Summary: Incorrect error for same binding label on two generic
interface specifics
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858
--- Comment #3 from Bill Long 2011-05-04 22:40:31 UTC
---
On 5/4/11 3:28 AM, burnus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858
>
> (In reply to comment #1)
> [BIND(C) with OPTIONAL arguments]
>> The Intel and P
1 - 100 of 151 matches
Mail list logo
