On 12/12/2018 12:06, Mark Eggleston wrote:
I'm about to build the compiler with
memset (buffer, 0x20, buffer_size);
instead of
memset (buffer, (flag_dec_pad_with_spaces ? 0x20 : 0x0), buffer_size);
and will check again, if necessary a padding variable can be used
instead initially set
On Wed, Dec 12, 2018 at 12:06:12PM +, Mark Eggleston wrote:
>
> On 12/12/2018 11:52, Jakub Jelinek wrote:
> > What about:
> >integer(kind=2) :: a
> >a = -1
> >print *, transfer (1_2, 1_8), transfer (a, 1_8)
> > end
> > ?
>
> I assume you meant transfer (-1_2, 1_8), the result
On 12/12/2018 11:52, Jakub Jelinek wrote:
What about:
integer(kind=2) :: a
a = -1
print *, transfer (1_2, 1_8), transfer (a, 1_8)
end
?
I assume you meant transfer (-1_2, 1_8), the result from gfortran is
65535 for both transfers.
I'm about to build the compiler with
memset
On Wed, Dec 12, 2018 at 11:37:23AM +, Mark Eggleston wrote:
> Before delving into the code to make changes to handle the case when passing
> a variable into transfer instead of a literal I revised the the test cases.
> The results indicate to me that this patch as originally intended is
>
Before delving into the code to make changes to handle the case when
passing a variable into transfer instead of a literal I revised the the
test cases. The results indicate to me that this patch as originally
intended is erroneous.
When a character literal is assigned to character variable
> On Mon, Dec 10, 2018 at 02:09:50PM +, Mark Eggleston wrote:
> >
> > On 06/12/2018 10:20, Mark Eggleston wrote:
> > > > Yes. Mark, you'll need to also patch iresolve.c (gfc_resolve_transfer)
> > > > to affect non-constant resolution.
> > > Thanks for the hint.
> >
> > I've looked at
On Mon, Dec 10, 2018 at 02:09:50PM +, Mark Eggleston wrote:
>
> On 06/12/2018 10:20, Mark Eggleston wrote:
> > > Yes. Mark, you'll need to also patch iresolve.c (gfc_resolve_transfer)
> > > to affect non-constant resolution.
> > Thanks for the hint.
>
> I've looked at gfc_resolve_transfer
On 06/12/2018 10:20, Mark Eggleston wrote:
Yes. Mark, you'll need to also patch iresolve.c (gfc_resolve_transfer)
to affect non-constant resolution.
Thanks for the hint.
I've looked at gfc_resolve_transfer regarding handling of padding when a
character variable is passed to transfer
On 12/6/18 2:33 AM, Jakub Jelinek wrote:
On Wed, Dec 05, 2018 at 06:27:00PM -0800, Jerry DeLisle wrote:
I disagree completely. I assume the idea of -fdec-pad-with-spaces is to
accomodate some old dec fortran code. The only reason to use some other
character is if someone is writing new dec
On 06/12/2018 10:33, Jakub Jelinek wrote:
On Wed, Dec 05, 2018 at 06:27:00PM -0800, Jerry DeLisle wrote:
I disagree completely. I assume the idea of -fdec-pad-with-spaces is to
accomodate some old dec fortran code. The only reason to use some other
character is if someone is writing new dec
On Wed, Dec 05, 2018 at 06:27:00PM -0800, Jerry DeLisle wrote:
> I disagree completely. I assume the idea of -fdec-pad-with-spaces is to
> accomodate some old dec fortran code. The only reason to use some other
> character is if someone is writing new dec fortran code, which is implying
>
On 04/12/2018 17:04, Fritz Reese wrote:
On Tue, Dec 4, 2018 at 10:12 AM Jakub Jelinek wrote:
Just a couple of random comments.
-fdec-pad-with-spaces option name doesn't look right, because it doesn't say
what the option affects. So perhaps have transfer in the option name?
[...]
Wouldn't
On 04/12/2018 15:11, Jakub Jelinek wrote:
On Tue, Dec 04, 2018 at 02:47:25PM +, Mark Eggleston wrote:
Here is a patch to considered for incorporation into gfortran adding to its
legacy support. It pads character to integer conversions using spaces
instead of zeros when enabled.
The pad
On 12/4/18 9:04 AM, Fritz Reese wrote:
On Tue, Dec 4, 2018 at 10:12 AM Jakub Jelinek wrote:
Just a couple of random comments.
-fdec-pad-with-spaces option name doesn't look right, because it doesn't say
what the option affects. So perhaps have transfer in the option name?
[...]
Wouldn't it
On Tue, Dec 4, 2018 at 10:12 AM Jakub Jelinek wrote:
>
> Just a couple of random comments.
> -fdec-pad-with-spaces option name doesn't look right, because it doesn't say
> what the option affects. So perhaps have transfer in the option name?
[...]
> Wouldn't it be better to allow specifying
On Tue, Dec 04, 2018 at 02:47:25PM +, Mark Eggleston wrote:
> Here is a patch to considered for incorporation into gfortran adding to its
> legacy support. It pads character to integer conversions using spaces
> instead of zeros when enabled.
>
> The pad character is 'undefined' or 'processor
Here is a patch to considered for incorporation into gfortran adding to
its legacy support. It pads character to integer conversions using
spaces instead of zeros when enabled.
The pad character is 'undefined' or 'processor dependent' depending on
which standard you read. This makes it 0x20
17 matches
Mail list logo
