Re: [Patch, fortran] PR84674(12-15 regression) and PR117730 - non_overridable typebound proc problems

[Harald Anlauf]

Hi Paul,

Am 23.11.24 um 17:05 schrieb Paul Richard Thomas:

Hi All,

I was going through some of the older regressions and found pr84674, which
was distinctly low hanging fruit because the contributor has found the
offending bit of code. However, buried in this PR, on the grounds that it
looked similar, was what has now become pr117730. This was quite difficult
to diagnose and the cause of the problem was only found by instrumenting
class.c (add_proc_comp) to check the order in which non_overridable
procedure components were added to the vtables of derived type extensions
that are in different modules to the parent. Failure to keep the order the
same results, of course, in the wrong procedure being called.

The fixes for these PRs verge on 'obvious' but I thought that I should
submit them to the list because I want to push and backport them together.
Although PR117730 is not a regression, I think that it is sufficiently
limiting that it should be backported to active branches.


they are indeed almost obvious and fix possibly annoying wrong-code
issues.


OK for mainline and, after a week or two, backporting to 13- and
14-branches/


OK for mainline and backports.

Thanks for the patch!

Harald


Paul

Fortran: Fix non_overridable typebound proc problems [PR84674/117730].

2024-11-23  Paul Thomas  

gcc/fortran/ChangeLog

PR fortran/117730
* class.c (add_proc_comp): Only reject a non_overridable if it
has no overridden procedure and the component is already
present in the vtype.
PR fortran/84674
* resolve.cc (resolve_fl_derived): Do not build a vtable for a
derived type extension that is completely empty.

gcc/testsuite/ChangeLog

PR fortran/117730
* gfortran.dg/pr117730_a.f90: New test.
* gfortran.dg/pr117730_b.f90: New test.

PR fortran/84674
* gfortran.dg/pr84674.f90: New test.

[wwwdocs] Fortran changes, add description regarding commas in formats

[Jerry D]

Suggested docs change regarding fix to PR88052.

See attached diff file.

OK to push?

Regards,

