Planned Fortran unsigned numbers branch

Hi everybody, now that a proposal for unsigned number inclusion in Fortran has passed the J3 hurdle, https://j3-fortran.org/doc/year/24/24-116.txt , I thought I would put my working hours where my mouth is and try my hand at a testbed implementation for gfortran. I am still grateful to Reinhold

Re: c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

On Mon, 2024-07-22 at 17:54 +0100, Joern Wolfgang Rennecke wrote: > > > On 22/07/2024 17:13, Joern Wolfgang Rennecke wrote: >   > I guess you could reduce the differences between platforms if you > didn't > > use types as defined by headerfiles directly, as they might be > > #defines > > or type

Re: c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

On Mon, 2024-07-22 at 17:13 +0100, Joern Wolfgang Rennecke wrote: > > > On 22/07/2024 16:44, David Malcolm wrote: > > Does it help to hack this change into prune.exp: > > > > diff --git a/gcc/testsuite/lib/prune.exp > > b/gcc/testsuite/lib/prune.exp > > index d00d37f015f7..f467d1a97bc6 100644 >

Re: c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

On 22/07/2024 17:13, Joern Wolfgang Rennecke wrote: > I guess you could reduce the differences between platforms if you didn't use types as defined by headerfiles directly, as they might be #defines or typedefs or whatever, and instead used your own typedef or struct types. It seems a type

Re: c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

On 22/07/2024 16:44, David Malcolm wrote: Does it help to hack this change into prune.exp: diff --git a/gcc/testsuite/lib/prune.exp b/gcc/testsuite/lib/prune.exp index d00d37f015f7..f467d1a97bc6 100644 --- a/gcc/testsuite/lib/prune.exp +++ b/gcc/testsuite/lib/prune.exp @@ -109,7 +109,7 @@ proc

Re: c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

On Mon, 2024-07-22 at 11:37 +0100, Joern Wolfgang Rennecke wrote: > While on x86_64-pc-linux-gnu, the second diagram shows the type > written > as 'int', as expected, on a 16 and 32 bit newlib based toolchain, it > is > being output as int32_t .  And all the formatting is also a bit > different,

c-c++-common/analyzer/out-of-bounds-diagram-11.c written type vs toolchain

While on x86_64-pc-linux-gnu, the second diagram shows the type written as 'int', as expected, on a 16 and 32 bit newlib based toolchain, it is being output as int32_t . And all the formatting is also a bit different, probably due to the change in how the int32_t is displayed. What do other p