[COMMITTED 003/146] gccrs: Fix variable shadowing in late resolution 2.0

[arthur . cohen]

From: Owen Avery 

gcc/rust/ChangeLog:

* resolve/rust-late-name-resolver-2.0.cc
(Late::visit): Visit the initialization expressions of let
statements before visiting their patterns.

gcc/testsuite/ChangeLog:

* rust/compile/nr2/exclude: Remove entries.

Signed-off-by: Owen Avery 
---
 gcc/rust/resolve/rust-late-name-resolver-2.0.cc | 10 --
 gcc/testsuite/rust/compile/nr2/exclude  |  3 ---
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/gcc/rust/resolve/rust-late-name-resolver-2.0.cc 
b/gcc/rust/resolve/rust-late-name-resolver-2.0.cc
index 43f33dfab02..5fd49e7c2c9 100644
--- a/gcc/rust/resolve/rust-late-name-resolver-2.0.cc
+++ b/gcc/rust/resolve/rust-late-name-resolver-2.0.cc
@@ -126,8 +126,14 @@ Late::new_label (Identifier name, NodeId id)
 void
 Late::visit (AST::LetStmt &let)
 {
-  // so we don't need that method
-  DefaultResolver::visit (let);
+  DefaultASTVisitor::visit_outer_attrs (let);
+  if (let.has_type ())
+visit (let.get_type ());
+  // visit expression before pattern
+  // this makes variable shadowing work properly
+  if (let.has_init_expr ())
+visit (let.get_init_expr ());
+  visit (let.get_pattern ());
 
   // how do we deal with the fact that `let a = blipbloup` should look for a
   // label and cannot go through function ribs, but `let a = blipbloup()` can?
diff --git a/gcc/testsuite/rust/compile/nr2/exclude 
b/gcc/testsuite/rust/compile/nr2/exclude
index 383950ca863..c96fde25fc5 100644
--- a/gcc/testsuite/rust/compile/nr2/exclude
+++ b/gcc/testsuite/rust/compile/nr2/exclude
@@ -74,10 +74,8 @@ issue-1589.rs
 issue-1725-1.rs
 issue-1725-2.rs
 issue-1786.rs
-issue-1813.rs
 issue-1893.rs
 issue-1901.rs
-issue-1930.rs
 issue-1981.rs
 issue-2019-1.rs
 issue-2019-2.rs
@@ -142,7 +140,6 @@ match4.rs
 match5.rs
 match9.rs
 method2.rs
-multi_reference_type.rs
 multiple_bindings1.rs
 multiple_bindings2.rs
 name_resolution2.rs
-- 
2.45.2

[COMMITTED 094/146] gccrs: lower: Correctly lower parenthesized types

[arthur . cohen]

From: Arthur Cohen 

This is useful for handling multiple trait bounds, and required for better 
handling of auto traits.

gcc/rust/ChangeLog:

* hir/rust-ast-lower-type.cc (ASTLoweringType::visit): Add 
implementation for
ParenthesizedType.
* hir/rust-ast-lower-type.h: Declare that new visitor.

gcc/testsuite/ChangeLog:

* rust/compile/auto_traits1.rs: New test.
---
 gcc/rust/hir/rust-ast-lower-type.cc| 19 +++
 gcc/rust/hir/rust-ast-lower-type.h |  2 ++
 gcc/testsuite/rust/compile/auto_traits1.rs | 27 ++
 3 files changed, 48 insertions(+)
 create mode 100644 gcc/testsuite/rust/compile/auto_traits1.rs

diff --git a/gcc/rust/hir/rust-ast-lower-type.cc 
b/gcc/rust/hir/rust-ast-lower-type.cc
index df06e48b801..d1f95edc345 100644
--- a/gcc/rust/hir/rust-ast-lower-type.cc
+++ b/gcc/rust/hir/rust-ast-lower-type.cc
@@ -19,6 +19,7 @@
 #include "rust-ast-lower-type.h"
 #include "rust-hir-map.h"
 #include "rust-hir-path.h"
+#include "rust-hir-type.h"
 #include "rust-path.h"
 #include "rust-pattern.h"
 
@@ -471,6 +472,24 @@ ASTLoweringType::visit (AST::TraitObjectType &type)
 type.get_locus (), type.is_dyn ());
 }
 
