Re: VLA representation in GCC internals

[Alejandro Colomar via Gcc]

Hi Martin,

On Sat, Nov 09, 2024 at 11:34:58AM GMT, Martin Uecker wrote:
> > > You can just eliminate the code for the star as it would now
> > > automatically end up as variable.
> > 
> > Thanks!
> > 
> > Have a lovely day!
> > Alex
> 
> Just committed, so you could rebase on trunk now.

Thanks!  I read your mail just a few seconds before starting the
hours-long regression testing.  Just in time.  :-)

> I also wanted to change zero representation to be the same as
> in the C++ FE, but I need to rethink this.  Maybe this change
> already solves most of our problems.

It should.  Thankfully, I already wrote the tests for when this got
fixed, so that I should only need to comment/uncomment them, so that I
wouldn't need to remember what I needed to test.  So, hopefully this
will work out of the box.  :)

> BTW: My main practical issue with zero-sized arrays is that the
> UB sanitizers triggers for zero-sized variable arrays.

Hmmm.

> 
> Martin

Cheers,
Alex

-- 



signature.asc
Description: PGP signature

Re: VLA representation in GCC internals

[Martin Uecker via Gcc]

Am Samstag, dem 09.11.2024 um 11:29 +0100 schrieb Alejandro Colomar via Gcc:
> On Sat, Nov 09, 2024 at 09:38:45AM GMT, Martin Uecker wrote:
> > Am Samstag, dem 09.11.2024 um 00:54 +0100 schrieb Alejandro Colomar via Gcc:
> > > Hi Martin,
> > > 
> > > I'm in the process of rebasing my __countof__ changes after your patch
> > > that fixes support for [*] and [0].
> > > 
> > > I should update the implementation of the following function:
> > > 
> > >   static bool
> > >   is_top_array_vla (tree type)
> > >   {
> > > bool zero, star, var;
> > > tree d;
> > > 
> > > if (TREE_CODE (type) != ARRAY_TYPE)
> > >   return false;
> > > if (!COMPLETE_TYPE_P (type))
> > >   return false;
> > > 
> > > d = TYPE_DOMAIN (type);
> > > zero = !TYPE_MAX_VALUE (d);
> > > star = (zero && C_TYPE_VARIABLE_SIZE (type));
> > > if (star)
> > >   return true;
> > > if (zero)
> > >   return false;
> > > 
> > > var = (TREE_CODE (TYPE_MIN_VALUE (d)) != INTEGER_CST
> > >   || TREE_CODE (TYPE_MAX_VALUE (d)) != INTEGER_CST);
> > > return var;
> > >   }
> > > 
> > > The 'star' calculation should be updated.  Would you mind proposing an
> > > implementation of this function that works with your changes?  Thanks!
> > > 
> > You can just eliminate the code for the star as it would now
> > automatically end up as variable.
> 
> Thanks!
> 
> Have a lovely day!
> Alex

Just committed, so you could rebase on trunk now.

I also wanted to change zero representation to be the same as
in the C++ FE, but I need to rethink this.  Maybe this change
already solves most of our problems.

BTW: My main practical issue with zero-sized arrays is that the
UB sanitizers triggers for zero-sized variable arrays.

Martin

Re: VLA representation in GCC internals

[Martin Uecker via Gcc]

Am Samstag, dem 09.11.2024 um 00:54 +0100 schrieb Alejandro Colomar via Gcc:
> Hi Martin,
> 
> I'm in the process of rebasing my __countof__ changes after your patch
> that fixes support for [*] and [0].
> 
> I should update the implementation of the following function:
> 
>   static bool
>   is_top_array_vla (tree type)
>   {
> bool zero, star, var;
> tree d;
> 
> if (TREE_CODE (type) != ARRAY_TYPE)
>   return false;
> if (!COMPLETE_TYPE_P (type))
>   return false;
> 
> d = TYPE_DOMAIN (type);
> zero = !TYPE_MAX_VALUE (d);
> star = (zero && C_TYPE_VARIABLE_SIZE (type));
> if (star)
>   return true;
> if (zero)
>   return false;
> 
> var = (TREE_CODE (TYPE_MIN_VALUE (d)) != INTEGER_CST
>   || TREE_CODE (TYPE_MAX_VALUE (d)) != INTEGER_CST);
> return var;
>   }
> 
> The 'star' calculation should be updated.  Would you mind proposing an
> implementation of this function that works with your changes?  Thanks!
> 
You can just eliminate the code for the star as it would now
automatically end up as variable.

