Re: Handling of main() function for freestanding

[Arsen Arsenović via Gcc]

Hi,

On Friday, 7 October 2022 15:51:31 CEST Jason Merrill wrote:
> > * gcc.dg/noreturn-4.c: Likewise.
> 
> I'd be inclined to drop this test.
That seems like an odd choice, why do that over using another function 
for the test case? (there's nothing specific to main in this test, and 
it doesn't even need to link, so using any ol' function should be okay; 
see attachment)

The attached patch is also v2 of the original builtin-main one submitted 
earlier.  Tested on x86_64-pc-linux-gnu.  This revision excludes the 
mentioned pedwarns unless hosted.

Thanks,
-- 
Arsen Arsenović
>From 27a2cf85b1c3eb901413fd135918af0377bd1459 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Arsen=20Arsenovi=C4=87?= 
Date: Tue, 20 Sep 2022 19:17:31 +0200
Subject: [PATCH v2] c-family: Implement new `int main' semantics in
 freestanding

>From now, by default, (specifically) `int main' in freestanding will
implicitly return 0, as it does for hosted modes. The old behaviour is
still accessible via -fno-builtin-main.

gcc/c-family/ChangeLog:

	* c-common.cc (disable_builtin_function): Support special value
	`main' that, in freestanding, allows disabling special casing
	placed around `main'.
	* c-common.h: Add flag_builtin_main.
	(want_builtin_main_p): New function, true iff hosted OR
	builtin_main are set.

gcc/c/ChangeLog:

	* c-decl.cc (grokdeclarator): Consider flag_builtin_main when
	deciding whether to emit warnings.
	(finish_function): Consider flag_builtin_main and the noreturn
	flag when deciding whether to emit an implicit zero return.
	* c-objc-common.cc (c_missing_noreturn_ok_p): Consider missing
	noreturn okay only when hosted or when builtin_main is enabled.

gcc/cp/ChangeLog:

	* cp-tree.h (DECL_MAIN_P): Consider flag_builtin_main when
	deciding whether this function is to be the special function
	main.
	* decl.cc (grokfndecl): Only pedwarn on hosted.
	(finish_function): Do not inject extra return of marked
	noreturn.

gcc/ChangeLog:

	* doc/invoke.texi: Document -fno-builtin-main.

gcc/testsuite/ChangeLog:

	* gcc.dg/noreturn-4.c: Don't use `main', but a generic function
	name instead.
	* g++.dg/freestanding-main-implicitly-returns.C: New test.
	* g++.dg/no-builtin-main.C: New test.
	* gcc.dg/freestanding-main-implicitly-returns.c: New test.
	* gcc.dg/no-builtin-main.c: New test.
---
 gcc/c-family/c-common.cc  |  6 ++
 gcc/c-family/c-common.h   | 10 ++
 gcc/c/c-decl.cc   |  4 ++--
 gcc/c/c-objc-common.cc|  9 ++---
 gcc/cp/cp-tree.h  | 12 ++-
 gcc/cp/decl.cc|  6 --
 gcc/doc/invoke.texi   | 20 ++-
 .../freestanding-main-implicitly-returns.C|  5 +
 gcc/testsuite/g++.dg/no-builtin-main.C|  5 +
 .../freestanding-main-implicitly-returns.c|  5 +
 gcc/testsuite/gcc.dg/no-builtin-main.c|  5 +
 gcc/testsuite/gcc.dg/noreturn-4.c |  6 +++---
 12 files changed, 73 insertions(+), 20 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/freestanding-main-implicitly-returns.C
 create mode 100644 gcc/testsuite/g++.dg/no-builtin-main.C
 create mode 100644 gcc/testsuite/gcc.dg/freestanding-main-implicitly-returns.c
 create mode 100644 gcc/testsuite/gcc.dg/no-builtin-main.c

diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index 9ec9100cc90..f9060cbc171 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -232,6 +232,10 @@ int flag_isoc2x;
 
 int flag_hosted = 1;
 
+/* Nonzero means that we want to give main its special meaning */
+
+int flag_builtin_main = 1;
+
 
 /* ObjC language option variables.  */
 
@@ -4879,6 +4883,8 @@ disable_builtin_function (const char *name)
 {
   if (startswith (name, "__builtin_"))
 error ("cannot disable built-in function %qs", name);
+  else if (strcmp("main", name) == 0)
+flag_builtin_main = 0;
   else
 {
   disabled_builtin *new_disabled_builtin = XNEW (disabled_builtin);
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 62ab4ba437b..44537cc6977 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -689,6 +689,16 @@ extern int flag_isoc2x;
 
 extern int flag_hosted;
 
+/* Nonzero means that we want to give main its special meaning */
+
+extern int flag_builtin_main;
+
+/* Returns false if both flag_hosted and flag_builtin_main are zero, true
+   otherwise. */
+inline bool builtin_main_p() {
+  return flag_hosted || flag_builtin_main;
+}
+
 /* ObjC language option variables.  */
 
 
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 193e268f04e..891e36b30b6 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -10442,9 +10442,9 @@ finish_function (location_t end_loc)
   if (DECL_RESULT (fndecl) && DECL_RESULT (fndecl) != error_mark_node)
 DECL_CONTEXT (DECL_RESULT (fndecl)) = fndecl;
 
-  if (MAIN_NAME_P (DECL_NAME (fndecl)) && flag_hosted
+  if (MA

Re: Handling of main() function for freestanding

[Arsen Arsenović via Gcc]

On Thursday, 13 October 2022 19:10:10 CEST Jakub Jelinek wrote:
> Don't we have such a test already elsewhere?  If not, then certain
> "warn for main" part should be removed or replaced...

Whoops, missed that comment.  There is actually an equivalent test that 
I overlooked (noreturn-1.c), so maybe dropping is the right thing to do, 
indeed.

-- 
Arsen Arsenović


signature.asc
Description: This is a digitally signed message part.

Re: Handling of main() function for freestanding

[Arsen Arsenović via Gcc]

On Thursday, 13 October 2022 19:24:41 CEST Jason Merrill wrote:
> I was arguing that we don't need the new flag; there shouldn't be any
> need to turn it off.
At the time, I opted to go with a more conservative route; I haven't 
been around enough to have very strong opinions ;)  I certainly can't 
think of a way always adding a return can go wrong, but figured someone, 
somehow, might rely on this behavior.  Removed the flag and tested on 
x86_64-pc-linux-gnu, v3 attached.

FWIW, there's precedent for treating main specially regardless of 
flag_hosted (e.g. it's always marked extern "C" in the C++ frontend, 
AFAICT).

-- 
Arsen Arsenović
>From e60be6bb45fdba8085bde5d1883deeae640e786b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Arsen=20Arsenovi=C4=87?= 
Date: Thu, 13 Oct 2022 21:46:30 +0200
Subject: [PATCH v3] c-family: Implicitly return zero from main even on
 freestanding

... unless marked noreturn.

This should not get in anyone's way, but should permit the use of main()
in freestanding more easily, especially for writing test cases that
should work both in freestanding and hosted modes.

gcc/c/ChangeLog:

	* c-decl.cc (finish_function): Ignore hosted when deciding
	whether to implicitly return zero, but check noreturn.
	* c-objc-common.cc (c_missing_noreturn_ok_p): Loosen the
	requirements to just MAIN_NAME_P.

gcc/cp/ChangeLog:

	* cp-tree.h (DECL_MAIN_FREESTANDING_P): Move most DECL_MAIN_P
	logic here, so that we can use it when not hosted.
	(DECL_MAIN_P): Implement in terms of DECL_MAIN_FREESTANDING_P.
	* decl.cc (finish_function): Use DECL_MAIN_FREESTANDING_P
	instead of DECL_MAIN_P, to lose the hosted requirement, but
	check noreturn.

gcc/testsuite/ChangeLog:

	* g++.dg/freestanding-main.C: New test.
	* gcc.dg/freestanding-main.c: New test.
---
 gcc/c/c-decl.cc  | 2 +-
 gcc/c/c-objc-common.cc   | 5 ++---
 gcc/cp/cp-tree.h | 8 +---
 gcc/cp/decl.cc   | 3 ++-
 gcc/testsuite/g++.dg/freestanding-main.C | 5 +
 gcc/testsuite/gcc.dg/freestanding-main.c | 5 +
 6 files changed, 20 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/freestanding-main.C
 create mode 100644 gcc/testsuite/gcc.dg/freestanding-main.c

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 193e268f04e..8c655590558 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -10442,7 +10442,7 @@ finish_function (location_t end_loc)
   if (DECL_RESULT (fndecl) && DECL_RESULT (fndecl) != error_mark_node)
 DECL_CONTEXT (DECL_RESULT (fndecl)) = fndecl;
 
-  if (MAIN_NAME_P (DECL_NAME (fndecl)) && flag_hosted
+  if (MAIN_NAME_P (DECL_NAME (fndecl)) && !TREE_THIS_VOLATILE (fndecl)
   && TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (fndecl)))
   == integer_type_node && flag_isoc99)
 {
diff --git a/gcc/c/c-objc-common.cc b/gcc/c/c-objc-common.cc
index 70e10a98e33..2933414fd45 100644
--- a/gcc/c/c-objc-common.cc
+++ b/gcc/c/c-objc-common.cc
@@ -37,9 +37,8 @@ static bool c_tree_printer (pretty_printer *, text_info *, const char *,
 bool
 c_missing_noreturn_ok_p (tree decl)
 {
-  /* A missing noreturn is not ok for freestanding implementations and
- ok for the `main' function in hosted implementations.  */
-  return flag_hosted && MAIN_NAME_P (DECL_ASSEMBLER_NAME (decl));
+  /* A missing noreturn is ok for the `main' function.  */
+  return MAIN_NAME_P (DECL_ASSEMBLER_NAME (decl));
 }
 
 /* Called from check_global_declaration.  */
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 3b67be651b9..4c7adfbffd8 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -772,11 +772,13 @@ typedef struct ptrmem_cst * ptrmem_cst_t;
 
 /* Returns nonzero iff NODE is a declaration for the global function
`main'.  */
-#define DECL_MAIN_P(NODE)\
+#define DECL_MAIN_FREESTANDING_P(NODE)			\
(DECL_EXTERN_C_FUNCTION_P (NODE)			\
 && DECL_NAME (NODE) != NULL_TREE			\
-&& MAIN_NAME_P (DECL_NAME (NODE))			\
-&& flag_hosted)
+&& MAIN_NAME_P (DECL_NAME (NODE)))
+
+/* Nonzero iff NODE is a declaration for `main', and we are hosted. */
+#define DECL_MAIN_P(NODE) (DECL_MAIN_FREESTANDING_P(NODE) && flag_hosted)
 
 /* Lookup walker marking.  */
 #define LOOKUP_SEEN_P(NODE) TREE_VISITED (NODE)
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 82eb0c2f22a..cfc8cd5afd7 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -17854,7 +17854,8 @@ finish_function (bool inline_p)
   if (!DECL_CLONED_FUNCTION_P (fndecl))
 {
   /* Make it so that `main' always returns 0 by default.  */
-  if (DECL_MAIN_P (current_function_decl))
+  if (DECL_MAIN_FREESTANDING_P (current_function_decl)
+	  && !TREE_THIS_VOLATILE (current_function_decl))
 	finish_return_stmt (integer_zero_node);
 
   if (use_eh_spec_block (current_function_decl))
diff --git a/gcc/testsuite/g++.dg/freestanding-main.C b/gcc/testsuite/g++.dg/freestanding-main.C
new file mode 100644
index 000..3718cc4508e
--- /dev/null
+++ b/gcc/testsuite/g++

Re: Handling of main() function for freestanding

[Arsen Arsenović via Gcc]

On Thursday, 13 October 2022 23:16:02 CEST Jason Merrill wrote:
> I liked in the previous version that you checked the return type of
> main when !flag_hosted, here and in c_missing_noreturn_ok_p.  Let's
> bring that back.
Ah, right; I forgot about that.  What do you think of this?  

Thanks,
-- 
Arsen Arsenović
>From dfc1677d1dcfa1b3b963fca8ea5eb8878c4e63d0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Arsen=20Arsenovi=C4=87?= 
Date: Thu, 13 Oct 2022 21:46:30 +0200
Subject: [PATCH v4] c-family: Implicitly return zero from main even on
 freestanding

... unless marked noreturn.

This should not get in anyone's way, but should permit the use of main()
in freestanding more easily, especially for writing test cases that
should work both in freestanding and hosted modes.

gcc/c/ChangeLog:

	* c-decl.cc (finish_function): Ignore hosted when deciding
	whether to implicitly return zero, but check noreturn.
	* c-objc-common.cc (c_missing_noreturn_ok_p): Loosen the
	requirements to just MAIN_NAME_P when hosted, or `int main'
	otherwise.

gcc/cp/ChangeLog:

	* cp-tree.h (DECL_MAIN_P): Move most logic, besides the hosted
	check, from here...
	(DECL_MAIN_ANY_P): ... to here, so that it can be reused ...
	(DECL_MAIN_FREESTANDING_P): ... here, with an additional
	constraint on (hosted OR return type == int)
	* decl.cc (finish_function): Use DECL_MAIN_FREESTANDING_P
	instead of DECL_MAIN_P, to loosen the hosted requirement, but
	check noreturn, before adding implicit returns.

gcc/testsuite/ChangeLog:

	* gcc.dg/noreturn-4.c: Removed.
	* g++.dg/freestanding-main.C: New test.
	* g++.dg/freestanding-nonint-main.C: New test.
	* gcc.dg/freestanding-main.c: New test.
	* gcc.dg/freestanding-nonint-main.c: New test.
---
 gcc/c/c-decl.cc |  2 +-
 gcc/c/c-objc-common.cc  |  9 ++---
 gcc/cp/cp-tree.h| 15 ---
 gcc/cp/decl.cc  |  3 ++-
 gcc/testsuite/g++.dg/freestanding-main.C|  5 +
 gcc/testsuite/g++.dg/freestanding-nonint-main.C |  5 +
 gcc/testsuite/gcc.dg/freestanding-main.c|  5 +
 gcc/testsuite/gcc.dg/freestanding-nonint-main.c |  5 +
 gcc/testsuite/gcc.dg/noreturn-4.c   | 10 --
 9 files changed, 41 insertions(+), 18 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/freestanding-main.C
 create mode 100644 gcc/testsuite/g++.dg/freestanding-nonint-main.C
 create mode 100644 gcc/testsuite/gcc.dg/freestanding-main.c
 create mode 100644 gcc/testsuite/gcc.dg/freestanding-nonint-main.c
 delete mode 100644 gcc/testsuite/gcc.dg/noreturn-4.c

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 193e268f04e..8c655590558 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -10442,7 +10442,7 @@ finish_function (location_t end_loc)
   if (DECL_RESULT (fndecl) && DECL_RESULT (fndecl) != error_mark_node)
 DECL_CONTEXT (DECL_RESULT (fndecl)) = fndecl;
 
-  if (MAIN_NAME_P (DECL_NAME (fndecl)) && flag_hosted
+  if (MAIN_NAME_P (DECL_NAME (fndecl)) && !TREE_THIS_VOLATILE (fndecl)
   && TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (fndecl)))
   == integer_type_node && flag_isoc99)
 {
diff --git a/gcc/c/c-objc-common.cc b/gcc/c/c-objc-common.cc
index 70e10a98e33..b4680912547 100644
--- a/gcc/c/c-objc-common.cc
+++ b/gcc/c/c-objc-common.cc
@@ -37,9 +37,12 @@ static bool c_tree_printer (pretty_printer *, text_info *, const char *,
 bool
 c_missing_noreturn_ok_p (tree decl)
 {
-  /* A missing noreturn is not ok for freestanding implementations and
- ok for the `main' function in hosted implementations.  */
-  return flag_hosted && MAIN_NAME_P (DECL_ASSEMBLER_NAME (decl));
+  /* A missing noreturn is ok for the `main' function.  */
+  if (!MAIN_NAME_P (DECL_ASSEMBLER_NAME (decl)))
+return false;
+
+  return flag_hosted
+|| TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (decl))) == integer_type_node;
 }
 
 /* Called from check_global_declaration.  */
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 3b67be651b9..33529fa8093 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -772,11 +772,20 @@ typedef struct ptrmem_cst * ptrmem_cst_t;
 
 /* Returns nonzero iff NODE is a declaration for the global function
`main'.  */
-#define DECL_MAIN_P(NODE)\
+#define DECL_MAIN_ANY_P(NODE)\
(DECL_EXTERN_C_FUNCTION_P (NODE)			\
 && DECL_NAME (NODE) != NULL_TREE			\
-&& MAIN_NAME_P (DECL_NAME (NODE))			\
-&& flag_hosted)
+&& MAIN_NAME_P (DECL_NAME (NODE)))
+
+/* Nonzero iff NODE is a declaration for `int main', or we are hosted. */
+#define DECL_MAIN_FREESTANDING_P(NODE)\
+  (DECL_MAIN_ANY_P(NODE)	\
+   && (flag_hosted		\
+   || TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (NODE)))	\
+  == integer_type_node))
+
+/* Nonzero iff NODE is a declaration for `main', and we are hosted. */
+#define DECL_MAIN_P(NODE) (DECL_MAIN_ANY_P(NODE) && flag_hosted)
 
 /* Lookup walker marking.  */
 #define LOOKUP_SEEN_P(NODE) TRE