Jerry
diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html
index 46dad391..2dc222e3 100644
--- a/htdocs/gcc-15/changes.html
+++ b/htdocs/gcc-15/changes.html
@@ -143,6 +143,10 @@ a work-in-progress.
   >gfortran documentation for details. These have been proposed
   (https://j3-fortran.org/doc/year/24/24-116.txt";>J3/24-116)
   for inclusion in the next Fortran standard.
+  Missing commas separating descriptors in input/output format strings are no
+  longer permitted by default and are rejected at run-time unless -std=legacy
+  is used at compile time.  See Fortran 2023 constraint C1302.
+  
 
 
 

[PATCH v2] replace atoi with strtol in varasm.cc (decode_reg_name_and_count) [PR114540]

[Heiko Eißfeldt]

Thanks for considering (when the time is right),

but in the meantime I found a technical problem with my patch, so I am
replacing it with a correct one (please ignore the older one).

The problem was assigning to an integer from a long result was plain
wrong, because ERANGE checking in strtol() was done not for the intended
integer range but of course for long int range.

I am now working on my first test cases to verify all edge cases for
invalid register numbers lead to the same error message.

I will append them here when they are ready.

Heiko

On 11/22/24 4:48 PM, Jeff Law wrote:



On 11/22/24 7:40 AM, Heiko Eißfeldt wrote:

A simple replacement of atoi() with strtol() in
varasm.cc:decode_reg_name_and_count().
Parsing now has errno ERANGE checking, eg no undetected overflow.

Being new it is difficult for me to come up with a good test case.

So I don't see any technical problem with the patch, but we don't have
any evidence there's any kind of bug here.  I guess if a port had a
bogus register name we could trigger a problem.

Given we're in stage3 (bugfixing) in preparation for the gcc-15
release in the spring, I'm going to defer this patch.

Jeff

diff --git a/gcc/varasm.cc b/gcc/varasm.cc
index acc4b4a0419..ee9df83e0e1 100644
--- a/gcc/varasm.cc
+++ b/gcc/varasm.cc
@@ -993,9 +993,12 @@ decode_reg_name_and_count (const char *asmspec, int 
*pnregs)
  break;
   if (asmspec[0] != 0 && i < 0)
{
- i = atoi (asmspec);
- if (i < FIRST_PSEUDO_REGISTER && i >= 0 && reg_names[i][0])
-   return i;
+ char *pend{};
+ errno = 0;
+ long j = strtol (asmspec, &pend, 10);
+ if (errno != ERANGE && j <= INT_MAX
+ && j < FIRST_PSEUDO_REGISTER && j >= 0 && reg_names[j][0])
+   return j;
  else
return -2;
}

Fix type compatibility for types with flexible array member [PR113688,PR114014,PR117724]

[Martin Uecker]

This patch tries fixes the errors we have because of
flexible array members.  I am bit unsure about the exception
for the mode. 

Bootstrapped and regression tested on x86_64.



Fix type compatibility for types with flexible array member 
[PR113688,PR114014,PR117724]

verify_type checks the compatibility of TYPE_CANONICAL using
gimple_canonical_types_compatible_p.   But it is stricter than what the
C standard requires and therefor inconsistent with how TYPE_CANONICAL is set
in the C FE.  Here, the logic is changed to ignore array size when one of 
the
types is a flexible array member.  To not get errors because of inconsistent
number of members, zero-sized arrays are not ignored anymore when checking
fields of a struct (which is stricter than what was done before).
Finally, a exception is added that allows the TYPE_MODE of a type with
flexible array member to differ from another compatible type.

PR c/113688
PR c/114014
PR c/117724

gcc/ChangeLog:
* tree.cc (gimple_canonical_types_compatible_p): Revise
logic for types with FAM.
(verify_type): Add exception for mode for types with FAM.

gcc/testsuite/ChangeLog:
* gcc.dg/pr113688.c: New test.
* gcc.dg/pr114014.c: New test.
* gcc.dg/pr117724.c: New test.

diff --git a/gcc/testsuite/gcc.dg/pr113688.c b/gcc/testsuite/gcc.dg/pr113688.c
new file mode 100644
index 000..8dee8c86f1b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr113688.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-g" } */
+
+struct S{int x,y[1];}*a;
+int main(void){
+   struct S{int x,y[];};
+}
+
diff --git a/gcc/testsuite/gcc.dg/pr114014.c b/gcc/testsuite/gcc.dg/pr114014.c
new file mode 100644
index 000..ab783f4f85d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr114014.c
@@ -0,0 +1,14 @@
+/* PR c/114014
+ * { dg-do compile }
+ * { dg-options "-std=c23 -g" } */
+
+struct r {
+  int a;
+  char b[];
+};
+struct r {
+  int a;
+  char b[0];
+}; /* { dg-error "redefinition" } */
+
+
diff --git a/gcc/testsuite/gcc.dg/pr117724.c b/gcc/testsuite/gcc.dg/pr117724.c
new file mode 100644
index 000..d631daeb644
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr117724.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-g" } */
+
+struct {
+  unsigned long len;
+  unsigned long size;
+  char data[];
+}; /* { dg-warning "unnamed struct" } */
+struct {
+  struct {
+unsigned long len;
+unsigned long size;
+char data[6];
+  };
+}; /* { dg-warning "unnamed struct" } */
+
diff --git a/gcc/tree.cc b/gcc/tree.cc
index 1da06c7d4e9..dbf6b180496 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -13900,8 +13900,11 @@ gimple_canonical_types_compatible_p (const_tree t1, 
const_tree t2,
   || TREE_CODE (t1) == NULLPTR_TYPE)
 return true;
 
-  /* Can't be the same type if they have different mode.  */
-  if (TYPE_MODE (t1) != TYPE_MODE (t2))
+  /* Can't be compatible types if they have different mode.  We allow
+ mismatching modes for types with flexible array member.  */
+  if (!flexible_array_type_p (t1)
+  && !flexible_array_type_p (t2)
+  && (TYPE_MODE (t1) != TYPE_MODE (t2)))
 return false;
 
   /* Non-aggregate types can be handled cheaply.  */
@@ -13952,7 +13955,7 @@ gimple_canonical_types_compatible_p (const_tree t1, 
const_tree t2,
 {
 case ARRAY_TYPE:
   /* Array types are the same if the element types are the same and
-the number of elements are the same.  */
+minimum and maximum index are the same.  */
   if (!gimple_canonical_types_compatible_p (TREE_TYPE (t1), TREE_TYPE (t2),
trust_type_canonical)
  || TYPE_STRING_FLAG (t1) != TYPE_STRING_FLAG (t2)
@@ -14046,23 +14049,35 @@ gimple_canonical_types_compatible_p (const_tree t1, 
const_tree t2,
 f1 || f2;
 f1 = TREE_CHAIN (f1), f2 = TREE_CHAIN (f2))
  {
-   /* Skip non-fields and zero-sized fields.  */
-   while (f1 && (TREE_CODE (f1) != FIELD_DECL
- || (DECL_SIZE (f1)
- && integer_zerop (DECL_SIZE (f1)
+   /* Skip non-fields.  */
+   while (f1 && (TREE_CODE (f1) != FIELD_DECL))
  f1 = TREE_CHAIN (f1);
-   while (f2 && (TREE_CODE (f2) != FIELD_DECL
- || (DECL_SIZE (f2)
- && integer_zerop (DECL_SIZE (f2)
+   while (f2 && (TREE_CODE (f2) != FIELD_DECL))
  f2 = TREE_CHAIN (f2);
if (!f1 || !f2)
  break;
+
+   tree t1 = TREE_TYPE (f1);
+   tree t2 = TREE_TYPE (f2);
+
+   /* Special case for flexible array members.  */
+   if (TREE_CHAIN (f1) == NULL_TREE
+   && TREE_CHAIN (f2) == NULL_TREE
+   && TREE_CODE (t1) =

Re: [PATCH] build: Remove INCLUDE_MEMORY [PR117737]

[Andrew Pinski]

On Sat, Nov 23, 2024 at 7:25 AM Thomas Schwinge  wrote:
>
> Hi Andrew!
>
> On 2024-11-22T13:15:13-0800, Andrew Pinski  wrote:
> > Since diagnostic.h is included in over half of the sources, requiring to 
> > `#define INCLUDE_MEMORY`
> > does not make sense. Instead lets unconditionally include memory in 
> > system.h.
> >
> > The majority of this patch is just removing `#define INCLUDE_MEMORY` from 
> > the sources which currently
> > have it.
>
> Thanks!
>
> > --- a/gcc/system.h
> > +++ b/gcc/system.h
> > @@ -222,6 +222,7 @@ extern int fprintf_unlocked (FILE *, const char *, ...);
> >  #ifdef INCLUDE_FUNCTIONAL
> >  # include 
> >  #endif
> > +# include 
> >  # include 
> >  # include 
> >  # include 
> > @@ -758,13 +759,6 @@ private:
> >  #define LIKELY(x) (__builtin_expect ((x), 1))
> >  #define UNLIKELY(x) (__builtin_expect ((x), 0))
> >
> > -/* Some of the headers included by  can use "abort" within a
> > -   namespace, e.g. "_VSTD::abort();", which fails after we use the
> > -   preprocessor to redefine "abort" as "fancy_abort" below.  */
> > -
> > -#ifdef INCLUDE_MEMORY
> > -# include 
> > -#endif
> >
> >  #ifdef INCLUDE_MUTEX
> >  # include 
>
> Should we additionally '#pragma GCC poison INCLUDE_MEMORY' (further down
> in the file), so that it's documented, and other uses (external GCC
> parts, WIP work, etc.) also get cleaned up, and nobody remains confused
> about any lingering '#define INCLUDE_MEMORY's (even if they're harmless)?

poison won't work since it is not retroactive.
We could add:
#ifdef INCLUDE_MEMORY
#error "Don't define INCLUDE_MEMORY any more as it is automatic"
#endif

But I suspect that would break plugins which need to compile with say
GCC 14 and GCC 15 and you don't know the version you are compiling for
until after you include plugin.h.
So I think leaving it without the check is the best.

Thanks,
Andrew

>
>
> Grüße
>  Thomas

Re: [gcc-wwwdocs PATCH] gcc-15: Mention new ISA and Diamond Rapids support for x86_64 backend

[Gerald Pfeifer]

On Mon, 11 Nov 2024, Haochen Jiang wrote:
> This patch will add recent new ISA and arch support for x86_64 backend into
> gcc-wwwdocs.

> +  New ISA extension support for Intel AMX-AVX512 was added.

In all these cases, can we just sasy "ISA extension support ... was 
added" and drop the "New"?

> +  compiler switch. 128 and 256 bit MOVRS intrinsics are available via

"128- and 256-bit..."

> +  The EVEX version support for Intel SM4 was added.
> +  New 512-bit SM4 intrinsics are available via the
> +  -msm4 -mavx10.2-512 compiler switch.

Just "EVEX version support..."

> +AMX-FP8, AMX-MOVRS, AMX-TF32, AMX-TRANSPOSE, APX_F, AVX10.2 with 512 bit

"512-bit"

>Support for Xeon Phi CPUs (a.k.a. Knight Landing and Knight Mill) were
>removed in GCC 15. GCC will no longer accept -march=knl,
>-march=knm,-mavx5124fmaps,

"...no longer accepts..."

And make the last ", and -mavx5124fmaps" (adding a blank and 
the word "and").

This is fine with the above changes.

Thank you,
Gerald

[PATCH] gimplefe: Fix handling of ')'/'}' after a parse error [PR117741]

[Andrew Pinski]

The problem here is c_parser_skip_until_found stops at a closing nesting
delimiter without consuming it. So if we don't consume it in
c_parser_gimple_compound_statement, we would go into an infinite loop. The C
parser similar code in c_parser_statement_after_labels to handle this specific
case too.

PR c/117741

gcc/c/ChangeLog:

* gimple-parser.cc (c_parser_gimple_compound_statement): Handle
CPP_CLOSE_PAREN/CPP_CLOSE_SQUARE with an error and skipping the token.

gcc/testsuite/ChangeLog:

* gcc.dg/gimplefe-54.c: New test.

Signed-off-by: Andrew Pinski 
---
 gcc/c/gimple-parser.cc | 10 ++
 gcc/testsuite/gcc.dg/gimplefe-54.c | 10 ++
 2 files changed, 20 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/gimplefe-54.c

diff --git a/gcc/c/gimple-parser.cc b/gcc/c/gimple-parser.cc
index 81f3921c876..4763cf23313 100644
--- a/gcc/c/gimple-parser.cc
+++ b/gcc/c/gimple-parser.cc
@@ -664,6 +664,16 @@ c_parser_gimple_compound_statement (gimple_parser &parser, 
gimple_seq *seq)
break;
  }
 
+   case CPP_CLOSE_PAREN:
+   case CPP_CLOSE_SQUARE:
+ /* Avoid infinite loop in error recovery:
+c_parser_skip_until_found stops at a closing nesting
+delimiter without consuming it, but here we need to consume
+it to proceed further.  */
+ c_parser_error (parser, "expected statement");
+ c_parser_consume_token (parser);
+   break;
+
default:
 expr_stmt:
  c_parser_gimple_statement (parser, seq);
diff --git a/gcc/testsuite/gcc.dg/gimplefe-54.c 
b/gcc/testsuite/gcc.dg/gimplefe-54.c
new file mode 100644
index 000..71a49ac39c2
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/gimplefe-54.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-fgimple" } */
+
+/* PR c/117741 */
+/* Make sure after a parsing error we
+   don't go into an infinite loop. */
+
+int i;
+void __GIMPLE foo() {
+  i = ) /* { dg-error "" } */
-- 
2.43.0

optimize basic_string

[Jan Hubicka]

Hi,
another common source of unnecesary throw_bad_alloc calls is 
basic_string::_M_create.
basic_string<_CharT, _Traits, _Alloc>::
_M_create(size_type& __capacity, size_type __old_capacity)
{
  // _GLIBCXX_RESOLVE_LIB_DEFECTS
  // 83.  String::npos vs. string::max_size()
  if (__capacity > max_size())
std::__throw_length_error(__N("basic_string::_M_create"));

  // The below implements an exponential growth policy, necessary to
  // meet amortized linear time requirements of the library: see
  // http://gcc.gnu.org/ml/libstdc++/2001-07/msg00085.html.
  if (__capacity > __old_capacity && __capacity < 2 * __old_capacity)
{
  __capacity = 2 * __old_capacity;
  // Never allocate a string bigger than max_size.
  if (__capacity > max_size())
__capacity = max_size();
}

  // NB: Need an array of char_type[__capacity], plus a terminating
  // null char_type() element.
  return _S_allocate(_M_get_allocator(), __capacity + 1);
}

The code makes it visible that string is never bigger then max_size, however + 1
makes it one byte bigger than maximal size allowed by allocator.  I believe
this is by miscounting the 0 at the end of string in max_size function:

-  { return (_Alloc_traits::max_size(_M_get_allocator()) - 1) / 2; }
+  { return _Alloc_traits::max_size(_M_get_allocator()) / 2 - 1; }

Path also adds __builtin_unreachable to express value ranges of capacity and 
length.
This makes it possible to optimize out throw when copying strings as in the 
testcase.

std::string
test (std::string &a)
{
return a;
}

This now yields the following:

struct string test (struct string & a)
{
  size_type __siz;
  struct string & _2(D);
  char[16] * _4;
  char * _5;
  char * _7;
  char * prephitmp_10;
  char * pretmp_11;
  char _15;
  char * _18;
  char * _27;
  long unsigned int _32;

   [local count: 1073741824]:
  _4 = &MEM[(struct basic_string *)_2(D)].D.32970._M_local_buf;
  MEM[(struct _Alloc_hider *)_2(D)]._M_p = _4;
  _5 = MEM[(const struct basic_string *)a_3(D)]._M_dataplus._M_p;
  __siz_6 = MEM[(const struct basic_string *)a_3(D)]._M_string_length;
  if (__siz_6 > 15)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 354334800]:
  _32 = __siz_6 + 1;
  _27 = operator new (_32);
  MEM[(struct basic_string *)_2(D)]._M_dataplus._M_p = _27;
  MEM[(struct basic_string *)_2(D)].D.32970._M_allocated_capacity = __siz_6;
  goto ; [100.00%]

   [local count: 719407024]:
  if (__siz_6 == 1)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 353024841]:
  _15 = MEM[(const char_type &)_5];
  MEM[(char_type &)_2(D) + 16] = _15;

   [local count: 350316931]:
  goto ; [100.00%]

   [local count: 474808633]:
  if (__siz_6 == 0)
goto ; [73.78%]
  else
goto ; [26.22%]

   [local count: 334966574]:
  # _7 = PHI <_4(7), _27(3)>
  __builtin_memcpy (_7, _5, __siz_6);
  pretmp_11 = MEM[(const struct basic_string *)_2(D)]._M_dataplus._M_p;

   [local count: 1038308344]:
  # prephitmp_10 = PHI <_4(6), pretmp_11(8)>
  MEM[(struct basic_string *)_2(D)]._M_string_length = __siz_6;
  _18 = prephitmp_10 + __siz_6;
  MEM[(char_type &)_18] = 0;
  return _2(D);

}

.text segment is reduced from 213 bytes to 192 (saving 2 conditionals
and 2 calls to throw)

I find it funny that the code special cases a.size () == 1 to copy single byte
and a.size () == 0 to bypass memcpy call.  I would say it is job of middle-end
to optimize memcpy reasonably even for small blocks.  Was this based on some 
data
showing that many strings have size of 0 and 1 which is not visible to
compiler?

regtested x86_64-linux, OK?

Honza

libstdc++-v3/ChangeLog:

* include/bits/basic_string.h:

gcc/testsuite/ChangeLog:

* g++.dg/tree-ssa/string-1.C: New test.

diff --git a/gcc/testsuite/g++.dg/tree-ssa/string-1.C 
b/gcc/testsuite/g++.dg/tree-ssa/string-1.C
new file mode 100644
index 000..d38c23a7628
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/string-1.C
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -std=c++20 -fdump-tree-optimized" } */
+#include 
+std::string
+test (std::string &a)
+{
+   return a;
+}
+/* { dg-final { scan-tree-dump-not "throw" "optimized" } } */
diff --git a/libstdc++-v3/include/bits/basic_string.h 
b/libstdc++-v3/include/bits/basic_string.h
index f5b320099b1..d754deb28ed 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -1079,20 +1079,30 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
   size_type
   size() const _GLIBCXX_NOEXCEPT
-  { return _M_string_length; }
+  {
+   size_type __siz = _M_string_length;
+   if (__siz > max_size ())
+ __builtin_unreachable ();
+   return __siz;
+  }
 
   ///  Returns the number of characters in the string, not including any
   ///  null-termination.
   _GLIBCXX_NODISCARD _GLIBC

Re: [RFC/RFA][PATCH v6 03/12] RISC-V: Add CRC expander to generate faster CRC.

[Jeff Law]

On 11/13/24 7:16 AM, Mariam Arutunian wrote:




To address this, I added code in |target-supports.exp| and modified the 
relevant tests.

I've attached the patch. Could you please check whether it is correct?

Just a few more notes.

I revamped the changes to emit_crc.  I think the right way to fix that 
riscv problem you were chasing was actually higher in the call chain.


If you look at the setup code when you use the backend expanders, it 
looks like this:



  /* Use target specific expansion if it exists.
 Otherwise, generate table-based CRC.  */
  if (direct_internal_fn_supported_p (fn, tree_pair (data_type, result_type),
  OPTIMIZE_FOR_SPEED))
{
  class expand_operand ops[4];
  create_call_lhs_operand (&ops[0], dest, TYPE_MODE (result_type));
  create_input_operand (&ops[1], crc, TYPE_MODE (result_type));
  create_input_operand (&ops[2], data, TYPE_MODE (data_type));
  create_input_operand (&ops[3], polynomial, TYPE_MODE (result_type));
  insn_code icode = convert_optab_handler (optab, TYPE_MODE (data_type),
   TYPE_MODE (result_type));
  expand_insn (icode, 4, ops);
  assign_call_lhs (lhs, dest, &ops[0]);
}



We need to do basically the same thing (at least for the return value) 
when we expand via a table.  If you look in assign_call_lhs is has all 
the necessary bits to handle the promoted subreg case correctly.


I've changed the table based expansion clause to look like this:


  else
{
  /* We're bypassing all the operand conversions that are done in the
 case when we get an icode, operands and pass that off to expand_insn.

 That path has special case handling for promoted return values which
 we must emulate here (is the same kind of special treatment ever
 needed for input arguments here?).

 In particular we do not want to store directly into a promoted
 SUBREG destination, instead store into a suitably sized pseudo.  */
  rtx orig_dest = dest;
  if (SUBREG_P (dest) && SUBREG_PROMOTED_VAR_P (dest))
dest = gen_reg_rtx (GET_MODE (dest));

  /* If it's IFN_CRC generate bit-forward CRC.  */
  if (fn == IFN_CRC)
expand_crc_table_based (dest, crc, data, polynomial,
TYPE_MODE (data_type));
  else
/* If it's IFN_CRC_REV generate bit-reversed CRC.  */
expand_reversed_crc_table_based (dest, crc, data, polynomial,
 TYPE_MODE (data_type),
 generate_reflecting_code_standard);

  /* Now get the return value where it needs to be, taking care to
 ensure it's promoted appropriately if the ABI demands it.

 Re-use assign_call_lhs to handle the details.  */
  class expand_operand ops[4];
  create_call_lhs_operand (&ops[0], dest, TYPE_MODE (result_type));
  ops[0].value = dest;
  assign_call_lhs (lhs, orig_dest, &ops[0]);
}



And I'm also starting to fix the word_size assumptions, particularly in 
the table expansion path.  I know we used word_size to simplify stuff in 
the target bits and that's probably still the right thing to do in those 
target specific paths.  But for the table lookup path we shouldn't 
really need to do that.  By removing the word_size assumptions we also 
can avoid needing to make the CRC builtins conditional on target 
specific properties -- I'd really likely to avoid having the 
availability of the builtins be dependent on the target word size.


In the testsuite, tests which use integers that don't fit in 16 bits 
need a magic marker so they they're not used on 16 bit integer targets.


/* { dg-require-effective-target int32plus } */


There were two tests using assert which we generally try to avoid. 
Instead we should just do a simple equality test and abort if the test 
is false.  Also execution tests need to exit with zero status when they 
pass.  I've fixed those problems as well.


I've pushed the current state to users/jlaw/mariam-crc-branch.  I 
haven't yet incorporated your risc-v testsuite fix yet though.  I have 
done some rebasing/squashing of patches where it made sense.  I'm hoping 
to get the various final nits cleaned up this week.


Jeff

Re: [wwwdocs] Fortran changes, add description regarding commas in formats

[Jerry D]

On 11/23/24 10:59 AM, Harald Anlauf wrote:

Am 23.11.24 um 19:35 schrieb Jerry D:

Suggested docs change regarding fix to PR88052.

See attached diff file.

OK to push?

Regards,

Jerry


Jerry,

for clarification: isn't it the language standard option used when
compiling the main that is relevant?  The main might be compiled
separately from a module containing the offending legacy code,
where it may or may not be diagnosed at compile time.

Otherwise OK from my side.

Thanks,
Harald



Indeed, only the -std= specified on the main program unit is relevant.

I will clarify this in my description. I am working on a separate patch 
that will check the format strings at compile time when possible. We do 
not check format strings in character variables at compile time and I am 
not planning to this. (It might be possible in a translation or resolve 
stage if the character variable is a constant).


I will update and push this doc change.

Thanks Herald.

Re: [PATCH] rs6000, fix test builtins-1-p10-runnable.c

[Mike Stump]

On Nov 21, 2024, at 7:49 AM, Carl Love  wrote:
> 
> Ping 6
> 
> On 11/14/24 1:36 PM, Carl Love wrote:
>> Ping 5
>> 
>> On 11/5/24 8:27 AM, Carl Love wrote:
>>> Ping 4
>>> 
>>> On 10/28/24 4:28 PM, Carl Love wrote:
 Ping 3
 
 On 10/17/24 1:31 PM, Carl Love wrote:
> Ping 2
> 
> On 10/9/24 7:43 AM, Carl Love wrote:
>> Ping, FYI this is a fairly simple fix to a testcase.
>> 
>> On 10/3/24 8:11 AM, Carl Love wrote:
>>> 
>>> The builtins-1-10-runnable.c has the debugging inadvertently enabled.  
>>> The test uses #ifdef to enable/disable the debugging. Unfortunately, 
>>> the #define DEBUG was set to 0 to disable debugging and enable the call 
>>> to abort in case of error.  The #define should have been removed to 
>>> disable debugging.
>>> Additionally, a change in the expected output which was made for 
>>> testing purposes was not removed.  Hence, the test is printing that 
>>> there was an error not calling abort.  The result is the test does not 
>>> get reported as failing.
>>> 
>>> This patch removes the #define DEBUG to enable the call to abort and 
>>> restores the expected output to the correct value. The patch was tested 
>>> on a Power 10 without the #define DEBUG to verify that the test does 
>>> fail with the incorrect expected value.  The correct expected value was 
>>> then restored.  The test reports 19 expected passes and no errors.
>>> 
>>> Please let me know if this patch is acceptable for mainline.

Usually rs6000 is covered well, Ok.

>>> ---
>>>  
>>> 
>>> rs6000, fix test builtins-1-p10-runnable.c
>>> 
>>> The test has two issues:
>>> 
>>> 1) The test should generate execute abort() if an error is found.
>>> However, the test contains a #define 0 which actually enables the
>>> error prints not exectuting void() because the debug code is protected
>>> by an #ifdef not #if.  The #define DEBUG needs to be removed to so the
>>> test will abort on an error.
>>> 
>>> 2) The vec_i_expected output was tweeked to test that it would fail.
>>> The test value was not removed.
>>> 
>>> By removing the #define DEBUG, the test fails and reports 1 failure.
>>> Removing the intentionally wrong expected value results in the test
>>> passing with no errors as expected.
>>> 
>>> gcc/testsuite/ChangeLog:
>>> * gcc.target/powerpc/builtins-1-p10-runnable.c: Remove #define
>>> DEBUG.Replace vec_i_expected value with correct value.
>>> ---
>>>  gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c | 5 +
>>>  1 file changed, 1 insertion(+), 4 deletions(-)
>>> 
>>> diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c 
>>> b/gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c
>>> index 222c8b3a409..3e8a1c736e3 100644
>>> --- a/gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c
>>> +++ b/gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c
>>> @@ -25,8 +25,6 @@
>>>  #include 
>>>  #include 
>>> 
>>> -#define DEBUG 0
>>> -
>>>  #ifdef DEBUG
>>>  #include 
>>>  #endif
>>> @@ -281,8 +279,7 @@ int main()
>>>  /* Signed word multiply high */
>>>  i_arg1 = (vector int){ 2147483648, 2147483648, 2147483648, 
>>> 2147483648 };
>>>  i_arg2 = (vector int){ 2, 3, 4, 5};
>>> -//vec_i_expected = (vector int){-1, -2, -2, -3};
>>> -vec_i_expected = (vector int){1, -2, -2, -3};
>>> +vec_i_expected = (vector int){-1, -2, -2, -3};
>>> 
>>>  vec_i_result = vec_mulh (i_arg1, i_arg2);

improve std::deque::_M_reallocate_map

[Jan Hubicka]

Hi,
looking into reason why we still do throw_bad_alloc in clang binary I noticed
that quite few calls come from deque::_M_reallocate_map.  This patch adds
unreachable to limit the size of realloc_map.  _M_reallocate_map is called only
if new size is smaller then max_size.  map is an array holding pointers to
entries of fixed size.

Since rellocation is done by doubling the map size, I think the maximal size of
map allocated is max_size / deque_buf_size rounded up times two.  This should
be also safe for overflows since we have extra bit.

map size is always at least 8. Theoretically this computation may be wrong for
very large T, but in that case callers should never reallocate.

On the testcase I get:
jh@shroud:~> ~/trunk-install-new4/bin/g++ -O2 dq.C -c ; size -A dq.o | grep text
.text  284  0
.text._ZNSt5dequeIiSaIiEE17_M_reallocate_mapEmb485  0
.text.unlikely  10  0
jh@shroud:~> ~/trunk-install-new5/bin/g++ -O2 dq.C -c ; size -A dq.o | grep text
.text  284  0
.text._ZNSt5dequeIiSaIiEE17_M_reallocate_mapEmb465  0
.text.unlikely  10  0

so this saves about 20 bytes of rellocate_map, which I think is worthwhile.
Curiously enough gcc14 does:

jh@shroud:~> g++ -O2 dq.C -c ; size -A dq.o | grep text
.text 604  0
.text.unlikely 10  0

which is 145 bytes smaller. Obvoius difference is that _M_reallocate_map gets 
inlined.
Compiling gcc14 preprocessed file with trunk gives:

jh@shroud:~> g++ -O2 dq.C -S ; size -A dq.o | grep text
.text 762  0
.text.unlikely 10  0

So inlining is due to changes at libstdc++ side, but code size growth is due to
something else.

For clang this reduced number of thris_bad_new_array_length from 121 to 61.

Regtested x86_64-linux, OK?

libstdc++-v3/ChangeLog:

* include/bits/deque.tcc: Compute maximal size of alloc_map.

gcc/testsuite/ChangeLog:

* g++.dg/tree-ssa/deque.C: New test.


diff --git a/gcc/testsuite/g++.dg/tree-ssa/deque.C 
b/gcc/testsuite/g++.dg/tree-ssa/deque.C
new file mode 100644
index 000..c79de9b2161
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/deque.C
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -fdump-tree-optimized" } */
+#include 
+void
+test(std::deque &q, int v)
+{
+  q.push_back (v);
+}
+// { dg-final { scan-tree-dump-not "throw_bad_alloc" "optimized" } }
diff --git a/libstdc++-v3/include/bits/deque.tcc 
b/libstdc++-v3/include/bits/deque.tcc
index deb010a0ebb..653354f90a7 100644
--- a/libstdc++-v3/include/bits/deque.tcc
+++ b/libstdc++-v3/include/bits/deque.tcc
@@ -955,6 +955,10 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
  size_type __new_map_size = this->_M_impl._M_map_size
 + std::max(this->_M_impl._M_map_size,
__nodes_to_add) + 2;
+ size_type __max = __deque_buf_size(sizeof(_Tp));
+ if (__new_map_size > ((max_size() + __deque_buf_size(sizeof(_Tp)) - 1)
+   / __deque_buf_size(sizeof(_Tp))) * 2)
+   __builtin_unreachable ();
 
  _Map_pointer __new_map = this->_M_allocate_map(__new_map_size);
  __new_nstart = __new_map + (__new_map_size - __new_num_nodes) / 2

Re: [PATCH v2] replace atoi with strtol in varasm.cc (decode_reg_name_and_count) [PR114540]

[Jakub Jelinek]

On Sat, Nov 23, 2024 at 07:26:55PM +0100, Heiko Eißfeldt wrote:
> --- a/gcc/varasm.cc
> +++ b/gcc/varasm.cc
> @@ -993,9 +993,12 @@ decode_reg_name_and_count (const char *asmspec, int 
> *pnregs)
> break;
>if (asmspec[0] != 0 && i < 0)
>   {
> -   i = atoi (asmspec);
> -   if (i < FIRST_PSEUDO_REGISTER && i >= 0 && reg_names[i][0])
> - return i;
> +   char *pend{};

Why the {} strtol will write to pend no matter what, so it doesn't need to
be cleared.

> +   errno = 0;
> +   long j = strtol (asmspec, &pend, 10);
> +   if (errno != ERANGE && j <= INT_MAX
> +   && j < FIRST_PSEUDO_REGISTER && j >= 0 && reg_names[j][0])
> + return j;

If all conditions don't fit on a single line, all should be written
on separate lines, so
  if (errno != ERANGE
  && ...
  && ...)
I'm not sure what is the point of the j <= INT_MAX check,
FIRST_PSEUDO_REGISTER will surely be smaller than INT_MAX on all targets.

Furthermore, when strtol is used, I wonder if that
  for (i = strlen (asmspec) - 1; i >= 0; i--)
if (! ISDIGIT (asmspec[i]))
  break;
isn't just a waste of time, if it wouldn't be enough to test that
ISDIGIT (asmspec[0]) and *pend == '\0' after the strtol call (if not,
it should fallthrough to the name matching rather than just return -2.
So
-  for (i = strlen (asmspec) - 1; i >= 0; i--)
-   if (! ISDIGIT (asmspec[i]))
- break;
-  if (asmspec[0] != 0 && i < 0)
-   {
- i = atoi (asmspec);
- if (i < FIRST_PSEUDO_REGISTER && i >= 0 && reg_names[i][0])
-   return i;
- else
-   return -2;
-   }
+  if (ISDIGIT (asmspec[0]))
+   {
+ char *pend;
+ errno = 0;
+ unsigned long j = strtoul (asmspec, &pend, 10);
+ if (*pend == '\0')
+   {
+ if (errno != ERANGE
+ && j < FIRST_PSEUDO_REGISTER
+ && reg_names[j][0])
+   return j;
+ else
+   return -2;
+   }
+   }

Jakub

Re: [PATCH] Don't skip CodeView data for partially cold functions

[Jeff Law]

On 11/12/24 5:57 PM, Mark Harmstone wrote:

If a function is contained in two sections, for instance if it is
partially cold, it gets a DW_AT_ranges attribute in its DIE rather than
the normal DW_AT_low_pc and DW_AT_high_pc.

There's no way to express this in CodeView, so rather than skipping the
function entirely, use the labels in the first entry in the range list.

gcc/
* dwarf2codeview.cc (write_function): If no DW_AT_low_pc or
DW_AT_high_pc in DIE, handle DW_AT_ranges instead.
* dwarf2out.cc (struct dw_ranges): Move to dwarf2out.h.
(get_AT_range_list): New function.
(get_range_list_labels): New function.
* dwarf2out.h (struct dw_ranges): Move from dwarf2out.cc.
(get_AT_range_list, get_range_list_labels): Add declarations.
Presumably the first entries in the range list are for the "main" part 
of the function and thus you're getting something generally useful as 
opposed to just a random blob of (potentially cold) cold?






@@ -5532,6 +5513,36 @@ get_AT_file (dw_die_ref die, enum dwarf_attribute 
attr_kind)
return a ? AT_file (a) : NULL;
  }
  
+dw_ranges *

+get_AT_range_list (dw_die_ref die, enum dwarf_attribute attr_kind)
Needs a function comment, similarly for get_range_list_labels.  They're 
pretty simple functions, but even so we do try to make sure everything 
gets a basic function comment.  So maybe something like


/* Return the range list for DIE with type ATTR_KIND or NULL if no
   range list exists.  */

For the get_AT_range_list.  Something along the same lines for 
get_range_list_labels.


OK with that change.

jeff

Re: [PATCH] build: Discard obsolete references to $(GCC_PARTS)

[Maciej W. Rozycki]

On Tue, 19 Nov 2024, Joseph Myers wrote:

> > The $(GCC_PARTS) variable was deleted with the Makefile rework in commit 
> > fa9585134f6f ("libgcc move to the top level")[1] back in 2007, and yet 
> > the Ada and Modula 2 frontends added references to this variable later 
> > on, with commit e972fd5281b7 ("[Ada] clean ups in Makefiles")[2] back in 
> > 2011 and commit 1eee94d35177 ("Merge modula-2 front end onto gcc.") back 
> > in 2022 respectively.
> > 
> > I guess it's because the frontends lived too long externally.  Discard 
> > the references then, they serve no purpose nowadays.
> 
> OK.

 Applied now, with a copy-pasto fixed in one of the URLs.  Thank you for 
your review.

  Maciej

Re: [PATCH 02/15] testsuite: Expand coverage for `__builtin_memcpy'

[Maciej W. Rozycki]

On Tue, 19 Nov 2024, Jeff Law wrote:

> > gcc/testsuite/
> > * gcc.c-torture/execute/memcpy-a1.c: New file.
> > * gcc.c-torture/execute/memcpy-a2.c: New file.
> > * gcc.c-torture/execute/memcpy-a4.c: New file.
> > * gcc.c-torture/execute/memcpy-a8.c: New file.
> > * gcc.c-torture/execute/memcpy-ax.h: New file.
> OK.  There's some chance for timing fallouts on things like qemu emulated
> targets, but I wouldn't let that get in the way of adding coverage. The total
> memory sizes don't look terrible, so I'm not too concerned about how the small
> embedded targets would respond from a testing standpoint.

 The timeout factor here applies to compilation times, so target execution 
such as on QEMU does not matter.  By naked eye observation once compiled
these tests complete execution instantaneously.

 I have committed this change now, thank you for your review.

  Maciej

Re: [PATCH 13/15] IRA+LRA: Let the backend request to split basic blocks

[Maciej W. Rozycki]

On Mon, 18 Nov 2024, Richard Sandiford wrote:

> > gcc/
> > * function.h (struct function): Add 
> > `split_basic_blocks_after_reload' member.
> > * lra.cc (lra): Handle it.
> > * reload1.cc (reload): Likewise.
> 
> OK, thanks.

 Thank you for your review.  I'll commit the change once the patches that 
rely on it have been approved.

  Maciej

Re: [PATCH 2/4] Don't output CodeView line numbers for inlined functions

[Jeff Law]

On 11/6/24 9:39 PM, Mark Harmstone wrote:

If we encounter an inlined function, treat it as another
codeview_function, and skip over these when outputting line numbers.
This information will instead be output as part of the S_INLINESITE
symbols.

gcc/
* dwarf2codeview.cc (struct codeview_function): Add parent and
inline_block fields.
(cur_func): New global variable.
(new_codeview_function): New function.
(codeview_source_line): Call new_codeview_function, and use cur_func
instead of last_func.
(codeview_begin_block): New function.
(codeview_end_block): New function.
(write_line_numbers): No longer free data as we go along.
(codeview_switch_text_section): Call new_codeview_function, and use
cur_func instead of last_func.
(codeview_end_epilogue): Use cur_func instead of last_func.
(codeview_debug_finish): Free funcs list and its contents.
* dwarf2codeview.h (codeview_begin_block): Add declaration.
(codeview_end_block): Add declaration.
* dwarf2out.cc (dwarf2out_begin_block): Call codeview_begin_block if
outputting CodeView debug info.
(dwarf2out_end_block): Call codeview_end_block if outputting CodeView
debug info.

OK
jeff

Re: [PATCH 3/4] Write S_INLINEELINES CodeView subsection

[Jeff Law]

On 11/6/24 9:39 PM, Mark Harmstone wrote:

When outputting the .debug$S CodeView section, also write an
S_INLINEELINES subsection, which records the filename and line number of
the start of each inlined function.

gcc/
* dwarf2codeview.cc (DEBUG_S_INLINEELINES): Define.
(CV_INLINEE_SOURCE_LINE_SIGNATURE): Define.
(struct codeview_inlinee_lines): Define.
(struct inlinee_lines_hasher): Define.
(func_htab, inlinee_lines_htab): New global variables.
(get_file_id): New function.
(codeview_source_line): Move file_id logic to get_file_id.
(write_inlinee_lines_entry): New function.
(write_inlinee_lines): New function.
(codeview_debug_finish): Call write_inlinee_lines, and free func_htab
and inlinee_lines_htab.
(get_func_id): New function.
(add_function): Move func_id logic to get_func_id.
(codeview_abstract_function): New function.
* dwarf2codeview.h (codeview_abstract_function): Add declaration.
* dwarf2out.cc (dwarf2out_abstract_function): Call
codeview_abstract_function if outputting CodeView debug info.


OK
jeff

Re: [PATCH 1/4] Add block parameter to begin_block debug hook

[Jeff Law]

On 11/6/24 9:39 PM, Mark Harmstone wrote:

Add a parameter to the begin_block debug hook that is a pointer to the
tree_node of the block in question. CodeView needs this as it records
line numbers of inlined functions in a different manner, so we need to
be able to tell if the block is actually the start of an inlined
function.

gcc/
* debug.cc (do_nothing_debug_hooks): Change begin_block
function pointer.
(debug_nothing_int_int_tree): New function.
* debug.h (struct gcc_debug_hooks): Add tree parameter to begin_block.
(debug_nothing_int_int_tree): Add declaration.
* dwarf2out.cc (dwarf2out_begin_block): Add tree parameter.
(dwarf2_lineno_debug_hooks): Use new dummy function for begin_block.
* final.cc (final_scan_insn_1): Pass insn block through to
debug_hooks->begin_block.
* vmsdbgout.cc (vmsdbgout_begin_block): Add tree parameter.

OK
jeff

Re: [PATCH 4/4] Write S_INLINESITE CodeView symbols

[Jeff Law]

On 11/6/24 9:39 PM, Mark Harmstone wrote:

Translate DW_TAG_inlined_subroutine DIEs into S_INLINESITE CodeView
symbols, marking inlined functions.

gcc/
* dwarf2codeview.cc (enum cv_sym_type): Add S_INLINESITE and
S_INLINESITE_END.
(get_func_id): Add declaration.
(write_s_inlinesite): New function.
(write_inlinesite_records): New function.
(write_function): Call write_inlinesite_records.

OK
jeff

Re: [PATCH] build: Remove INCLUDE_MEMORY [PR117737]

[Thomas Schwinge]

Hi Andrew!

On 2024-11-22T13:15:13-0800, Andrew Pinski  wrote:
> Since diagnostic.h is included in over half of the sources, requiring to 
> `#define INCLUDE_MEMORY`
> does not make sense. Instead lets unconditionally include memory in system.h.
>
> The majority of this patch is just removing `#define INCLUDE_MEMORY` from the 
> sources which currently
> have it.

Thanks!

> --- a/gcc/system.h
> +++ b/gcc/system.h
> @@ -222,6 +222,7 @@ extern int fprintf_unlocked (FILE *, const char *, ...);
>  #ifdef INCLUDE_FUNCTIONAL
>  # include 
>  #endif
> +# include 
>  # include 
>  # include 
>  # include 
> @@ -758,13 +759,6 @@ private:
>  #define LIKELY(x) (__builtin_expect ((x), 1))
>  #define UNLIKELY(x) (__builtin_expect ((x), 0))
>  
> -/* Some of the headers included by  can use "abort" within a
> -   namespace, e.g. "_VSTD::abort();", which fails after we use the
> -   preprocessor to redefine "abort" as "fancy_abort" below.  */
> -
> -#ifdef INCLUDE_MEMORY
> -# include 
> -#endif
>  
>  #ifdef INCLUDE_MUTEX
>  # include 

Should we additionally '#pragma GCC poison INCLUDE_MEMORY' (further down
in the file), so that it's documented, and other uses (external GCC
parts, WIP work, etc.) also get cleaned up, and nobody remains confused
about any lingering '#define INCLUDE_MEMORY's (even if they're harmless)?


Grüße
 Thomas

Re: [libgfortran, patch] PR88052 Format contravening constraint C1002 permitted

[Thomas Koenig]

Hi Jerry,

I had originally created this patch in 2018 and we did not get back to 
it. This results in more restrictive runtime behavior. I will go through 
the front-end code with another patch to catch this at compile time.


Changelog and new test case. See attached patch.

OK for trunk

Yes, OK.

Can you also make a mention of this in

https://gcc.gnu.org/gcc-15/changes.html ?

Best regards

Thomas

Re: [PATCH] Remove the rest of INCLUDE_MEMORY

[Gaius Mulley]

Andrew Pinski  writes:

> I missed these in r15-5603-gb3f1b9e2aa079f8ec73e because they
> were no in a `.cc` or `.h` file or they were outside of the gcc
> subdirectory.
>
> Bootstrapped and tested on x86_64-linux-gnu.
>
> gcc/m2/ChangeLog:
>
>   * mc/keyc.mod: Don't print `#define INCLUDE_MEMORY`.

lgtm

[committed] include: Add yet another DW_LANG_* enumerator from https://dwarfstd.org/languages.html

[Jakub Jelinek]

Hi!

Another DW_LANG_* code has been added recently...

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.

2024-11-23  Jakub Jelinek  

* dwarf2.h (enum dwarf_source_language): Add DW_LANG_Fortran23
enumerator.

--- include/dwarf2.h.jj 2024-11-21 10:17:00.138345784 +0100
+++ include/dwarf2.h2024-11-22 11:42:06.743114469 +0100
@@ -405,6 +405,7 @@ enum dwarf_source_language
 DW_LANG_P4 = 0x003c,
 DW_LANG_Metal = 0x003d,
 DW_LANG_C23 = 0x003e,
+DW_LANG_Fortran23 = 0x003f,
 DW_LANG_Ruby = 0x0040,
 DW_LANG_Move = 0x0041,
 DW_LANG_Hylo = 0x0042,

Jakub

Re: [PATCH 00/15] Fix data races with sub-longword accesses on Alpha

[Maciej W. Rozycki]

Hi Adrian,

> >  This has come out of a discussion[1] around the removal of non-BWX Alpha 
> > support from the Linux kernel due to data races affecting RCU algorithms. 
> > (...)
> >  Comments, questions, voices of concern or appreciation, all very welcome.
> 
> Thanks a lot for your work, much appreciated!

 You are welcome!

> I gave this a try on gcc.git master with LRA enabled for both non-BWX and
> BWX targets. BWX targets build fine with almost all languages enabled (I
> didn't try Ada, Go and Rust), but non-BWX fails with:

 Thank you for checking.  I expected it would cause issues given that we 
haven't sorted the conversion of the existing stuff yet and the aligned 
case seems to have caused troubles already.

 Are you equipped for and would you be willing to run regression-testing 
with a real BWX system for me, since I have no such hardware and QEMU 
seems broken?  I will appreciate that.

> Do you have any plans for handling unaligned accesses for LRA as well?

 Yes, once the Alpha backend has been properly converted to LRA, which I 
suppose is not going to happen before GCC 16 though.  Mind that also in my 
queue there are the VAX backend and the VAX exception unwinder, which will 
necessarily have to take precedence, especially the latter issue, since it 
blocks a lot of stuff.

  Maciej

[Patch, fortran] PR84674(12-15 regression) and PR117730 - non_overridable typebound proc problems

[Paul Richard Thomas]

Hi All,

I was going through some of the older regressions and found pr84674, which
was distinctly low hanging fruit because the contributor has found the
offending bit of code. However, buried in this PR, on the grounds that it
looked similar, was what has now become pr117730. This was quite difficult
to diagnose and the cause of the problem was only found by instrumenting
class.c (add_proc_comp) to check the order in which non_overridable
procedure components were added to the vtables of derived type extensions
that are in different modules to the parent. Failure to keep the order the
same results, of course, in the wrong procedure being called.

The fixes for these PRs verge on 'obvious' but I thought that I should
submit them to the list because I want to push and backport them together.
Although PR117730 is not a regression, I think that it is sufficiently
limiting that it should be backported to active branches.

OK for mainline and, after a week or two, backporting to 13- and
14-branches/

Paul

Fortran: Fix non_overridable typebound proc problems [PR84674/117730].

2024-11-23  Paul Thomas  

gcc/fortran/ChangeLog

PR fortran/117730
* class.c (add_proc_comp): Only reject a non_overridable if it
has no overridden procedure and the component is already
present in the vtype.
PR fortran/84674
* resolve.cc (resolve_fl_derived): Do not build a vtable for a
derived type extension that is completely empty.

gcc/testsuite/ChangeLog

PR fortran/117730
* gfortran.dg/pr117730_a.f90: New test.
* gfortran.dg/pr117730_b.f90: New test.

PR fortran/84674
* gfortran.dg/pr84674.f90: New test.
diff --git a/gcc/fortran/class.cc b/gcc/fortran/class.cc
index fc709fec322..388891a2fd5 100644
--- a/gcc/fortran/class.cc
+++ b/gcc/fortran/class.cc
@@ -886,11 +886,12 @@ add_proc_comp (gfc_symbol *vtype, const char *name, gfc_typebound_proc *tb)
 {
   gfc_component *c;

-  if (tb->non_overridable && !tb->overridden)
-return;

   c = gfc_find_component (vtype, name, true, true, NULL);

+  if (tb->non_overridable && !tb->overridden && c)
+return;
+
   if (c == NULL)
 {
   /* Add procedure component.  */
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index e8f780d1ef9..79f73e7ec40 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -16288,6 +16288,10 @@ resolve_fl_derived (gfc_symbol *sym)
   && sym->ns->proc_name
   && sym->ns->proc_name->attr.flavor == FL_MODULE
   && sym->attr.access != ACCESS_PRIVATE
+  && !(sym->attr.extension
+	   && sym->attr.zero_comp
+	   && !sym->f2k_derived->tb_sym_root
+	   && !sym->f2k_derived->tb_uop_root)
   && !(sym->attr.vtype || sym->attr.pdt_template))
 {
   gfc_symbol *vtab = gfc_find_derived_vtab (sym);
diff --git a/gcc/testsuite/gfortran.dg/pr117730_a.f90 b/gcc/testsuite/gfortran.dg/pr117730_a.f90
new file mode 100644
index 000..12e28214b02
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr117730_a.f90
@@ -0,0 +1,50 @@
+! { dg-do compile }
+!
+! Test the fix for PR117730 in which the non_overrridable procedures in 'child'
+! were mixied up in the vtable for the extension 'child2' in pr117730_b.f90.
+! This resulted in 'this%calc()' in 'function child_get(this)' returning garbage
+! when 'this' was of dynamic type 'child2'.
+!
+! Contributed by   in comment 4 of PR84674.
+!
+module module1
+implicit none
+private
+public :: child
+
+type, abstract :: parent
+contains
+procedure, pass :: reset => parent_reset
+end type parent
+
+type, extends(parent), abstract :: child
+contains
+procedure, pass, non_overridable :: reset => child_reset
+procedure, pass, non_overridable :: get => child_get
+procedure(calc_i), pass, deferred :: calc
+end type child
+
+abstract interface
+pure function calc_i(this) result(value)
+import :: child
+class(child), intent(in) :: this
+integer :: value
+end function calc_i
+end interface
+
+contains
+pure subroutine parent_reset(this)
+class(parent), intent(inout) :: this
+end subroutine parent_reset
+
+pure subroutine child_reset(this)
+class(child), intent(inout) :: this
+end subroutine child_reset
+
+function child_get(this) result(value)
+class(child), intent(inout) :: this
+integer   :: value
+
+value = this%calc()
+end function child_get
+end module module1
diff --git a/gcc/testsuite/gfortran.dg/pr117730_b.f90 b/gcc/testsuite/gfortran.dg/pr117730_b.f90
new file mode 100644
index 000..09707882989
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr117730_b.f90
@@ -0,0 +1,47 @@
+! { dg-do run }
+! { dg-compile-aux-modules "pr117730_a.f90" }
+! { dg-additional-sources pr117730_a.f90 }
+!
+! Test the fix for PR117730 in which the non_overrridable procedures in
+! pr117730_a.f90 were mixied up in the vtable for 'child2' below. This resulted
+! in 'this%calc()' in 'fun

Re: [libgfortran, patch] PR88052 Format contravening constraint C1002 permitted

[Jerry D]

On 11/23/24 12:40 AM, Thomas Koenig wrote:

Hi Jerry,

I had originally created this patch in 2018 and we did not get back to 
it. This results in more restrictive runtime behavior. I will go 
through the front-end code with another patch to catch this at compile 
time.


Changelog and new test case. See attached patch.

OK for trunk

Yes, OK.

Can you also make a mention of this in

https://gcc.gnu.org/gcc-15/changes.html ?

Best regards

 Thomas



Thanks for review, pushed.

Working on the docs change now.

Jerry

Re: [wwwdocs] Fortran changes, add description regarding commas in formats

[Harald Anlauf]

Am 23.11.24 um 19:35 schrieb Jerry D:

Suggested docs change regarding fix to PR88052.

See attached diff file.

OK to push?

Regards,

Jerry


Jerry,

for clarification: isn't it the language standard option used when
compiling the main that is relevant?  The main might be compiled
separately from a module containing the offending legacy code,
where it may or may not be diagnosed at compile time.

Otherwise OK from my side.

Thanks,
Harald

Re: [PATCH 00/15] Fix data races with sub-longword accesses on Alpha

[John Paul Adrian Glaubitz]

Hi Maciej,

On Sat, 2024-11-23 at 12:28 +, Maciej W. Rozycki wrote:
> > Thanks a lot for your work, much appreciated!
> 
>  You are welcome!
> 
> > I gave this a try on gcc.git master with LRA enabled for both non-BWX and
> > BWX targets. BWX targets build fine with almost all languages enabled (I
> > didn't try Ada, Go and Rust), but non-BWX fails with:
> 
>  Thank you for checking.  I expected it would cause issues given that we 
> haven't sorted the conversion of the existing stuff yet and the aligned 
> case seems to have caused troubles already.
> 
>  Are you equipped for and would you be willing to run regression-testing 
> with a real BWX system for me, since I have no such hardware and QEMU 
> seems broken?  I will appreciate that.

Yes, I will definitely give it a go. My fastest, currently available Alpha
is just an XP-1000, but I should get access to a pretty fast DS-15? in the
near future which I could also make accessible for you.

In fact, let me reach out to the owner again.

> > Do you have any plans for handling unaligned accesses for LRA as well?
> 
>  Yes, once the Alpha backend has been properly converted to LRA, which I 
> suppose is not going to happen before GCC 16 though.  Mind that also in my 
> queue there are the VAX backend and the VAX exception unwinder, which will 
> necessarily have to take precedence, especially the latter issue, since it 
> blocks a lot of stuff.

I knew you'd be working on the VAX backend as well ;-). Thanks so much for
taking care of both. The community can't appreciate such work enough!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Rust: Work around 'error[E0599]: no method named `leak` found for struct `std::string::String` in the current scope' (was: [PATCH 048/125] gccrs: format-args: Start storing string in Rust memory)

[Thomas Schwinge]

Hi!

On 2024-08-01T16:56:44+0200, Arthur Cohen  wrote:
> --- a/libgrust/libformat_parser/src/lib.rs
> +++ b/libgrust/libformat_parser/src/lib.rs

> [...]
> +let rust_string = RustString {
> +len: str.len(),
> +cap: str.capacity(),
> +ptr: str.leak().as_ptr(),
> +};
> [...]

> [...]
> +let RustString { ptr, len, cap } = *s;
> +let s = unsafe { String::from_raw_parts(ptr as *mut u8, len, cap) };
> +let cloned_s = s.clone();
> +
> +// FIXME: Documentation
> +s.leak();
> +
> +let rust_string = RustString {
> +len: cloned_s.len(),
> +cap: cloned_s.capacity(),
> +ptr: cloned_s.leak().as_ptr(),
> +};
> [...]

OK to push the attached
"Rust: Work around 'error[E0599]: no method named `leak` found for struct 
`std::string::String` in the current scope'"?
Builds and tests fine, but I don't know if this code path is actually
exercised at this time, so please check carefully; as you know I'm not
actually a Rust programmer (yet).  ;-)


Grüße
 Thomas


>From 8d4821dabcf4663e51c7db859801837710038821 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sat, 3 Aug 2024 16:39:17 +0200
Subject: [PATCH] Rust: Work around 'error[E0599]: no method named `leak` found
 for struct `std::string::String` in the current scope'

Compiling with Debian GNU/Linux 12 (bookworm) packages:

$ apt-cache madison cargo rustc
 cargo | 0.66.0+ds1-1 | http://deb.debian.org/debian bookworm/main ppc64el Packages
 cargo | 0.66.0+ds1-1 | http://deb.debian.org/debian bookworm/main Sources
 rustc | 1.63.0+dfsg1-2 | http://deb.debian.org/debian bookworm/main ppc64el Packages
 rustc | 1.63.0+dfsg1-2 | http://deb.debian.org/debian bookworm/main Sources

..., we run into:

   Compiling libformat_parser v0.1.0 ([...]/source-gcc/libgrust/libformat_parser)
error[E0599]: no method named `leak` found for struct `std::string::String` in the current scope
   --> src/lib.rs:396:18
|
396 | ptr: str.leak().as_ptr(),
|   method not found in `std::string::String`

error[E0599]: no method named `leak` found for struct `std::string::String` in the current scope
   --> src/lib.rs:434:7
|
434 | s.leak();
|    method not found in `std::string::String`

error[E0599]: no method named `leak` found for struct `std::string::String` in the current scope
   --> src/lib.rs:439:23
|
439 | ptr: cloned_s.leak().as_ptr(),
|    method not found in `std::string::String`

Locally replace 1.72.0+ method 'leak' for struct 'std::string::String'.

	libgrust/
	* libformat_parser/src/lib.rs: Work around 'error[E0599]:
	no method named `leak` found for struct `std::string::String` in the current scope'.
---
 libgrust/libformat_parser/src/lib.rs | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/libgrust/libformat_parser/src/lib.rs b/libgrust/libformat_parser/src/lib.rs
index 84fac38e224d..28f6a6a62b62 100644
--- a/libgrust/libformat_parser/src/lib.rs
+++ b/libgrust/libformat_parser/src/lib.rs
@@ -5,6 +5,13 @@
 
 use std::ffi::CStr;
 
+// Local replacement for 1.72.0+ method 'leak' for struct 'std::string::String',
+// 
+fn leak_string<'a>(s: String) -> &'a mut str {
+let slice = s.into_bytes().leak();
+unsafe { std::str::from_utf8_unchecked_mut(slice) }
+}
+
 trait IntoFFI {
 fn into_ffi(self) -> T;
 }
@@ -393,7 +400,7 @@ pub extern "C" fn collect_pieces(
 let rust_string = RustString {
 len: str.len(),
 cap: str.capacity(),
-ptr: str.leak().as_ptr(),
+ptr: leak_string(str).as_ptr(),
 };
 
 FormatArgsHandle(piece_slice, rust_string)
@@ -431,12 +438,12 @@ pub extern "C" fn clone_pieces(
 let cloned_s = s.clone();
 
 // FIXME: Documentation
-s.leak();
+leak_string(s);
 
 let rust_string = RustString {
 len: cloned_s.len(),
 cap: cloned_s.capacity(),
-ptr: cloned_s.leak().as_ptr(),
+ptr: leak_string(cloned_s).as_ptr(),
 };
 
 FormatArgsHandle(piece_slice, rust_string)
-- 
2.34.1

Re: [PATCH] build: Remove INCLUDE_MEMORY [PR117737]

[Gaius Mulley]

Andrew Pinski  writes:

> Since diagnostic.h is included in over half of the sources, requiring to 
> `#define INCLUDE_MEMORY`
> does not make sense. Instead lets unconditionally include memory in system.h.
>
> The majority of this patch is just removing `#define INCLUDE_MEMORY` from the 
> sources which currently
> have it.
>
> This should also fix the mingw build issue but I have not tried it.
>
> Bootstrapped and tested on x86_64-linux-gnu.
>
>   PR bootstrap/117737
>
> gcc/m2/ChangeLog:

acked for m2 as well,

regards,
Gaius

[patch, avr, applied] Fix PR117744: Load partially clobbers address reg

[Georg-Johann Lay]

Applied as obvious.

Johann

--

AVR: target/117744 - Fix asm for partial clobber of address reg,

gcc/
PR target/117744
* config/avr/avr.cc (out_movqi_r_mr): Fix code when a load
only partially clobbers an address register due to
changing the address register temporally to accommodate for
faked addressing modes.AVR: target/117744 - Fix asm for partial clobber of address reg,

gcc/
PR target/117744
* config/avr/avr.cc (out_movqi_r_mr): Fix code when a load
only partially clobbers an address register due to
changing the address register temporally to accommodate for
faked addressing modes.

diff --git a/gcc/config/avr/avr.cc b/gcc/config/avr/avr.cc
index 64d7795f37c..940ac3f0279 100644
--- a/gcc/config/avr/avr.cc
+++ b/gcc/config/avr/avr.cc
@@ -4055,11 +4055,11 @@ avr_out_movqi_r_mr_reg_disp_tiny (rtx_insn *insn, rtx op[], int *plen)
   rtx base2 = all_regs_rtx[1 ^ REGNO (dest)];
 
   if (!reg_unused_after (insn, base2))
-	avr_asm_len ("mov __tmp_reg__,%0" , &base2, plen, 1);
+	avr_asm_len ("mov __tmp_reg__,%0", &base2, plen, 1);
   avr_asm_len (TINY_ADIW (%I1, %J1, %o1) CR_TAB
 		   "ld %0,%b1", op, plen, 3);
   if (!reg_unused_after (insn, base2))
-	avr_asm_len ("mov %0,__tmp_reg__" , &base2, plen, 1);
+	avr_asm_len ("mov %0,__tmp_reg__", &base2, plen, 1);
 }
 
   return "";
@@ -4086,40 +4086,66 @@ out_movqi_r_mr (rtx_insn *insn, rtx op[], int *plen)
 {
   /* memory access by reg+disp */
 
-  int disp = INTVAL (XEXP (x, 1));
-
   if (AVR_TINY)
 	return avr_out_movqi_r_mr_reg_disp_tiny (insn, op, plen);
 
+  if (plen)
+	*plen = 0;
+
+  int disp = INTVAL (XEXP (x, 1));
+  rtx base = XEXP (x, 0);
+  rtx base2 = all_regs_rtx[1 ^ REGNO (dest)];
+  bool partial_clobber = (reg_overlap_mentioned_p (dest, base)
+			  && ! reg_unused_after (insn, base2));
+
   if (disp - GET_MODE_SIZE (GET_MODE (src)) >= 63)
 	{
+	  // PR117744: The base register overlaps dest and is
+	  // only partially clobbered.
+	  if (partial_clobber)
+	avr_asm_len ("mov __tmp_reg__,%0", &base2, plen, 1);
+
 	  if (REGNO (XEXP (x, 0)) != REG_Y)
 	fatal_insn ("incorrect insn:",insn);
 
 	  if (disp <= 63 + MAX_LD_OFFSET (GET_MODE (src)))
-	return avr_asm_len ("adiw r28,%o1-63" CR_TAB
-"ldd %0,Y+63" CR_TAB
-"sbiw r28,%o1-63", op, plen, -3);
+	avr_asm_len ("adiw r28,%o1-63" CR_TAB
+			 "ldd %0,Y+63" CR_TAB
+			 "sbiw r28,%o1-63", op, plen, 3);
+	  else
+	avr_asm_len ("subi r28,lo8(-%o1)" CR_TAB
+			 "sbci r29,hi8(-%o1)" CR_TAB
+			 "ld %0,Y"CR_TAB
+			 "subi r28,lo8(%o1)"  CR_TAB
+			 "sbci r29,hi8(%o1)", op, plen, 5);
 
-	  return avr_asm_len ("subi r28,lo8(-%o1)" CR_TAB
-			  "sbci r29,hi8(-%o1)" CR_TAB
-			  "ld %0,Y"CR_TAB
-			  "subi r28,lo8(%o1)"  CR_TAB
-			  "sbci r29,hi8(%o1)", op, plen, -5);
+	  if (partial_clobber)
+	avr_asm_len ("mov __tmp_reg__,%0", &base2, plen, 1);
+
+	  return "";
 	}
   else if (REGNO (XEXP (x, 0)) == REG_X)
 	{
 	  /* This is a paranoid case LEGITIMIZE_RELOAD_ADDRESS must exclude
 	 it but I have this situation with extremal optimizing options.  */
 
-	  avr_asm_len ("adiw r26,%o1" CR_TAB
-		   "ld %0,X", op, plen, -2);
+	  // PR117744: The base register overlaps dest and is
+	  // only partially clobbered.
+	  bool clobber_r26 = (partial_clobber
+			  && REGNO (base) == (REGNO (base) & ~1));
+	  if (partial_clobber
+	  && ! clobber_r26)
+	avr_asm_len ("mov __tmp_reg__,%0", &base2, plen, 1);
 
-	  if (!reg_overlap_mentioned_p (dest, XEXP (x, 0))
-	  && !reg_unused_after (insn, XEXP (x, 0)))
-	{
-	  avr_asm_len ("sbiw r26,%o1", op, plen, 1);
-	}
+	  avr_asm_len ("adiw r26,%o1" CR_TAB
+		   "ld %0,X", op, plen, 2);
+
+	  if (clobber_r26)
+	avr_asm_len ("subi r26,lo8(%o1)", op, plen, 1);
+	  else if (partial_clobber)
+	avr_asm_len ("mov %0,__tmp_reg__", &base2, plen, 1);
+	  else if (! reg_unused_after (insn, base))
+	avr_asm_len ("sbiw r26,%o1", op, plen, 1);
 
 	  return "";
 	}

[PATCH] Alpha: Respect `_Atomic' keyword for HI and QI data on !BWX [PR117759]

[Maciej W. Rozycki]

Correct an issue with 8-bit/16-bit stores to `_Atomic' QI and HI data 
objects producing non-BWX assembly such as:

mb
insql $17,$16,$17
ldq_u $1,0($16)
mskwl $1,$16,$1
bis $17,$1,$17
stq_u $17,0($16)
mb

for:

void
atomic_store16 (_Atomic unsigned short *p, unsigned short v)
{
  *p = v;
}

where an unprotected RMW sequence does not indeed guarantee atomicity of 
the access to the data object addressed.  This is because Alpha machine 
description does not provide `atomic_storeMODE' patterns and in their 
absence the middle end assumes plain stores are atomic for data objects 
whose size is up to the target's word size, which does not stand for 
non-BWX Alpha hardware, where only SI and DI mode stores are atomic.

Fix the issue by adding `atomic_storeQI' and `atomic_storeHI' patterns, 
derived from corresponding `atomic_exchangeQI' and `atomic_exchangeHI' 
ones, but with original data not retrieved from the object addressed.

Issue reported by Arnd Bergmann.

gcc/
PR target/117759
* config/alpha/alpha-protos.h (alpha_expand_atomic_store_12)
(alpha_split_atomic_store_12): New prototypes.
* config/alpha/alpha.cc (alpha_expand_atomic_store_12)
(alpha_split_atomic_store_12): New functions.
* config/alpha/sync.md (atomic_store): New expander.
(atomic_store_1): New insn and splitter.

gcc/testsuite/
PR target/117759
* gcc.target/alpha/atomic-clear-hi.c: New file.
* gcc.target/alpha/atomic-clear-qi.c: New file.
* gcc.target/alpha/atomic-store-di.c: New file.
* gcc.target/alpha/atomic-store-hi.c: New file.
* gcc.target/alpha/atomic-store-hi-bwx.c: New file.
* gcc.target/alpha/atomic-store-qi.c: New file.
* gcc.target/alpha/atomic-store-qi-bwx.c: New file.
* gcc.target/alpha/atomic-store-si.c: New file.
---
Hi,

 No regressions in `alpha-linux-gnu' testing across all the frontends and 
libraries (except for Rust, excluded from the configuration).  OK for 
trunk?

 Also as a grave bug that has eventually led to the removal of EV4 support 
from the Linux kernel one hand and a localised self-contained target bug 
fix on the other OK to backport to release branches even though not a 
regression?  I think this will help handling downstream.

  Maciej
---
 gcc/config/alpha/alpha-protos.h  |2 
 gcc/config/alpha/alpha.cc|   69 +++
 gcc/config/alpha/sync.md |   28 +++
 gcc/testsuite/gcc.target/alpha/atomic-clear-hi.c |   28 +++
 gcc/testsuite/gcc.target/alpha/atomic-clear-qi.c |   28 +++
 gcc/testsuite/gcc.target/alpha/atomic-store-di.c |   22 ++
 gcc/testsuite/gcc.target/alpha/atomic-store-hi-bwx.c |   22 ++
 gcc/testsuite/gcc.target/alpha/atomic-store-hi.c |   32 
 gcc/testsuite/gcc.target/alpha/atomic-store-qi-bwx.c |   22 ++
 gcc/testsuite/gcc.target/alpha/atomic-store-qi.c |   32 
 gcc/testsuite/gcc.target/alpha/atomic-store-si.c |   22 ++
 11 files changed, 307 insertions(+)

gcc-alpha-atomic-store.diff
Index: gcc/gcc/config/alpha/alpha-protos.h
===
--- gcc.orig/gcc/config/alpha/alpha-protos.h
+++ gcc/gcc/config/alpha/alpha-protos.h
@@ -90,6 +90,8 @@ extern void alpha_split_atomic_op (enum
 extern void alpha_split_compare_and_swap (rtx op[]);
 extern void alpha_expand_compare_and_swap_12 (rtx op[]);
 extern void alpha_split_compare_and_swap_12 (rtx op[]);
+extern void alpha_expand_atomic_store_12 (rtx op[]);
+extern void alpha_split_atomic_store_12 (rtx op[]);
 extern void alpha_split_atomic_exchange (rtx op[]);
 extern void alpha_expand_atomic_exchange_12 (rtx op[]);
 extern void alpha_split_atomic_exchange_12 (rtx op[]);
Index: gcc/gcc/config/alpha/alpha.cc
===
--- gcc.orig/gcc/config/alpha/alpha.cc
+++ gcc/gcc/config/alpha/alpha.cc
@@ -4634,6 +4634,75 @@ alpha_split_compare_and_swap_12 (rtx ope
 emit_label (XEXP (label2, 0));
 }
 
+/* Expand an atomic store operation.  */
+
+void
+alpha_expand_atomic_store_12 (rtx operands[])
+{
+  rtx mem, val, model;
+  machine_mode mode;
+  rtx addr, align;
+
+  mem = operands[0];
+  val = operands[1];
+  model = operands[2];
+  mode = GET_MODE (mem);
+
+  /* We forced the address into a register via mem_noofs_operand.  */
+  addr = XEXP (mem, 0);
+  gcc_assert (register_operand (addr, DImode));
+
+  align = expand_simple_binop (Pmode, AND, addr, GEN_INT (-8),
+  NULL_RTX, 1, OPTAB_DIRECT);
+
+  /* Insert val into the correct byte location within the word.  */
+  if (val != const0_rtx)
+val = emit_insxl (mode, val, addr);
+
+  emit_insn (gen_atomic_store_1 (mode, mem, val, align, model));
+}
+
+void
+alpha_split_atomic_store_12 (rtx operands[])
+{
+  rtx orig_me

Re: [PATCH 00/15] Fix data races with sub-longword accesses on Alpha

[Maciej W. Rozycki]

On Tue, 19 Nov 2024, Maciej W. Rozycki wrote:

> > time I think the RMW sequence on _Atomic variables is a clear
> > bug that you'd need to fix also for -mno-safe-bwa.
> 
>  That's weird indeed, GCC internals manual clearly says:
> 
> "'atomic_storeMODE'
>  This pattern implements an atomic store operation with memory model
>  semantics.  Operand 0 is the memory address being stored to.
>  Operand 1 is the value to be written.  Operand 2 is the memory
>  model to be used for the operation.
> 
>  If not present, the '__atomic_store' built-in function will attempt
>  to perform a normal store and surround it with any required memory
>  fences.  If the store would not be atomic, then an
>  '__atomic_exchange' is attempted with the result being ignored."
> 
> and while we do not have `atomic_storeqi' nor `atomic_storehi' operations 
> we do have `atomic_exchangeqi' and `atomic_exchangehi' ones defined in the 
> Alpha backend (for byte and word operations respectively).  So presumably 
> the middle end is not aware for some reason that on non-BWX Alpha normal 
> QI and HI mode stores are not atomic.

 FTR the reason is the middle end universally assumes, in the absence of 
an 'atomic_storeMODE' pattern, that stores are atomic for object sizes of 
up to the target's word size, which does not stand for non-BWX Alpha.  

>  I do hope this obviously obscure but trivial GCC bug was not the *sole* 
> reason to drop non-BWX support from Linux.

 I found no previous bug report, so this is now PR target/117759[1].  An 
obvious bug fix has been posted for review as well[2].

References:

[1] "Alpha: `_Atomic' keyword not respected for !BWX and 8-bit/16-bit stores", 


[2] "Alpha: Respect `_Atomic' keyword for HI and QI data on !BWX [PR117759]",



  Maciej

[PATCH] testsuite:RISC-V:Modify the char string.

[shiyulong]

From: yulong 

This patch modifies the char string from __riscv_xsfvcp to __riscv_xsfcease.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/predef-sf-2.c: Modify the char string.
---
 gcc/testsuite/gcc.target/riscv/predef-sf-2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/testsuite/gcc.target/riscv/predef-sf-2.c 
b/gcc/testsuite/gcc.target/riscv/predef-sf-2.c
index dcb746bcd26..aaf73a6d8c5 100644
--- a/gcc/testsuite/gcc.target/riscv/predef-sf-2.c
+++ b/gcc/testsuite/gcc.target/riscv/predef-sf-2.c
@@ -7,7 +7,7 @@ int main () {
 #endif
 
 #if !defined(__riscv_xsfcease)
-#error "__riscv_xsfvcp"
+#error "__riscv_xsfcease"
 #endif
 
   return 0;
-- 
2.34.1

Re: Ping [PATCH] ada: PR target/117538 Traceback includes load address if executable is PIE.

[Eric Botcazou]

> What I didn’t say before is that, if for example an exception is raised
> in Ada Language Server and the code uses s-trasym to output a report,
> what you get on macOS is, for example,
> 
> ALS.MAIN] in GNATformat Format
> [ALS.MAIN] raised CONSTRAINT_ERROR : erroneous memory access
> _ALS.MAIN_ 0x000105847D68 0x000105847DA0 0x0001058EA6AC
> 0x0001058EB5F4 0x000104B292C5 0x000104B36C5C
> 0x000104A8C0A0 0x000104A3C29C 0x0001049DB52C
> 0x000104A03844 0x000104A02DE8 0x000104A03058
> 0x000104A03C0C 0x000104A03240 0x000104A03854
> 0x000104A03884 0x000104A02DE8 0x000104A04F8C
> 0x0001049996E8 0x0001035BD344 0x0001035BD620
> 0x0001034AFBC8 0x0001034962DC 0x00010354930C
> 0x00010353D33C 0x00010252074C 0x00010252D25C
> 0x00010350A53C 0x000105831980 0x00019EE8F2E0
> 
> which is useless without the program load address. (A symbolic traceback
> would be even better, but that would be a different and more difficult
> project).
> 
> What should I do to get this change pushed?

Yes, the patch is a progress, but please remove the part fiddling with zeros 
and just concentrate on printing the load address.

-- 
Eric Botcazou