[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module

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?"

[Bug fortran/95037] gfortran fails to compile a simple subroutine, issues an opaque message

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.

[Bug fortran/95038] Not treating function result name as a variable.

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?

[Bug libfortran/95104] [9/10 Regression] Segfault on a legal WAIT statement

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.

[Bug fortran/95119] [9/10 Regression] CLOSE hangs when -fopenmp is specified in compilation

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.

[Bug fortran/40876] OpenMP private variable referenced in a statement function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876 Bill Long changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED

[Bug fortran/42478] [meta-bug] gfortran OpenMP bugs

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 -

[Bug fortran/95038] Not treating function result name as a variable.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95038 --- Comment #5 from Bill Long --- Original submitter asking for a fixed-in version number.

[Bug fortran/97272] New: Wrong answer from MAXLOC with character arg

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272 Bug ID: 97272 Summary: Wrong answer from MAXLOC with character arg Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fort

[Bug fortran/95644] IEEE_FMA is missing from the IEEE_ARITHMETIC module

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.)

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

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?

[Bug fortran/97272] Wrong answer from MAXLOC with character arg

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

[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module

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.

[Bug fortran/98699] New: Reset OMP_NESTED to true if OMP_MAX_ACTIVE_LEVELS is > 1.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98699 Bug ID: 98699 Summary: Reset OMP_NESTED to true if OMP_MAX_ACTIVE_LEVELS is > 1. Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Pri

[Bug libgomp/98699] Reset OMP_NESTED to true if OMP_MAX_ACTIVE_LEVELS is > 1.

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.

[Bug fortran/95647] operator(.eq.) and operator(==) treated differently

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 --- Comment #5 from Bill Long --- Is this fixed in a release version of GCC?

[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644 --- Comment #5 from Bill Long --- Original customer is asking again...

[Bug fortran/97272] Wrong answer from MAXLOC with character arg

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?

[Bug fortran/95640] gfortran ieee_selected_real_kind returns 10

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.

[Bug fortran/95038] Not treating function result name as a variable.

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?

[Bug fortran/95038] Not treating function result name as a variable.

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

[Bug fortran/95647] operator(.eq.) and operator(==) treated differently

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 --- Comment #7 from Bill Long --- For our purposes, 10 will be fine.

[Bug fortran/42954] [9/10/11/12 regression] TARGET_*_CPP_BUILTINS issues with gfortran

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?

[Bug fortran/104252] New: OpenMP array reduction support issue

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104252 Bug ID: 104252 Summary: OpenMP array reduction support issue Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran

[Bug fortran/102368] New: Failure to compile program using the C_SIZEOF function in ISO_C_BINDING

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102368 Bug ID: 102368 Summary: Failure to compile program using the C_SIZEOF function in ISO_C_BINDING Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: norm

[Bug fortran/102369] New: VALUE attribute for arrays not allowed

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102369 Bug ID: 102369 Summary: VALUE attribute for arrays not allowed Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran

[Bug fortran/102369] VALUE attribute for arrays not allowed

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.

[Bug demangler/102370] New: Runtime failure with allocatable component of allocatable parent and MOVE_ALLOC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102370 Bug ID: 102370 Summary: Runtime failure with allocatable component of allocatable parent and MOVE_ALLOC Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severi

[Bug fortran/102371] New: Error for type spec in FORALL statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102371 Bug ID: 102371 Summary: Error for type spec in FORALL statement Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortra

[Bug libfortran/102370] Runtime failure with allocatable component of allocatable parent and MOVE_ALLOC

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

[Bug fortran/95038] Not treating function result name as a variable.

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

[Bug fortran/101658] New: Bogus message for declaration of polymorphic dummy argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101658 Bug ID: 101658 Summary: Bogus message for declaration of polymorphic dummy argument Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/104585] incorrect error for dummy arguments with both VALUE and DIMENSION attributes

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 B

[Bug fortran/78219] [F08] specifying the kind of a FORALL index in the header

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?

[Bug fortran/104585] incorrect error for dummy arguments with both VALUE and DIMENSION attributes

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.)