https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119502
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836
--- Comment #15 from Jerry DeLisle ---
Building with Steve's latest patch now. If all passes here I will commit to 16
and request to backport to 15. Thanks Steve.
||83282
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
Last reconfirmed||2025-04-18
Ever confirmed|0 |1
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836
--- Comment #13 from Jerry DeLisle ---
(In reply to kargls from comment #12)
> On 4/17/25 23:59, pault at gcc dot gnu.org wrote:
> >
> > Is it worth reverting or fixing this before the 15-branch release? After
> > all,
> > the bug made its way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836
--- Comment #6 from Jerry DeLisle ---
I get one test failure:
FAIL: gfortran.dg/do_concurrent_all_clauses.f90 -O (test for errors, line
21)
from:
! { dg-do compile }
program do_concurrent_all_clauses
implicit none
integer :: i, arr(10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836
--- Comment #2 from Jerry DeLisle ---
You have a great crystal ball.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119502
--- Comment #6 from Jerry DeLisle ---
Interestingly PR 48618 has a slightly different interpretation of the standard.
I will be checking the 2023 to see.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119502
Jerry DeLisle changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119502
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119502
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119406
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119403
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119406
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119403
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119380
--- Comment #3 from Jerry DeLisle ---
Works for me on gcc version 12.3.1 20230805 (GCC)
The last commit there is commit a3931bf6093dbeda637601da07cdbbd07e57ccbd (HEAD
-> releases/gcc-12)
This was a cherry pick from commit 03fb35f8753d87148b. M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119380
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119349
--- Comment #4 from Jerry DeLisle ---
(In reply to anlauf from comment #3)
> Looks related to pr118747, where an elemental subroutine was used
> instead of a function.
It has some similarities. Since Andre did the fix on that one, we need to se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119349
--- Comment #2 from Jerry DeLisle ---
With this modification it works:
implicit none
type string_t
character(len=:), allocatable :: string_
end type
logical :: result
result = .false.
result = true(string())
print *, resu
|1
CC||jvdelisle at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #1 from Jerry DeLisle ---
I can reproduce this. The following might be a hint.
$ gfc14 -Wall -pedantic -fcheck=all pr119349.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265
--- Comment #11 from Jerry DeLisle ---
(In reply to Matthew Krupcale from comment #10)
> Thanks Jerry! I think you may also have to backport the fix [1] for PR118640
> to avoid regression on the 14 branch as well.
>
> [1]
> https://gcc.gnu.org/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118640
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265
--- Comment #8 from Jerry DeLisle ---
I have backported cleanly and regression tested on 14 branch. Will push
shortly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115265
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119054
--- Comment #5 from Jerry DeLisle ---
Fixed on gcc-15, preparing backport to 14.
|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #7 from Jerry DeLisle ---
I have some ideas about how to do this. so i will take it. I may be asking for
additional input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119136
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119118
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118793
--- Comment #4 from Jerry DeLisle ---
The particular error situation is unique because it is just before we try to
match the variable name. This might be sufficient in this case:
$ ./a.out
At line 18 of file pr118793.f90
Fortran runtime error
|1
CC||jvdelisle at gcc dot gnu.org
Last reconfirmed||2025-02-28
--- Comment #1 from Jerry DeLisle ---
Thanks for PR and a patch submitted here:
https://gcc.gnu.org/pipermail/fortran/2025-February/061793.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
--- Comment #3 from Jerry DeLisle ---
(In reply to urbanjost from comment #2)
> I can imagine that different parsing of the input might make this very
> difficult but might also be very straight-forward so was hoping for the
> b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
--- Comment #23 from Jerry DeLisle ---
I have modified gcc.texi here to yield, after make info, the following pasted
out of my terminal viewing with info:
‘-x LANGUAGE’
Specify explicitly the LANGUAGE for the following input files
(ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
--- Comment #21 from Jerry DeLisle ---
(In reply to kargls from comment #20)
> (In reply to Jerry DeLisle from comment #19)
> >
> > What this is doing is invoking -std=legacy for files with suffixes that
> > imply legacy files such as .f
> >
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
--- Comment #19 from Jerry DeLisle ---
Created attachment 60593
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60593&action=edit
Possible patch to change compile behavior
This patch changes the fortran/lang-spec.h as a possible better app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
--- Comment #12 from Jerry DeLisle ---
"The keyword INTEGER with no kind-selector specifies type integer with default
kind; the kind type parameter value is equal to KIND (0). The decimal exponent
range of default integer shall be at least 5." -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117430
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
--- Comment #9 from Jerry DeLisle ---
We can have only one default integer otherwise its not a default. Our default
integer is KIND=4
The RANGE of KIND=4 integer is 9, so we exceed the requirement for at least a
decimal range of 5. RANGE is def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
--- Comment #7 from Jerry DeLisle ---
>From the 2023 standard I find:
"The keyword INTEGER with no kind-selector specifies type integer with default
kind; the kind type parameter value is equal to KIND (0). The decimal exponent
range of default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
--- Comment #6 from Jerry DeLisle ---
The check is being done in interface.cc. The kind is being checked against
default_integer_kind.
case(2):/* UNIT */
type = BT_INTEGER;
kind = gfc_default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Jerry DeLisle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |WAITING
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
--- Comment #12 from Jerry DeLisle ---
(In reply to Thomas Koenig from comment #10)
> What does the OpenMP standard say about I/O in partallel exexution?
I don't know,but the situation is libgfortran threads are being launched by the
async I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118935
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115781
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118789
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
||jvdelisle at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Jerry DeLisle ---
I must agree this would be very useful. I have not looked at our implementation
recently to see how
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118884
--- Comment #13 from Jerry DeLisle ---
Thanks Thomas. I was just getting ready to get lapack set up here for future
testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118884
--- Comment #6 from Jerry DeLisle ---
I forgot to mention this is a good hint for Thomas regarding how to tweak the
previous fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118884
--- Comment #5 from Jerry DeLisle ---
Not disagreeing, however:
Warning: Type mismatch at (1) passing global function ‘cslect’ declared at (2)
(UNKNOWN/LOGICAL(4))
cget24.f-pp.f:545:32:
237 |IF( CSLECT( W( I ) ) )
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118884
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117430
--- Comment #4 from Jerry DeLisle ---
If I had just scrolled down in resolve.cc a few more hunks, eye roll:
$ gfc -pedantic zorig.f90
zorig.f90:45:32:
45 | write(*,*) "B:", self%cptr
|1
Warning:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118831
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117430
--- Comment #3 from Jerry DeLisle ---
Where we resolve the data transfer statement the variable c_ptr is derived, It
has an attribute of private_comp. The interop_kind is 0. The gdb in resolve.cc
shows:
11745 derived = ts->u.derived;
(g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116829
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618
--- Comment #9 from Jerry DeLisle ---
I am thinking to backport this as it cleans up some output with garbage in it.
Any thoughts?
|ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
Last reconfirmed||2025-02-06
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jvdelisle at gcc dot gnu.org
Target Milestone: ---
This test case found during review of patch for PR114618.
program z3
implicit none
integer, parameter :: wp = kind(0d0)
real(kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
|--- |FIXED
CC||jvdelisle at gcc dot gnu.org
--- Comment #8 from Jerry DeLisle ---
I do not see a reason to backport. Let me know otherwise.
at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
CC||jvdelisle at gcc dot gnu.org
--- Comment #2 from Jerry DeLisle ---
I am going to make an attempt on this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
--- Comment #18 from Jerry DeLisle ---
(In reply to Jerry DeLisle from comment #17)
> (In reply to Damian Rouson from comment #16)
> > Is there a chance of this fix being backported to the 14 branch? If not,
> > then I assume this issue can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117434
--- Comment #17 from Jerry DeLisle ---
(In reply to Damian Rouson from comment #16)
> Is there a chance of this fix being backported to the 14 branch? If not,
> then I assume this issue can be marked as resolved. Unfortunately, however,
> I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118724
--- Comment #3 from Jerry DeLisle ---
I wonder if the fix was the patch for 117434.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118571
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118724
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618
--- Comment #7 from Jerry DeLisle ---
Oatch submitted:
https://gcc.gnu.org/pipermail/fortran/2025-January/061651.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101602
--- Comment #8 from Jerry DeLisle ---
I have the patch applied here. do_concurrent_12.f90 has six failures that look
like related to optimization. I will see if I can figure this out.
Running /home/jerry/dev/trunk/gcc/testsuite/gfortran.dg/dg.e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101602
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58857
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118571
Jerry DeLisle changed:
What|Removed |Added
Last reconfirmed||2025-01-24
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116668
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116668
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
|--- |INVALID
CC||jvdelisle at gcc dot gnu.org
--- Comment #3 from Jerry DeLisle ---
I think this can be closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118571
--- Comment #8 from Jerry DeLisle ---
Created attachment 60256
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60256&action=edit
Proposed final patch
This patch submitted for approval.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118571
--- Comment #7 from Jerry DeLisle ---
If no width is specified w_len comes in as zero so we have to handle that case.
diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 54312bf67e9..15a0dd5c3e9 100644
--- a/libgfortran/io/write.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118571
--- Comment #6 from Jerry DeLisle ---
(In reply to kargls from comment #3)
> diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
> index 54312bf67e9..084ac314f5c 100644
> --- a/libgfortran/io/write.c
> +++ b/libgfortran/io/write.c
> @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118571
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
--- Comment #10 from Jerry DeLisle ---
(In reply to Thomas Koenig from comment #9)
> Question is, what should we permit...
>
> For 'normal' operations, only unsigned op unsigned is permitted,
> so unsigned**unsigned is obviously ok.
>
> What a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118499
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118471
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118406
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118372
--- Comment #2 from Jerry DeLisle ---
Also appears to be OK on 14 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118372
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117798
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #28 from Jerry DeLisle ---
--- snip ---
> In iso-c-binding.def, one finds
>
> NAMED_CHARKNDCST (ISOCBINDING_CHAR, "c_char",gfc_default_character_kind)
>
> so kind('a') == kind(c_char_'a') on all targets.
This implies that is_c_in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #26 from Jerry DeLisle ---
Why not set it in gfc_resolve_expr near the top before any other actions?
also
Are there any systems where c_char is not equal to 1? If not then BT_CHARACTER
and KIND==1 is always C interoperable. ??
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #25 from Jerry DeLisle ---
I clearly see where my logic was incorrect. I do wonder if there is a resolve
string expr that would allow us to set the interop for all cases of kind=1
BT_CHARACTER.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47928
--- Comment #5 from Jerry DeLisle ---
I was not thinking about rewriting the whole thing, but rearranging enmasse may
be helpful if you know how to do that. I think we need to hear from others
though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47928
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #19 from Jerry DeLisle ---
(In reply to kargls from comment #17)
> On 12/24/24 10:03, jvdelisle at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
> >
> > --- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
Jerry DeLisle changed:
What|Removed |Added
Attachment #59960|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #16 from Jerry DeLisle ---
Needed a minor tweak:
+ if (string->ts.type != BT_CHARACTER
+ || (string->ts.type == BT_CHARACTER
// && on the inner paren instead of ||
+ && (string->ts.kind != 1 && string->ts.is_c_interop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #15 from Jerry DeLisle ---
>From Harald's post. "There is another case I found while playing which is
rejected:
print *, f_c_string(c_char_"abc", asis)"
I bet the parsing does not handle c_char_ with the two underscores. I h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #13 from Jerry DeLisle ---
Created attachment 59960
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59960&action=edit
Cleaned up patch with Harald's addition.
This patch fixes some white space and merges in Haralds patch for op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #12 from Jerry DeLisle ---
The following additional patch from Harald posted on the gfortran list:
https://gcc.gnu.org/pipermail/fortran/2024-December/061452.html
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intr
1 - 100 of 2248 matches
Mail list logo
