Re: smtgcc translation validation

[Krister Walfridsson via Gcc]

On Sun, 18 Aug 2024, Gerald Pfeifer wrote:

On Sat, 30 Sep 2023, Krister Walfridsson via Gcc wrote:

I have now released the new implementation for translation validation I talked
about at the GNU Tools Cauldron last week:
  https://github.com/kristerw/smtgcc


Wouldn't it be appropriate/nice to promote this a bit more strongly from
gcc.gnu.org?

One example I can think of is https://gcc.gnu.org/extensions.html .

Another might be https://gcc.gnu.org/bugs/ to help understand whether
something is a user bug or GCC bug?

Happy to accept patches, or if you want to suggest some text massage that
into HTML and add it.


I suggest waiting a few weeks -- the tool still has a few issues with 
false positives, and I need to document the limitations. But my plan is to 
have it fixed before the GNU Tools Cauldron; the main message in my 
proposed talk is "all of you should start using smtgcc!" :)


I'll send you a patch when this is done!

  /Krister

[PATCH v10 0/3] c: Add __nelementsof__ operator

[Alejandro Colomar via Gcc]

Hi!

This is v10 of this patch set; hopefully, we're close to an end.

I've already submitted a proposal for C2y to WG14, as n3313:


For those who haven't been following since the start, the entire thread
of patch set revisions and their discussions can be found here:

It also contains drafts of the n3313 proposal.

Changes since v9:

-  Rename s/__elementsof__/__nelementsof__/

   elementsof() doesn't mean in English something compatible with its
   programming semantics.  While there's existing uses of it in
   programming, that's an abuse of English, which could cause confusion,
   or maybe preclude a more appropriate use of that name in the future.

   nelementsof() is just one more byte, and is much more appropriate, by
   being a contraction of "_n_umber (of) elements of".

   Also, there's only one use of nelementsof() in the wild, which makes
   backwards compatibility much less of a concern.  That use is
   semantically compatible with this proposed operator.  And we could
   just notify that project the existence of a new standard operator
   with that name, if we finally settle on this name.

-  Rebase on top of git HEAD.

-  CC +=
Daniel Lundin, Nikolaos, JeanHeyd, Fernando, Jonathan, Chris,
Ville, Alex Celeste, Jakub Łukasiewicz

I have a draft for an updated proposal to WG14 (more recent than n3313).
It has some changes to the documentation of prior art, some typo fixes,
etc., and renames elementsof()=>nelementsof(), but the meat of the
proposal is the same.  I've also rebased it on top of the latest draft
for C2y, which is n3301.  I'll send it as a reply to this subthread.

This cover letter is sent to both gcc-patches@ and gcc@.  The patches
are only sent to gcc-patches@, and the draft for WG14 is only sent to
gcc@.

If anyone wants to add an `Acked-by:` (or `Reviewed-by:`), please do it
explicitly.  There've been some informal ones, but I prefer to pick them
from explicit ones.


Have a lovely day!

Alex


Alejandro Colomar (3):
  gcc/: Rename array_type_nelts() => array_type_nelts_minus_one()
  Merge definitions of array_type_nelts_top()
  c: Add __nelementsof__ operator

 gcc/c-family/c-common.cc   |  26 
 gcc/c-family/c-common.def  |   3 +
 gcc/c-family/c-common.h|   2 +
 gcc/c/c-decl.cc|  32 +++--
 gcc/c/c-fold.cc|   7 +-
 gcc/c/c-parser.cc  |  62 +++--
 gcc/c/c-tree.h |   4 +
 gcc/c/c-typeck.cc  | 118 +++-
 gcc/config/aarch64/aarch64.cc  |   2 +-
 gcc/config/i386/i386.cc|   2 +-
 gcc/cp/cp-tree.h   |   1 -
 gcc/cp/decl.cc |   2 +-
 gcc/cp/init.cc |   8 +-
 gcc/cp/lambda.cc   |   3 +-
 gcc/cp/operators.def   |   1 +
 gcc/cp/tree.cc |  13 --
 gcc/doc/extend.texi|  30 +
 gcc/expr.cc|   8 +-
 gcc/fortran/trans-array.cc |   2 +-
 gcc/fortran/trans-openmp.cc|   4 +-
 gcc/rust/backend/rust-tree.cc  |  13 --
 gcc/rust/backend/rust-tree.h   |   2 -
 gcc/target.h   |   3 +
 gcc/testsuite/gcc.dg/nelementsof-compile.c | 115 
 gcc/testsuite/gcc.dg/nelementsof-vla.c |  46 +++
 gcc/testsuite/gcc.dg/nelementsof.c | 150 +
 gcc/tree.cc|  17 ++-
 gcc/tree.h |   3 +-
 28 files changed, 600 insertions(+), 79 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/nelementsof-compile.c
 create mode 100644 gcc/testsuite/gcc.dg/nelementsof-vla.c
 create mode 100644 gcc/testsuite/gcc.dg/nelementsof.c

Range-diff against v9:
1:  a6aa38c9013 = 1:  ab72c4cee8f gcc/: Rename array_type_nelts() => 
array_type_nelts_minus_one()
2:  4ce16ee4dfe ! 2:  27852be4ac0 Merge definitions of array_type_nelts_top()
@@ Commit message
 Merge definitions of array_type_nelts_top()
 
 There were two identical definitions, and none of them are available
-where they are needed for implementing __elementsof__.  Merge them, and
+where they are needed for implementing __nelementsof__.  Merge them, 
and
 provide the single definition in gcc/tree.{h,cc}, where it's available
-for __elementsof__, which will be added in the following commit.
+for __nelementsof__, which will be added in the following commit.
 
 gcc/ChangeLog:
 
3:  caae5dbecb3 ! 3:  9c78ce1f66d c: Add __elementsof__ operator
@@ Metadata
 Author: Alejandro Colomar 
 
  ## Commit message #

[C2y] n3313.1 draft

[Alejandro Colomar via Gcc]

On Mon, Aug 19, 2024 at 12:58:30PM GMT, Alejandro Colomar wrote:
> I have a draft for an updated proposal to WG14 (more recent than n3313).
> It has some changes to the documentation of prior art, some typo fixes,
> etc., and renames elementsof()=>nelementsof(), but the meat of the
> proposal is the same.  I've also rebased it on top of the latest draft
> for C2y, which is n3301.  I'll send it as a reply to this subthread.

I've attached the PDF document of the draft n3313.1, the informal name
for an eventual revision of the n3313 proposal.  I've also attached the
man(7) source.  Below is a diff since n3313.

Have a lovely day!
Alex


diff --git i/elementsof.man w/elementsof.man
index 7c5a006..7002553 100644
--- i/elementsof.man
+++ w/elementsof.man
@@ -1,13 +1,13 @@
 .
 .
-.TH n3313\~ WG14 2024-08-15 ISO/IEC\~9899 "Proposal for C2y"
+.TH n3313.1\~ WG14 202?-??-?? ISO/IEC\~9899 "Proposal for C2y"
 .
 .
 .SH Name
 .
-n3313
+n3313.1
 \-
-New elementsof() operator (v2)
+New nelementsof() operator (v2)
 .
 .
 .SH Category
@@ -35,10 +35,6 @@ GNU Compiler Collection
 Martin Uecker
 .ME
 .br
-.MT xry...@xry111.site
-Xi Ruoyao
-.ME
-.br
 .MT xavi@tutanota.com
 Xavier Del Campo Romero
 .ME
@@ -98,6 +94,42 @@ Aaron Ballman
 .MT paulkon...@comcast.net
 Paul Koning
 .ME
+.br
+.MT daniel.lundin.m...@gmail.com
+Daniel Lundin
+.ME
+.br
+.MT strni...@protonmail.com
+Nikolaos Strimpas
+.ME
+.br
+.MT ferna...@borretti.me
+Fernando Borretti
+.ME
+.br
+.MT phdoftheho...@gmail.com
+JeanHeyd Meneide
+.ME
+.br
+.MT jonathan.protze...@ens-lyon.org
+Jonathan Protzenko
+.ME
+.br
+.MT chris.baz...@arm.com
+Chris Bazley
+.ME
+.br
+.MT ville.voutilai...@gmail.com
+Ville Voutilainen
+.ME
+.br
+.MT alexg.n...@gmail.com
+Alex Celeste
+.ME
+.br
+.MT jakublukasiew...@outlook.com
+Jakub Łukasiewicz
+.ME
 .
 .
 .SH History