+void
+ASTLoweringType::visit (AST::ParenthesisedType &type)
+{
+  auto *inner = ASTLoweringType::translate (*type.get_type_in_parens (),
+   default_to_static_lifetime);
+
+  auto crate_num = mappings.get_current_crate ();
+  Analysis::NodeMapping mapping (crate_num, type.get_node_id (),
+mappings.get_next_hir_id (crate_num),
+mappings.get_next_localdef_id (crate_num));
+
+  // FIXME: Do we actually need to know if a type is parenthesized in the HIR?
+  // or can we just use the type in parens?
+  translated
+= new HIR::ParenthesisedType (mapping, std::unique_ptr (inner),
+ type.get_locus ());
+}
+
 HIR::GenericParam *
 ASTLowerGenericParam::translate (AST::GenericParam ¶m)
 {
diff --git a/gcc/rust/hir/rust-ast-lower-type.h 
b/gcc/rust/hir/rust-ast-lower-type.h
index 0429e3fcf98..26ca8684083 100644
--- a/gcc/rust/hir/rust-ast-lower-type.h
+++ b/gcc/rust/hir/rust-ast-lower-type.h
@@ -22,6 +22,7 @@
 #include "rust-ast-lower-base.h"
 #include "rust-ast-lower-expr.h"
 #include "rust-hir-path.h"
+#include "rust-type.h"
 
 namespace Rust {
 namespace HIR {
@@ -83,6 +84,7 @@ public:
   void visit (AST::NeverType &type) override;
   void visit (AST::TraitObjectTypeOneBound &type) override;
   void visit (AST::TraitObjectType &type) override;
+  void visit (AST::ParenthesisedType &type) override;
 
 private:
   ASTLoweringType (bool default_to_static_lifetime)
diff --git a/gcc/testsuite/rust/compile/auto_traits1.rs 
b/gcc/testsuite/rust/compile/auto_traits1.rs
new file mode 100644
index 000..192052d4815
--- /dev/null
+++ b/gcc/testsuite/rust/compile/auto_traits1.rs
@@ -0,0 +1,27 @@
+// { dg-additional-options "-frust-compile-until=typecheck" }
+
+#![feature(optin_builtin_traits)]
+
+pub unsafe auto trait Send {}
+#[lang = "sync"]
+pub unsafe auto trait Sync {}
+
+trait A {
+fn a_method(&self) {}
+}
+
+fn foo(a: &(dyn A + Send + Sync)) {
+a.a_method();
+}
+
+struct S;
+
+impl A for S {
+fn a_method(&self) {}
+}
+
+fn main() {
+let s = S;
+
+foo(&s);
+}
-- 
2.45.2

[COMMITTED 130/146] gccrs: ast-collector: Adapt to lang item type path segments

[arthur . cohen]

From: Arthur Cohen 

gcc/rust/ChangeLog:

* ast/rust-ast-collector.cc (TokenCollector::visit): Fix collector to 
better
handle lang item type path segments.
---
 gcc/rust/ast/rust-ast-collector.cc | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/gcc/rust/ast/rust-ast-collector.cc 
b/gcc/rust/ast/rust-ast-collector.cc
index f493da3fa3f..4c9c360c04d 100644
--- a/gcc/rust/ast/rust-ast-collector.cc
+++ b/gcc/rust/ast/rust-ast-collector.cc
@@ -543,10 +543,14 @@ TokenCollector::visit (TypePathSegment &segment)
 {
   // Syntax:
   //PathIdentSegment
-  auto ident_segment = segment.get_ident_segment ();
-  auto id = ident_segment.as_string ();
-  push (
-Rust::Token::make_identifier (ident_segment.get_locus (), std::move (id)));
+
+  auto locus = segment.is_lang_item ()
+? segment.get_locus ()
+: segment.get_ident_segment ().get_locus ();
+  auto segment_string = segment.is_lang_item ()
+ ? LangItem::PrettyString (segment.get_lang_item ())
+ : segment.get_ident_segment ().as_string ();
+  push (Rust::Token::make_identifier (locus, std::move (segment_string)));
 }
 
 void
@@ -558,10 +562,13 @@ TokenCollector::visit (TypePathSegmentGeneric &segment)
   //`<` `>`
   //| `<` ( GenericArg `,` )* GenericArg `,`? `>`
 
-  auto ident_segment = segment.get_ident_segment ();
-  auto id = ident_segment.as_string ();
-  push (
-Rust::Token::make_identifier (ident_segment.get_locus (), std::move (id)));
+  auto locus = segment.is_lang_item ()
+? segment.get_locus ()
+: segment.get_ident_segment ().get_locus ();
+  auto segment_string = segment.is_lang_item ()
+ ? LangItem::PrettyString (segment.get_lang_item ())
+ : segment.get_ident_segment ().as_string ();
+  push (Rust::Token::make_identifier (locus, std::move (segment_string)));
 
   if (segment.get_separating_scope_resolution ())
 push (Rust::Token::make (SCOPE_RESOLUTION, UNDEF_LOCATION));
-- 
2.45.2

[Bug rust/119508] Hundreds of rust tests XPASS

[pierre-emmanuel.patry at embecosm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508

--- Comment #1 from Pierre-Emmanuel Patry  ---
There is something funny happening here because canonical_paths1.rs should not
pass, nr2 tests are a list of test with an additional flag. We're using it to
reduce the gap between both name resolution.

Does XPASSEs happen solely on Solaris or does it also happen on x86_64 ?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/119508] Hundreds of rust tests XPASS

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508

--- Comment #2 from Andrew Pinski  ---
(In reply to Pierre-Emmanuel Patry from comment #1)
> There is something funny happening here because canonical_paths1.rs should
> not pass, nr2 tests are a list of test with an additional flag. We're using
> it to reduce the gap between both name resolution.
> 
> Does XPASSEs happen solely on Solaris or does it also happen on x86_64 ?

I see them also even on x86_64-linux-gnu.
Basically there is an ICE which is not reported and then the XPASS is due to
the diagnostic showing up.

crab1: internal compiler error: in visit, at
rust/resolve/rust-late-name-resolver-2.0.cc:342
0x2acc11f internal_error(char const*, ...)
   
/home/apinski/src/upstream-gcc-match/gcc/gcc/diagnostic-global-context.cc:517
0xb55de1 fancy_abort(char const*, int, char const*)
/home/apinski/src/upstream-gcc-match/gcc/gcc/diagnostic.cc:1749
0x92df13 Rust::Resolver2_0::Late::visit(Rust::AST::TypePath&)
   
/home/apinski/src/upstream-gcc-match/gcc/gcc/rust/resolve/rust-late-name-resolver-2.0.cc:342
0xc648de void
Rust::AST::DefaultASTVisitor::visit(Rust::AST::Type&)
   
/home/apinski/src/upstream-gcc-match/gcc/gcc/rust/ast/rust-ast-visitor.h:402
0xc648de Rust::AST::DefaultASTVisitor::visit(Rust::AST::InherentImpl&)
   
/home/apinski/src/upstream-gcc-match/gcc/gcc/rust/ast/rust-ast-visitor.cc:1018
0xe10cf3 std::function::operator()() const
   
/home/apinski/src/upstream-gcc-match/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/std_function.h:593
0xe10cf3
Rust::Resolver2_0::NameResolutionContext::scoped(Rust::Resolver2_0::Rib::Kind,
unsigned int, std::function, tl::optional)
   
/home/apinski/src/upstream-gcc-match/gcc/gcc/rust/resolve/rust-name-resolution-context.cc:122
0xe13c6f Rust::Resolver2_0::DefaultResolver::visit(Rust::AST::InherentImpl&)
   
/home/apinski/src/upstream-gcc-match/gcc/gcc/rust/resolve/rust-default-resolver.cc:77
0xc6399f void
Rust::AST::DefaultASTVisitor::visit(std::unique_ptr >&)
   
/home/apinski/src/upstream-gcc-match/gcc/gcc/rust/ast/rust-ast-visitor.h:406
0xc6399f Rust::AST::DefaultASTVisitor::visit(Rust::AST::Module&)
   
/home/apinski/src/upstream-gcc-match/gcc/gcc/rust/ast/rust-ast-visitor.cc:785
0xe10cf3 std::function::operator()() const
   
/home/apinski/src/upstream-gcc-match/gcc/objdir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/bits/std_function.h:593
0xe10cf3
Rust::Resolver2_0::NameResolutionContext::scoped(Rust::Resolver2_0::Rib::Kind,
unsigned int, std::function, tl::optional)
   
/home/apinski/src/upstream-gcc-match/gcc/gcc/rust/resolve/rust-name-resolution-context.cc:122
0xe14093 Rust::Resolver2_0::DefaultResolver::visit(Rust::AST::Module&)
   
/home/apinski/src/upstream-gcc-match/gcc/gcc/rust/resolve/rust-default-resolver.cc:43
0xe2e9df Rust::Resolver2_0::Late::go(Rust::AST::Crate&)
   
/home/apinski/src/upstream-gcc-match/gcc/gcc/rust/resolve/rust-late-name-resolver-2.0.cc:118
0xc925fd Rust::Session::compile_crate(char const*)
   
/home/apinski/src/upstream-gcc-match/gcc/gcc/rust/rust-session-manager.cc:648
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.
compiler exited with status 1

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/119508] Hundreds of rust tests XPASS

[pierre-emmanuel.patry at embecosm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508

--- Comment #5 from Pierre-Emmanuel Patry  ---
(In reply to Andrew Pinski from comment #4)
> I wonder if it is showing up due to running the testsuite with -jN

It is indeed showing up with -jN on my machine. Good call!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/119508] Hundreds of rust tests XPASS

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508

Sam James  changed:

   What|Removed |Added

   Keywords||testsuite-fail

--- Comment #3 from Sam James  ---
I see it too on x86_64 linux and it seems to flap a bit.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[COMMITTED 021/144] gccrs: [gccrs#2324] Add error message for E0532

[arthur . cohen]

From: Liam Naddell 

gcc/rust/ChangeLog:
* typecheck/rust-hir-type-check-pattern.cc:
Emit E0532 when trying to reference a Tuple or Struct variant
using a non Tuple or Struct pattern.

gcc/testsuite/ChangeLog:
* rust/compile/issue-2324-1.rs:
add test for E0532 with tuple enum variant
* rust/compile/issue-2324-2.rs:
add test for E0532 with struct enum variant

Signed-off-by: Liam Naddell 
---
 .../typecheck/rust-hir-type-check-pattern.cc  | 25 +++
 gcc/testsuite/rust/compile/issue-2324-1.rs| 19 ++
 gcc/testsuite/rust/compile/issue-2324-2.rs| 19 ++
 3 files changed, 63 insertions(+)
 create mode 100644 gcc/testsuite/rust/compile/issue-2324-1.rs
 create mode 100644 gcc/testsuite/rust/compile/issue-2324-2.rs

diff --git a/gcc/rust/typecheck/rust-hir-type-check-pattern.cc 
b/gcc/rust/typecheck/rust-hir-type-check-pattern.cc
index c469f6095d8..1a3d0ecd185 100644
--- a/gcc/rust/typecheck/rust-hir-type-check-pattern.cc
+++ b/gcc/rust/typecheck/rust-hir-type-check-pattern.cc
@@ -44,6 +44,31 @@ void
 TypeCheckPattern::visit (HIR::PathInExpression &pattern)
 {
   infered = TypeCheckExpr::Resolve (&pattern);
+
+  /*
+   * We are compiling a PathInExpression, which can't be a Struct or Tuple
+   * pattern. We should check that the declaration we are referencing IS NOT a
+   * struct pattern or tuple with values.
+   */
+
+  rust_assert (infered->get_kind () == TyTy::TypeKind::ADT);
+  TyTy::ADTType *adt = static_cast (infered);
+
+  HirId variant_id = UNKNOWN_HIRID;
+  bool ok
+= context->lookup_variant_definition (pattern.get_mappings ().get_hirid (),
+ &variant_id);
+  rust_assert (ok);
+
+  TyTy::VariantDef *variant = nullptr;
+  ok = adt->lookup_variant_by_id (variant_id, &variant);
+
+  TyTy::VariantDef::VariantType vty = variant->get_variant_type ();
+
+  if (vty != TyTy::VariantDef::VariantType::NUM)
+rust_error_at (
+  pattern.get_final_segment ().get_locus (), ErrorCode::E0532,
+  "expected unit struct, unit variant or constant, found tuple variant");
 }
 
 void
diff --git a/gcc/testsuite/rust/compile/issue-2324-1.rs 
b/gcc/testsuite/rust/compile/issue-2324-1.rs
new file mode 100644
index 000..afce1f3b570
--- /dev/null
+++ b/gcc/testsuite/rust/compile/issue-2324-1.rs
@@ -0,0 +1,19 @@
+enum State {
+Succeeded,
+Failed(u32),
+}
+
+fn print_on_failure(state: &State) {
+match *state {
+State::Succeeded => (),
+State::Failed => (), // { dg-error "expected unit struct, unit variant 
or constant, found tuple variant" }
+_ => ()
+}
+}
+
+fn main() {
+let b = State::Failed(1);
+
+print_on_failure(&b);
+
+}
diff --git a/gcc/testsuite/rust/compile/issue-2324-2.rs 
b/gcc/testsuite/rust/compile/issue-2324-2.rs
new file mode 100644
index 000..5ef40147961
--- /dev/null
+++ b/gcc/testsuite/rust/compile/issue-2324-2.rs
@@ -0,0 +1,19 @@
+enum State {
+Succeeded,
+Failed { x: u32 },
+}
+
+fn print_on_failure(state: &State) {
+match *state {
+State::Succeeded => (),
+State::Failed => (), // { dg-error "expected unit struct, unit variant 
or constant, found tuple variant" }
+_ => ()
+}
+}
+
+fn main() {
+let b = State::Failed{x: 1};
+
+print_on_failure(&b);
+
+}
-- 
2.45.2

[COMMITTED 080/144] gccrs: [gccrs#3141] Fix incorrect handling of overflow in numeric types

[arthur . cohen]

From: JoanVC 

Fixes gccrs#3141.

gcc/rust/ChangeLog:

* backend/rust-compile-expr.cc: Fix range checking for both integers 
and floats.
* hir/tree/rust-hir-expr.h: Add "negative_number" boolean to 
LiteralExpr class.

gcc/testsuite/ChangeLog:

* rust/compile/issue-3141.rs: New test.

Signed-off-by: Joan Vilardaga 
---
 gcc/rust/backend/rust-compile-expr.cc| 67 ++--
 gcc/rust/hir/tree/rust-hir-expr.h|  9 
 gcc/testsuite/rust/compile/issue-3141.rs | 62 ++
 3 files changed, 133 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/rust/compile/issue-3141.rs

diff --git a/gcc/rust/backend/rust-compile-expr.cc 
b/gcc/rust/backend/rust-compile-expr.cc
index 4c06e8e4090..0c0d993acde 100644
--- a/gcc/rust/backend/rust-compile-expr.cc
+++ b/gcc/rust/backend/rust-compile-expr.cc
@@ -235,7 +235,21 @@ void
 CompileExpr::visit (HIR::NegationExpr &expr)
 {
   auto op = expr.get_expr_type ();
-  auto negated_expr = CompileExpr::Compile (expr.get_expr ().get (), ctx);
+
+  const auto literal_expr = expr.get_expr ().get ();
+  if (op == NegationOperator::NEGATE
+  && literal_expr->get_expression_type () == HIR::Expr::ExprType::Lit)
+{
+  auto new_literal_expr = static_cast (literal_expr);
+  auto lit_type = new_literal_expr->get_lit_type ();
+  if (lit_type == HIR::Literal::LitType::INT
+ || lit_type == HIR::Literal::LitType::FLOAT)
+   {
+ new_literal_expr->set_negative ();
+   }
+}
+  auto negated_expr = CompileExpr::Compile (literal_expr, ctx);
+
   auto location = expr.get_locus ();
 
   // this might be an operator overload situation lets check
@@ -1506,6 +1520,10 @@ CompileExpr::compile_integer_literal (const 
HIR::LiteralExpr &expr,
   mpz_init (type_max);
   get_type_static_bounds (type, type_min, type_max);
 
+  if (expr.is_negative ())
+{
+  mpz_neg (ival, ival);
+}
   if (mpz_cmp (ival, type_min) < 0 || mpz_cmp (ival, type_max) > 0)
 {
   rust_error_at (expr.get_locus (),
@@ -1513,6 +1531,11 @@ CompileExpr::compile_integer_literal (const 
HIR::LiteralExpr &expr,
 tyty->get_name ().c_str ());
   return error_mark_node;
 }
+  // Other tests break if we don't reverse the negation
+  if (expr.is_negative ())
+{
+  mpz_neg (ival, ival);
+}
 
   tree result = wide_int_to_tree (type, wi::from_mpz (type, ival, true));
 
@@ -1530,6 +1553,8 @@ CompileExpr::compile_float_literal (const 
HIR::LiteralExpr &expr,
   rust_assert (expr.get_lit_type () == HIR::Literal::FLOAT);
   const auto literal_value = expr.get_literal ();
 
+  tree type = TyTyResolveCompile::compile (ctx, tyty);
+
   mpfr_t fval;
   if (mpfr_init_set_str (fval, literal_value.as_string ().c_str (), 10,
 MPFR_RNDN)
@@ -1539,12 +1564,44 @@ CompileExpr::compile_float_literal (const 
HIR::LiteralExpr &expr,
   return error_mark_node;
 }
 
-  tree type = TyTyResolveCompile::compile (ctx, tyty);
-
   // taken from:
   // see go/gofrontend/expressions.cc:check_float_type
-  mpfr_exp_t exp = mpfr_get_exp (fval);
-  bool real_value_overflow = exp > TYPE_PRECISION (type);
+  bool real_value_overflow;
+
+  if (mpfr_regular_p (fval) != 0)
+{
+  mpfr_exp_t exp = mpfr_get_exp (fval);
+  mpfr_exp_t min_exp;
+  mpfr_exp_t max_exp;
+
+  /*
+   * By convention, the radix point of the significand is just before the
+   * first digit (which is always 1 due to normalization), like in the C
+   * language, but unlike in IEEE 754 (thus, for a given number, the
+   * exponent values in MPFR and in IEEE 754 differ by 1).
+   */
+  switch (TYPE_PRECISION (type))
+   {
+   case 32:
+ min_exp = -128 + 1;
+ max_exp = 127 + 1;
+ break;
+   case 64:
+ min_exp = -1024 + 1;
+ max_exp = 1023 + 1;
+ break;
+   default:
+ rust_error_at (expr.get_locus (),
+"precision of type %<%s%> not supported",
+tyty->get_name ().c_str ());
+ return error_mark_node;
+   }
+  real_value_overflow = exp < min_exp || exp > max_exp;
+}
+  else
+{
+  real_value_overflow = false;
+}
 
   REAL_VALUE_TYPE r1;
   real_from_mpfr (&r1, fval, type, GMP_RNDN);
diff --git a/gcc/rust/hir/tree/rust-hir-expr.h 
b/gcc/rust/hir/tree/rust-hir-expr.h
index 8a2d82f6996..1ee10663708 100644
--- a/gcc/rust/hir/tree/rust-hir-expr.h
+++ b/gcc/rust/hir/tree/rust-hir-expr.h
@@ -93,6 +93,7 @@ class LiteralExpr : public ExprWithoutBlock
 {
   Literal literal;
   location_t locus;
+  bool negative_number = false;
 
 public:
   std::string as_string () const override
@@ -132,6 +133,14 @@ public:
 
   ExprType get_expression_type () const override final { return ExprType::Lit; 
}
 
+  bool is_negative () const { return negative_number; }
+  void set_negative ()
+  {
+rust_assert (get_lit_type () == Literal::LitType::IN

Re: Sourceware Survey 2025

[Mark Wielaard]

On Fri, Mar 14, 2025 at 01:38:26AM +0100, Mark Wielaard wrote:
> The Sourceware Project Leadership Committee would like to know who our
> users are, which hosted projects they feel part of, what services they
> rely on and what the priorities should be for new initiatives.
> 
> https://nextcloud.sfconservancy.org/apps/forms/s/xmGgmJFzSb2FZNd58cXMtAZp

Just 4 more days till the Sourceware Survey 2025 ends (Monday 31
March). We already received 85 replies. Thanks! Please do fill out the
survey if you haven't yet and have some time this weekend:
https://sourceware.org/survey-2025

> The survey will run till the end of March and contains 20 quick
> questions (none of the questions are mandatory, please feel free to
> skip any you find not relevant, but any answer you give is helpful.)
> 
> The overview page (where we will also publish the summary/results) is
> here https://sourceware.org/survey-2025 the direct link to the form is
> https://nextcloud.sfconservancy.org/apps/forms/s/xmGgmJFzSb2FZNd58cXMtAZp
> 
> Also if you like to discuss this survey or give feedback another way
> there is the Sourceware Open Office this Friday 14 March at 16:00 UTC
> in #overseers on irc.libera.chat. To get the right time in your local
> timezone: $ date -d "Fri Mar 14 16:00 UTC 2025"
> 
> Thanks,
> 
>  Frank Ch. Eigler, Christopher Faylor, Ian Kelling, Ian Lance Taylor,
>  Tom Tromey, Jon Turney, Mark J. Wielaard, Elena Zannoni

[Bug rust/119508] New: Hundreds of rust tests XPASS

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508

Bug ID: 119508
   Summary: Hundreds of rust tests XPASS
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rust
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org,
pierre-emmanuel.patry at embecosm dot com
  Target Milestone: ---
Target: amd64-pc-solaris2.11, sparcv9-sun-solaris2.11,
x86_64-pc-linux-gnu, i686-pc-linux-gnu

Currently, hundreds of rust tests XPASS on several targets, creating an insane
amount of noise in make mail-report.log output: with multilib testing (32 and
64-bit in each case), the numbers are like

  Linux/x86_64  900
  Linux/i686900
  Solaris/amd64 1864/4194
  Solaris/sparcv9   1398/932

The Solaris numbers even differ between as and gas configurations, haven't yet
checked why.

The output is always like this:

XPASS:
/vol/gcc/src/hg/master/local/gcc/testsuite/rust/compile/canonical_paths1.rs:
nr2 unexpectedly passed

There are several problems here, apart from the general fact of the XPASSes:

* The test name contains an absolute path name, which is a no-no because it
  makes comparing different test results difficult.

* There are always many (often 10 per multilib) instances of the same XPASS
  with no way to tell where they differ.

* The message is pretty useless as is: we already know the 'unexpectedly
passed'
  part from the XPASS; no need to repeat it.

It may be that gcc/testsuite/rust/compile/nr2/exclude just needs updating for
recent changes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/119508] Hundreds of rust tests XPASS

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug rust/119508] Hundreds of rust tests XPASS

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508

--- Comment #4 from Andrew Pinski  ---
I wonder if it is showing up due to running the testsuite with -jN

-- 
You are receiving this mail because:
You are on the CC list for the bug.