Ping (c,c++): Handling of main() function for freestanding

[Arsen Arsenović via Gcc]

Ping on this patch.

https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603574.html

For context, see the rest of this thread.  TL;DR is that `int main' 
should implicitly return 0 on freestanding, without the other burdens of 
main (hosted should remain unchanged, as well as non-int `main's).  This 
applies to both the C and C++ frontends.
-- 
Arsen Arsenović


signature.asc
Description: This is a digitally signed message part.

Re: C2x features status

[Arsen Arsenović via Gcc]

On Friday, 21 October 2022 21:14:54 CEST Marek Polacek via Gcc wrote:
> commit 0a91bdaf177409a2a5e7895bce4f0e7091b4b3ca
> Author: Joseph Myers 
> Date:   Wed Sep 7 13:56:25 2022 +
> 
> c: New C2x keywords
> 
> which says:
> 
> As with the removal of unprototyped functions, this change has a
> high risk of breaking some old code and people doing GNU/Linux
> distribution builds may wish to see how much is broken in a build
> with a -std=gnu2x default.

It already does break a lot.  See https://bugs.gentoo.org/870412 
(comments go over the details).  I was intending on giving this issue a 
proper look in the GNU toolchain frame of reference, but never got 
around to it (and I kinda knocked priority down after managing to 
configure properly once IIRC).

-- 
Arsen Arsenović


signature.asc
Description: This is a digitally signed message part.

Re: C2x features status

[Arsen Arsenović via Gcc]

On Friday, 21 October 2022 21:55:53 CEST Florian Weimer wrote:
> That's the implicit function declaration/implicit int change.  This
> won't happen in GCC 13, it's too late for that.  I tried to make this
> change a couple of years in Fedora, and just flipping the compiler
> flag Does Not Work.  I hope to get there in time for GCC 14.
The tracker also covers what clang calls strict-prototype (which is 
AFAICT about K&R style prototypes and () arg lists), so I figured it's 
relevant (but, IIRC, Clang is holding off on making that an error for 
now, so it was lower priority).

> Thank you for sharing the Gentoo tracker.  Maybe we can reuse some
> patches from there and contribute ours.  I trust Gentoo aims to
> upstream patches as they become available?  Unfortunately, I expect
> that a lot of these issues will be in packages that don't have an
> active upstream anymore, which makes sharing patches more
> challenging.  In other cases, we'll just build with -std=gnu89 (e.g.
> unzip
> , it has
> configure-style checking implemented without autoconf).
Yes, indeed, the devs that fixed packages did send patches usptream 
while they worked on this issue.  Unfortunately, there is dead 
upstreams, as you said, so I expect either lingering in-tree patches for 
issues or compile flag changes like the one for unzip you mentioned.  
Such contribution and collaboration is more than welcome, though; please 
do reach out.

Thanks,
-- 
Arsen Arsenović


signature.asc
Description: This is a digitally signed message part.

Re: Ping (c,c++): Handling of main() function for freestanding

[Arsen Arsenović via Gcc]

On Friday, 21 October 2022 23:02:02 CEST Joseph Myers wrote:
> I have no objections to the C changes.

Great!  Thanks for the review.  I don't have push rights currently, so I 
must ask that someone else pushes this patch for me.

Have a great day!
-- 
Arsen Arsenović


signature.asc
Description: This is a digitally signed message part.

Re: Triggering -save-temps from the front-end code

[Arsen Arsenović via Gcc]

Hi,

Florian Weimer via Gcc  writes:

> Unfortunately, some build systems immediately delete the input source
> files.  Is there some easy way I can dump the pre-processed and
> non-preprocessed sources to my log file?  I tried to understand how
> -save-temps for crash recovery works, but it seems that this runs
> outside of the frontend, in the driver.

Would dumping unconditionally into some "side channel" -dumpdir be a
sufficient workaround?

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Overall-Options.html#index-dumpdir

Hope that helps, have a great day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

cgraph: does node->inlined_to imply node->clones is non-empty?

[Arsen Arsenović via Gcc]

Hi,

I was debugging PR96059 and ran into a question which does not seem
obvious from the code.

For the test case in the PR, in ipa.cc:remove_unreachable_nodes, GCC
seems to try to remove an unreachable function that was already inlined
into a different unreachable function.  When the original inline
happens, ipa-inline-transform.cc:clone_inlined_nodes decides not to make
a clone, since the function being cloned is a master clone but with no
non-inline clones.

This decision later trips up the gcc_assert in:

  /* Inline clones might be kept around so their materializing allows further
 cloning.  If the function the clone is inlined into is removed, we need
 to turn it into normal cone.  */
  FOR_EACH_FUNCTION (node)
{
  if (node->inlined_to
  && !node->callers)
{
  gcc_assert (node->clones);
  node->inlined_to = NULL;
  update_inlined_to_pointer (node, node);
}
  node->aux = NULL;
}

