Rust: Move void_list_node init to common code (was: [PATCH] Move void_list_node init to common code)

2023-02-22 Thread Thomas Schwinge 
Hi!

On 2022-09-14T16:06:55+0200, Richard Biener via Gcc-patches 
 wrote:
> All frontends replicate this, so move it.

At that time, the Rust front end was not yet in master branch; I've now
pushed to master branch commit 334f23d83261997ca89d8919b94b97aa22003a65
"Rust: Move void_list_node init to common code", see attached.


Grüße
 Thomas


> Bootstrap and regtest running for all languages on
> x86_64-unknown-linux-gnu.
>
> OK if that succeeds?
>
> Thanks,
> Richard.
>
> gcc/
>   * tree.cc (build_common_tree_nodes): Initialize void_list_node
>   here.
>
> gcc/ada/
>   * gcc-interface/trans.cc (gigi): Do not initialize void_list_node.
>
> gcc/c-family/
>   * c-common.h (build_void_list_node): Remove.
>   * c-common.cc (c_common_nodes_and_builtins): Do not initialize
>   void_list_node.
>
> gcc/c/
>   * c-decl.cc (build_void_list_node): Remove.
>
> gcc/cp/
>   * decl.cc (cxx_init_decl_processing): Inline last
>   build_void_list_node call.
>   (build_void_list_node): Remove.
>
> gcc/d/
>   * d-builtins.cc (d_build_c_type_nodes): Do not initialize
>   void_list_node.
>
> gcc/fortran/
>   * f95-lang.c (gfc_init_decl_processing): Do not initialize
>   void_list_node.
>
> gcc/go/
>   * go-lang.cc (go_langhook_init): Do not initialize
>   void_list_node.
>
> gcc/jit/
>   * dummy-frontend.cc (jit_langhook_init): Do not initialize
>   void_list_node.
>
> gcc/lto/
>   * lto-lang.cc (lto_build_c_type_nodes): Do not initialize
>   void_list_node.
> ---
>  gcc/ada/gcc-interface/trans.cc |  1 -
>  gcc/c-family/c-common.cc   |  2 --
>  gcc/c-family/c-common.h|  1 -
>  gcc/c/c-decl.cc|  8 
>  gcc/cp/decl.cc | 10 +-
>  gcc/d/d-builtins.cc|  1 -
>  gcc/fortran/f95-lang.cc|  2 --
>  gcc/go/go-lang.cc  |  3 ---
>  gcc/jit/dummy-frontend.cc  |  3 ---
>  gcc/lto/lto-lang.cc|  1 -
>  gcc/tree.cc|  2 ++
>  11 files changed, 3 insertions(+), 31 deletions(-)
>
> diff --git a/gcc/ada/gcc-interface/trans.cc b/gcc/ada/gcc-interface/trans.cc
> index f2e0cb2299b..2d93947cb26 100644
> --- a/gcc/ada/gcc-interface/trans.cc
> +++ b/gcc/ada/gcc-interface/trans.cc
> @@ -413,7 +413,6 @@ gigi (Node_Id gnat_root,
>save_gnu_tree (gnat_literal, t, false);
>
>/* Declare the building blocks of function nodes.  */
> -  void_list_node = build_tree_list (NULL_TREE, void_type_node);
>void_ftype = build_function_type_list (void_type_node, NULL_TREE);
>ptr_void_ftype = build_pointer_type (void_ftype);
>
> diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
> index 0a5b7e120c9..c0f15f4cab1 100644
> --- a/gcc/c-family/c-common.cc
> +++ b/gcc/c-family/c-common.cc
> @@ -4505,8 +4505,6 @@ c_common_nodes_and_builtins (void)
>  TYPE_NAME (void_type_node) = void_name;
>}
>
> -  void_list_node = build_void_list_node ();
> -
>/* Make a type to be the domain of a few array types
>   whose domains don't really matter.
>   200 is small enough that it always fits in size_t
> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
> index ce971a29b5d..2f592f5cd58 100644
> --- a/gcc/c-family/c-common.h
> +++ b/gcc/c-family/c-common.h
> @@ -853,7 +853,6 @@ extern tree identifier_global_tag (tree);
>  extern bool names_builtin_p (const char *);
>  extern tree c_linkage_bindings (tree);
>  extern void record_builtin_type (enum rid, const char *, tree);
> -extern tree build_void_list_node (void);
>  extern void start_fname_decls (void);
>  extern void finish_fname_decls (void);
>  extern const char *fname_as_string (int);
> diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
> index 34f8feda897..b09c6393b91 100644
> --- a/gcc/c/c-decl.cc
> +++ b/gcc/c/c-decl.cc
> @@ -10676,14 +10676,6 @@ record_builtin_type (enum rid rid_index, const char 
> *name, tree type)
>  debug_hooks->type_decl (decl, false);
>  }
>
> -/* Build the void_list_node (void_type_node having been created).  */
> -tree
> -build_void_list_node (void)
> -{
> -  tree t = build_tree_list (NULL_TREE, void_type_node);
> -  return t;
> -}
> -
>  /* Return a c_parm structure with the given SPECS, ATTRS and DECLARATOR.  */
>
>  struct c_parm *
> diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
> index 006e9affcba..070f673c3a2 100644
> --- a/gcc/cp/decl.cc
> +++ b/gcc/cp/decl.cc
> @@ -4623,7 +4623,7 @@ cxx_init_decl_processing (void)
>record_unknown_type (init_list_type_node, "init list");
>
>/* Used when parsing to distinguish parameter-lists () and (void).  */
> -  explicit_void_list_node = build_void_list_node ();
> +  explicit_void_list_node = build_tree_list (NULL_TREE, void_type_node);
>
>{
>  /* Make sure we get a unique function type, so we can give
> @@ -18450,14 +18450,6 @@ cp_tree_node_structure (union lang_tree_node * t)
>  }
>  }
>
> -/* Build the void_list_node (void_type_node having been created).  */
> -tree
> -build_void_list_

Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types (was: Modula-2 / Rust: Many targets failing)

2023-02-22 Thread Thomas Schwinge 
Hi!

Richard, you may remember your words from 
"ICE: SIGSEGV in optab_for_tree_code (optabs.c:407) with -O 
-fno-tree-scev-cprop -ftree-vectorize":

> Ideally we'd never use lang_hooks.types.type_for_mode (or _for_size) in the
> middle-end but had a pure middle-end based implementation.

Is there a canonical PR or other discussion thread for that?

Here's another instance of this issue:

On 2022-12-19T22:23:45+0100, Jan-Benedict Glaw  wrote:
> With the recent merges for Modula-2 and Rust, I see a good number of
> targets failing with --enable-languages=all, mostly due to issues with
> the Modula-2 driver.

Thanks for reporting.

>  Modula-2 related issues
> [snipped]

>  Rust related issues
> =
>
>  --target=msp430-elfbare
> ~
>   /var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/xgcc 
> -B/var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/  -xrust 
> -frust-incomplete-and-experimental-compiler-do-not-use -nostdinc /dev/null -S 
> -o /dev/null -fself-test=../../gcc/gcc/testsuite/selftests
>   : internal compiler error: Segmentation fault
>   0xf2efbf crash_signal
> ../../gcc/gcc/toplev.cc:314
>   0x120c8c7 build_function_type(tree_node*, tree_node*, bool)
> ../../gcc/gcc/tree.cc:7360
>   0x120cc20 build_function_type_list(tree_node*, ...)
> ../../gcc/gcc/tree.cc:7442
>   0x120d16b build_common_builtin_nodes()
> ../../gcc/gcc/tree.cc:9883
>   0x8449b4 grs_langhook_init
> ../../gcc/gcc/rust/rust-lang.cc:132
>   0x8427b2 lang_dependent_init
> ../../gcc/gcc/toplev.cc:1815
>   0x8427b2 do_compile
> ../../gcc/gcc/toplev.cc:2110
>   Please submit a full bug report, with preprocessed source (by using 
> -freport-bug).
>   Please include the complete backtrace with any bug report.
>   See  for instructions.
>   make[1]: *** [../../gcc/gcc/rust/Make-lang.in:275: s-selftest-rust] 
> Error 1

See also 
"Test failure on msp430-elfbare target".

I confirm with both upstream GCC master branch and GCC/Rust master
branch:

$ ../source-gcc/configure --target=msp430-elfbare --enable-languages=rust 
[...]
$ make all-gcc [...]
[...]
[...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/  -xc -nostdinc 
/dev/null -S -o /dev/null -fself-test=../../source-gcc/gcc/testsuite/selftests
-fself-test: 57323 pass(es) in 0.42 seconds
echo timestamp > s-selftest-c
[...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/  -xrust 
-frust-incomplete-and-experimental-compiler-do-not-use -nostdinc /dev/null -S 
-o /dev/null -fself-test=../../source-gcc/gcc/testsuite/selftests
: internal compiler error: Segmentation fault
0xf51b9f crash_signal
../../source-gcc/gcc/toplev.cc:314
0x12e6a3a build_function_type(tree_node*, tree_node*, bool)
../../source-gcc/gcc/tree.cc:7447
0x12e6ee0 build_function_type_list(tree_node*, ...)
../../source-gcc/gcc/tree.cc:7529
0x12e748e build_common_builtin_nodes()
../../source-gcc/gcc/tree.cc:9977
0x7661c4 grs_langhook_init
../../source-gcc/gcc/rust/rust-lang.cc:128
0x762ac9 lang_dependent_init
../../source-gcc/gcc/toplev.cc:1815
0x762ac9 do_compile
../../source-gcc/gcc/toplev.cc:2110
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
make[1]: *** [s-selftest-rust] Error 1
[...]

OK to push the attached
"Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types"?


Grüße
 Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
>From cae898bef63db18cc40b94ee4d48f85aec258c02 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Wed, 22 Feb 2023 11:42:43 +0100
Subject: [PATCH] Rust: In 'type_for_mode' langhook also consider all 'int_n'
 modes/types

As reported in "Rust related issues" at the end of

"Modula-2 / Rust: Many targets failing",

"Test failure on msp430-elfbare target", for '--target=msp430-elfbar' we ICE:

: internal compiler error: Segmentation fault
0xf2efbf crash_signal
  ../../gcc/gcc/toplev.cc:314
0x120c8c7 build_function_type(tree_node*, tree_node*, bool)
  ../../gcc/gcc/tree.cc:7360
0x120cc20 build_function_type_list(tree_node*, ...)
  ../../gcc/gcc/tree.cc:7442
0x120d16b build_common_builtin_nodes

Re: Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types (was: Modula-2 / Rust: Many targets failing)

2023-02-22 Thread Richard Biener via Gcc-rust 
On Wed, 22 Feb 2023, Thomas Schwinge wrote:

> Hi!
> 
> Richard, you may remember your words from 
> "ICE: SIGSEGV in optab_for_tree_code (optabs.c:407) with -O 
> -fno-tree-scev-cprop -ftree-vectorize":
> 
> > Ideally we'd never use lang_hooks.types.type_for_mode (or _for_size) in the
> > middle-end but had a pure middle-end based implementation.
> 
> Is there a canonical PR or other discussion thread for that?

No, not that I'm aware of.

Richard.

> Here's another instance of this issue:
> 
> On 2022-12-19T22:23:45+0100, Jan-Benedict Glaw  wrote:
> > With the recent merges for Modula-2 and Rust, I see a good number of
> > targets failing with --enable-languages=all, mostly due to issues with
> > the Modula-2 driver.
> 
> Thanks for reporting.
> 
> >  Modula-2 related issues
> > [snipped]
> 
> >  Rust related issues
> > =
> >
> >  --target=msp430-elfbare
> > ~
> >   /var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/xgcc 
> > -B/var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/  -xrust 
> > -frust-incomplete-and-experimental-compiler-do-not-use -nostdinc /dev/null 
> > -S -o /dev/null -fself-test=../../gcc/gcc/testsuite/selftests
> >   : internal compiler error: Segmentation fault
> >   0xf2efbf crash_signal
> > ../../gcc/gcc/toplev.cc:314
> >   0x120c8c7 build_function_type(tree_node*, tree_node*, bool)
> > ../../gcc/gcc/tree.cc:7360
> >   0x120cc20 build_function_type_list(tree_node*, ...)
> > ../../gcc/gcc/tree.cc:7442
> >   0x120d16b build_common_builtin_nodes()
> > ../../gcc/gcc/tree.cc:9883
> >   0x8449b4 grs_langhook_init
> > ../../gcc/gcc/rust/rust-lang.cc:132
> >   0x8427b2 lang_dependent_init
> > ../../gcc/gcc/toplev.cc:1815
> >   0x8427b2 do_compile
> > ../../gcc/gcc/toplev.cc:2110
> >   Please submit a full bug report, with preprocessed source (by using 
> > -freport-bug).
> >   Please include the complete backtrace with any bug report.
> >   See  for instructions.
> >   make[1]: *** [../../gcc/gcc/rust/Make-lang.in:275: s-selftest-rust] 
> > Error 1
> 
> See also 
> "Test failure on msp430-elfbare target".
> 
> I confirm with both upstream GCC master branch and GCC/Rust master
> branch:
> 
> $ ../source-gcc/configure --target=msp430-elfbare --enable-languages=rust 
> [...]
> $ make all-gcc [...]
> [...]
> [...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/  -xc -nostdinc 
> /dev/null -S -o /dev/null -fself-test=../../source-gcc/gcc/testsuite/selftests
> -fself-test: 57323 pass(es) in 0.42 seconds
> echo timestamp > s-selftest-c
> [...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/  -xrust 
> -frust-incomplete-and-experimental-compiler-do-not-use -nostdinc /dev/null -S 
> -o /dev/null -fself-test=../../source-gcc/gcc/testsuite/selftests
> : internal compiler error: Segmentation fault
> 0xf51b9f crash_signal
> ../../source-gcc/gcc/toplev.cc:314
> 0x12e6a3a build_function_type(tree_node*, tree_node*, bool)
> ../../source-gcc/gcc/tree.cc:7447
> 0x12e6ee0 build_function_type_list(tree_node*, ...)
> ../../source-gcc/gcc/tree.cc:7529
> 0x12e748e build_common_builtin_nodes()
> ../../source-gcc/gcc/tree.cc:9977
> 0x7661c4 grs_langhook_init
> ../../source-gcc/gcc/rust/rust-lang.cc:128
> 0x762ac9 lang_dependent_init
> ../../source-gcc/gcc/toplev.cc:1815
> 0x762ac9 do_compile
> ../../source-gcc/gcc/toplev.cc:2110
> Please submit a full bug report, with preprocessed source (by using 
> -freport-bug).
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make[1]: *** [s-selftest-rust] Error 1
> [...]
> 
> OK to push the attached
> "Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types"?
> 
> 
> Grüße
>  Thomas
> 
> 
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

[Bug rust/108631] gcc/rust/backend/rust-constexpr.cc:2099:33: error: too few arguments to function ‘tree_node* Rust::Compile::unshare_constructor(tree, const char*, int, const char*)’ with --enable-ga

2023-02-22 Thread cohenarthur at gcc dot gnu.org via Gcc-rust 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108631

Arthur Cohen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |cohenarthur at gcc dot 
gnu.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types (was: Modula-2 / Rust: Many targets failing)

2023-02-22 Thread Arthur Cohen 

Hi Thomas,

On 2/22/23 12:25, Thomas Schwinge wrote:

Hi!

Richard, you may remember your words from 
"ICE: SIGSEGV in optab_for_tree_code (optabs.c:407) with -O -fno-tree-scev-cprop 
-ftree-vectorize":


Ideally we'd never use lang_hooks.types.type_for_mode (or _for_size) in the
middle-end but had a pure middle-end based implementation.


Is there a canonical PR or other discussion thread for that?

Here's another instance of this issue:

On 2022-12-19T22:23:45+0100, Jan-Benedict Glaw  wrote:

With the recent merges for Modula-2 and Rust, I see a good number of
targets failing with --enable-languages=all, mostly due to issues with
the Modula-2 driver.


Thanks for reporting.


  Modula-2 related issues
[snipped]



  Rust related issues
=

  --target=msp430-elfbare
~
   /var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/xgcc 
-B/var/lib/laminar/run/gcc-msp430-elfbare/24/toolchain-build/./gcc/  -xrust 
-frust-incomplete-and-experimental-compiler-do-not-use -nostdinc /dev/null -S 
-o /dev/null -fself-test=../../gcc/gcc/testsuite/selftests
   : internal compiler error: Segmentation fault
   0xf2efbf crash_signal
 ../../gcc/gcc/toplev.cc:314
   0x120c8c7 build_function_type(tree_node*, tree_node*, bool)
 ../../gcc/gcc/tree.cc:7360
   0x120cc20 build_function_type_list(tree_node*, ...)
 ../../gcc/gcc/tree.cc:7442
   0x120d16b build_common_builtin_nodes()
 ../../gcc/gcc/tree.cc:9883
   0x8449b4 grs_langhook_init
 ../../gcc/gcc/rust/rust-lang.cc:132
   0x8427b2 lang_dependent_init
 ../../gcc/gcc/toplev.cc:1815
   0x8427b2 do_compile
 ../../gcc/gcc/toplev.cc:2110
   Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
   Please include the complete backtrace with any bug report.
   See  for instructions.
   make[1]: *** [../../gcc/gcc/rust/Make-lang.in:275: s-selftest-rust] 
Error 1


See also 
"Test failure on msp430-elfbare target".

I confirm with both upstream GCC master branch and GCC/Rust master
branch:

 $ ../source-gcc/configure --target=msp430-elfbare --enable-languages=rust 
[...]
 $ make all-gcc [...]
 [...]
 [...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/  -xc -nostdinc 
/dev/null -S -o /dev/null -fself-test=../../source-gcc/gcc/testsuite/selftests
 -fself-test: 57323 pass(es) in 0.42 seconds
 echo timestamp > s-selftest-c
 [...]/build-gcc/./gcc/xgcc -B[...]/build-gcc/./gcc/  -xrust 
-frust-incomplete-and-experimental-compiler-do-not-use -nostdinc /dev/null -S 
-o /dev/null -fself-test=../../source-gcc/gcc/testsuite/selftests
 : internal compiler error: Segmentation fault
 0xf51b9f crash_signal
 ../../source-gcc/gcc/toplev.cc:314
 0x12e6a3a build_function_type(tree_node*, tree_node*, bool)
 ../../source-gcc/gcc/tree.cc:7447
 0x12e6ee0 build_function_type_list(tree_node*, ...)
 ../../source-gcc/gcc/tree.cc:7529
 0x12e748e build_common_builtin_nodes()
 ../../source-gcc/gcc/tree.cc:9977
 0x7661c4 grs_langhook_init
 ../../source-gcc/gcc/rust/rust-lang.cc:128
 0x762ac9 lang_dependent_init
 ../../source-gcc/gcc/toplev.cc:1815
 0x762ac9 do_compile
 ../../source-gcc/gcc/toplev.cc:2110
 Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
 Please include the complete backtrace with any bug report.
 See  for instructions.
 make[1]: *** [s-selftest-rust] Error 1
 [...]

OK to push the attached
"Rust: In 'type_for_mode' langhook also consider all 'int_n' modes/types"?|


OK :) patch was tested on x86_64 and builds, bootstraps and pass the 
testsuite.


Kindly,

Arthur




Grüße
  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


OpenPGP_0x1B3465B044AD9C65.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: [committed 034/103] gccrs: dump: Emit visibility when dumping items

2023-02-22 Thread Gerald Pfeifer 
Just noticed this by chance: 

How does this patch constitute a functional change (that matches the 
ChangeLog)? It looks it only adds an empty line to the source code?

Gerald

On Tue, 21 Feb 2023, arthur.co...@embecosm.com wrote:
> From: Arthur Cohen 
> 
> gcc/rust/ChangeLog:
> 
>   * ast/rust-ast-dump.cc: Emit visibility when dumping items.
> ---
>  gcc/rust/ast/rust-ast-dump.cc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/gcc/rust/ast/rust-ast-dump.cc b/gcc/rust/ast/rust-ast-dump.cc
> index fdcd97561bb..b7557bdee0c 100644
> --- a/gcc/rust/ast/rust-ast-dump.cc
> +++ b/gcc/rust/ast/rust-ast-dump.cc
> @@ -835,6 +835,7 @@ void
>  Dump::visit (Function &function)
>  {
>emit_visibility (function.get_visibility ());
> +
>stream << "fn " << function.get_function_name ();
>if (function.has_generics ())
>  emit_generic_params (function.get_generic_params ());

-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust