ubscripts up to 2^64-1 seem to be a great
sufficiency.
auto sub = real_to_integer (TREE_REAL_CST_PTR
(subscript->data.value_of()));
REAL_VALUE_TYPE csub;
real_from_integer (&csub, VOIDmode, sub, SIGNED);
> -Original Message-----
> From: Jakub Jelinek
> Sent: Sunday,
ut-file out for a spin.
> -Original Message-
> From: Jakub Jelinek
> Sent: Saturday, March 22, 2025 03:29
> To: Richard Biener
> Cc: Robert Dubner ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] change cbl_field_data_t::etc_t::value from
_Float128
> to t
On Fri, 21 Mar 2025, Robert Dubner wrote:
> I am stepping my way through the code that initializes the COBOL variable
>
> 01 FLOATLONG FLOAT-LONG VALUE 12345678.
>
> In the version created by Richard's patch, I arrive at line 15721, which I
> have flagged with /**/. (My editor lacks th
I did what I described to apply the patch copied in this e-mail
The results: You started with two errors in our gcc/cobol/tests, one was
the 55.5556 problem. That one is gone. But another test where a
couple of results that should be 0.01 and 0.1 are coming out .00 and .0
You started with
On Fri, Mar 21, 2025 at 08:25:10PM +0100, Richard Biener wrote:
> > --- gcc/cobol/parse.y.jj2025-03-21 17:49:43.571440176 +0100
> > +++ gcc/cobol/parse.y 2025-03-21 20:15:24.852414777 +0100
> > @@ -4331,7 +4331,8 @@ value_clause: VALUE all LITERAL[lit] {
> >cbl_field
All this said, I am more than a little astonished at the progress that's
being made here.
Bob D.
> -Original Message-
> From: Richard Biener
> Sent: Friday, March 21, 2025 15:25
> To: Jakub Jelinek
> Cc: Robert Dubner ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH]
> -Original Message-
> From: Richard Biener
> Sent: Monday, March 24, 2025 05:04
> To: Robert Dubner
> Cc: Jakub Jelinek ; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] change cbl_field_data_t::etc_t::value from
_Float128
> to tree
>
> On Sun, 23 Ma
obert Dubner ; James K. Lowden
> ; Richard Biener ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH] change cbl_field_data_t::etc_t::value from
_Float128
> to tree
>
> On Mon, Mar 24, 2025 at 09:44:40AM +0100, Jakub Jelinek wrote:
> > On Sun, Mar 23, 2025 at 08:28:47PM -0500,
On Sun, Mar 23, 2025 at 02:44:29PM -0500, Robert Dubner wrote:
> I am enclosing a patch to be applied on top of yours. (Your patch got us
> down to zero errors in the "Coughlan" tests, 2 UAT errors, and 4 errors in
> the NIST tests. Well done!)
>
> This one passes all of my tests, in both ASCII
On Mon, Mar 24, 2025 at 09:44:40AM +0100, Jakub Jelinek wrote:
> On Sun, Mar 23, 2025 at 08:28:47PM -0500, Robert Dubner wrote:
> > Jim is back from a short COBOL-related business trip. I am going to take
> > this working collection of patched patched patches and put it up where he
> > can get at
const cbl_field_t
> *subscript ) const {
> if( subscript->type != FldLiteralN ) return false;
>
>// ??? This only gets us int64_t
> + // Answer: Array subscripts up to 2^64-1 seem to be a great
> sufficiency.
>auto sub = real_to_integer (TREE_REAL_CST
On Sun, Mar 23, 2025 at 08:28:47PM -0500, Robert Dubner wrote:
> Jim is back from a short COBOL-related business trip. I am going to take
> this working collection of patched patched patches and put it up where he
> can get at it.
>
> That location is the float_to_tree branch of
>
> https://git
Jim is back from a short COBOL-related business trip. I am going to take
this working collection of patched patched patches and put it up where he
can get at it.
That location is the float_to_tree branch of
https://gitlab.cobolworx.com/COBOLworx/gcc-cobol.git
And we'll review it. We want to ma
age-
> From: Richard Biener
> Sent: Friday, March 21, 2025 14:12
> To: Robert Dubner
> Cc: gcc-patches@gcc.gnu.org; Jakub Jelinek
> Subject: RE: [PATCH] change cbl_field_data_t::etc_t::value from
_Float128
> to tree
>
> On Fri, 21 Mar 2025, Robert Dubner wrote:
>
On Sat, Mar 22, 2025 at 11:25:13PM -0500, Robert Dubner wrote:
> Real progress here. Preliminary report:
>
> I am still seeing trouble with a PIC PP9 variable coming back .000 instead
> of 0.001.
>
> In my 679 UAT tests, the failure count is down from 23 to 4
>
> In the NIST tests, the failure
> On Mar 21, 2025, at 11:44 PM, Robert Dubner wrote:
>
> [I am going to try to maintain a grip on my professionalism. A
> professional does not give in to the urge to say, "I told you so".]
>
> This program, compiled with the most recent level of patching, is
> generating the result
>
>
On Fri, Mar 21, 2025 at 08:25:10PM +0100, Richard Biener wrote:
> Hmm, but I see that digits_from_float128 from
>
> (gdb) p debug (value)
> 1.0e+0
>
> produces via real_to_integer zero:
>
> (gdb) s
> real_to_integer (r=0x7fff69a0, fail=0x7fff685f, precision=128)
> at ../../src/gcc/gc
atches@gcc.gnu.org; Jakub Jelinek
> > > Subject: RE: [PATCH] change cbl_field_data_t::etc_t::value from
> > _Float128
> > > to tree
> > >
> > > Crossed in the mail.
> > >
> > > I applied your fixes below.
> > >
> > > T
Hi!
I have still strong doubts that this parser_display_internal replacement
does what the code used to do before.
On Fri, Mar 21, 2025 at 01:56:40PM +0100, Richard Biener wrote:
> @@ -4884,8 +4883,9 @@ parser_display_internal(tree file_descriptor,
> // We make use of that here
>
> ch
> -Original Message-
> From: Richard Biener
> Sent: Friday, March 21, 2025 15:25
> To: Jakub Jelinek
> Cc: Robert Dubner ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] change cbl_field_data_t::etc_t::value from
_Float128
> to tree
>
> On Fri, 21 Ma
On Fri, 21 Mar 2025, Robert Dubner wrote:
> I did what I described to apply the patch copied in this e-mail
>
> The results: You started with two errors in our gcc/cobol/tests, one was
> the 55.5556 problem. That one is gone. But another test where a
> couple of results that should be 0.0
Just so I understand your terminology:
Am I to understand that by pulling master, and then applying the patch in
this message, that the source code will be at the point you are ready to
have me test?
I am more used to being three hours ahead of the US west coast than I am
to being five hours behi
On Fri, Mar 21, 2025 at 07:12:23PM +0100, Richard Biener wrote:
> So this is the following hunk where I totally misunderstood
> real_to_target when converting this from native_encode_expr and
> a tree to using REAL_VALUE_TYPE:
>
> @@ -15702,13 +15714,16 @@ initial_from_float128(cbl_field_t *field,
ener ; Jakub Jelinek
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] change cbl_field_data_t::etc_t::value from
_Float128
> to tree
>
>
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Friday, March 21, 2025 15:25
> > To: Jakub Je
On Fri, Mar 21, 2025 at 01:47:05PM -0500, Robert Dubner wrote:
> > -Original Message-
> > From: Robert Dubner
> > Sent: Friday, March 21, 2025 14:23
> > To: Richard Biener
> > Cc: gcc-patches@gcc.gnu.org; Jakub Jelinek
> > Subject: RE: [PATCH] change
> -Original Message-
> From: Robert Dubner
> Sent: Friday, March 21, 2025 14:23
> To: Richard Biener
> Cc: gcc-patches@gcc.gnu.org; Jakub Jelinek
> Subject: RE: [PATCH] change cbl_field_data_t::etc_t::value from
_Float128
> to tree
>
> Crossed in the mail
I am stepping my way through the code that initializes the COBOL variable
01 FLOATLONG FLOAT-LONG VALUE 12345678.
In the version created by Richard's patch, I arrive at line 15721, which I
have flagged with /**/. (My editor lacks the ability too prepend line
numbers, sadly.)
case F
On Fri, 21 Mar 2025, Robert Dubner wrote:
> Just so I understand your terminology:
>
> Am I to understand that by pulling master, and then applying the patch in
> this message, that the source code will be at the point you are ready to
> have me test?
Yes.
> I am more used to being three hours
28 matches
Mail list logo
