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
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=45430
--- Comment #1 from longb at cray dot com 2010-08-27 18:31 ---
Comments from original submitter:
A [deleted] user has given me the following code which fails with gcc/4.5.0.
The
code is OK with PGI and CCE. The problem seems to come about from the use of
threadprivate in
--- Comment #2 from longb at cray dot com 2010-08-27 18:36 ---
Created an attachment (id=21579)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21579&action=view)
Test case, including source files and compile script
Attached tar.gz file contains the source files and the comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46752
Summary: OpenMP - Seg fault for unallocated allocatable array
in firstprivate clause
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46753
Summary: ICE: OpenMP - in extract_omp_for_data, at
omp-low.c:335
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46752
--- Comment #3 from Bill Long 2010-12-02 17:22:48 UTC
---
Conflicting commentary from the OpenMP testers and James Beyer of the OpenMP
committee:
This test case is derived from OpenMP test omp3f/F03_2_9_3_4_5c.f90 .
The case involves an allocata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46752
--- Comment #5 from Bill Long 2010-12-02 18:42:53 UTC
---
Reply from James:
Version 3.1 of the OpenMP specification removes the offending bullet: " A
variable that appears in a firstprivate clause must be definable." When the
new spec is releas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46753
--- Comment #7 from Bill Long 2010-12-09 10:29:19 UTC
---
I am out of the office until Tuesday, December 21, 2010. Send technical
questions to spsl...@cray.com.
--- Comment #7 from longb at cray dot com 2010-05-07 22:06 ---
The original problem reported in the Description concerned a missing error
message. So, fixing the segfault (while an excellent situation) does not
address the original issue. My 2 cents is this is not ready to close yet
ected output is no output, e.g. from Intel compiler.]
--
Summary: OpenMP - case involving tasks with implicit shared i -
incorrect output
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority:
accesses threadprivate - non-
conforming but no msg
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lon
--- Comment #7 from longb at cray dot com 2010-05-12 14:34 ---
For what it's worth, the Cray compiler produces this message for the test code:
!$OMP shared (a,n,f)
^
ftn-1473 crayftn: ERROR DP, File = test.f90, Line = 13, Column = 19
Object F must be a var
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: x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383
Bill Long changed:
What|Removed |Added
CC||longb at cray dot com
--- Comment #6 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49693
Bill Long changed:
What|Removed |Added
CC||longb at cray dot com
--- Comment #1 from
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=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=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=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=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=40876
Bill Long changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
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=95038
--- Comment #5 from Bill Long ---
Original submitter asking for a fixed-in version number.
: 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=95644
--- Comment #2 from Bill Long ---
Any update on a fix for this? (The original customer is asking.)
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=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 t
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.
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=98699
--- Comment #3 from Bill Long ---
Thanks, Tobias. GCC 11 should be fine. Great to see you back.
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=95644
--- Comment #5 from Bill Long ---
Original customer is asking again...
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=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=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=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 do
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=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?
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&action=edit
Source for test case.
For the attached test case source file:
> gfortra
: 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
: 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
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.
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
: 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
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 upda
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 th
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=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=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
--- Comment #4 from Bill Long ---
Any prediction for this one? (I realize you still have F2018 an F2023 to get
through.)
101 - 151 of 151 matches
Mail list logo