.. because it is expecting that an inlined function without callers
(which is necessarily true here as this function is unreachable and so
was ->remove ()'d earlier) has clones.

Either removing the assertion or making clone_inline_nodes clone when
there are no existing clones 'fixes' (suppresses, but I haven't verified
whether the results are correct) the problem.

Is this gcc_assert correct in that an inlined function without callers
necessarily must have clones?

And as a side question, do all clone nodes have a ->clones pointing to
the same list of all clones, or are they in a tree-ish arrangement,
where clones of clones end up forming a tree, with the clone_of pointer
being a pointer to the parent?  (in this instance, the node that trips
the assert has a nullptr clone_of and clones value, which would AIUI
imply that it is the original)

This train of thinking doesn't end up involving any devirtualization
code, which the PR was originally reproduced with, but my current theory
is that devirtualizing here just exposed an edge case that is decently
well hidden, rather than it playing a crucial role.

Thanks in advance, have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [GSoC] gccrs Unicode support

[Arsen Arsenović via Gcc]

Philip Herron via Gcc  writes:

> Hi Raiki

Welcome, Raiki!

> Excellent work on getting up to speed on the rust front-end. From my
> perspective I am interested to see what the wider GCC community thinks
> about using https://www.gnu.org/software/libunistring/ library within GCC
> instead of rolling our own, this means it will be another dependency on GCC.

As my $0.02, it is likely best not to create yet another
re-implementation.  There's already precedent for including dependencies
that can do a very complex job well, like GMP and MPFR.

Text handling is deceivingly simple, and in practice, nobody seems to
get it fully right.  The effort is minimized, and yet most effectively
shared, if done in a library.

(note: I don't have a horse in the race wrt which specific library to
use, as I'm no expert, but I suspect libunistring could work well)

Have a wonderful day!

> The other option is there is already code in the other front-ends to do
> this so in the worst case it should be possible to extract something out of
> them and possibly make this a shared piece of functionality which we can
> mentor you through.
>
> Thanks
>
> --Phil
>
> On Mon, 13 Mar 2023 at 16:19, Raiki Tamura via Gcc  wrote:
>
>> Hello,
>>
>> My name is Raiki Tamura, an undergraduate student at Kyoto University in
>> Japan and I want to work on Unicode support in gccrs this year.
>> I have already written my proposal (linked below) and shared it with the
>> gccrs team in Zulip.
>> In the project, I am planning to use the GNU unistring library to handle
>> Unicode characters and the GNU IDN library to normalize identifiers.
>> According to my potential mentor, it would provide Unicode libraries for
>> all frontends in GCC. If there are concerns or feedback about this, please
>> tell me about it.
>> Thank you.
>>
>> Link to my proposal:
>>
>> https://docs.google.com/document/d/1MgsbJMF-p-ndgrX2iKeWDR5KPSWw9Z7onsHIiZ2pPKs/edit?usp=sharing
>>
>> Raiki Tamura
>>


-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: cgraph: does node->inlined_to imply node->clones is non-empty?

[Arsen Arsenović via Gcc]

Hi Martin,

Thank you for the thorough response, and apologies for replying so late
(I'm busy most hours of most workdays nowadays).

Martin Jambor  writes:

> Hello,
>
> I had been aware of your message even before Martin Liška pointed to it,
> but I could not answer the questions without looking into the problem
> myself.
>
> On Mon, Mar 13 2023, Arsen Arsenović via Gcc wrote:
>> Hi,
>>
>> I was debugging PR96059 and ran into a question which does not seem
>> obvious from the code.
>
> Thanks for looking into old bugs, it really is appreciated!

My pleasure.

>> When the original inline
>> happens, ipa-inline-transform.cc:clone_inlined_nodes decides not to make
>> a clone, since the function being cloned is a master clone but with no
>> non-inline clones.
>
> The reason is rather that cloning can simply be avoided if you know that
> you do not need an offline copy, for anything, be it other normal calls,
> calls from outside of the compilation unit, indirect calls, virtual
> calls, calls through aliases, thunks... that you do not need the intact
> body of the function to create other inline copies, other specialized
> clones... and maybe I forgot about something.  But this is an efficiency
> thing.

Right.  I was just trying to be specific about which requirement in the
if turned out to be false.

>>
>> For the test case in the PR, in ipa.cc:remove_unreachable_nodes, GCC
>> seems to try to remove an unreachable function that was already inlined
>> into a different unreachable function.
>
> No, it fails to remove it.  It is still there but should not have been,
> that is the problem.

Ah - I see.

>>
>> This decision later trips up the gcc_assert in:
>>
>>   /* Inline clones might be kept around so their materializing allows further
>>  cloning.  If the function the clone is inlined into is removed, we need
>>  to turn it into normal cone.  */
>>   FOR_EACH_FUNCTION (node)
>> {
>>   if (node->inlined_to
>>&& !node->callers)
>>  {
>>gcc_assert (node->clones);
>>node->inlined_to = NULL;
>>update_inlined_to_pointer (node, node);
>>  }
>>   node->aux = NULL;
>> }
>>
>> .. because it is expecting that an inlined function without callers
>> (which is necessarily true here as this function is unreachable and so
>> was ->remove ()'d earlier) has clones.
>
> The assert makes sure that if we encounter an inlined-to node without
> any caller, that it merely holds as the holder of the function body for
> its other specialized (think IPA-CP) or inline clones.  If node->clones
> is false, there are no such clones and it was a bug to mark the node as
> required during the removal of unreachable nodes.

I see.  That makes sense.  So, this assert is placed here by convenience
rather than being this invariant being absolutely required for the
purpose of the loop?  (it is related, so this placement makes sense, I
just want to confirm whether it's a "mandatory" invariant)

>>
>> Either removing the assertion or making clone_inline_nodes clone when
>> there are no existing clones 'fixes' (suppresses, but I haven't verified
>> whether the results are correct) the problem.
>>
>> Is this gcc_assert correct in that an inlined function without callers
>> necessarily must have clones?
>
> It is correct.  An inlined function without a caller is even a logical
> oxymoron and can only exist if it has the purpose described above (and
> even then probably only in a fairly special circumstances).

Right.  I wasn't quite sure whether setting inlined_to would remove that
caller, but if I understood right, it should not.

What is interesting, though, is that there is an attempt to remove this
node during ipa_inline:

 (gdb) bt
 #0  cgraph_edge::remove_callee (
 this= -> )>)
 at ../../gcc/gcc/cgraph.h:3299
 #1 0x00d03c37 in cgraph_node::remove_callees (this=) at
  ../../gcc/gcc/cgraph.cc:1743
 #2 0x00d04387 in cgraph_node::remove (this=) at ../../gcc/gcc/cgraph.cc:1884
 #3 0x010da74f in symbol_table::remove_unreachable_nodes
  (this=0x76ddb000, file=0x77a814c0 <_IO_2_1_stderr_>) at
  ../../gcc/gcc/ipa.cc:518
 #4 0x02b51e53 in ipa_inline () at
  ../../gcc/gcc/ipa-inline.cc:2761
 #5 0x02b52cf7 in (anonymous
  namespace)::pass_ipa_inline::execute (this=0x3c8d5b0) at
  ../../gcc/gcc/ipa-inline.cc:3153
 (etc)

... I presume that my assumption that cgraph_node::remove () should
remove nodes from the cgraph_node::next chain is wrong?

>>
>> And as a side question, do all clone nodes have a ->clones pointi

Re: Is it possible to enable data sections and function sections without explicitly giving flags "-fdata-sections" and "-ffunction-sections"?

[Arsen Arsenović via Gcc]

"3119369616.qq via Gcc"  writes:

> To divide functions into sections and then remove unused sections, I must
> provide flags "-fdata-sections" and "-ffunction-sections" in GCC and a flag
> "--gc-sections" in LD. Most of the build systems don't support these flags so
> GCC will generate bigger binaries.
> Is it possible to enable this feature without  giving any command line 
> flags manually?

All (at least decent) build systems support passing extra flags to the
compiler and linker (e.g. CXXFLAGS="-ffunction-sections"), or passing a
custom compiler and linker (which can set those flags, something like
CC="gcc -ffunction-sections").  This is how you should be setting such
flags.

If you're interested in DCE and other size-reducing optimizations, you
might also be interested in LTO and -Os.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: cgraph: does node->inlined_to imply node->clones is non-empty?

[Arsen Arsenović via Gcc]

Hi,

Martin Jambor  writes:

> Hi,
>
> On Sat, Mar 18 2023, Arsen Arsenović wrote:
>> Martin Jambor  writes:
>
> [...]
>

 For the test case in the PR, in ipa.cc:remove_unreachable_nodes, GCC
 seems to try to remove an unreachable function that was already inlined
 into a different unreachable function.
>>>
>>> No, it fails to remove it.  It is still there but should not have been,
>>> that is the problem.
>>
>> Ah - I see.
>>

 This decision later trips up the gcc_assert in:

   /* Inline clones might be kept around so their materializing allows 
 further
  cloning.  If the function the clone is inlined into is removed, we 
 need
  to turn it into normal cone.  */
   FOR_EACH_FUNCTION (node)
 {
   if (node->inlined_to
  && !node->callers)
{
  gcc_assert (node->clones);
  node->inlined_to = NULL;
  update_inlined_to_pointer (node, node);
}
   node->aux = NULL;
 }

 .. because it is expecting that an inlined function without callers
 (which is necessarily true here as this function is unreachable and so
 was ->remove ()'d earlier) has clones.
>>>
>>> The assert makes sure that if we encounter an inlined-to node without
>>> any caller, that it merely holds as the holder of the function body for
>>> its other specialized (think IPA-CP) or inline clones.  If node->clones
>>> is false, there are no such clones and it was a bug to mark the node as
>>> required during the removal of unreachable nodes.
>>
>> I see.  That makes sense.  So, this assert is placed here by convenience
>> rather than being this invariant being absolutely required for the
>> purpose of the loop?  (it is related, so this placement makes sense, I
>> just want to confirm whether it's a "mandatory" invariant)
>
> If the assert fails, the algorithm does not work as intended.  OTOH, It
> could be a gcc_checking_assert only since user compiled code would still
> work, just would be unnecessarily bigger.

Yes, that is what I was trying to ask ;-)  Apologies for failing to
articulate so.

>>
>>> It is correct.  An inlined function without a caller is even a logical
>>> oxymoron and can only exist if it has the purpose described above (and
>>> even then probably only in a fairly special circumstances).
>>
>> Right.  I wasn't quite sure whether setting inlined_to would remove that
>> caller, but if I understood right, it should not.
>>
>> What is interesting, though, is that there is an attempt to remove this
>> node during ipa_inline:
>
> IPA-inline calls remove_unreachable_nodes to get rid of call graph nodes
> which are known not to be necessary after inlining (inlining can lead to
> redirection of some call graph edges to __builtin_unreachable) and
> unreachable removal... well.. removes nodes.
>
>>
>>  (gdb) bt
>>  #0  cgraph_edge::remove_callee (
>>  this=>  "__ct_base "/18> -> )>)
>>  at ../../gcc/gcc/cgraph.h:3299
>>  #1 0x00d03c37 in cgraph_node::remove_callees (this=>   * const 0x76dedaa0 "__ct_base "/18>) at
>>   ../../gcc/gcc/cgraph.cc:1743
>>  #2 0x00d04387 in cgraph_node::remove (this=>   0x76dedaa0 "__ct_base "/18>) at ../../gcc/gcc/cgraph.cc:1884
>>  #3 0x010da74f in symbol_table::remove_unreachable_nodes
>>   (this=0x76ddb000, file=0x77a814c0 <_IO_2_1_stderr_>) at
>>   ../../gcc/gcc/ipa.cc:518
>>  #4 0x02b51e53 in ipa_inline () at
>>   ../../gcc/gcc/ipa-inline.cc:2761
>>  #5 0x02b52cf7 in (anonymous
>>   namespace)::pass_ipa_inline::execute (this=0x3c8d5b0) at
>>   ../../gcc/gcc/ipa-inline.cc:3153
>>  (etc)
>>
>> ... I presume that my assumption that cgraph_node::remove () should
>> remove nodes from the cgraph_node::next chain is wrong?
>
> Ummm the function does that through the call to
> symtab_node::unregister.  But how is that related?

Oh - my bad.  I seem to have broken on the wrong condition here.
"value"/28 is *not* removed.

That makes more sense, it'd be confusing if remove() still lead to
FOR_EACH_FUNCTION touching a node.

>>

 And as a side question, do all clone nodes have a ->clones pointing to
 the same list of all clones, or are they in a tree-ish arrangement,
 where clones of clones end up forming a tree, with the clone_of pointer
 being a pointer to the parent?
>>>
>>> The latter, they form a tree.
>>
>> I see, that makes sense.  Thanks.
>>
 (in this instance, the node that trips
 the assert has a nullptr clone_of and clones value, which would AIUI
 imply that it is the original)
>>>
>>> Yes.
>>>
 This train of thinking doesn't end up involving any devirtualization
 code, which the PR was originally reproduced with, but my current theory
 is that devirtualizing here just exposed an edge case that is decently
 well hidden, rather than it playing a crucial role.
>>>
>>> The inlined function is - I believe erroneously - marked as reachable by
>

Re: Don't want to receive messages

[Arsen Arsenović via Gcc]

Ruchit Raushan via Gcc  writes:

> I don't want to receive further emails.

Please see https://gcc.gnu.org/mailman/listinfo/gcc
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Dave Blanchard  writes:

> On Tue, 09 May 2023 16:07:50 +0100
> Sam James via Gcc  wrote:
>
>> Florian did note this already - ABI. Implicit function declarations are
>> pretty horrible in a number of cases:
>> - they prevent fortification (_FORTIFY_SOURCE)
>
> So what? Print a warning, for those who are writing new code or maintaining 
> old
> code and actually care. Done.
>
>> - they prevent time64 and LFS migrations from working correctly
>
> So what? Print a warning, for those who are writing new code or maintaining 
> old
> code and actually care. Done.
>
> 2038 is 15 years away. I'm trying to keep existing code working TODAY.
>
>> - they break with different ABIs (see e.g. Apple's arm64 ABI)
>
> I don't care about Apple or ARM64. I'm trying to keep old code working fine 
> on x86.

It doesn't work fine on x86 (or any other arch).  See the two points
above that you've baselessly dismissed.

>> - they can cause runtime crashes when combined wtih bfd's default of
>> not warning on underlinking
>
> My system is perfectly stable, thanks. In fact it is much more stable and much
> snappier than the garbage released by the likes of Fedora, RedHat, etc. If
> runtime crashes and stability were a concern for those folks, they should 
> start
> by dropping 'Linux Puttering' out of a helicopter.

Employment of such language is unwanted, but sadly, I'm not surprised.

>> int-conversion generally indicates severe runtime problems as well. 
>
> Not in my experience. My system works fine, despite approximately 10,000,000
> warnings spit out by GCC during the build process.

You've actively and baselessly dismissed the general case (and are, and
I say this with a lot of confidence, missing subtle bugs on your
system).

>> Many of the cases I've seen on musl absolutely do not work at runtime and
>> weren't caught by any other warnings (often because of padding mismatches).
>
> Well that's the risk you take by changing the C standard library. My system
> works fine on glibc. If any given package has a problem on musl, I will take
> that on a case by case basis. Wrecking my build process by introducing 10,000
> new errors isn't part of the solution.

The number of errors is far smaller than you estimate.  We've been
working through the queue for a while and have a decent idea of the
scope of the problem, and it is very manageable.

On top of that, the errors in question are largely trivial to fix,
unlike detecting the errors introduced by the current 'working' code.

>> That's why Fedora and Gentoo have been aggressively working on this
>> before even proposing it. We are being proactive in making sure that
>> common things are fixed.
>
> Yeah, you're being proactive in ruining everything. Thanks. How's systemd and
> pulseaudio working out for you?

They compile fine, and run without subtle bugs caused by constructs that
have been invalid for over 20 years.

>> I don't know if it's that aggressive to drop something which was
>> removed in C99 because of how dangerous it is.
>
> You're breaking old code unnecessarily by introducing an error, when the
> existing warning is perfectly fine.
>
> If it was such a horrible, terrible, no-good thing that it must be removed
> immediately, then why wasn't this already changed decades ago? Hint: BECAUSE
> YOU ARE BREAKING PEOPLE'S FUCKING SYSTEMS FOR NO REASON.

It doesn't work fine.  See the points that you've dismissed above.

The situation was also far simpler decades ago, and the actual trade-off
far greater (now invalid code is the exception).

>> Also, keep in mind, Florian went around and asked many of the first
>> group (the foundational folks) who didn't object.
>
> No, he asked a few big shot million dollar well-funded distributions if they
> had any problems with increasing their workload and maybe hiring a few extra
> developers. Unsurprisingly that select group of insiders had no problem with
> it. Meanwhile there are thousands of other smaller users and organizations out
> there whose concerns are just as important.

This seems irrelevant, and is not an accurate representation of who's
involved in the process.

>> Not that this is a strong argument, and I don't like making it, but
>> if Clang is doing it and GCC does too, it's not like they can reassess
>> their choices anyway.
>
> In fact that's exactly why GCC should continue just the way it is, so that
> people can have an actual alternative to the "bondage and discipline" 
> approach,
> and continue keeping their old code working just fine when there are literally
> NO PROBLEMS with the status quo.