@@ -115,6 +147,64 @@ v2;
 2024-08-15.
 .IP
 New elementsof() operator (v2)
+.RS
+.IP \[bu] 3
+.PD 0
+Provide an implementation for GCC.
+.IP \[bu]
+Rename _Lengthof => elementsof.
+.IP \[bu]
+Clarify when it should result in an integer constant expression.
+.IP \[bu]
+Require parentheses.
+.IP \[bu]
+Document prior art.
+.IP \[bu]
+Document backwards compatibility.
+.IP \[bu]
+Document reasons for having this operator beyond the pointer safety
+(which is already solved with complex macros and/or diagnostics).
+.IP \[bu]
+Add specific proposed changes to the draft document (based on n3220).
+.PD
+.RE
+.TP
+n3313.1
+v3;
+202?-??-??.
+.IP
+New nelementsof() operator (v3)
+.IP
+n3313.1 is an informal name for a future proposal that supersedes n3313.
+.RS
+.IP \[bu] 3
+.PD 0
+Rename elementsof => nelementsof.
+.IP \[bu]
+Rebase on n3301.
+.IP \[bu]
+Document performance problem of sizeof division.
+.IP \[bu]
+Document exponential macro growth problem of magic macros.
+.IP \[bu]
+Fix support for VLAs in example of NITEMS().
+This needs GNU C's
+.MR __builtin_types_compatible_p "" .
+.IP \[bu]
+Remove concerns about double evaluation,
+since it's possible to evaluate at most once,
+by using
+.I typeof
+and GNU C's statement expression.
+That improvement also adds support for type names,
+so also remove that concern.
+.IP \[bu]
+Add support for compound literals in example of NITEMS(),
+by using a variadic macro that will accept commas in the operand.
+.IP \[bu]
+Fix typo in proposed wording.
+.PD
+.RE
 .
 .
 .SH Synopsis
@@ -126,14 +216,16 @@ This operator yields the number of elements of an array.
 .
 .SS Portability
 .
-Prior to C23 it was impossible to do this portably,
-but since C23 it is possible to
-portably write a macro that
-determines the number of elements of an array,
-that is,
-the number of elements in the array.
+It is possible to write a macro that
+yields the number of elements of an array.
+However, it is impossible to reject pointer arguments portably.
+Here's an implementation using GNU C:
 .IP
 .EX
+#define is_same_type(a, b)__builtin_types_compatible_p(a, b)
+#define is_same_typeof(a, b)  is_same_type(typeof(a), typeof(b))
+#define decay(a)  (&*(a))
+#define is_array(a)   (!is_same_typeof(a, decay(a)))
 #define must_be(e)  \[rs]
 (   \[rs]
 0 * (int) sizeof(   \[rs]
@@ -143,38 +235,30 @@ the number of elements in the array.
 }   \[rs]
 )   \[rs]
 )
-#define is_array(a) \[rs]
-(   \[rs]
-_Generic(&(a),  \[rs]
-typeof((a)[0]) **:  0,  \[rs]
-default:1   \[rs]
-)   \[rs]
-)
-#define sizeof_array(a)  (sizeof(a) + must_be(is_array(a)))
-#define nitems(a)(sizeof_array(a) / sizeof((a)[0]))
+#define sizeo

Deprecating complex integer types in GCC

[Andrew Pinski (QUIC) via Gcc]

Deprecating complex integer types in GCC seems like a good idea. There has been 
issues with division with them before and it was raised back them maybe we 
should deprecate their support.
The previous discussion about deprecating them can be found 
https://gcc.gnu.org/legacy-ml/gcc/2001-11/msg00790.html and 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2995 .
They were never standardized nor I doubt many folks use them. 
This also came up since clang/LLVM has similar issues to GCC previously had 
too: https://github.com/llvm/llvm-project/issues/104738 .
I doubt many folks use them or even know it is an supported GNU extension 
either so deprecating them for GCC 15 seems like a decent idea.

Any thoughts on this? And possibly removing support in GCC 16?

Thanks,
Andrew Pinski

Re: Deprecating complex integer types in GCC

[Pip Cet via Gcc]

"Andrew Pinski \(QUIC\) via Gcc"  writes:

> Deprecating complex integer types in GCC seems like a good idea. There
> has been issues with division with them before and it was raised back
> them maybe we should deprecate their support.
> The previous discussion about deprecating them can be found
> https://gcc.gnu.org/legacy-ml/gcc/2001-11/msg00790.html and
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2995 .
> They were never standardized nor I doubt many folks use them.
> This also came up since clang/LLVM has similar issues to GCC previously had 
> too: https://github.com/llvm/llvm-project/issues/104738 .
> I doubt many folks use them or even know it is an supported GNU extension 
> either so deprecating them for GCC 15 seems like a decent idea.
>
> Any thoughts on this? And possibly removing support in GCC 16?

Just as an anecdote, they caused trouble for Emacs developers not so
long ago:

https://lists.gnu.org/archive/html/emacs-devel/2024-07/msg4.html

As changing 0 (or 1) to "i" is such a common C idiom, that typo is not
going to be rare, so adding, at least, a warning option analogous to
clang's (undocumented?) -Wgnu-imaginary-constant
(https://lists.gnu.org/archive/html/emacs-devel/2024-07/msg00030.html)
would be a good idea.

Gaussian integers are useful sometimes, but I'm not so sure about
Gaussian ints, truncated to 32 or 64 bits.  I suspect most users would
be much happier with unlimited-precision libraries that avoid the
truncation.

Pip Cet

Re: GCC Quad-Precision Math Library Manual: Errors

[FX Coudert via Gcc]

Hi Peter,

You are right, thanks for reporting these issues in the libquadmath 
documentation. I am CC’ing the GCC mailing-list. Does the following patch seem 
right?

diff --git a/libquadmath/libquadmath.texi b/libquadmath/libquadmath.texi
index dc2a9ff374b..ce4accf6421 100644
--- a/libquadmath/libquadmath.texi
+++ b/libquadmath/libquadmath.texi
@@ -118,15 +118,15 @@ The following mathematical constants of type 
@code{__float128} are defined.
   @table @asis
 @item @code{M_Eq}: the constant e (Euler's number)
-@item @code{M_LOG2Eq}: binary logarithm of 2
-@item @code{M_LOG10Eq}: common, decimal logarithm of 2
+@item @code{M_LOG2Eq}: base 2 logarithm of e
+@item @code{M_LOG10Eq}: decimal (base 10) logarithm of e
 @item @code{M_LN2q}: natural logarithm of 2
 @item @code{M_LN10q}: natural logarithm of 10
 @item @code{M_PIq}: pi
 @item @code{M_PI_2q}: pi divided by two
 @item @code{M_PI_4q}: pi divided by four
 @item @code{M_1_PIq}: one over pi
-@item @code{M_2_PIq}: one over two pi
+@item @code{M_2_PIq}: two over pi
 @item @code{M_2_SQRTPIq}: two over square root of pi
 @item @code{M_SQRT2q}: square root of 2
 @item @code{M_SQRT1_2q}: one over square root of 2


Regarding the naming of M_SQRT1_2q, it simply follows the traditional M_SQRT1_2 
macro which, according to glibc doc: "These constants come from the Unix98 
standard and were also available in 4.4BSD”. I agree with you that logic would 
dictate M_1_SQRT2, but we simply follow the existing pattern there.

Best,
FX


> Many thanks for the 'quadmath.h' library, which is where I found this email 
> address.  I have addressed this email to you as the problem isn't a bug in 
> GCC itself, it didn't seem right to try and coerce it into the bug report 
> system, and I didn't know where else to start, but I appreciate that the 
> problem is not yours, especially as the corresponding comments in  
> 'quadmath.h' itself are correct.  I'd be grateful if you could forward it to 
> whoever is maintaining the Quad-Precision Math Library Manuals. 
> 
> Three of the constants are mis-labelled in the current (14.2) version of that 
> Library Manual document (and in all the previous versions I've looked at) , 
> as follows:
> 
> M_LOG2Eq:  )  both are described as logarithms of 2, whereas they are 
> logarithms of 'e'
> M_LOG10Eq: )
> ...
> M_2_PIq:described as "one over two pi", actually two over pi [2/pi]
> 
> Additionally, whilst I realise that the two are mathematically equal, the 
> generic 'M_numerator_denominatorq' naming format convention suggests that 
> M_SQRT1_2q, described as "one over square root of 2", should better be 
> labelled as "square root of (1/2)"; M_1_SQRT2q would be the name that 
> corresponds to the original description.  Is this a lacuna in the standard?
> 
> Regards
> 
> Peter Randall

Re: GCC Quad-Precision Math Library Manual: Errors

[Jonathan Wakely via Gcc]

On Mon, 19 Aug 2024, 22:27 FX Coudert via Gcc,  wrote:

> Hi Peter,
>
> You are right, thanks for reporting these issues in the libquadmath
> documentation. I am CC’ing the GCC mailing-list. Does the following patch
> seem right?
>
> diff --git a/libquadmath/libquadmath.texi b/libquadmath/libquadmath.texi
> index dc2a9ff374b..ce4accf6421 100644
> --- a/libquadmath/libquadmath.texi
> +++ b/libquadmath/libquadmath.texi
> @@ -118,15 +118,15 @@ The following mathematical constants of type
> @code{__float128} are defined.
>@table @asis
>  @item @code{M_Eq}: the constant e (Euler's number)
> -@item @code{M_LOG2Eq}: binary logarithm of 2
> -@item @code{M_LOG10Eq}: common, decimal logarithm of 2
> +@item @code{M_LOG2Eq}: base 2 logarithm of e
> +@item @code{M_LOG10Eq}: decimal (base 10) logarithm of e
>  @item @code{M_LN2q}: natural logarithm of 2
>  @item @code{M_LN10q}: natural logarithm of 10
>  @item @code{M_PIq}: pi
>  @item @code{M_PI_2q}: pi divided by two
>  @item @code{M_PI_4q}: pi divided by four
>  @item @code{M_1_PIq}: one over pi
> -@item @code{M_2_PIq}: one over two pi
> +@item @code{M_2_PIq}: two over pi
>  @item @code{M_2_SQRTPIq}: two over square root of pi
>  @item @code{M_SQRT2q}: square root of 2
>  @item @code{M_SQRT1_2q}: one over square root of 2
>
>
> Regarding the naming of M_SQRT1_2q, it simply follows the traditional
> M_SQRT1_2 macro which, according to glibc doc: "These constants come from
> the Unix98 standard and were also available in 4.4BSD”. I agree with you
> that logic would dictate M_1_SQRT2, but we simply follow the existing
> pattern there.
>
> Best,
> FX
>
>
> > Many thanks for the 'quadmath.h' library, which is where I found this
> email address.  I have addressed this email to you as the problem isn't a
> bug in GCC itself, it didn't seem right to try and coerce it into the bug
> report system


The docs are part of libquadmath, which is part of GCC, so it certainly
would have been appropriate in the GCC bug database.


, and I didn't know where else to start, but I appreciate that the problem
> is not yours, especially as the corresponding comments in  'quadmath.h'
> itself are correct.  I'd be grateful if you could forward it to whoever is
> maintaining the Quad-Precision Math Library Manuals.
> >
> > Three of the constants are mis-labelled in the current (14.2) version of
> that Library Manual document (and in all the previous versions I've looked
> at) , as follows:
> >
> > M_LOG2Eq: )  both are described as logarithms of 2, whereas they are
> logarithms of 'e'
> > M_LOG10Eq: )
> > ...
> > M_2_PIq: described as "one over two pi", actually two over pi [2/pi]
> >
> > Additionally, whilst I realise that the two are mathematically equal,
> the generic 'M_numerator_denominatorq' naming format convention suggests
> that M_SQRT1_2q, described as "one over square root of 2", should better be
> labelled as "square root of (1/2)"; M_1_SQRT2q would be the name that
> corresponds to the original description.  Is this a lacuna in the standard?
> >
> > Regards
> >
> > Peter Randall
>
>
>