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=117643
--- Comment #30 from GCC Commits ---
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:efc0981077a70c4de4596f682c4aeade07ec2f17
commit r15-6471-gefc0981077a70c4de4596f682c4aeade07ec2f17
Author: Steven G. Kargl
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #29 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #28)
> --- snip ---
>
> > In iso-c-binding.def, one finds
> >
> > NAMED_CHARKNDCST (ISOCBINDING_CHAR, "c_char",gfc_default_character_kind)
> >
> > so ki
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 #27 from kargls at comcast dot net ---
On 12/28/24 11:49, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
>
> --- Comment #26 from Jerry DeLisle ---
> Why not set it in gfc_resolve_expr near
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=117643
--- Comment #24 from kargls at comcast dot net ---
(In reply to anlauf from comment #22)
> (In reply to anlauf from comment #21)
>
> > diff --git a/gcc/fortran/iresolve.cc b/gcc/fortran/iresolve.cc
> > index 580f8c8407d..759eb99a645 100644
> > -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #23 from kargls at comcast dot net ---
(In reply to anlauf from comment #20)
> (In reply to Jerry DeLisle from comment #19)
> > (In reply to kargls from comment #17)
> > > I suppose the error in check.cc(gfc_check_f_c_string) that sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #22 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #21)
> diff --git a/gcc/fortran/iresolve.cc b/gcc/fortran/iresolve.cc
> index 580f8c8407d..759eb99a645 100644
> --- a/gcc/fortran/iresolve.cc
> +++ b/gcc/fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #21 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #20)
Replying to myself:
> So if I come from the other side, which code to accept and which to diagnose,
> I tried:
>
> if (string->ts.type != BT_CHARACTER
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #20 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #19)
> (In reply to kargls from comment #17)
> > I suppose the error in check.cc(gfc_check_f_c_string) that starts
> > with
> >
> > if (string->ts.typ
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 #15 from Jerry DeLisle ---
> > F
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 #17 from kargls at comcast dot net ---
On 12/24/24 10:03, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
>
> --- Comment #15 from Jerry DeLisle ---
> From Harald's post. "There is another
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 #14 from kargls at comcast dot net ---
(In reply to Jerry DeLisle from comment #12)
> The following additional patch from Harald posted on the gfortran list:
>
> https://gcc.gnu.org/pipermail/fortran/2024-December/061452.html
>
> di
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #11 from Jerry DeLisle ---
I get a clean sweep on x86_64_linux_gnu. I will try some jerry-code to see if I
can break it. If anyone else has comments, chime in. I think you submit to
the list Steve.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #10 from kargls at comcast dot net ---
On 12/17/24 16:23, jvdelisle at gcc dot gnu.org wrote:
> --- Comment #9 from Jerry DeLisle ---
> Patch applies cleanly. Testing started.
>
Thanks, Jerry, for taking a look at the patch.
On x8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Assignee|unassigned at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #8 from kargls at comcast dot net ---
(In reply to kargls from comment #7)
> Created attachment 59903 [details]
> Complete patch with testcase included
>
> The new diff is a complete implementation with an included testcase.
Forgot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
kargls at comcast dot net changed:
What|Removed |Added
Attachment #59827|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
kargls at comcast dot net changed:
What|Removed |Added
Attachment #59830|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
kargls at comcast dot net changed:
What|Removed |Added
Attachment #59617|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #3 from kargls at comcast dot net ---
Created attachment 59827
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59827&action=edit
Testcase for f_c_string
The attached testcase has a number of tests currently commented out.
Those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #2 from kargls at comcast dot net ---
Created attachment 59617
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59617&action=edit
initial partial implementation
The attached patch is an initial implementation of f_c_string() up t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117643
--- Comment #1 from kargls at comcast dot net ---
Here's a testcase (obviously untested).
!
! { dg-do run }
!
program foo
use iso_c_binding, only : c_null_char, f_c_string
logical, volatile :: asis
character(len=6, kind=c_char) s1
31 matches
Mail list logo