Current code is subtly broken.  It is a disservice to users to pretend
otherwise.

Have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Dave Blanchard  writes:

> On Tue, 9 May 2023 16:14:28 +0100
> Jonathan Wakely via Gcc  wrote:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> And in the process, break half of my system, and make it even more of a pain 
> in
> the ass to compile old software. With no real gain or benefit whatsoever. To
> hell with that bullshit.

Your system seems to be already broken.

You're actively dismissing the benefit.

>> Accepting invalid code by default is a disservice to users. Those who
>> need to compile invalid C code can use an extra option to allow it,
>> the default should be to tell users their code is doing something bad.
>
> The default ALREADY IS to tell users their code is doing something bad. It's
> called a "warning." Hello?

This construct is a blatant error and is easily fixable.  Not to mention
that it has been invalid, just the same as 'if {foo() == 3} ( bar{} );'
is.  We're currently not emitting a warning and accepting such code, so
I don't see why this blatantly invalid construct should be taken
differently, especially when it is an exception rather than a rule in
practice.

Have a great day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Eli Zaretskii  writes:

>> Cc: Jonathan Wakely , gcc@gcc.gnu.org
>> Date: Tue, 09 May 2023 18:38:05 +0200
>> From: Arsen Arsenović via Gcc 
>> 
>> You're actively dismissing the benefit.
>
> Which benefit?
>
> No one has yet explained why a warning about this is not enough, and
> why it must be made an error.  Florian's initial post doesn't explain
> that, and none of the followups did, although questions about whether
> a warning is not already sufficient were asked.

Quite simple: people don't (as easily) choose to ignore errors.

You can see this in any teaching environment, and I've had such
experience in many of them, so I can say with an extremely high degree
of confidence that people, by default, do not ignore errors.  A student
will see twenty warnings and brush it off, but will see one error and
diligently go back to fix it.

If we tally up the hypothetical users of the hypothetical -fpermissive
coverage for enabling these broken constructs, I think that we (compiler
and distro developers) will be a supermajority or more.

I am absolutely certain, by virtue of us having this conversation today,
that warnings are not enough.  I am also absolutely certain that an
opt-out error *will* work, as it has before for cases like -fcommon and
the G++ -fpermissive flag (naturally, these aren't magically gone, but
they are becoming rarer).  Hell, I've missed warnings before as they do
not normally raise a flag during development (hence -Werror), even
though I have many years of dealing with loose toolchain defaults.

> That's a simple question, and unless answered with valid arguments,
> the proposal cannot make sense to me, at least.

I'll repeat a few reasons others have cited:
- implicit or misdeclared calls lead to subtly incorrect code,
- implicit calls lead to a lack of toolchain features like
  _FORTIFY_SOURCE,
- implicit calls lead to wrong symbols being chosen, leading to
  data being trimmed, which can on occasion hide itself for a long time,
- all of these constructs have been unambiguously invalid for decades,
- the impact is relatively small (Florian cited a figure of six percent,
  which lines up roughly with my own observation), yet an escape hatch
  for aged code can be easily provided.
- as the compiler is less informed about what code its interfacing in,
  diagnostics are proportionally affected (alongside producing incorrect
  code).
- these constructs have been invalid for decades, and, if considered an
  extension, they're a hideous blot.
- by making GCC not a strict compiler *by default*, we encourage using
  non-GNU toolchains because 'they provide better error reporting'.
  This also applies for other components of the toolchain.  I, for one,
  have little interest in enabling that when the cost for keeping
  fast-and-loose-playing compilers for old (read: broken) codebases is
  low.

It is very much okay (nae, a feature) to be compatible with previous
versions of the compiler, and a prior status quo, but we should not let
it hold us to worse old standards in terms of strictness.

On the contrary, I'd like to hear the upsides of keeping these defaults,
besides compatibility, as that one is easily achieved without keeping
horrid defaults

Have a most lovely evening.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

David Edelsohn  writes:

> This seems to be the core tension.  If developers cared about these issues,
> they would enable appropriate warnings and -Werror.

These issues are easy to miss and overlook.  Making them louder helps
prevent that.

Additionally, requiring the users to remember a dozen flags to make the
compiler strict rather than compatible is just terrible UX.

Today, developers need to both care and know about toolchain oddities to
effectively catch these errors, not just to care.

> The code using these idioms is not safe and does create security
> vulnerabilities.  And software security is increasingly important.
>
> The concern is using the good will of the GNU Toolchain brand as the tip of
> the spear or battering ram to motivate software packages to fix their
> problems. It's using GCC as leverage in a manner that is difficult for
> package maintainers to avoid.  Maybe that's a necessary approach, but we
> should be clear about the reasoning.  Again, I'm not objecting, but let's
> clarify why we are choosing this approach.

Both the GNU Toolchain and the GNU Toolchain users will benefit from a
stricter toolchain.

People can and have stopped using the GNU Toolchain due to lackluster
and non-strict defaults.  This is certainly not positive for the brand,
and I doubt it buys it much good will.

Depending on what exactly you mean by package maintainers, there's
already precedent on how to provide an out (and the OP talks about that
exact topic, too, as it is not something to ignore).
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Thomas Koenig via Gcc  writes:

> Not replying to anybody in particular, just a bit of history, with
> some potential parallels.
>
> In gfortran, we have had two major issues with interfaces.  One was that
> code which had happily violated the compiler ABI started failing, due
> to a fix in the gfortran front end which meant that we were no longer
> mixing varargs and non-varargs calls (which led to code being correctly
> compiled for POWER which had been miscompiled for basically forewer).
>
> Among other things, this broke R, and was fixed by Jakub by applying
> a workaround.  After a few years, people in core libraries like BLAS
> and Netlib are finally getting around to fixing their code.  There is
> no knowing what codes still have that, so the workaround will probably
> stay around forever, although we don't promise that it does.
>
> Partially motivated by this, we then added a file-level check for
> argument list mismatches (type and rank), which issued an error.
>
> That error could be disabled by a new option, -fallow-argument-mismatch,
> but that caused problems for people using different versions of the
> compiler. So we added this option to -std=legacy, which is a catch-all
> kitchen sink, which accepts some not-so-nice things.
>
> Of course, as everybody on this list knows, mixing types like this is
> dangerous, and is liable to break sooner or later in future compiler
> release. Nonetheless, even a package like MPICH chose to use autoconf
> to set the -fallow-argument-mismatch flag rather than fix the code :-(
>
> Others, like the LAPACK maintainers, have reacted and installed
> patches.
>
> So... using an error message as a crowbar to change people's behavior
> failed, at least partially.  And you only hear from the people who
> complain, not from those who are glad that they found errors that they
> would otherwise have missed.
>
> What does that mean for the case at hand?  Based on past experience,
> I'd lean towards putting all the warnings about the special offending
> codes into one warning option (-Wsevere, or something) which could
> then be made into an error by -Werror=severe or such variant; maybe
> other warnings could be grouped in there as well.  And if these severe
> warnings should then be made default or not, well... that (like the
> rest of my mail) is open for discussion.

I don't see permitting this code by default as providing any benefit,
even in a world in which we presume everyone passes -fpermissive or
such.

We should not make the default loose.  It is worse for the average
responsible developer to carry a heap of flags than it is for the
occasional irresponsible one (or a person dealing with legacy code) to
carry a single flag (or even a couple).

I can't speak on how close this is to how people will behave when
dealing with C, as I have minimal Fortran experience, but I am decently
sure that, unambiguously, these mistakes are entirely unwanted in C,
without significant upside, and so, I'm optimistic that any maintained
piece of code will soon get rid of them as a result of increasing
strictenss in GCC.

(again, this line of thought excludes the upside of compatibility with
old code as that is not particularly hard to achieve, and so I feel it
doesn't need to be considered)

> Best regards
>
>   Thomas

Thank you for your insight, have a lovely evening.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Eli Zaretskii  writes:

> It is not GCC's business to force developers of packages to get their
> act together.

Why not?  Compilers are diagnostic tools besides just machines that
guess what machine code you mean.

> It is the business of those package developers themselves.  GCC should
> give those developers effective and convenient means of detecting any
> unsafe and dubious code and of correcting it as they see fit.  Which
> GCC already does by emitting warnings.

There's a difference between dubious and unsafe code and code that is
unambiguously wrong, but was chosen to be accepted many years ago.

> GCC should only error out if it is completely unable to produce valid
> code, which is not the case here, since it has been producing valid
> code for ages.

Producing call code with wrong prototypes is not within my definition of
producing valid code.

> It is a disservice to GCC users if a program that compiled yesterday
> and worked perfectly well suddenly cannot be built because GCC was
> upgraded, perhaps due to completely unrelated reasons.

Please see the various porting-to pages.  Compilers stop being able to
produce code with older versions of programs because of them being a
lil' too lax and the programs accidentally relying on that every year.
There's nothing wrong there.

If compilers stopped being lax, such things wouldn't happen simply
because programs couldn't accidentally rely on it, so we'd get the ideal
world without breakages.  We don't get that by pretending code is fine
when it is not, and letting developers write that code.

Now, of course, this instance is different to porting-to pages, because
we aren't talking about code accidentally relying on a transitive
include or an edge case or somesuch, we're talking about the compiler
going out of its way to produce wrong code and whispering into the wind
about doing it.

> It would be a grave mistake on the part of GCC to decide that part of
> its mission is to teach package developers how to write their code and
> when and how to modify it.

It would be a grave mistake on the part of GCC to decide that part of
its mission is to pretend code is fine when it is unambiguously broken,
and then not tell people about it very loudly.

I don't think we should send out the message of "GCC: the compiler for
your untouchable legacy code, not for writing new code, or upgrading
existing code".

Providing compatibility here is a trivial job, we don't need to make
each developer suffer with tweaking compiler flags to get the compiler
to diagnose blatantly wrong code as errors, or more likely, not do it at
all because they don't know about this problem.

We could, of course, alter documentation to tell people that running GCC
in strict mode requires some concoction of flags, or we could alter it
so that it says that running GCC in a lax mode requires *one* flag, for
the exceptional case where code can't be easily fixed, and it's more
useful to pretend it's fine and emit broken calls.

We could even provide a 'laxgcc' or such driver that covers this
exceptional case OOTB (though I'm unconvinced that does anything that
setting CC='gcc -fpermissive' doesn't cover).

Have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Po Lu via Gcc  writes:

> jwakely@gmail.com (Jonathan Wakely) writes:
>
>> This isn't "be like Clang", this is "diagnose things that have been
>> invalid C since 1999".
>
> Only if your definition of valid C is ``strictly conforming to the ISO
> Standard''.  I doubt there are many programs which fit such a
> definition.
>
> And anyway, GCC accepts many other constructs which can not be used in a
> strictly conforming Standard C programs.  For example, the use of dollar
> signs in identifiers.  Should we not also reject those, identifier names
> with external linkage longer than thirty two characters, hex floats,
> arithmetic on void pointers, zero-length arrays, statement expressions,
> and so on?

None of these result in a whisper-level warning before a severe but
difficult to detect breakage.

>> Accepting invalid code by default is a disservice to users. Those who
>> need to compile invalid C code can use an extra option to allow it,
>> the default should be to tell users their code is doing something bad.
>
> The code is conforming, it simply relies on extensions to the Standard.
> Implicit int does not break any strictly conforming program, so a C
> implementation implemented it continues to be conforming, along with
> those programs relying on implicit int.  See this wording in the
> Standard:

All of the features in question actively break programs (because they
allow entirely wrong code to be emitted).

>   A conforming implementation may have extensions (including additional
>   library functions), provided they do not alter the behavior of any
>   strictly conforming program.
>
> You are not trying to reject non-conforming C code.  You are, for better
> or worse, trying to impose your personal preferences on users of GCC.

> Let's debate the real problem at hand instead of using the Standard as a
> boogeyman: namely, whether or not disabling implicit-int in GCC 14 is a
> good idea.

It is.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Po Lu via Gcc  writes:

> Jonathan Wakely via Gcc  writes:
>
>> On Wed, 10 May 2023, 03:32 Eli Zaretskii,  wrote:
>>
>>>
>>> And then people will start complaining about GCC unnecessarily
>>> erroring out, which is a compiler bug, since there's no problem
>>> producing correct code in these cases.
>>>
>>
>>
>> What is the correct code for this?
>>
>> void foo(int);
>> void bar() { foo("42"); }
>>
>> Why should this compile?
>
> Because keeping that from compiling will also keep this from compiling:
>
> bar ()
> {
>   extern foo ();
>
>   return foo ("42");
> }

Good.  The above code is nonsense, the chances that foo will be
incorrectly called are high.

>> You keep demanding better rationale for the change, but your argument
>> amounts to nothing more than "it compiles today, it should compile
>> tomorrow".
>
> And so it should.  Because for every invalid piece of code you can think
> of, there are hundereds or thousands of combinations that may as well be
> valid.  For example, on the 68020, vax, or similarly reasonable 32-bit
> machine:
>
> foo (ptr)
> {
>   register char *str;
>
>   str = ptr;
>
>   /* do stuff with str */
>
>   puts (str);
> }
>
> /* In another translation unit.  */
>
> bar ()
> {
>   foo ("42");
> }

What is this meant to produce?

This is, at best, a "works by coincidence", rather than being code
anyone should be writing.

Such code is already written, when building it, pass -fpermissive.
You benefit from the error otherwise.

(and no, this isn't an issue of style, the code in question *does not*
convey sufficient information for the compiler to always do the right
thing)

Have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Po Lu  writes:

> Arsen Arsenović  writes:
>
>> Good.  The above code is nonsense, the chances that foo will be
>> incorrectly called are high.
>
> Yet lint (or scrutiny, as should be performed with any declaration,
> implicit or not) makes sure that does not happen.

Relying on human scrutiny when an algorithm can trivially deduce an
answer more quickly and more reliably (because even in the case that the
code you showed compiles, it assumes processor specific facts) has
historic precedent as being a bad idea.

I'm curious, though, about how lint checks for this.

>> What is this meant to produce?
>
> It was just an example.  I'm not allowed to show any real code.
>
>> This is, at best, a "works by coincidence", rather than being code
>> anyone should be writing.
>
> See what I said about being the judge, jury and executioner.
>
>   (BTW, I thought implicit int was being discussed, not implicit
>function declarations, but here goes.)
>
> The same problems will appear with _any_ extern declaration.  If you
> remove implicit function declarations, people will simply paste:
>
>   extern int foo ();
>
> above the code which no longer compiles.
> Or, if you force everyone to use prototypes,
>
>   extern int foo (char *);

So be it.  The edge case still exists.  The normal case that I expect
most code is dealing with is much simpler: a missing include.  That case
is not discounted by the existence of misdeclarations across TUs.

> You will not be able to diagnose whether or not this declaration is
> correct, because the definition will lie in another translation unit.
> Except that in this case, no diagnostic will be issued at all when
> the declared function is called.
>
> The only place where you can truly fix mismatched declarations is the
> linker (or collect2?)  GCC proper cannot do anything about it.

There's already -Wlto-type-mismatch.  It has spotted a few bugs in my
own code.

>> Such code is already written, when building it, pass -fpermissive.
>> You benefit from the error otherwise.
>>
>> (and no, this isn't an issue of style, the code in question *does not*
>> convey sufficient information for the compiler to always do the right
>> thing)
>
> It does on reasonable machines for which the code was written.  I gave
> two examples.  Perhaps the 386 is another.

Yes, indeed.  And code should keep working on those machines, because it
costs little to nothing to keep it working.  And it will if you pass
-fpermissive.

It seems to me plausible that the paragraph in the original proposal
that suggested -fpermissive might have been missed.

It is unfeasible for GCC to entirely stop compiling this code, there's
nobody that is advocating for doing that; however, the current default
of accepting this code in C is harmful to those who are writing new
code, or are learning C.

This seems like a good route to me - it facilitates both veterans
maintaining code and beginners just learning how to write C.

Have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Eli Zaretskii  writes:

>> Cc: Jonathan Wakely , gcc@gcc.gnu.org
>> Date: Thu, 11 May 2023 10:44:47 +0200
>> From: Arsen Arsenović via Gcc 
>> 
>> the current default of accepting this code in C is harmful to those
>> who are writing new code, or are learning C.
>
> People who learn C should be advised to turn on all the warnings, and
> should be educated not to ignore any warnings.  So this is a red
> herring.

Indeed they should be - but warning vs. error holds significance.  A
beginner is much less likely to be writing clever code that allegedly
uses these features properly than to be building new code, and simply
having made an error that they do not want and will suffer through
confused.

>> This seems like a good route to me - it facilitates both veterans
>> maintaining code and beginners just learning how to write C.
>
> No, it prefers beginners (which already have the warnings, unless they
> deliberately turn them off) to veterans who know what they are doing,
> and can live with those warnings.

Indeed.  I said facilitates, not treats equally.  I think the veterans
here won't lose much by having to pass -fpermissive, and I think that's
a worthwhile sacrifice to make, to nurture the new without pressuring
the old very much.

> The right balance is exactly what we have now: emitting warnings
> without breaking builds.

I disagree - I think breaking builds here (remember, it takes 13 bytes
to fix them) is a much lower weight than the other case being shot in
the foot for an easily detectable and treatable error being made easily
missable instead, so I reckon the scale is tipped heavily towards the
veterans.

On that note - lets presume a beginners role.  I've just started using
GCC.  I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out.  It
mentions some 'implicit function generation', dunno what that means - if
it mattered much, it'd have been an error.  I wrote a function called
test that prints the int it got in hex, but I called it with 12.3, but
it printed 1.. what the heck?

Why that happened is obvious to you and I (if you're on the same CPU as
me), but to a beginner is utter nonsense.

At this point, I can only assume one goes to revisit that warning..  I'd
hope so at least.

I doubt the beginner would know to pass
-Werror=implicit-function-declaration in this case (or even about
Werror...  I just told them what -Wall and to read the warnings, which
was gleefully ignored)

Anyway - I'm not making that up - this circle of 'yeah the warnings
actually matter.. a lot' has happened with everyone I've tutored that
has had little to no contact with programming before (those who had more
contact have a higher respect for the word 'warning'), and it will keep
happening.

Hell, I've seen professors do it, and for a simple reason: they knew how
to write code, not how to use a compiler.  That's a big gap.

The beginner here can't adapt - they don't know what -Wall means, they
just pass it because they were told to do it (if they're lucky!).

At the same time, they lose out on what is, IMO, one of the most useful
pieces of the toolchain: _FORTIFY_SOURCE (assuming your vendor enables
it by default.. we do).  It provides effective bug detection, when the
code compiles right.  It regularly spots bugs that haven't happened yet
for me.

(and same goes for all the other useful analysis the toolchain can do
when it has sufficient information to generate correct code, or more;
some of which can't reasonably be a default)

(on a related note, IMO it's a shame that the toolchain hides so many
possibilities behind 'cult knowledge', depths of many manuals and bad
defaults)

On the other hand... I've been writing C for a long time, and you have
been doing so for a longer time.  We see 'error: ...' in an old codebase
for a pedantic (rather, by my definition, bare essential) check and we
know where to look to fix it or ignore it.

I build old, unfamiliar codebases all the time, and I've been using a
modified toolchain that enables the error proposed today for a while; my
peers and I, who are proposing this, have gone over thousands of old
codebases, I've fixed some personally, yet the percentage of those that
have been full-out broken by this change is small (configure scripts are
almost all of it, too; Po has mentioned that they use a laxer compiler
for those - we (Gentoo) test two compilers in order to detect when these
differences happen, but keep the results of the laxer one, and then try
to fix the code upstream - often it comes down to just running autoconf
-f, even).

This sample is subject to selection bias.  My testing targets mostly
more modern codebases that have long fixed these errors (if they have
active maintainers), and exclusively Free Software, so I expect that the

Re: Wish: scoped enum

[Arsen Arsenović via Gcc]

Hi,

Yair Lenga via Gcc  writes:

> I wonder if it will be possible to add support for "scoped" enum to GCC.
> The current C standard has one name space for all enums, and different name
> space for the members of each "struct". As a result, possible to say
>
> struct foo { int a } ;
> struct bar { double a }; // This is different 'a', different type
>
> But illegal to to (ignoring the conversion to use all upper for enum).
>
> enum a { u, v } ;
> enum b { v, w } ; // can not do this, as 'v' must be distinct
>
> One annoying side effect is that any package/module creating an enum has to
> worry about namespace collision with everyone else in the world. Common
> practices include distinct prefixes, similar to the way different libraries
> use distinct prefixes to avoid function name collision. This solution is
> far from perfect and leads to excessive long enum name.
>
> A reasonable wish list - add a magic keyword that will place the enums into
> a scope, so that the following work:
>
> SCOPED enum shirt_sz { small, medium, large } ;
> SCOPED enum shoe_sz { small, medium, medium_wide, large, xlarge } ;
>
> enum shirt_sz tshift_size = shift_sz.medium ;
> enum shoe_siz boot_size = shoe_sz.xlarge ;
>
> Not perfect, but not complex, will make enum reusable across many scenario,
> where they are currently hard to implement - because of namespace conflict
> - between system header and user headers, between different packages.
>
> A smart compiler can also alert when "types" are mixed (assign value from
> shift_sz to a variable of type shoe_sz). Not critical - as my understanding
> is that this is not enforced today. For the case that an enum symbol is
> distinct (in the current compilation unit), the compiler can allow using it
> without the namespace - practically falling back into current behavior.
>
> Feedback ? Anyone know how to get a prototype into gcc ? How one get
> approval for such "extensions".

I'd suggest, if you choose to implement this, to imitate what C++ does
for these, maybe even propose it for the standard.  There's already
established syntax and semantics.

It would certainly be nice to have such a thing in C.

Have a lovely evening.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Po Lu via Gcc  writes:

...

> Where is it written that GNU CC follows your so-called
> ``specification-driven development''?

Any development style making documentation a source of truth matches
this principle.  This does not refer to ISO specifications specifically,
though, normally, unless the standard disagrees with reality, as
implicit-... did many years ago, ISO decisions are taken seriously.

> Here is an explanation from one of the original GCC developers.  It
> discusses strict aliasing, but the same principles apply here:
>
> (199909100634.caa01...@psilocin.gnu.org)
>
>   My comment is similar to Mark's comment.  Documentation, what can
>   we document as working?
>
>   We should not even try to document that these cases work.
>   Documentation is what we do when we add a feature.
>
>   I am not proposing this as a feature, just as a way to avoid evitable
>   trouble for users.  We should not even try to document a class of
>   cases that are "supposed" to work, because I'm not saying these are
>   "supposed" to work.  We should just let them work.
>
>
>   Anway, more questions from me than answers...  Off hand though, if
>   we can make the compiler generate `right' code in more cases, even
>   if the users code is wrong, I think we should probably do it.
>
>   In C, we cannot divide all user code into "right" and "wrong" in this
>   kind of simple way, and certainly not based on the ISO standard.  That
>   standard is just the decisions of a certain committee (which I was a
>   member of) about what cases conforming compilers should commit to
>   support.  We must not let ourselves start thinking that C code is
>   "wrong", just because it is not conforming ISO C code.
>
>   C programs use many cases that are not conforming, but do work.  This
>   will be true for as long as C is used, because changing it would
>   require major changes in the C language.
>
>   From time to time, there is a real *need* to make some of these cases
>   stop working, for the sake of some benefit that users want.  When this
>   happens, we should do it; the user community will accept it, because
>   they will see that it is being done for their sake.  Some will
>   grumble, but the users who appreciate the benefits will convince them.
>
>   But when there is no *need* to break these cases, when we can keep
>   them working fairly easily, we should keep them working.  If we break
>   them unnecessarily, we invite the legitimate anger of the users.
>
> and another (199909100634.caa01...@psilocin.gnu.org):
>
>   However, I have a rather serious objection: it means that users
>   cannot tell whether their code is valid, even according to the GCC
>   rules, without knowing the internals of the compiler.
>
>   This has always been true.  It is true in the current version of GCC
>   with regard to aliasing, even when -fstrict-aliasing is used.  It is
>   part of the nature of C.
>
>   The goal of trying to avoid it is unrealistic and misguided; it can't
>   be done.  So this cannot be a valid reason to reject a change.
>
>   The compiler should continue to aggressively break code that
>   misbehaves in this way.
>
>   This proposes to break users' code, just to bully them into changing
>   it.  That is a callous and harsh attitude towards the users of GCC.
>   No wonder users are angry.  They know that the problems are not due to
>   necessity, but due to callous disregard for them.
>
>   We cannot do everything all users want, and sometimes a maintainer has
>   to say no to users.  "You cannot please everyone," as the saying goes.
>   There are many kinds of reasons which can sometimes be good reasons to
>   say no.
>
>   But maintainers should always say no reluctantly--never eagerly.  We
>   should never aggressively cause trouble for users today, just because
>   someday it might be necessary.  That is like amputating limbs because
>   someday they might be crushed.
>
>   This treatment of users brings shame on the GNU Project.  I ask
>   everyone therefore not to suggest that we should treat users this way.
>
>> Sound familiar? A bit like GCC triggering a warning, telling you that
>> what you're doing is bad and should not be relied on?
>
> A diagnostic message is supposed to inform me of a diagnosis by the
> translator.  The severity of the diagnosis, is, as always, up to the
> user to decide, as long as enough information remains for translation to
> continue.

It is, after this proposal is accepted, still up to the user to decide.
The only difference is that the default would be friendlier to new code
and users and most code that exists today, rather than to very old code
and incorrect code.

Additionally, there isn't enough information to compile.  The compiler
makes up new information to fill in the gaps.

If that definition accepted, most error recovery should be turned into
valid code paths that participate as GNU exte

Re: LSP based on GCC

[Arsen Arsenović via Gcc]

David Malcolm  writes:

> [...snip...]
> I wrote that prototype, but I haven't touched it since 2017, and I
> already have more than enough other work, alas.  I'm happy to help if
> someone wants to pick up the work and finish it.
>
> That patch kit did several things:
> (a) adds a new "on the side" representation of source code locations
> (b) adds a JSON implementation to gcc
> (c) implements an LSP server on a port, implementing only the
> "textDocument/definition" method.
>
> Not having quite enough source code location is a pet peeve of mine
> within GCC's intermediate representation, as we lose a fair bit of
> location information as we go from frontends to the tree/generic
> representation (e.g. "exactly where was each brace?").

You mentioned 'cousin' tools in your original post, and I largely agree
with your sentiment.  Many parts of the job of an FE can be reused for
many other purposes, evidently.  Even beyond an LSP implementation.

> Unfortunately the particular approach I came up with in (a) was
> rejected by frontend maintainers, so I abandoned that part of the
> work.

I couldn't find the relevant messages.  Mind sharing a message-id or
archive link?

> The part of (b) for storing JSON trees in memory and writing them out
> is in GCC's source tree; the JSON-parsing code isn't yet, but I have a
> relatively up-to-date refreshed version of that code in one of my
> working copies which I can post to the list if it will be helpful.
>
> As for (c), doing it on a port is probably wrong, and working with
> stdin/stdout seems a much better approach.

AIUI, many editors (including Emacs' Eglot) also expect this (but I
suspect many can leverage other methods of connecting too).


ISTR Alexandre Oliva (CC added) mentioning leveraging GDB to implement
various bits of LSP functionality, such as handling multiple TUs.  This
sounds like a good idea to me (at least at a high level), as it could
lead to the hypothetical GNU toolchain LSP implementation being
partially language-agnostic (naturally, some things like candidate lists
would still need language support, as well as documentation parsing,
...), which would be quite handy.

Do you happen to have any memory of that?

Thanks in advance, have a lovely evening.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Will GCC eventually learn to use BSR or even TZCNT on AMD/Intel processors?

[Arsen Arsenović via Gcc]

David Edelsohn  writes:

> The GNU Toolchain leadership has blacklisted people in the past, but we
> have used the power sparingly.
>
> The behavior of the individual attracts attention, albeit negative, while
> not effectively accomplishing what he purports to desire.  The recommended
> solution is to ignore the poster instead of trying to encourage him to
> communicate more effectively.

IMO, the sparing usage of this power on what are clearly purely abusive
participants can only drive away users and contributors.  It seems
reasonable to establish a process for dealing with incidents like this
(and appeals, of course), especially given their frecency.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Please stop blocking xstyle/stylish

[Arsen Arsenović via Gcc]

zxuiji via Gcc  writes:

> Your site is far too bright and is absolutely painful to the eyes, I
> have a simple invert style that I expected to work on all sites and I
> found your site is undertaking the vile act of blocking user styles. I
> expect that sort of rotten design from microsoft & apple (which
> ironically don't), not from a site that is supposed to be on the user
> freedom of choice side of the spectrum.

We don't block either.  Something else is afoot.

As a test, I set:

  * {
  background-color: red;
  }

... in Stylus locally, and it worked fine.

What lead you to believe that it's blocked on the site (and which site
do you mean, precisely)?

Hope I can help, have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Request for Software Usage License

[Arsen Arsenović via Gcc]

孟祥龙  writes:

> Dear Teacher,
>
>
> I hope this email finds you well.  I am writing to kindly request a software
> usage license for the GCC for our research and development activities.  We
> believe that this software would greatly contribute to our work and enable us
> to achieve our research goals more effectively.
>
>
> Given the nature of our projects and our commitment to advancing knowledge, 
> we are excited about the potential of incorporating this software into our 
> workflow.
>
>
> We assure you that the software will be used strictly for non-commercial 
> research purposes.  We are prepared to comply with any terms and conditions 
> outlined by the software provider regarding its usage and dissemination of 
> results.
>
>
> If possible, we kindly request information about the licensing process, any 
> associated costs, and the steps required to acquire the license.  We 
> appreciate your consideration of our request and would be grateful for any 
> guidance you can provide in this matter.
>
>
> Thank you for your attention to this request.  We look forward to your 
> response.

Hi,

GCC is Free Software, as such you can use it for any purpose, commercial
or otherwise.  See https://www.gnu.org/philosophy/free-sw.html for a
description of what free software is.

In particular, GCC is licensed under the GNU GPL version 3, or any later
version[1], with some bits of code also being under the GCC Runtime
Libraries Exception[2] or the GNU Lesser GPL version 3, or any later
version[3].

I must personally ask that you consider also releasing your work as free
software, and to support free software development and free systems, but
you're not under obligation to do so.

Please see the license texts for a description of your rights and
obligations.

[1] https://www.gnu.org/licenses/gpl-3.0.html
[2] https://www.gnu.org/licenses/gcc-exception-3.1.html
[3] https://www.gnu.org/licenses/lgpl-3.0.html

Hope that helps, have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Report from the additional type errors for GCC 14 BoF at Cauldron

[Arsen Arsenović via Gcc]

Sam James via Gcc  writes:

> Florian Weimer via Gcc  writes:
>
>> My understanding of the consensus goes as follows:
>>
>> * We want to make some changes in this area for GCC 14.
>> * We should do the same thing that Clang does: default to the relevant
>>   -Werror= options.
>> * Unlike regular warnings, these warnings-as-errors should also apply
>>   to system headers.
>> * At least implict-int and implicit-function-declaration should be
>>   upgraded to errors in this way.
>> * It's too early to make the () changes and bool-as-keyword from C2X
>>   for GCC 14.
>> * We should fix the missing scope of the int-conversion warnings
>>   (PR109827).  Likweise for incompatible-pointer-types (PR109826).
>>
>> Is this summary accurate?
>>
>
> I wasn't there, but this reflects my understanding & what I would've
> said if I could've attended.
>
>> I think the open issues are:
>>
>> * Do we want to implement something else beside implicit-int and
>>   implicit-function-declaration?  (Candidates are int-conversion and
>>   incompatible-pointer-types, and the void vs non-void part of
>>   return-type, maybe others as previously discussed on the list.)
>
> Ideally, I'd like both int-conversion + incompatible-pointer-types in
> this cycle, but if we have to defer one, I'd say to keep int-conversion.

+1, this seems reasonable.  I'm not sure I can imagine any even
half-legitimate use for falling off the end of functions and similar, so
perhaps we should also take return-type?  Is that part of C23?

> A lot of the low hanging fruit is already fixed there, with the only
> big remaining blocker being Vala (which is a
> compiler/transpiler). They've indicated they're not that fussed
> unless/until GCC changes.
>
> Putting it another way: I don't think waiting a year or two
> would actually help the situation much.

Yes, at best it helps with the schedule.

>> * How do we divide up the test suite cleanup work?
>
> Once there's some patches to work with, I'm happy to do a good
> chunk (obviously).
>
> IIRC Jakub and others indicated that the priority is to preserve
> the test cases (and hence pass appropriate flags) rather than fix them
> up, to avoid inadvertently testing the wrong thing.

We could possibly even automate that, by checking what new errors
appeared per testcase and inverting them.

>>
>> Thanks,
>> Florian


-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Scaling -fmacro-prefix-map= to thousands entries

[Arsen Arsenović via Gcc]

Hi,

Sergei Trofimovich via Gcc  writes:

> Sounds good. Do you have any preference over specific syntax? My
> suggestions would be:
>
> 1. `-fmacro-prefix-map=file-name`: if `file-name` there is not in `key=val`
>format then treat it as file
> 2. `-fmacro-prefix-map=@file-name`: use @ as a signal to use file
> 3. `fmacro-prefix-map-file=file-name`: use a new option
>
>> Btw, I thought we have response files to deal with command-line limits,
>> why doesn't that work here?  I see the driver expands response files
>> but IIRC it also builds those when the command-line gets too large
>> and uses it for the environment and the cc1 invocation?  If it doesn't
>> do the latter why not fix it that way?
>
> Yeah, in theory response files would extend the limit. In practice `gcc`
> always extends response files internally into a single
> `COLLECT_GCC_OPTIONS` option and hits the environment variable limit
> very early:
>
> https://gcc.gnu.org/PR111527

Doesn't it make more sense to fix this?  The issue is more general than
just this option (even if manifesting like so today).

Can the COLLECT_GCC_OPTIONS consumers deal with argfiles?

> Example reproducer:
>
> $ for i in `seq 1 1000`; do printf -- "-fmacro-prefix-map=%0*d=%0*d\n" 
> 200 1 200 2; done > a.rsp
> $ touch a.c; gcc @a.rsp -c a.c
> gcc: fatal error: cannot execute 'cc1': execv: Argument list too long
> compilation terminated.
>
> And if you want to look at the gory details:
>
> $ strace -f -etrace=execve -s 100 -v -v -v  gcc @a.rsp -c a.c
> ...
> [pid78] execve("cc1", ["cc1", "-quiet", "a.c", "-quiet", "-dumpbase", 
> "a.c", "-dumpbase-ext", ".c", "-mtune=generic", "-march=x86-64",
> "-fmacro-prefix-map=...=...",
> "-fmacro-prefix-map=...=...",
> ...],
> [...,
>  "COLLECT_GCC=gcc",
>  "COLLECT_GCC_OPTIONS='-fmacro-prefix-map=...=...' 
> '-fmacro-prefix-map=...=...' ... '-c' '-mtune=generic' '-march=x86-64'"]) = 
> -1 E2BIG (Argument list too long)
>
> Note how `gcc` not only expands response file into an argument list
> (that is not too bad) but also duplicates the whole list as a single
> `COLLECT_GCC_OPTIONS=...` environment variable with added quoting on
> top.
>
> Would be nice if `gcc` just passed response files around as is :)


-- 
Arsen Arsenović


signature.asc
Description: PGP signature

libstdc++ -> libiconv depenedncy: implications on in-tree libiconv

[Arsen Arsenović via Gcc]

Evening!

While working on

  https://inbox.sourceware.org/20240414001113.1698685-1-ar...@aarsen.me/

I had noticed that libstdc++ currently does not get linked against an
in-tree libiconv, as the in-tree libiconv is only a host library.
Should it also be a target one?

With a quick hack of copying libiconv in the build dir as
arm64-apple-darwin21.6.0/libiconv, I had managed to get libstdc++ not to
link system libiconv.  This implies that simply enabling building iconv
as a target library also would suffice.

There are considerations with this, though:  naturally, this implies
that libstdc++ now contains a copy of libiconv as it gets linked in as a
'.a'.  It appears not to cause a copy of the symbols to be emitted on
this platform:

  cfarm104:gcc-build arsen$ objdump --syms 
./aarch64-apple-darwin21.6.0/libstdc++-v3/src/.libs/libstdc++.6.dylib | grep 
iconv
  cfarm104:gcc-build arsen$

... however, even in that case, the symbols are renamed AFAICT:

  cfarm104:gcc-build arsen$ objdump --syms 
./aarch64-apple-darwin21.6.0/libiconv/lib/.libs/libiconv.a | grep iconv
  ./aarch64-apple-darwin21.6.0/libiconv/lib/.libs/libiconv.a(iconv.o):  file 
format mach-o arm64
  000dbbe0 g O __DATA,__data __libiconv_version
  00013730 g F __TEXT,__text _iconv_canonicalize
  00013080 g F __TEXT,__text _libiconv
  000130c0 g F __TEXT,__text _libiconv_close
  00012ca0 g F __TEXT,__text _libiconv_open
  000130e0 g F __TEXT,__text _libiconv_open_into
  00013468 g F __TEXT,__text _libiconvctl
  000135ac g F __TEXT,__text _libiconvlist
  ./aarch64-apple-darwin21.6.0/libiconv/lib/.libs/libiconv.a(localcharset.o):   
file format mach-o arm64
  ./aarch64-apple-darwin21.6.0/libiconv/lib/.libs/libiconv.a(relocatable.o):
file format mach-o arm64
  00e4 g F __TEXT,__text _libiconv_relocate
  01e0 g F __TEXT,__text _libiconv_relocate2
   g F __TEXT,__text _libiconv_set_relocation_prefix

... so, that might be okay?

What do you think?  Should be build a libiconv as a target lib for
libstdc++ use?

TIA, have a lovely night!
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [RFC] MAINTAINERS: require a BZ account field

[Arsen Arsenović via Gcc]

Hi,

Sam James via Gcc  writes:

> Hi!
>
> This comes up in #gcc on IRC every so often, so finally
> writing an RFC.
>
> What?
> ---
>
> I propose that MAINTAINERS be modified to be of the form,
> adding an extra field for their GCC/sourceware account:
>account>
>   Joe Bloggsjoeblo...@example.com  jblo...@gcc.gnu.org
>
> Further, that the field must not be blank (-> must have a BZ account;
> there were/are some without at all)!
>
> Why?
> ---
>
> 1) This is tied to whether or not people should use their committer email
> on Bugzilla or a personal email. A lot of people don't seem to use their
> committer email (-> no permissions) and end up not closing bugs, so
> pinskia (and often myself these days) end up doing it for them.
>
> 2) It's standard practice to wish to CC the committer of a bisect result
> - or to CC someone who you know wrote patches on a subject area. Doing
> this on Bugzilla is challenging when there's no map between committer
> <-> BZ account.
>
> Specifically, there are folks who have git committer+author as
> joeblo...@example.com (or maybe even coold...@example.com) where the
> local part of the address has *no relation* to their GCC/sw account,
> so finding who to CC is difficult without e.g. trawling through gcc-cvs
> mails or asking overseers for help.

I was also proposing (and would like to re-air that here) enforcing that
the committer field of each commit is a (valid) @gcc.gnu.org email.
This can be configured repo-locally via:

  $ git config committer.email @gcc.gnu.org

Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d
(v2.22.0).

This makes a permanent association of each commit to its authors
Sourceware account.

This should not inhibit pushes, as the committer should be a reflection
of who /applied/ a patch, and anyone applying a patch that can also push
has a Sourceware account.  It also should not inhibit any workflow, as
it should be automatic.

> Summary
> ---
>
> TL;DR: The proposal is:
>
> 1) MAINTAINERS should list a field containing either the gcc.gnu.org
> email in full, or their gcc username (bikeshedding semi-welcome);
>
> 2) It should become a requirement that to be in MAINTAINERS, one must
> possess a Bugzilla account (ideally using their gcc.gnu.org email).

-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [RFC] MAINTAINERS: require a BZ account field

[Arsen Arsenović via Gcc]

Hi,

Andrew Stubbs  writes:

> On 24/06/2024 23:34, Arsen Arsenović via Gcc wrote:
>> I was also proposing (and would like to re-air that here) enforcing that
>> the committer field of each commit is a (valid) @gcc.gnu.org email.
>> This can be configured repo-locally via:
>>$ git config committer.email @gcc.gnu.org
>> Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d
>> (v2.22.0).
>> This makes a permanent association of each commit to its authors
>> Sourceware account.
>> This should not inhibit pushes, as the committer should be a reflection
>> of who /applied/ a patch, and anyone applying a patch that can also push
>> has a Sourceware account.  It also should not inhibit any workflow, as
>> it should be automatic.
>
> This will make it hard to a) find emails from a maintainer/committer in the
> mailing list archives -- since it's not generally possible to send "From:" a
> @gcc.gnu.org address -- and b) make it hard to compile statistics about
> contributions from corporate domains (which people do do).

I'm not sure that is the case - the committer field is separate to the
author field, so all statistics one could do with the author field
remain unaltered.  For instance (as I've been doing that for a while),
here's what a commit of mine looks like under that scheme:

  commit 36cb7be477885a2464fe9a70467278c7debd5e79
  Author: Arsen Arsenović 
  AuthorDate: Thu Nov 16 23:50:30 2023 +0100
  Commit: Arsen Arsenović 
  CommitDate: Wed Dec 13 13:17:35 2023 +0100

  gettext: disable install, docs targets, libasprintf, threads

More often than not, the committer field is redundant with the author
field.

The email I use for correspondence is still present (and, in fact, is
the only one visible with the default git log and show formats).

It is possible that someone could be doing statistics based on the
committer field, if they also want to, say, count patches applied by
members of some company, but I'm not sure how wide-spread that is.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [RFC] MAINTAINERS: require a BZ account field

[Arsen Arsenović via Gcc]

Hi,

Richard Biener  writes:

> [snip]
>> I was also proposing (and would like to re-air that here) enforcing
>> that the committer field of each commit is a (valid) @gcc.gnu.org
>> email.  This can be configured repo-locally via:
>>
>>   $ git config committer.email @gcc.gnu.org
>>
>> Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d
>> (v2.22.0).
>>
>> This makes a permanent association of each commit to its authors
>> Sourceware account.
>
> I'd welcome this - care to create a patch for
> contrib/gcc-git-customization.sh?

Sure - I've attached a partial patch.  I didn't find the hook which runs
on each push to check commits, so the current patch is minimal.  Is that
also in the tree?  I could try hacking it to check commits.
-- 
Arsen Arsenović
From c7ca9e26693a707a0aa9f87aeb35717f5fecdc79 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Arsen=20Arsenovi=C4=87?= 
Date: Tue, 25 Jun 2024 20:57:34 +0200
Subject: [PATCH] git-customizations: set committer email to @gcc.gnu.org email

See discussion at
https://inbox.sourceware.org/gcc/87y16uowix@gentoo.org/

contrib/ChangeLog:

* gcc-git-customization.sh: Set committer.email to
remote...@gcc.gnu.org.
---
 contrib/gcc-git-customization.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/gcc-git-customization.sh b/contrib/gcc-git-customization.sh
index 54bd35ea1aab..9e23e71f4204 100755
--- a/contrib/gcc-git-customization.sh
+++ b/contrib/gcc-git-customization.sh
@@ -129,6 +129,7 @@ fi
 
 ask "Account name on gcc.gnu.org (for your personal branches area)" 
"$remote_id" remote_id
 git config "gcc-config.user" "$remote_id"
+git config "committer.email" "${remote_id}@gcc.gnu.org"
 
 old_pfx=$(git config --get "gcc-config.userpfx")
 if [ "x$old_pfx" = "x" ]
-- 
2.45.2



signature.asc
Description: PGP signature

Re: [RFC] MAINTAINERS: require a BZ account field

[Arsen Arsenović via Gcc]

Hi,

Thomas Koenig via Gcc  writes:

> Am 25.06.24 um 21:08 schrieb Arsen Arsenović via Gcc:
>
>> Richard Biener  writes:
>
>>> I'd welcome this - care to create a patch for
>>> contrib/gcc-git-customization.sh?
>> Sure - I've attached a partial patch.  I didn't find the hook which runs
>> on each push to check commits, so the current patch is minimal.  Is that
>> also in the tree?  I could try hacking it to check commits.
>
> Will this also influence commits to, for example, github?

In the sense that their contents will be changed, yes - commits are
independent of remote, so their committer field is common for all
remotes.  However, since only the committer field changes, and usually
commits are tracked by the author field, that might not be too big of an
issue.  I've been pushing to SourceHut and GitHub with a committer.email
set to arsen at gcc dot gnu dot org for a while now, here are example
commits from both:

https://git.sr.ht/~arsen/gcc/commit/0290e3ce8c017701bc5f665daf5ea438b3cd996f
https://github.com/ArsenArsen/gcc/commit/ee6cc90

Note that, in the latter, GitHub attributes the commit to a non-GitHub
account as committer, but it is still attributed to my account by
author, if that is of concern.  Note also that GH verifies GPG by
*committer* (which makes sense..).  This is why it states that my commit
is unverified - I never added my sourceware/gcc.gnu.org email to GH.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [RFC] MAINTAINERS: require a BZ account field

[Arsen Arsenović via Gcc]

Hi,

"Richard Earnshaw (lists)"  writes:

> On 24/06/2024 23:34, Arsen Arsenović via Gcc wrote:
>> Hi,
>> 
>> Sam James via Gcc  writes:
>> 
>>> Hi!
>>>
>>> This comes up in #gcc on IRC every so often, so finally
>>> writing an RFC.
>>>
>>> What?
>>> ---
>>>
>>> I propose that MAINTAINERS be modified to be of the form,
>>> adding an extra field for their GCC/sourceware account:
>>>   >> sourceware account>
>>>   Joe Bloggsjoeblo...@example.com  jblo...@gcc.gnu.org
>>>
>>> Further, that the field must not be blank (-> must have a BZ account;
>>> there were/are some without at all)!
>>>
>>> Why?
>>> ---
>>>
>>> 1) This is tied to whether or not people should use their committer email
>>> on Bugzilla or a personal email. A lot of people don't seem to use their
>>> committer email (-> no permissions) and end up not closing bugs, so
>>> pinskia (and often myself these days) end up doing it for them.
>>>
>>> 2) It's standard practice to wish to CC the committer of a bisect result
>>> - or to CC someone who you know wrote patches on a subject area. Doing
>>> this on Bugzilla is challenging when there's no map between committer
>>> <-> BZ account.
>>>
>>> Specifically, there are folks who have git committer+author as
>>> joeblo...@example.com (or maybe even coold...@example.com) where the
>>> local part of the address has *no relation* to their GCC/sw account,
>>> so finding who to CC is difficult without e.g. trawling through gcc-cvs
>>> mails or asking overseers for help.
>> 
>> I was also proposing (and would like to re-air that here) enforcing that
>> the committer field of each commit is a (valid) @gcc.gnu.org email.
>> This can be configured repo-locally via:
>> 
>>   $ git config committer.email @gcc.gnu.org
>> 
>> Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d
>> (v2.22.0).
>> 
>> This makes a permanent association of each commit to its authors
>> Sourceware account.
>> 
>> This should not inhibit pushes, as the committer should be a reflection
>> of who /applied/ a patch, and anyone applying a patch that can also push
>> has a Sourceware account.  It also should not inhibit any workflow, as
>> it should be automatic.
>
>
> I think this presumes a strict 'git apply' model for incorporating patches 
> from
> mailing lists, but what about contributors who do not have a sourceware 
> account
> and rely on another developer to fetch from their tree and push it afterwards
> (eg the linux bubble-up model)?  In that case the patch fetched will show the
> original author as the committer.

Right - that is a problem that I didn't think of..  A soft requirement
is better here for that reason.

Thanks for pointing it out.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: [RFC] MAINTAINERS: require a BZ account field

[Arsen Arsenović via Gcc]

"Richard Earnshaw (lists)"  writes:

> On 25/06/2024 20:08, Arsen Arsenović via Gcc wrote:
>> Hi,
>> 
>> Richard Biener  writes:
>> 
>>> [snip]
>>>> I was also proposing (and would like to re-air that here) enforcing
>>>> that the committer field of each commit is a (valid) @gcc.gnu.org
>>>> email.  This can be configured repo-locally via:
>>>>
>>>>   $ git config committer.email @gcc.gnu.org
>>>>
>>>> Git has supported this since 39ab4d0951ba64edcfae7809740715991b44fa6d
>>>> (v2.22.0).
>>>>
>>>> This makes a permanent association of each commit to its authors
>>>> Sourceware account.
>>>
>>> I'd welcome this - care to create a patch for
>>> contrib/gcc-git-customization.sh?
>> 
>> Sure - I've attached a partial patch.  I didn't find the hook which runs
>> on each push to check commits, so the current patch is minimal.  Is that
>> also in the tree?  I could try hacking it to check commits.
>
> This won't work for developers who don't have a gcc account.  Previously it 
> didn't matter what you said here, but now it will mess up any personal tree 
> you have.
>
> +git config "committer.email" "${remote_id}@gcc.gnu.org"

You're right - I will add a prompt before pushing (should that even
happen).
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: RFC: Changing Bugzilla updates at release time

[Arsen Arsenović via Gcc]

Jonathan Wakely via Overseers  writes:

> I don't care which account does the changes but I'd prefer to keep the
> emails. There's always at least one that reminds me a bug is actually fixed
> and should be closed, or the target milestone should be removed because it
> isn't going to be fixed on that branch now.

Is this on gcc-bugs@ or on bugs you are CC'd on?  IMO the benefit is
greatest on the former (and I wouldn't suppress them on the latter
either).

> If they were just sent from a separate account then I'd still get emails
> but you could filter them out more easily.

Indeed.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

C++: Coroutine lambdas and the incomplete closure type

[Arsen Arsenović via Gcc]

Hi!

Currently, I'm looking at PR115731.  To summarize the issue, it is
possible for the user to, through coroutines, observe the closure type
of a lambda before it is completed.  This closure type, in GCC, is
started before and finished after parsing the lambda body, meaning that
it is incomplete during the parsing (and finishing) the lambda
operator().  As a result, when we attempt to resolve the promise type of
the coroutine, we can get an incomplete type error (as in the testcase
in the PR).

I was originally intending to defer expansion of CO_*_EXPRs up until
finishing the lambda operator(), by finishing the struct after pruning
captures and then expanding CO_*_EXPRs with a tree-walk, but this fails
because finishing the struct involves popping its binding level, but the
level stack contains the outermost binding level for the function at
that point.

I'm not sure if I can do that expansion later (defer it until after
finish_function (lambda_fn) or finish_struct (lambda_closure)) either
(in order to go back and recreate the CO_*_EXPRs in the lambda body, and
to "re-finish" the function, so that the coroutine transform gets
applied).

Is there a potential solution I am missing?  Can one of the proposals
above be implemented somehow?  What'd be the best thing to do?

TIA, have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Proposed CHOST change for the 64bit time_t transition

[Arsen Arsenović via Gcc]

Paul Eggert  writes:

> One possible improvement would be to append "t32" if you want 32-bit time_t,
> instead of appending "t64" for 64-bit time_t. That way, people wouldn't be
> stuck with appending that confusing "t64" for the foreseeable future, and only
> specialists concerned with 32-bit time_t would need to know about the issue.

But that'd change semantics in non-obvious ways.  The intention behind
this suggestion is to have a mechanism to communicate to packages and
the toolchain alike that "yes, this system is Y2038-proof".  There is
currently no mechanism to do that.  There isn't even a mechanism to
guess based on your dependencies whether you should also enable LFS and
T64 (and there can't be a general one - you'd need to detect what
libraries are doing what if they have time_t or other system integers on
ABI boundaries, which is not generally possible).  Not that the latter
would suffice - even if we changed all packages we can to use such a
mechanism, there would be plenty of packages that don't (think of all
the hand-rolled makefiles..).

An alternative that I pondered was to teach the linker about some notion
of "compatibility strings" that it would compare and reject if
different, plus teaching the compiler how to emit those, plus teaching
glibc to tell the compiler to emit those..  We could have key-value
pairs in some section.  For each key K, we could have the linker check
that, for each (shared or otherwise) object either does not contain K or
contains K with the same value as all the other ones, and produce an
error otherwise.  On the resulting object, the KV pairs would be the
union of all KV pairs of all constituent objects.

... but this is for i?86, a CPU family I haven't used in ~15 years (and
I suspect many also have not..), and there are other things eating my
time.  And it'd still require a world rebuild.

> Personally, I hope backward-compatibility concerns don't require this sort of
> thing. I'd rather just switch, as Debian has.

The "status quo" of some packages enabling it of their own volition, and
some not, leads to various subtle breakages (example:
https://bugs.gentoo.org/828001).  I think switching like that would not
be much different.

I do not know what approach Debian took, but if it is one of altering
the toolchain, then this is a sure way to introduce subtle divergences
between distros (this is why I've suggested we CC the GCC and binutils
MLs); if it is one of teaching debhelper (is that the right tool?  not
sure) about it, then this will break user-compiled packages (so,
./configure && make && make install, or moral equivalent).  If it is to
alter libc, then, can we do libc.so.7?  ;)

The only actually solid approach I see today is to /somehow/ communicate
to the system to not use 32-bit time, ever (and consequently, to enable
LFS).  I think that the "least effort" path to do that is through the
tuple.

There's precedent for this also, AFAIK, in the 32-bit ARM world
(gnueabi/gnueabihf, whatever that means).

config.guess would need to be altered a little bit.  My preference is
for [[ $os = *-*-gnu*t64* ]] informing glibc to completely ignore
_FILE_OFFSET_BITS, _LARGEFILE_SOURCE, _LARGEFILE64_SOURCE, and
_TIME_BITS and just presume 64 for all of those system integers.  This
means that config.guess could undef those (in case a toolchain sets
those) and include some libc file, then check for sizeof (time_t), or
just have glibc define something if on a gnut64 target.

> I felt the same way about the 64-bit off_t back in the 1990s. It was obvious 
> to
> me even at the time that we would have been significantly better off making
> off_t 64-bit, while keeping 32-bit off_t in the ABI for backward 
> compatibility;
> this is what NetBSD did with time_t in 2012. Although I realize others felt
> differently, I never fully understood their concerns.

That is history now I fear; I also wish that time_t was made
64-bit a long ago ;)

> And here I am, three decades later, still having to make changes[1] to
> Autoconf's AC_SYS_LARGEFILE macro to continue to support that 30-year-old 
> off_t3
> mistake, and now with 64-bit time_t interacting with 64-off_t in 
> non-orthogonal
> ways.

Indeed, and the "best" part is that, whatever you do in autoconf, unless
a program exists in isolation only interfacing with libc, it will break
some consumer (or will be broken by some dependency) because there's no
mechanism to signal the time_t size across ABI boundaries.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Proposed CHOST change for the 64bit time_t transition

[Arsen Arsenović via Gcc]

Bruno Haible  writes:

> Arsen Arsenović wrote:
>> An alternative that I pondered was to teach the linker about some notion
>> of "compatibility strings" that it would compare and reject if
>> different, plus teaching the compiler how to emit those, plus teaching
>> glibc to tell the compiler to emit those..  We could have key-value
>> pairs in some section.  For each key K, we could have the linker check
>> that, for each (shared or otherwise) object either does not contain K or
>> contains K with the same value as all the other ones, and produce an
>> error otherwise.  On the resulting object, the KV pairs would be the
>> union of all KV pairs of all constituent objects.
>
> This sounds much like the arm eabi attributes: If a .s file does not
> start with
> .eabi_attribute 20, 1
> .eabi_attribute 21, 1
> .eabi_attribute 23, 3
> .eabi_attribute 24, 1
> .eabi_attribute 25, 1
> .eabi_attribute 26, 2
> .eabi_attribute 30, 2
> .eabi_attribute 34, 0
> .eabi_attribute 18, 4
> the resulting .o file cannot be linked with other .o files on the system.
>
> Is it a hassle even for packages that don't use time_t of off_t (such as
> GNU libffcall or libffi).
>
> Yes, it would be useful to have a way to have the linker warn if a binary
> that depends on 32-bit time_t and a binary that depends on 64-bit time_t
> get linked together. But PLEASE implement this in a way that is a no-op
> when time_t is not used by either of the two binaries.

I mentioned that a missing pair should not preclude linking.  This is
because what I imagined is somehow attaching this tag to the typedef for
time_t, or such, so if the typedef is not used, no such tag is emitted.

I'm not sure how feasible that is, I, of course, don't have a full
implementation.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Proposed CHOST change for the 64bit time_t transition

[Arsen Arsenović via Gcc]

Bruno Haible  writes:

> Paul Eggert wrote:
>> I'd rather just switch, as Debian has.
>
> I'd go one step further, and not only
>   make the ABI transition without changing the canonical triplet,
> but also
>   make gcc and clang define -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
>   among their predefines.

At that point, we should bump SONAME of libc and simply remove 32-bit
time support.  This would probably be okay generally.  Just doing the
predefine doesn't really fix anything - all the problems of not being
able to detect whether t64 support exists still persist, with no
mechanism to prevent mixing.

But, in the case we don't do a bump, why not update the tuple?  This'd
allow easy communication of whether we have 32 bit time to all
components of the system, and, in lieu of a better detection mechanism,
it'd allow anyone at a glance to look at a hosts tuple and see whether
it is compatible with something based on the tuple it was built on.

AFAIK the only reason not to do that is cosmetic - and it is ugly, but
this is for a dead platform, so I'm not too worried.

> Rationale:
>
>   * We want that a user of a distro with the new ABI can build
> packages in the usual way:
>   - ./configure; make; make install (when using Autoconf), or
>   - make; make install  (when there is just a Makefile).
> This *requires* that gcc and clang get patched, as indicated
> above.
> (Only changing Debian-specific files or variables won't do it.)
>
>   * Once this has been done, is there a need for a triplet change?
> Not in the toolchain, and not in the packages either.
> Needs that have been mentioned in [1][2]:
>
>   - Users would like to know in which ABI they / their distro lives.
> This can be done through a property in /etc/os-release.
>
>   - "risks incompatibility with other distributions" [2]
> What is the problem? Do we expect users to build binaries
> on 32-bit distro X and try to run them on 32-bit distro Y?
> Or do we expect binary package distributors (like Mozilla,
> videolan.org) to do so?
> It was my impression that this approach is doomed anyway,
> because so many shared libraries have different major version
> in distro X than in distro Y.

It is, many do it anyway, and what's worse, many users misguidedly
prefer it to better approaches (like the ones you mentioned).

> And that such binary package distributors use flatpak, AppImage, etc.
> precisely to get out of this dilemma.
>
>   - Building gcc and glibc might need some particular options.
> Such options can be documented without requiring a new triplet.
>
> References:
> [1] https://wiki.debian.org/ReleaseGoals/64bit-time
> [2] https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration

-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Proposed CHOST change for the 64bit time_t transition

[Arsen Arsenović via Gcc]

Jacob Bachmeyer  writes:

>> At that point, we should bump SONAME of libc and simply remove 32-bit
>> time support.  This would probably be okay generally.
>
> This is probably the best solution to this problem at hand, especially since
> the old ABI has a definite expiration date about 14 years from now.  Bump the
> libc SONAME major and hope that we can get rid of the last dependencies on the
> old SONAME before the deadline.  We will have 14 years to do it, if that arch
> is even still used then.

Indeed.  I believe the current thinking is that the existing software
for the old ABI could benefit from libc updates, hence not breaking it,
but.. it practically is somewhat broken already (hence the troubles that
lead to this thread).

>> [...]
>> But, in the case we don't do a bump, why not update the tuple?  This'd
>> allow easy communication of whether we have 32 bit time to all
>> components of the system, and, in lieu of a better detection mechanism,
>> it'd allow anyone at a glance to look at a hosts tuple and see whether
>> it is compatible with something based on the tuple it was built on.
>>   
>
> This is closely related to the idea I floated a year ago of redefining
> configuration tuples as lists of tags (with a canonical order) progressively
> narrowing a broad architecture.  Start with CPU architecture and work
> "narrower" from there.  In that system, adding "-t32" and "-t64" to indicate
> time_t width would be the simple solution.  In context then, it was to handle
> different libc choices on Windows.

Yes, that's about what I imagined as the effect of the suffix.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Is -Wtraditional obsolete?

[Arsen Arsenović via Gcc]

Eli Zaretskii via Gcc  writes:

> Please don't remove the support for -Wtraditional if it's easy to fix.
> Removing it runs risk of breaking someone's program, so unless keeping
> it is a real dumper on GCC development, I hope you will keep it.

ISTM that it is proposed to ignore rather than reject Wtraditional, and
as a warning option, it should be incosequential to parsing and codegen,
so risk of breakage is minimal or nonexistent, save for the change in
workflow caused by it not being effective.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: On pull request workflows for the GNU toolchain

[Arsen Arsenović via Gcc]

Thomas Koenig  writes:

> [For the fortran people: Discussion on gcc@]
>
> Just a general remark.
>
> There are people, such as myself, who regularly mess up
> their git repositories because they have no mental model
> of what git is doing (case in point: The Fortran unsigned
> branch, which I managed to put into an unrepairable state
> despite considerable help from people who tried to help me
> fix it). This is especially true of volunteer maintainers,
> who are still the mainstay of gfortran.
>
> Whatever you end up doing, consider such maintainers, and
> if they still can contribute or would simply give up.
> If what you end up doing is too complicated, it may end up
> severely impacting the gfortran project (and possibly others).

Git is extremely helpful if one learns to wield it rather than fight it.
It is based on a very simple model also.  I strongly encourage going
over https://git-scm.com/book/en/v2 and/or
https://eagain.net/articles/git-for-computer-scientists/ as it might
help you even independent of collaboration (for instance, I scarcely do
any work _without_ git nowadays.. it helps me to find old revisions and
temporary unfinished work, to synchronize work across machines, to
triage bugs, context switch, ...).

The workflow change proposed would reduce sending and reviewing patches
to a push, and interaction via some different (perhaps web?) means.  It
should not be more complex than email.

If the gfortran project finds that such a workflow hinders it, I suggest
a hybrid approach, where maintainers still can send patches via current
means.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: x86_64 regression tests arbitrary failing?

[Arsen Arsenović via Gcc]

Hi,

Georg-Johann Lay  writes:

> For a trivial change that I'd like to bootstrap + regtest, I am
> am getting FAILs like:
>
> $ diff xxx/gcc/testsuite/gcc/gcc.sum  yyy/gcc/testsuite/gcc/gcc.sum
> 164656c164656
> < PASS: c-c++-common/tsan/atomic_stack.c   -O0  output pattern test
> ---
>> FAIL: c-c++-common/tsan/atomic_stack.c   -O0  output pattern test
> 164659c164659
> < FAIL: c-c++-common/tsan/atomic_stack.c   -O2  output pattern test
> ---
>> PASS: c-c++-common/tsan/atomic_stack.c   -O2  output pattern test
> 164662c164662
> < PASS: c-c++-common/tsan/bitfield_race.c   -O0  output pattern test
> ---
>> FAIL: c-c++-common/tsan/bitfield_race.c   -O0  output pattern test
> 164668c164668
> < PASS: c-c++-common/tsan/fd_pipe_race.c   -O0  output pattern test
> ---
>> FAIL: c-c++-common/tsan/fd_pipe_race.c   -O0  output pattern test
> 164674c164674
> < FAIL: c-c++-common/tsan/free_race.c   -O0  output pattern test
> ---
>> PASS: c-c++-common/tsan/free_race.c   -O0  output pattern test
>
> Is there anything special so that these tests don't arbitrary flip
> their PASS/FAIL state?
>
> The GCC version that's being tested is current trunk.
> The build compiler is GCC v14.2.1.
>
> The two testsuites (one for xxx and one for yyy) are being run
> at the same time (in their tmux panes).  For what I know tests
> may run at the same time when they are in different build
> directories.

They can.  That's fine.

> The configure command is basically
>
> $ ../../source/gcc/configure
>
> The command to run the testsuites is
>
> $ make check
>
> from the respective top level build directory.

For TSAN tests, this might happen on some machines, for a reason I am
yet to determine (I've also seen it on cfarm420, but not on my PC).

If you wish to confirm this is spurious, you could rerun that part of
the testsuite on the same source tree and compare the results.  I expect
you'll get differences again (and not the same ones as the ones you
showed above).

I'd love to know why this happens, but haven't looked far into it yet.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature

Re: Commits not appearing in bugzilla

[Arsen Arsenović via Gcc]

Thomas Koenig via Gcc  writes:

> (Incidentally, the mailing system messes up the UTF-8 represntation
> of my last name, König, maybe that is somehing to do with it).

IIRC my commits were failing to go through due to the presence of a "ć"
in my /etc/passwd entry on Sourceware.  This might be the same thing.

I don't know why it is an issue, though.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature