FX,
You're likely correct that the creation of an expression for
c_null_char is overkill. I copied the code from gfc_conv_concat_op()
in trans-expr.cc to get the 'f_c_string(s) -> trim(s) // c_null_char'.
This was the motivation of creating a string. If I look at the
-fdump-tree-orginal for
Hi Steve,
I think it’d be simpler not to create a front-end expression for the
c_null_char. Unless I’m mistaken, you only need it as an argument to pass to
build_call_expr_loc (input_location, gfor_fndecl_concat_string, …). You can
pass a pointer to the constant character, and the length is one
On Tue, Dec 10, 2024 at 09:05:02AM +0100, FX Coudert wrote:
> Hi Steve,
>
> > I've an almost complete implementation of F_C_STRING,
> > but need a bit of insight on the inlining that I'm
> > trying to implement.
>
> Maybe I can help. Can you send in your current patch?
>
FX,
I've attached the
Hi Paul,
no, I don't have an example in mind out of the box.
May be something like:
type :: T
character :: s(:)
character :: c
end type
class(T) :: foo(2)
But that is just a guess. I was triggered only by the first condition your
patch removes, where span was used instead of the of element
Hi Andre,
I don't think that's possible but I am prepared to be proven wrong :-) Do
you have an example in mind, where this might happen?
Regards
Paul
On Tue, 10 Dec 2024 at 10:52, Andre Vehreschild wrote:
> Hi Paul,
>
> in principle the patch looks sound, but is the vptr_size always the sam
Pushed r15-6090-gcf406a6c
Thanks for the review!
Jerry
On 12/10/24 12:15 AM, Andre Vehreschild wrote:
Hi Jerry,
patch looks good. Ok for mainline and backport after grace period.
Thanks for the patch,
Andre
On Mon, 9 Dec 2024 20:31:08 -0800
Jerry D wrote:
Hi all,
The attached p
Hi Andre,
I don't know the answer to your question but was following practice that is
followed elsewhere in gfortran with DECL_EXPRs by generating nameless
declarations in local scope.
Thanks for the review.
Paul
On Tue, 10 Dec 2024 at 10:20, Andre Vehreschild wrote:
> Hi Paul,
>
> the patch
Hi Paul,
in principle the patch looks sound, but is the vptr_size always the same as a
descriptor->span? Can't the later be larger because of padding? If that is the
case, then the first `else if (UNLIMITED...` you removed in `gfc_get_array_span
()` would return a larger number.
Regards,
Hi Paul,
the patch looks ok to me, but one questions remains:
You are doing this for all character arrays. Would it not be sufficient to
create the DECL only for deferred chararrays?
Ok for mainline and with a grace period for backporting.
Thanks for the patch,
Andre
On Tue, 10 Dec 202
Hi All,
This was yet another regression that I caused, which was backported and so
I am rather anxious to fix it promptly.
The modifications that I made to gfc_get_array_span caused
unlimited polymorphic array components to be missed, when contained in a
dummy. Instead, the dummy was taken to be
Hi All,
This was a rather vexatious bug to track down and squash. I was led astray
by the appearance of the bug in the tests for the implementation of
intrinsic transformational functions with class arguments. It turns out to
be an incipient bug in the handling of character(*) array associate name
Hi Jerry,
patch looks good. Ok for mainline and backport after grace period.
Thanks for the patch,
Andre
On Mon, 9 Dec 2024 20:31:08 -0800
Jerry D wrote:
> Hi all,
>
> The attached patch fixes this bug by checking for the case of a short
> READ that should be padded with blanks and if
Hi Jerry,
This looks okay to me, but maybe leave 48 hours for others to comment?
Best,
FX
Hi Steve,
> I've an almost complete implementation of F_C_STRING,
> but need a bit of insight on the inlining that I'm
> trying to implement.
Maybe I can help. Can you send in your current patch?
FX
14 matches
Mail list logo