Martin

Re: VLA representation in GCC internals

[Alejandro Colomar via Gcc]

On Sat, Nov 09, 2024 at 09:38:45AM GMT, Martin Uecker wrote:
> Am Samstag, dem 09.11.2024 um 00:54 +0100 schrieb Alejandro Colomar via Gcc:
> > Hi Martin,
> > 
> > I'm in the process of rebasing my __countof__ changes after your patch
> > that fixes support for [*] and [0].
> > 
> > I should update the implementation of the following function:
> > 
> > static bool
> > is_top_array_vla (tree type)
> > {
> >   bool zero, star, var;
> >   tree d;
> > 
> >   if (TREE_CODE (type) != ARRAY_TYPE)
> > return false;
> >   if (!COMPLETE_TYPE_P (type))
> > return false;
> > 
> >   d = TYPE_DOMAIN (type);
> >   zero = !TYPE_MAX_VALUE (d);
> >   star = (zero && C_TYPE_VARIABLE_SIZE (type));
> >   if (star)
> > return true;
> >   if (zero)
> > return false;
> > 
> >   var = (TREE_CODE (TYPE_MIN_VALUE (d)) != INTEGER_CST
> > || TREE_CODE (TYPE_MAX_VALUE (d)) != INTEGER_CST);
> >   return var;
> > }
> > 
> > The 'star' calculation should be updated.  Would you mind proposing an
> > implementation of this function that works with your changes?  Thanks!
> > 
> You can just eliminate the code for the star as it would now
> automatically end up as variable.

Thanks!

Have a lovely day!
Alex

> 
> Martin

-- 



signature.asc
Description: PGP signature

gcc-14-20241109 is now available

[GCC Administrator via Gcc]

Snapshot gcc-14-20241109 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/14-20241109/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-14 revision bb21d80e3d6e5e91e2d3c6636e3f667a0a44d3e1

You'll find:

 gcc-14-20241109.tar.xz   Complete GCC

  SHA256=f59dea9fc1eaf9d886191d5e3424f20bae4af5f76405e2bd3409017a7f1fd3b0
  SHA1=b94635e266ac24aa690148a97bf5048b4f4670dd

Diffs from 14-20241102 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-14
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

-Wfloat-equal and comparison to zero

[Sad Clouds via Gcc]

Hello, I don't know if this is a known GCC bug or intentional design,
but code like this:

double value = 0.0;
...
if (value == 0.0)
{
...
}

Results in the following warning with gcc-12.2.0:

"... warning: comparing floating-point with ‘==’ or ‘!=’ is unsafe"

Even though there is nothing unsafe here and comparison to floating
point 0.0 value is well defined.

The LLVM clang seems to handle this correctly and does not produce any
warnings with -Wfloat-equal option.

Is there any way to silence GCC without disabling -Wfloat-equal?

Thanks.

Re: -Wfloat-equal and comparison to zero

[Andrew Pinski via Gcc]

On Sat, Nov 9, 2024, 11:19 AM Sad Clouds via Gcc  wrote:

> Hello, I don't know if this is a known GCC bug or intentional design,
> but code like this:
>
> double value = 0.0;
> ...
> if (value == 0.0)
> {
> ...
> }
>
> Results in the following warning with gcc-12.2.0:
>
> "... warning: comparing floating-point with ‘==’ or ‘!=’ is unsafe"
>
> Even though there is nothing unsafe here and comparison to floating
> point 0.0 value is well defined.
>
> The LLVM clang seems to handle this correctly and does not produce any
> warnings with -Wfloat-equal option.
>
> Is there any way to silence GCC without disabling -Wfloat-equal?
>

You can use the diagnostic pragma to disable it directly for the statement.

But I will note comparing double even against 0 can be problematic. You
might not get exactly 0 in some cases with things like FMA or when using
x87 instructions set.

That is it still unsafe. Why clang does not warn is for them to answer.


> Thanks.
>