https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104585
--- Comment #4 from Bill Long ---
Any prediction for this one? (I realize you still have F2018 an F2023 to get
through.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78219
--- Comment #12 from Bill Long ---
Has this been fixed in a more recent version of gfortran?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104585
Bill Long changed:
What|Removed |Added
CC||longb at cray dot com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038
--- Comment #10 from Bill Long ---
The original issue seems fixed in 12.1. However, the wording of the ERROR
message (objecting that something is not a DATA entity when it really is) could
still be improved. Can we either convert this bug to
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
Created attachment 52299
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52299=edit
Source for test case.
For the attached test case source file:
> gfortran -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102370
--- Comment #2 from Bill Long ---
I've sent a question back to the original submitter. On completion, the first
argument to MOVE_ALLOC is unallocated, so it does look suspicious to be
printing a component of an unallocated structure. I'll
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
> cat test.f90
program main
implicit none
integer, parameter :: long = selected_int_kind(18)
integer(long), parameter :: very_large = 128_long
integer, allocatable, dimens
Severity: normal
Priority: P3
Component: demangler
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
> cat test.f90
program main
implicit none
type mytype
real :: val
integer :: idx
type(mytype), allocatable :: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102369
--- Comment #1 from Bill Long ---
I assume the cascade of error messages all originate with the first one. The
combination of VALUE for an array is allowed in F08 and later versions.
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
> cat test.f90
module mymod
contains
pure real function myfunc(x)
integer, value, dimension(:), intent(in) :: x
myfunc = x(1)
end function myfunc
end module mymod
program main
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
> cat test.f90
program main
use,intrinsic :: iso_c_binding
implicit none
character(kind=c_char, len=*), parameter :: ble
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
For this code:
> cat test2.f90
module test_module
use, intrinsic:: iso_fortran_env, only: int32
implicit none
type, abstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954
--- Comment #35 from Bill Long ---
A lot of users have moved to the 10.X series of compilers, and the adventurous
ones to 11.X. Will the fixes also appear in those compilers?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644
--- Comment #7 from Bill Long ---
Inquiry from the original site:
"Does GCC provide a timeline for when they will conform to F2018?"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647
--- Comment #7 from Bill Long ---
For our purposes, 10 will be fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038
--- Comment #9 from Bill Long ---
The original test is not conforming due to the missing IMPORT statement.
However, the error message , which I assume is for the second non-blank line in
the listing, seems odd. The standard says
"If RESULT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038
--- Comment #6 from Bill Long ---
Is there a released version with the fix noted in this bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #20 from Bill Long ---
Original customer is asking about the status of this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272
--- Comment #10 from Bill Long ---
Still fails with 10.2.0. Can you say which release version will include the
fix?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644
--- Comment #5 from Bill Long ---
Original customer is asking again...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647
--- Comment #5 from Bill Long ---
Is this fixed in a release version of GCC?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98699
--- Comment #3 from Bill Long ---
Thanks, Tobias. GCC 11 should be fine. Great to see you back.
mal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
The user's desire is that, for an OpenMP code, if the maximum number
of active levels (OMP_MAX_ACTIVE_LEVELS) has a value greater tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038
--- Comment #5 from Bill Long ---
Original submitter asking for a fixed-in version number.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42478
Bug 42478 depends on bug 40876, which changed state.
Bug 40876 Summary: OpenMP private variable referenced in a statement function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876
Bill Long changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95119
--- Comment #12 from Bill Long ---
Original submitter asking which GCC version(s) have / will have the fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95104
--- Comment #18 from Bill Long ---
Original submitted asking about the GCC version that has / will have the fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038
--- Comment #4 from Bill Long ---
Original submitter is looking for a fix version for this issue. Any
predictions?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95037
--- Comment #4 from Bill Long ---
Original submitter is interested in knowing what GCC version will have this
fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644
--- Comment #4 from Bill Long ---
The customer has nuclear weapons. They do not do "bounty". :) Cray/HPE is
just the messenger. I think they would be happy with a plan for including the
routine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272
--- Comment #5 from Bill Long ---
The original intent of adding the KIND argument was because some
implementations used a 32-bit integer for the result, and it is possible for
the answer to be larger than 2**31-1. Just checking to be sure that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95640
--- Comment #19 from Bill Long ---
On an ia64 Intel target that does not support x87 floating point, it seems that
having IEEE_SUPPORT_DATATYPE (1._10) return .true. is as error. If that is
fixed, will the rest of the issue fall into place?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644
--- Comment #2 from Bill Long ---
Any update on a fix for this? (The original customer is asking.)
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: longb at cray dot com
Target Milestone: ---
Test case:
> cat test.f90
program test
character, allocatable :: a(:)
integer(8) l, i
l = 200_8
allocate (a(l))
do i = 1, l
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
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 : &
&
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
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
> >
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 #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
: 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
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
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
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
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='test.
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?
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,
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=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
: 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
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
: 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
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?
: 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=86248
--- Comment #5 from Bill Long ---
Any progress on this?
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86248
--- Comment #1 from Bill Long ---
Possibly related to 44265.
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=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.
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
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 #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).
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,int
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
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 #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
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=edit
Source files module.F90 and pushe.f90 (in bug.tar)
As a basic sanity check:
&
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
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
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 =>
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 do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64925
--- Comment #2 from Bill Long longb at cray dot com ---
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 longb at cray dot com ---
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
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=33056action=edit
test3.f90
Bad result:
gfortran -march=corei7-avx -O3 test3.f90
./a.out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501
--- Comment #14 from Bill Long longb at cray dot com ---
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55501
--- Comment #1 from Bill Long longb at cray dot com 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.
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54247
Bill Long longb at cray dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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
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=51815
Bug #: 51815
Summary: confusing substring syntax with array section for
character coarray
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51815
--- Comment #1 from Bill Long longb at cray dot com 2012-01-10 19:34:58 UTC
---
The (coindexed parent-string) bit at the end of the last line of the
Description does not apply here. It's just a scalar-variable-name here as the
parent-name.
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=50692
Bug #: 50692
Summary: option -finstrument-functions causes ICE
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
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=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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50201
--- Comment #2 from Bill Long longb at cray dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49693
Bill Long longb at cray dot com changed:
What|Removed |Added
CC||longb at cray dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383
Bill Long longb at cray dot com changed:
What|Removed |Added
CC||longb at cray dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48894
Summary: generic omp_get_ancestor_thread_num(l(i)) produces
incorrect output
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858
--- Comment #3 from Bill Long longb at cray dot com 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858
--- Comment #1 from Bill Long longb at cray dot com 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
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=48174
--- Comment #4 from Bill Long longb at cray dot com 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
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876
--- Comment #8 from Bill Long longb at cray dot com 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.
1 - 100 of 151 matches
Mail list logo
