Re: [PATCH] gcc: header-tools scripts updated to python3

[Sundeep KOKKONDA]

Can I get some update on this patch. Is this patch ok? Will it be taken 
to upstream sources?


On 29-Mar-24 15:52, sundeep.kokko...@windriver.com wrote:

From: Sundeep KOKKONDA 

The scripts in contrib/header-tools/ are breaks with python3. These scripts are 
updated for python3 compatability.

Signed-off-by: Sundeep KOKKONDA 
---
  contrib/header-tools/count-headers |   8 +-
  contrib/header-tools/gcc-order-headers |  64 
  contrib/header-tools/graph-header-logs |  42 +-
  contrib/header-tools/graph-include-web |  26 +++
  contrib/header-tools/headerutils.py|  36 -
  contrib/header-tools/included-by   |  32 
  contrib/header-tools/reduce-headers| 102 -
  contrib/header-tools/replace-header|  12 +--
  contrib/header-tools/show-headers  |  32 
  9 files changed, 177 insertions(+), 177 deletions(-)

diff --git a/contrib/header-tools/count-headers 
b/contrib/header-tools/count-headers
index 7a92596a602..9e7046a2a1e 100755
--- a/contrib/header-tools/count-headers
+++ b/contrib/header-tools/count-headers
@@ -1,4 +1,4 @@
-#! /usr/bin/python2
+#! /usr/bin/python3
  import os.path
  import sys
  import shlex
@@ -45,11 +45,11 @@ if not usage and len (src) > 0:
l.sort (key=lambda tup:tup[0], reverse=True)
  
for f in l:

-print str (f[0]) + " : " + f[1]
+print(str (f[0]) + " : " + f[1])
  
  else:

-  print "count-headers file1 [filen]"
-  print "Count the number of occurrences of all includes across all listed 
files"
+  print("count-headers file1 [filen]")
+  print("Count the number of occurrences of all includes across all listed 
files")
  
   
  
diff --git a/contrib/header-tools/gcc-order-headers b/contrib/header-tools/gcc-order-headers

index ee76cba4b18..8d2e3cf6e77 100755
--- a/contrib/header-tools/gcc-order-headers
+++ b/contrib/header-tools/gcc-order-headers
@@ -1,11 +1,11 @@
-#! /usr/bin/python2
+#! /usr/bin/python3
  import os
  import sys
  import shlex
  import re
  
  from headerutils import *

-import Queue
+import queue
  
  file_list = list ()

  usage = False
@@ -77,19 +77,19 @@ def create_master_list (fn, verbose):
  if fn != "diagnostic.h" and fn != "diagnostic-core.h":
master_list.append (fn)
if (verbose):
-print fn + "  included by: " + includes[fn][0]
+print(fn + "  included by: " + includes[fn][0])
  
  
  
  def print_dups ():

if dups:
-print "\nduplicated includes"
+print("\nduplicated includes")
for i in dups:
  string =  "dup : " + i + " : "
  string += includes[i][0]
  for i2 in dups[i]:
string += ", "+i2
-print string
+print(string)
  
  
  def process_known_dups ():

@@ -230,11 +230,11 @@ for arg in sys.argv[1:]:
  elif arg[0:2] == "-v":
show_master = True
  else:
-  print "Error: unrecognized option " + arg
+  print("Error: unrecognized option " + arg)
elif os.path.exists(arg):
  file_list.append (arg)
else:
-print "Error: file " + arg + " Does not exist."
+print("Error: file " + arg + " Does not exist.")
  usage = True
  
  if not file_list and not show_master:

@@ -242,7 +242,7 @@ if not file_list and not show_master:
  
  if not usage and not os.path.exists ("coretypes.h"):

usage = True
-  print "Error: Must run command in main gcc source directory containing 
coretypes.h\n"
+  print("Error: Must run command in main gcc source directory containing 
coretypes.h\n")
  
  # process diagnostic.h first.. it's special since GCC_DIAG_STYLE can be

  # overridden by languages, but must be done so by a file included BEFORE it.
@@ -268,20 +268,20 @@ process_known_dups ()
  desired_order = master_list
  
  if show_master:

-  print " Canonical order of gcc include files: "
+  print(" Canonical order of gcc include files: ")
for x in master_list:
-print x
-  print " "
+print(x)
+  print(" ")
  
  if usage:

-  print "gcc-order-headers [-i] [-v] file1 [filen]"
-  print "Ensures gcc's headers files are included in a normalized form 
with"
-  print "redundant headers removed.  The original files are saved in 
filename.bak"
-  print "Outputs a list of files which changed."
-  print " -i ignore conditional compilation."
-  print "Use after examining the file to be sure includes within #ifs are 
safe"
-  print "Any headers within conditional sections will be ignored."
-  print " -v Show the canonical order of known headers"
+  print("gcc-order-headers [-i] [-v] file1 [filen]")
+  print("Ensures gcc's headers files are included in a normalized form 
with")
+  print("redundant headers removed.  The original files are saved in 
filename.bak")
+  print("Outputs a list of files which changed.")
+  print(" -i ignore conditional compilation.")
+  print("Use after examining the file to be sure includes within #ifs are 
safe")
+  print("Any headers within conditional sections will be ignored.")
+  

Re: [PATCH v1] rs6000: Stackoverflow in optimized code on PPC [PR100799]

[Kewen.Lin]

Hi!

on 2024/3/22 17:36, Jakub Jelinek wrote:
> On Fri, Mar 22, 2024 at 02:55:43PM +0530, Ajit Agarwal wrote:
>> rs6000: Stackoverflow in optimized code on PPC [PR100799]
>>
>> When using FlexiBLAS with OpenBLAS we noticed corruption of
>> the parameters passed to OpenBLAS functions. FlexiBLAS
>> basically provides a BLAS interface where each function
>> is a stub that forwards the arguments to a real BLAS lib,
>> like OpenBLAS.
>>
>> Fixes the corruption of caller frame checking number of
>> arguments is less than equal to GP_ARG_NUM_REG (8)
>> excluding hidden unused DECLS.
> 
> Looks mostly good to me except some comment nits, but I'll defer
> the actual ack to the rs6000 maintainers.
> 
>> +  /* Workaround buggy C/C++ wrappers around Fortran routines with
>> + character(len=constant) arguments if the hidden string length arguments
>> + are passed on the stack; if the callers forget to pass those arguments,
>> + attempting to tail call in such routines leads to stack corruption.
> 
> I thought it isn't just tail calls, even normal calls.
> When the buggy C/C++ wrappers call the function with fewer arguments
> than it actually has and doesn't expect the parameter save area on the
> caller side because of that while the callee expects it and the callee
> actually stores something in the parameter save area, it corrupts whatever
> is in the caller stack frame at that location.

I agree it's not just tail calls, but currently DECL_HIDDEN_STRING_LENGTH
setting is guarded with flag_tail_call_workaround, which was intended to
be only for tail calls.  So I wonder if we should update this option name,
or introduce another option which is more for C/Fortran interoperability
workaround, set DECL_HIDDEN_STRING_LENGTH with this guard and also enable
this existing flag_tail_call_workaround.

> 
>> + Avoid return stack space for parameters <= 8 excluding hidden string
>> + length argument is passed (partially or fully) on the stack in the
>> + caller and the callee needs to pass any arguments on the stack.  */
>> +  unsigned int num_args = 0;
>> +  unsigned int hidden_length = 0;
>> +
>> +  for (tree arg = DECL_ARGUMENTS (current_function_decl);
>> +   arg; arg = DECL_CHAIN (arg))
>> +{
>> +  num_args++;
>> +  if (DECL_HIDDEN_STRING_LENGTH (arg))
>> +{
>> +  tree parmdef = ssa_default_def (cfun, arg);
>> +  if (parmdef == NULL || has_zero_uses (parmdef))
>> +{
>> +  cum->hidden_string_length = 1;
>> +  hidden_length++;
>> +}
>> +}

As Fortran allows to have some string with unknown length, it's possible to
have some test cases which have mixed used and unused hidden lengths, since
the used ones matter, users may already modify their C code to prepare the
required used hidden length.  But with this change, the modified code could
not work any more.  For example, 7th and 8th are unused but 9th argument is
used, 9th is passed by caller on stack but callee expects it comes from r9
instead (7th arg).  So IMHO we should be more conservative and only make
this workaround by taking care of the continuous unused hidden length at the
end of arg list.  Someone may argue if users already know how to modify their
C code to interoperate with Fortran, we should already modify all their C code
and won't adopt this workaround, but if this restriction still works for all
the motivated test cases, IMHO keeping more conservative is good, as users
could only update some "broken" cases not "all".

BR,
Kewen


>> +   }
>> +
>> +  cum->actual_parm_length = num_args - hidden_length;
>> +
>>/* Check for a longcall attribute.  */
>>if ((!fntype && rs6000_default_long_calls)
>>|| (fntype
>> @@ -1857,7 +1884,16 @@ rs6000_function_arg (cumulative_args_t cum_v, const 
>> function_arg_info )
>>  
>>return rs6000_finish_function_arg (mode, rvec, k);
>>  }
>> -  else if (align_words < GP_ARG_NUM_REG)
>> + /* Workaround buggy C/C++ wrappers around Fortran routines with
>> +character(len=constant) arguments if the hidden string length arguments
>> +are passed on the stack; if the callers forget to pass those arguments,
>> +attempting to tail call in such routines leads to stack corruption.
>> +Avoid return stack space for parameters <= 8 excluding hidden string
>> +length argument is passed (partially or fully) on the stack in the
>> +caller and the callee needs to pass any arguments on the stack.  */
>> +  else if (align_words < GP_ARG_NUM_REG
>> +   || (cum->hidden_string_length
>> +   && cum->actual_parm_length <= GP_ARG_NUM_REG))
>>  {
>>if (TARGET_32BIT && TARGET_POWERPC64)
>>  return rs6000_mixed_function_arg (mode, type, align_words);
>> diff --git a/gcc/config/rs6000/rs6000.h b/gcc/config/rs6000/rs6000.h
>> index 68bc45d65ba..a1d3ed00b14 100644
>> --- a/gcc/config/rs6000/rs6000.h
>> +++ b/gcc/config/rs6000/rs6000.h
>> @@ -1490,6 +1490,14 @@ typedef struct 

Re:[pushed] [PATCH] Regenerate loongarch.opt.urls.

[chenglulu]

Pushed to r14-9741.

在 2024/4/1 上午11:08, Lulu Cheng 写道:

Fixes: d28ea8e5a704 ("LoongArch: Split loongarch_option_override_internal
  into smaller procedures")

gcc/ChangeLog:

* config/loongarch/loongarch.opt.urls: Regenerate.
---
  gcc/config/loongarch/loongarch.opt.urls | 19 +--
  1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/gcc/config/loongarch/loongarch.opt.urls 
b/gcc/config/loongarch/loongarch.opt.urls
index c78bbfea2da..8e16304b66a 100644
--- a/gcc/config/loongarch/loongarch.opt.urls
+++ b/gcc/config/loongarch/loongarch.opt.urls
@@ -51,10 +51,10 @@ 
UrlSuffix(gcc/LoongArch-Options.html#index-mexplicit-relocs-1)
  mexplicit-relocs
  UrlSuffix(gcc/LoongArch-Options.html#index-mexplicit-relocs-1)
  
-mrecip

+mrecip=
  UrlSuffix(gcc/LoongArch-Options.html#index-mrecip)
  
-mrecip=

+mrecip
  UrlSuffix(gcc/LoongArch-Options.html#index-mrecip)
  
  ; skipping UrlSuffix for 'mcmodel=' due to finding no URLs

@@ -64,3 +64,18 @@ 
UrlSuffix(gcc/LoongArch-Options.html#index-mdirect-extern-access)
  
  ; skipping UrlSuffix for 'mrelax' due to finding no URLs
  
+mfrecipe

+UrlSuffix(gcc/LoongArch-Options.html#index-mfrecipe)
+
+mdiv32
+UrlSuffix(gcc/LoongArch-Options.html#index-mdiv32)
+
+mlam-bh
+UrlSuffix(gcc/LoongArch-Options.html#index-mlam-bh)
+
+mlamcas
+UrlSuffix(gcc/LoongArch-Options.html#index-mlamcas)
+
+mld-seq-sa
+UrlSuffix(gcc/LoongArch-Options.html#index-mld-seq-sa)
+

[PATCH] LoongArch: Fix missing plugin header

[Yang Yujie]

gcc/ChangeLog:

* config/loongarch/t-loongarch: Add loongarch-def-arrays.h
to OPTION_H_EXTRA.
---
 gcc/config/loongarch/t-loongarch | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gcc/config/loongarch/t-loongarch b/gcc/config/loongarch/t-loongarch
index 3dd7c4b031e..acf5da95310 100644
--- a/gcc/config/loongarch/t-loongarch
+++ b/gcc/config/loongarch/t-loongarch
@@ -18,8 +18,9 @@
 
 
 GTM_H += loongarch-multilib.h
-OPTIONS_H_EXTRA += $(srcdir)/config/loongarch/loongarch-def.h  \
-  $(srcdir)/config/loongarch/loongarch-tune.h  \
+OPTIONS_H_EXTRA += $(srcdir)/config/loongarch/loongarch-def.h  \
+  $(srcdir)/config/loongarch/loongarch-def-array.h \
+  $(srcdir)/config/loongarch/loongarch-tune.h  \
   $(srcdir)/config/loongarch/loongarch-cpucfg-map.h
 
 # Canonical target triplet from config.gcc
-- 
2.44.0

Re: [PATCH] Regenerate loongarch.opt.urls.

[chenglulu]

在 2024/4/1 下午7:24, Mark Wielaard 写道:

Hi,

On Mon, Apr 01, 2024 at 11:08:08AM +0800, Lulu Cheng wrote:

Fixes: d28ea8e5a704 ("LoongArch: Split loongarch_option_override_internal
  into smaller procedures")

gcc/ChangeLog:

* config/loongarch/loongarch.opt.urls: Regenerate.

This looks OK to me. I cannot officially approve patches, but I think
this falls under the Obvious fixes rule.


Roger that. Thanks for your review.:-)

Lulu



Cheers,

Mark

[PATCH 1/1] [RISC-V] Add support for _Bfloat16

[Xiao Zeng]

1 At point ,
  BF16 has already been completed "post public review".

2 LLVM has also added support for RISCV BF16 in
   and
  .

3 According to the discussion 
,
  this use __bf16 and use DF16b in riscv_mangle_type like x86.

Below test are passed for this patch
* The riscv fully regression test.

gcc/ChangeLog:

* config/riscv/iterators.md: New mode iterator HFBF.
* config/riscv/riscv-builtins.cc (riscv_init_builtin_types):
Initialize data type _Bfloat16.
* config/riscv/riscv-modes.def (FLOAT_MODE): New.
(ADJUST_FLOAT_FORMAT): New.
* config/riscv/riscv.cc (riscv_mangle_type): Support for BFmode.
(riscv_scalar_mode_supported_p): Ditto.
(riscv_libgcc_floating_mode_supported_p): Ditto.
(riscv_init_libfuncs): Set the conversion method for BFmode and
HFmode.
(riscv_block_arith_comp_libfuncs_for_mode): Set the arithmetic
and comparison libfuncs for the mode.
* config/riscv/riscv.md (mode" ): Add BF.
(movhf): Support for BFmode.
(mov): Ditto.
(*movhf_softfloat): Ditto.
(*mov_softfloat): Ditto.

libgcc/ChangeLog:

* config/riscv/sfp-machine.h (_FP_NANFRAC_B): New.
(_FP_NANSIGN_B): Ditto.
* config/riscv/t-softfp32: Add support for BF16 libfuncs.
* config/riscv/t-softfp64: Ditto.
* soft-fp/floatsibf.c: For si -> bf16.
* soft-fp/floatunsibf.c: For unsi -> bf16.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/bf16_arithmetic.c: New test.
* gcc.target/riscv/bf16_call.c: New test.
* gcc.target/riscv/bf16_comparison.c: New test.
* gcc.target/riscv/bf16_float_libcall_convert.c: New test.
* gcc.target/riscv/bf16_integer_libcall_convert.c: New test.

Co-authored-by: Jin Ma 
---
 gcc/config/riscv/iterators.md |  2 +
 gcc/config/riscv/riscv-builtins.cc| 16 
 gcc/config/riscv/riscv-modes.def  |  3 +
 gcc/config/riscv/riscv.cc | 64 ++-
 gcc/config/riscv/riscv.md | 24 +++---
 .../gcc.target/riscv/bf16_arithmetic.c| 42 ++
 gcc/testsuite/gcc.target/riscv/bf16_call.c| 12 +++
 .../gcc.target/riscv/bf16_comparison.c| 36 +
 .../riscv/bf16_float_libcall_convert.c| 57 +
 .../riscv/bf16_integer_libcall_convert.c  | 81 +++
 libgcc/config/riscv/sfp-machine.h |  3 +
 libgcc/config/riscv/t-softfp32| 10 ++-
 libgcc/config/riscv/t-softfp64|  3 +-
 libgcc/soft-fp/floatsibf.c| 45 +++
 libgcc/soft-fp/floatunsibf.c  | 45 +++
 15 files changed, 407 insertions(+), 36 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/bf16_arithmetic.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/bf16_call.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/bf16_comparison.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/bf16_float_libcall_convert.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/bf16_integer_libcall_convert.c
 create mode 100644 libgcc/soft-fp/floatsibf.c
 create mode 100644 libgcc/soft-fp/floatunsibf.c

diff --git a/gcc/config/riscv/iterators.md b/gcc/config/riscv/iterators.md
index a7694137685..40bf20f42bb 100644
--- a/gcc/config/riscv/iterators.md
+++ b/gcc/config/riscv/iterators.md
@@ -75,6 +75,8 @@
 ;; Iterator for floating-point modes that can be loaded into X registers.
 (define_mode_iterator SOFTF [SF (DF "TARGET_64BIT") (HF "TARGET_ZFHMIN")])
 
+;; Iterator for floating-point modes of BF16
+(define_mode_iterator HFBF [HF BF])
 
 ;; ---
 ;; Mode attributes
diff --git a/gcc/config/riscv/riscv-builtins.cc 
b/gcc/config/riscv/riscv-builtins.cc
index d457e306dd1..4c08834288a 100644
--- a/gcc/config/riscv/riscv-builtins.cc
+++ b/gcc/config/riscv/riscv-builtins.cc
@@ -230,6 +230,7 @@ static GTY(()) int riscv_builtin_decl_index[NUM_INSN_CODES];
   riscv_builtin_decls[riscv_builtin_decl_index[(CODE)]]
 
 tree riscv_float16_type_node = NULL_TREE;
+tree riscv_bfloat16_type_node = NULL_TREE;
 
 /* Return the function type associated with function prototype TYPE.  */
 
@@ -273,6 +274,21 @@ riscv_init_builtin_types (void)
   if (!maybe_get_identifier ("_Float16"))
 lang_hooks.types.register_builtin_type (riscv_float16_type_node,
"_Float16");
+
+  /* Provide the _Bfloat16 type and bfloat16_type_node if needed.  */
+  if (!bfloat16_type_node)
+{
+  riscv_bfloat16_type_node = make_node (REAL_TYPE);
+  TYPE_PRECISION (riscv_bfloat16_type_node) = 16;
+  SET_TYPE_MODE (riscv_bfloat16_type_node, BFmode);
+  layout_type (riscv_bfloat16_type_node);
+ 

[PATCH 0/1] [RISC-V] Add support for _Bfloat16

[Xiao Zeng]

Hi all RISC-V folks:

This patch completes the support for the bf16 data type in the
riscv architecture.On this basis, there will be a series of
patches in the future to strengthen support for BF16.

It is recommended to first review this patch from the testcases,
where detailed explanations have been provided on the flow of
data type conversion.

The basis of this patch is: 


The website for the first patch submission is: 


However, considering the non-standard commit information, this
submission was made.

Xiao Zeng (1):
  [RISC-V] Add support for _Bfloat16

 gcc/config/riscv/iterators.md |  2 +
 gcc/config/riscv/riscv-builtins.cc| 16 
 gcc/config/riscv/riscv-modes.def  |  3 +
 gcc/config/riscv/riscv.cc | 64 ++-
 gcc/config/riscv/riscv.md | 24 +++---
 .../gcc.target/riscv/bf16_arithmetic.c| 42 ++
 gcc/testsuite/gcc.target/riscv/bf16_call.c| 12 +++
 .../gcc.target/riscv/bf16_comparison.c| 36 +
 .../riscv/bf16_float_libcall_convert.c| 57 +
 .../riscv/bf16_integer_libcall_convert.c  | 81 +++
 libgcc/config/riscv/sfp-machine.h |  3 +
 libgcc/config/riscv/t-softfp32| 10 ++-
 libgcc/config/riscv/t-softfp64|  3 +-
 libgcc/soft-fp/floatsibf.c| 45 +++
 libgcc/soft-fp/floatunsibf.c  | 45 +++
 15 files changed, 407 insertions(+), 36 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/bf16_arithmetic.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/bf16_call.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/bf16_comparison.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/bf16_float_libcall_convert.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/bf16_integer_libcall_convert.c
 create mode 100644 libgcc/soft-fp/floatsibf.c
 create mode 100644 libgcc/soft-fp/floatunsibf.c

-- 
2.17.1

Re: [PATCH v5] LoongArch: Add support for TLS descriptors

[chenglulu]

在 2024/4/1 下午9:51, Xi Ruoyao 写道:

Is this patch targeting GCC 14 or 15?  If 14 I guess we'd commit now...

Generally we don't add features in stage 4, but if we keep trad as the
default I think it'd be OK.  And RISC-V guys plan to push their TLS desc
implementation this week too.


I've rebase the code to the latest commit, and if the test is okay I'll 
bring it up right away.


Thanks!:-)



On Tue, 2024-03-19 at 09:54 +0800, mengqinggang wrote:

Add support for TLS descriptors on normal code model and extreme code model.

Normal code model instruction sequence:
   -mno-explicit-relocs:
     la.tls.desc$r4, s
     add.d  $r12, $r4, $r2
   -mexplicit-relocs:
     pcalau12i  $r4,%desc_pc_hi20(s)
     addi.d $r4,$r4,%desc_pc_lo12(s)
     ld.d   $r1,$r4,%desc_ld(s)
     jirl   $r1,$r1,%desc_call(s)
     add.d  $r12, $r4, $r2

Extreme code model instruction sequence:
   -mno-explicit-relocs:
     la.tls.desc$r4, $r12, s
     add.d  $r12, $r4, $r2
   -mexplicit-relocs:
     pcalau12i  $r4,%desc_pc_hi20(s)
     addi.d $r12,$r0,%desc_pc_lo12(s)
     lu32i.d$r12,%desc64_pc_lo20(s)
     lu52i.d$r12,$r12,%desc64_pc_hi12(s)
     add.d  $r4,$r4,$r12
     ld.d   $r1,$r4,%desc_ld(s)
     jirl   $r1,$r1,%desc_call(s)
     add.d  $r12, $r4, $r2

The default is still traditional TLS model, but can be configured with
--with-tls={trad,desc}. The default can change to TLS descriptors once
libc and LLVM support this.

gcc/ChangeLog:

* config.gcc: Add --with-tls option to change TLS flavor.
* config/loongarch/genopts/loongarch.opt.in: Add -mtls-dialect to
configure TLS flavor.
* config/loongarch/loongarch-def.h (struct loongarch_target): Add
tls_dialect.
* config/loongarch/loongarch-driver.cc (la_driver_init): Add tls
flavor.
* config/loongarch/loongarch-opts.cc (loongarch_init_target): Add
tls_dialect.
(loongarch_config_target): Ditto.
(loongarch_update_gcc_opt_status): Ditto.
* config/loongarch/loongarch-opts.h (loongarch_init_target):Ditto.
(TARGET_TLS_DESC): New define.
* config/loongarch/loongarch.cc (loongarch_symbol_insns): Add TLS DESC
instructions sequence length.
(loongarch_legitimize_tls_address): New TLS DESC instruction sequence.
(loongarch_option_override_internal): Add la_opt_tls_dialect.
(loongarch_option_restore): Add la_target.tls_dialect.
* config/loongarch/loongarch.md (@got_load_tls_desc): Normal
code model for TLS DESC.
(got_load_tls_desc_off64): Extreme code model for TLS DESC.
* config/loongarch/loongarch.opt: Regenerated.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/cmodel-extreme-1.c: Add -mtls-dialect=trad.
* gcc.target/loongarch/cmodel-extreme-2.c: Ditto.
* gcc.target/loongarch/explicit-relocs-auto-tls-ld-gd.c: Ditto.
* gcc.target/loongarch/explicit-relocs-medium-call36-auto-tls-ld-gd.c:
Ditto.
* gcc.target/loongarch/func-call-medium-1.c: Ditto.
* gcc.target/loongarch/func-call-medium-2.c: Ditto.
* gcc.target/loongarch/func-call-medium-3.c: Ditto.
* gcc.target/loongarch/func-call-medium-4.c: Ditto.
* gcc.target/loongarch/tls-extreme-macro.c: Ditto.
* gcc.target/loongarch/tls-gd-noplt.c: Ditto.
* gcc.target/loongarch/explicit-relocs-auto-extreme-tls-desc.c: New 
test.
* gcc.target/loongarch/explicit-relocs-auto-tls-desc.c: New test.
* gcc.target/loongarch/explicit-relocs-extreme-tls-desc.c: New test.
* gcc.target/loongarch/explicit-relocs-tls-desc.c: New test.

Co-authored-by: Lulu Cheng 
Co-authored-by: Xi Ruoyao 

[PATCH] libstdc++: Allow adjacent __maybe_present_t to overlap

[Patrick Palka]

Tested on x86_64-pc-linux-gnu, does this look OK for trunk?

-- >8 --

Currently __maybe_present_t maps to the same empty class
type independent of T.  This is suboptimal because it means adjacent
__maybe_present_t members with the [[no_unique_address]]
attribute can't overlap even if the conditionally present types are
different.

This patch fixes this by turning this empty class type into a template
parameterized by the conditionally present type, so that

  [[no_unique_address]] __maybe_present_t _M_a;
  [[no_unique_address]] __maybe_present_t _M_b;

now overlap if T and U are different.

This patch goes a step further and also adds an optional integer
discriminator parameter to allow for overlapping when T and U are
the same.

libstdc++-v3/ChangeLog:

* include/std/ranges (ranges::__detail::_Empty): Rename to ...
(ranges::__detail::_Absent): ... this.  Turn into a template
parameterized by the absent type _Tp and discriminator _Disc.
(ranges::__detail::__maybe_present_t): Add an optional
discriminator parameter.
(slide_view::_M_cached_begin): Pass a discriminator argument to
__maybe_present_t.
(slide_view::_M_cached_end): Likewise.
* testsuite/std/ranges/adaptors/sizeof.cc: Verify the size of
slide_view is 3 instead 4 pointers.
---
 libstdc++-v3/include/std/ranges | 13 -
 .../testsuite/std/ranges/adaptors/sizeof.cc |  4 
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index 7d739852677..afce818376b 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -886,14 +886,17 @@ namespace views
 
 namespace __detail
 {
-  struct _Empty { };
+  template
+struct _Absent { };
 
   // Alias for a type that is conditionally present
   // (and is an empty type otherwise).
   // Data members using this alias should use [[no_unique_address]] so that
   // they take no space when not needed.
-  template
-using __maybe_present_t = __conditional_t<_Present, _Tp, _Empty>;
+  // The optional template parameter _Disc is for discriminating two otherwise
+  // equivalent absent types so that even they can overlap.
+  template
+using __maybe_present_t = __conditional_t<_Present, _Tp, _Absent<_Tp, 
_Disc>>;
 
   // Alias for a type that is conditionally const.
   template
@@ -6553,10 +6556,10 @@ namespace views::__adaptor
 range_difference_t<_Vp> _M_n;
 [[no_unique_address]]
   __detail::__maybe_present_t<__detail::__slide_caches_first<_Vp>,
- __detail::_CachedPosition<_Vp>> 
_M_cached_begin;
+ __detail::_CachedPosition<_Vp>, 0> 
_M_cached_begin;
 [[no_unique_address]]
   __detail::__maybe_present_t<__detail::__slide_caches_last<_Vp>,
- __detail::_CachedPosition<_Vp>> _M_cached_end;
+ __detail::_CachedPosition<_Vp>, 1> 
_M_cached_end;
 
 template class _Iterator;
 class _Sentinel;
diff --git a/libstdc++-v3/testsuite/std/ranges/adaptors/sizeof.cc 
b/libstdc++-v3/testsuite/std/ranges/adaptors/sizeof.cc
index 12a9da3181d..08c01704d10 100644
--- a/libstdc++-v3/testsuite/std/ranges/adaptors/sizeof.cc
+++ b/libstdc++-v3/testsuite/std/ranges/adaptors/sizeof.cc
@@ -49,3 +49,7 @@ static_assert(sizeof(ranges::lazy_split_view) == 4*ptr);
 
 static_assert
  (sizeof(ranges::reverse_view>) == 
3*ptr);
+
+#if __cpp_lib_ranges_slide
+static_assert(sizeof(ranges::slide_view) == 3*ptr);
+#endif
-- 
2.44.0.448.gc2cbfbd2e2

Re: [Patch, fortran] PR106999 [11/12/13/14 Regression] ICE tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_data_get, at fortran/trans-expr.cc:233

[Harald Anlauf]

Hi Paul,

On 3/31/24 15:01, Paul Richard Thomas wrote:

This regression has a relatively simple fix. The passing of a subroutine
procedure pointer component to a dummy variable was being missed
completely. The error has been added. Conversely, an error was generated
for a procedure pointer variable but no use was being made of the
interface, if one was available. This has been corrected.

OK for mainline and backporting in a couple of weeks?


this is all OK.

Thanks for the patch!

Harald


Paul

Fortran: Add error for subroutine passed to a variable dummy [PR106999]

2024-03-31  Paul Thomas  

gcc/fortran
PR fortran/106999
*interface.cc (gfc_compare_interfaces): Add error for a
subroutine proc pointer passed to a variable formal.
(compare_parameter): If a procedure pointer is being passed to
a non-procedure formal arg, and there is an an interface, use
gfc_compare_interfaces to check and provide a more useful error
message.

gcc/testsuite/
PR fortran/106999
* gfortran.dg/pr106999.f90: New test.

Re: [Patch, fortran] PR112407 - [13/14 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab

[Harald Anlauf]

Hi Paul!

Am 31.03.24 um 14:08 schrieb Paul Richard Thomas:

Hi Harald,



I had only a quick glance at your patch.  I guess you unintentionally
forgot to remove those parts that you already committed for PR110987,
along with the finalize-testcases.



Guilty as charged. I guess I got out of the wrong side of the bed :-)



I am still trying to find the precise paragraph in the standard
you refer to regarding INTENT(OUT) and default initialization.



Page 114 of the draft F2023 standard:
"The INTENT (OUT) attribute for a nonpointer dummy argument specifies that
the dummy argument becomes undefined on invocation of the procedure, except
for any subcomponents that are default-initialized (7.5.4.6)."
With the fix, gfortran behaves in the same way as ifort and nagfor.

On rereading the patch, I think that s/"and use the passed value"/"and
leave undefined"/ or some such is in order.


Yes, something along this line is better.

I also did test with NAG and Intel, and was surprised (confused?) at how
the count of finalizer calls changes if component "i" gets a default
value or not.  Something one wouldn't do right after getting out of bed!

So the patch looks good to me - except for one philosophical question:

Fortran 2018 makes procedures recursive by default, but this is not
yet implemented as such, and NON_RECURSIVE is not yet implemented.

The new testcase pr112407b.f90 compiles with nagfor -f2018 without
any warnings, and gives an error with nagfor -f2008.  It appears
that it works in the testsuite after the patch and when adding
"-std=f2008" instead of using the default "-std=gnu".

Would you mind adding "-std=f2008" as dg-option to that testcase?
This would avoid one bogus regression when gfortran moves forward.

Thanks for the patch!

Harald




While at it, I think I found a minor nit in testcase pr112407a.f90:
component x%i appears undefined the first time it is printed.



Fixed - thanks for pointing it out.

A correct patch is attached.

Thanks for looking at the previous, overloaded version.

Paul






2024-03-30  Paul Thomas  

gcc/fortran
PR fortran/112407
*resolve.cc (resolve_procedure_expression): Change the test for
for recursion in the case of hidden procedures from modules.
(resolve_typebound_static): Add warning for possible recursive
calls to typebound procedures.
* trans-expr.cc (gfc_trans_class_init_assign): Do not apply
default initializer to class dummy where component initializers
are all null.

gcc/testsuite/
PR fortran/112407
* gfortran.dg/pr112407a.f90: New test.
* gfortran.dg/pr112407b.f90: New test.

Combine patch ping

[Uros Bizjak]

Hello!

I'd like to ping the
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647634.html
PR112560 P1 patch.

Thanks,
Uros.

[PATCH] c++: make __is_array return false for T[0] [PR114479]

[Marek Polacek]

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

-- >8 --
When we switched to using the __is_array built-in trait to implement
std::is_array in r14-6623-g7fd9c349e45534, we started saying that
T[0] is an array.  There are various opinions as to whether that is
the best answer, but it seems prudent to keep the GCC 13 result.

PR c++/114479

gcc/cp/ChangeLog:

* semantics.cc (trait_expr_value) : Return false
for zero-sized arrays.

gcc/testsuite/ChangeLog:

* g++.dg/ext/is_array.C: Extend.
---
 gcc/cp/semantics.cc |  4 +++-
 gcc/testsuite/g++.dg/ext/is_array.C | 12 
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 9838331d2a9..f561c119dfd 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -12439,7 +12439,9 @@ trait_expr_value (cp_trait_kind kind, tree type1, tree 
type2)
   return CP_AGGREGATE_TYPE_P (type1);
 
 case CPTK_IS_ARRAY:
-  return type_code1 == ARRAY_TYPE;
+  return (type_code1 == ARRAY_TYPE
+ /* We don't want to report T[0] as being an array type.  */
+ && !(TYPE_SIZE (type1) && integer_zerop (TYPE_SIZE (type1;
 
 case CPTK_IS_ASSIGNABLE:
   return is_xible (MODIFY_EXPR, type1, type2);
diff --git a/gcc/testsuite/g++.dg/ext/is_array.C 
b/gcc/testsuite/g++.dg/ext/is_array.C
index f1a6e08b87a..84993266629 100644
--- a/gcc/testsuite/g++.dg/ext/is_array.C
+++ b/gcc/testsuite/g++.dg/ext/is_array.C
@@ -1,4 +1,5 @@
 // { dg-do compile { target c++11 } }
+// { dg-options "" }
 
 #define SA(X) static_assert((X),#X)
 
@@ -10,18 +11,29 @@
 
 class ClassType { };
 
+constexpr int sz0 = 0;
+constexpr int sz2 = 2;
+
 SA_TEST_CATEGORY(__is_array, int[2], true);
 SA_TEST_CATEGORY(__is_array, int[], true);
+SA_TEST_CATEGORY(__is_array, int[0], false);
 SA_TEST_CATEGORY(__is_array, int[2][3], true);
 SA_TEST_CATEGORY(__is_array, int[][3], true);
+SA_TEST_CATEGORY(__is_array, int[0][3], false);
+SA_TEST_CATEGORY(__is_array, int[3][0], false);
 SA_TEST_CATEGORY(__is_array, float*[2], true);
 SA_TEST_CATEGORY(__is_array, float*[], true);
 SA_TEST_CATEGORY(__is_array, float*[2][3], true);
 SA_TEST_CATEGORY(__is_array, float*[][3], true);
 SA_TEST_CATEGORY(__is_array, ClassType[2], true);
 SA_TEST_CATEGORY(__is_array, ClassType[], true);
+SA_TEST_CATEGORY(__is_array, ClassType[0], false);
 SA_TEST_CATEGORY(__is_array, ClassType[2][3], true);
 SA_TEST_CATEGORY(__is_array, ClassType[][3], true);
+SA_TEST_CATEGORY(__is_array, ClassType[0][3], false);
+SA_TEST_CATEGORY(__is_array, ClassType[2][0], false);
+SA_TEST_CATEGORY(__is_array, int[sz2], true);
+SA_TEST_CATEGORY(__is_array, int[sz0], false);
 
 // Sanity check.
 SA_TEST_CATEGORY(__is_array, ClassType, false);

base-commit: bba118db3f63cb1e3953a014aa3ac2ad89908950
-- 
2.44.0

[pushed] c++: C++26 returning reference to temporary

[Jason Merrill]

Tested x86_64-pc-linux-gnu, applying to trunk.

-- 8< --

P2748R5 makes it ill-formed to return a reference to temporary in C++26;
implementing this is a simple matter of changing the existing warning to a
permerror.

For most of the tests I just changed dg-warning to dg-message to accept
both; I test the specific diagnostic type in Wreturn-local-addr-5.C.

gcc/cp/ChangeLog:

* typeck.cc (maybe_warn_about_returning_address_of_local):
Permerror in C++26.

gcc/testsuite/ChangeLog:

* g++.dg/conversion/pr16333.C: Change dg-warning to dg-message.
* g++.dg/cpp0x/constexpr-48324.C
* g++.dg/other/pr94326.C
* g++.dg/warn/Wreturn-local-addr-2.C
* g++.old-deja/g++.jason/warning8.C: Likewise.
* g++.dg/cpp1y/auto-fn6.C: Check that others don't complain.
* g++.dg/warn/Wreturn-local-addr-5.C: Expect error in C++26.
---
 gcc/cp/typeck.cc | 6 --
 gcc/testsuite/g++.dg/conversion/pr16333.C| 2 +-
 gcc/testsuite/g++.dg/cpp0x/constexpr-48324.C | 2 +-
 gcc/testsuite/g++.dg/cpp1y/auto-fn6.C| 8 
 gcc/testsuite/g++.dg/other/pr94326.C | 2 +-
 gcc/testsuite/g++.dg/warn/Wreturn-local-addr-2.C | 4 ++--
 gcc/testsuite/g++.dg/warn/Wreturn-local-addr-5.C | 3 ++-
 gcc/testsuite/g++.old-deja/g++.jason/warning8.C  | 2 +-
 8 files changed, 16 insertions(+), 13 deletions(-)

diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index f5a0a2273be..88ed38e4f30 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -10626,8 +10626,10 @@ maybe_warn_about_returning_address_of_local (tree 
retval, location_t loc)
   || TREE_CODE (whats_returned) == TARGET_EXPR)
 {
   if (TYPE_REF_P (valtype))
-   warning_at (loc, OPT_Wreturn_local_addr,
-   "returning reference to temporary");
+   /* P2748 made this an error in C++26.  */
+   emit_diagnostic (cxx_dialect >= cxx26 ? DK_PERMERROR : DK_WARNING,
+loc, OPT_Wreturn_local_addr,
+"returning reference to temporary");
   else if (TYPE_PTR_P (valtype))
warning_at (loc, OPT_Wreturn_local_addr,
"returning pointer to temporary");
diff --git a/gcc/testsuite/g++.dg/conversion/pr16333.C 
b/gcc/testsuite/g++.dg/conversion/pr16333.C
index a00bc5c167c..d0049304790 100644
--- a/gcc/testsuite/g++.dg/conversion/pr16333.C
+++ b/gcc/testsuite/g++.dg/conversion/pr16333.C
@@ -6,5 +6,5 @@ struct X {
 
 int a[3];
 X foo1 () { return a; }
-const X  () { return a; } // { dg-warning "returning reference to 
temporary" }
+const X  () { return a; } // { dg-message "returning reference to 
temporary" }
 X  () { return a; } // { dg-error "cannot bind non-const lvalue ref" }
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-48324.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-48324.C
index 37ed0e1d163..f53fd4ddbd3 100644
--- a/gcc/testsuite/g++.dg/cpp0x/constexpr-48324.C
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-48324.C
@@ -7,7 +7,7 @@ struct S {
 };
 
 constexpr const int& to_ref(int i) {
-  return S(i).val; // { dg-warning "reference to temporary" }
+  return S(i).val; // { dg-message "reference to temporary" }
 }
 
 constexpr int ary[to_ref(98)] = { }; // { dg-error "25:size of array .ary. is 
not an integral" }
diff --git a/gcc/testsuite/g++.dg/cpp1y/auto-fn6.C 
b/gcc/testsuite/g++.dg/cpp1y/auto-fn6.C
index 17ca6f22c50..7fada180841 100644
--- a/gcc/testsuite/g++.dg/cpp1y/auto-fn6.C
+++ b/gcc/testsuite/g++.dg/cpp1y/auto-fn6.C
@@ -8,11 +8,11 @@ char& g(char);
 double&& g(double);
 
 template  auto&& f(T t)
-{ return g(t); }   // { dg-warning "reference to temporary" }
+{ return g(t); }   // { dg-message "reference to temporary" }
 
 int main()
 {
-  ST();
-  ST();
-  ST();
+  ST();  // { dg-message "required from here" }
+  ST(); // { dg-bogus "required from here" }
+  ST(); // { dg-bogus "required from here" }
 }
diff --git a/gcc/testsuite/g++.dg/other/pr94326.C 
b/gcc/testsuite/g++.dg/other/pr94326.C
index 4069c038d52..5df72a648fd 100644
--- a/gcc/testsuite/g++.dg/other/pr94326.C
+++ b/gcc/testsuite/g++.dg/other/pr94326.C
@@ -3,7 +3,7 @@
 // { dg-options "-fcompare-debug" }
 
 template  struct A {
-  const int () { return 0; }   // { dg-warning "returning reference to 
temporary" }
+  const int () { return 0; }   // { dg-message "returning reference to 
temporary" }
   template  void bar(_Kt) { foo(); }
 };
 struct B {
diff --git a/gcc/testsuite/g++.dg/warn/Wreturn-local-addr-2.C 
b/gcc/testsuite/g++.dg/warn/Wreturn-local-addr-2.C
index c483601e6b2..a9f984c153d 100644
--- a/gcc/testsuite/g++.dg/warn/Wreturn-local-addr-2.C
+++ b/gcc/testsuite/g++.dg/warn/Wreturn-local-addr-2.C
@@ -3,9 +3,9 @@
 struct Base2 { int m_foo; };
 struct Derived2 : public Base2 {};
 
-const Base2& f8() { return Derived2(); } // { dg-warning "reference to 
temporary" }
+const Base2& f8() { return Derived2(); } // { dg-message "reference to 
temporary" }
 
 struct 

Re: [PATCH v5] LoongArch: Add support for TLS descriptors

[Xi Ruoyao]

Is this patch targeting GCC 14 or 15?  If 14 I guess we'd commit now...

Generally we don't add features in stage 4, but if we keep trad as the
default I think it'd be OK.  And RISC-V guys plan to push their TLS desc
implementation this week too.

On Tue, 2024-03-19 at 09:54 +0800, mengqinggang wrote:
> Add support for TLS descriptors on normal code model and extreme code model.
> 
> Normal code model instruction sequence:
>   -mno-explicit-relocs:
>     la.tls.desc   $r4, s
>     add.d $r12, $r4, $r2
>   -mexplicit-relocs:
>     pcalau12i $r4,%desc_pc_hi20(s)
>     addi.d$r4,$r4,%desc_pc_lo12(s)
>     ld.d  $r1,$r4,%desc_ld(s)
>     jirl  $r1,$r1,%desc_call(s)
>     add.d $r12, $r4, $r2
> 
> Extreme code model instruction sequence:
>   -mno-explicit-relocs:
>     la.tls.desc   $r4, $r12, s
>     add.d $r12, $r4, $r2
>   -mexplicit-relocs:
>     pcalau12i $r4,%desc_pc_hi20(s)
>     addi.d$r12,$r0,%desc_pc_lo12(s)
>     lu32i.d   $r12,%desc64_pc_lo20(s)
>     lu52i.d   $r12,$r12,%desc64_pc_hi12(s)
>     add.d $r4,$r4,$r12
>     ld.d  $r1,$r4,%desc_ld(s)
>     jirl  $r1,$r1,%desc_call(s)
>     add.d $r12, $r4, $r2
> 
> The default is still traditional TLS model, but can be configured with
> --with-tls={trad,desc}. The default can change to TLS descriptors once
> libc and LLVM support this.
> 
> gcc/ChangeLog:
> 
>   * config.gcc: Add --with-tls option to change TLS flavor.
>   * config/loongarch/genopts/loongarch.opt.in: Add -mtls-dialect to
>   configure TLS flavor.
>   * config/loongarch/loongarch-def.h (struct loongarch_target): Add
>   tls_dialect.
>   * config/loongarch/loongarch-driver.cc (la_driver_init): Add tls
>   flavor.
>   * config/loongarch/loongarch-opts.cc (loongarch_init_target): Add
>   tls_dialect.
>   (loongarch_config_target): Ditto.
>   (loongarch_update_gcc_opt_status): Ditto.
>   * config/loongarch/loongarch-opts.h (loongarch_init_target):Ditto.
>   (TARGET_TLS_DESC): New define.
>   * config/loongarch/loongarch.cc (loongarch_symbol_insns): Add TLS DESC
>   instructions sequence length.
>   (loongarch_legitimize_tls_address): New TLS DESC instruction sequence.
>   (loongarch_option_override_internal): Add la_opt_tls_dialect.
>   (loongarch_option_restore): Add la_target.tls_dialect.
>   * config/loongarch/loongarch.md (@got_load_tls_desc): Normal
>   code model for TLS DESC.
>   (got_load_tls_desc_off64): Extreme code model for TLS DESC.
>   * config/loongarch/loongarch.opt: Regenerated.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/loongarch/cmodel-extreme-1.c: Add -mtls-dialect=trad.
>   * gcc.target/loongarch/cmodel-extreme-2.c: Ditto.
>   * gcc.target/loongarch/explicit-relocs-auto-tls-ld-gd.c: Ditto.
>   * gcc.target/loongarch/explicit-relocs-medium-call36-auto-tls-ld-gd.c:
>   Ditto.
>   * gcc.target/loongarch/func-call-medium-1.c: Ditto.
>   * gcc.target/loongarch/func-call-medium-2.c: Ditto.
>   * gcc.target/loongarch/func-call-medium-3.c: Ditto.
>   * gcc.target/loongarch/func-call-medium-4.c: Ditto.
>   * gcc.target/loongarch/tls-extreme-macro.c: Ditto.
>   * gcc.target/loongarch/tls-gd-noplt.c: Ditto.
>   * gcc.target/loongarch/explicit-relocs-auto-extreme-tls-desc.c: New 
> test.
>   * gcc.target/loongarch/explicit-relocs-auto-tls-desc.c: New test.
>   * gcc.target/loongarch/explicit-relocs-extreme-tls-desc.c: New test.
>   * gcc.target/loongarch/explicit-relocs-tls-desc.c: New test.
> 
> Co-authored-by: Lulu Cheng 
> Co-authored-by: Xi Ruoyao 

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

[PATCH][Backport][GCC10] Fix SSA corruption due to widening_mul opt on conflict across an abnormal edge [PR111407]

[Qing Zhao]

This is a bug in tree-ssa-math-opts.c, when applying the widening mul
optimization, the compiler needs to check whether the operand is in a
ABNORMAL PHI, if YES, we should avoid the transformation.

PR tree-optimization/111407

gcc/ChangeLog:

* tree-ssa-math-opts.c (convert_mult_to_widen): Avoid the transform
when one of the operands is subject to abnormal coalescing.

gcc/testsuite/ChangeLog:

* gcc.dg/pr111407.c: New test.

(cherry picked from commit 4aca1cfd6235090e48a53dab734437740671bbf3)

bootstraped and regression tested on both aarch64 and x86.

Okay for commit to GCC10?

thanks.

Qing
---
 gcc/testsuite/gcc.dg/pr111407.c | 21 +
 gcc/tree-ssa-math-opts.c|  8 
 2 files changed, 29 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr111407.c

diff --git a/gcc/testsuite/gcc.dg/pr111407.c b/gcc/testsuite/gcc.dg/pr111407.c
new file mode 100644
index ..a171074753f9
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr111407.c
@@ -0,0 +1,21 @@
+/* PR tree-optimization/111407*/
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+enum { SEND_TOFILE } __sigsetjmp();
+void fclose();
+void foldergets();
+void sendpart_stats(int *p1, int a1, int b1) {
+ int *a = p1;
+ fclose();
+ p1 = 0;
+ long t = b1;
+ if (__sigsetjmp()) {
+   {
+ long t1 = a1;
+ a1+=1;
+ fclose(a1*(long)t1);
+   }
+ }
+ if (p1)
+   fclose();
+}
diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c
index dd0b8c6f0577..47981da20e05 100644
--- a/gcc/tree-ssa-math-opts.c
+++ b/gcc/tree-ssa-math-opts.c
@@ -2543,6 +2543,14 @@ convert_mult_to_widen (gimple *stmt, 
gimple_stmt_iterator *gsi)
   if (!is_widening_mult_p (stmt, , , , ))
 return false;
 
+  /* if any one of rhs1 and rhs2 is subject to abnormal coalescing,
+ avoid the tranform. */
+  if ((TREE_CODE (rhs1) == SSA_NAME
+   && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs1))
+  || (TREE_CODE (rhs2) == SSA_NAME
+ && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs2)))
+return false;
+
   to_mode = SCALAR_INT_TYPE_MODE (type);
   from_mode = SCALAR_INT_TYPE_MODE (type1);
   if (to_mode == from_mode)
-- 
2.31.1

[PATCH][Backport][GCC11] Fix SSA corruption due to widening_mul opt on conflict across an abnormal edge [PR111407]

[Qing Zhao]

This is a bug in tree-ssa-math-opts.c, when applying the widening mul
optimization, the compiler needs to check whether the operand is in a
ABNORMAL PHI, if YES, we should avoid the transformation.

PR tree-optimization/111407

gcc/ChangeLog:

* tree-ssa-math-opts.c (convert_mult_to_widen): Avoid the transform
when one of the operands is subject to abnormal coalescing.

gcc/testsuite/ChangeLog:

* gcc.dg/pr111407.c: New test.

(cherry picked from commit 4aca1cfd6235090e48a53dab734437740671bbf3)

bootstraped and regression tested on both aarch64 and x86.

Okay for commit to GCC11?

thanks.

Qing
---
 gcc/testsuite/gcc.dg/pr111407.c | 21 +
 gcc/tree-ssa-math-opts.c|  8 
 2 files changed, 29 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr111407.c

diff --git a/gcc/testsuite/gcc.dg/pr111407.c b/gcc/testsuite/gcc.dg/pr111407.c
new file mode 100644
index ..a171074753f9
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr111407.c
@@ -0,0 +1,21 @@
+/* PR tree-optimization/111407*/
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+enum { SEND_TOFILE } __sigsetjmp();
+void fclose();
+void foldergets();
+void sendpart_stats(int *p1, int a1, int b1) {
+ int *a = p1;
+ fclose();
+ p1 = 0;
+ long t = b1;
+ if (__sigsetjmp()) {
+   {
+ long t1 = a1;
+ a1+=1;
+ fclose(a1*(long)t1);
+   }
+ }
+ if (p1)
+   fclose();
+}
diff --git a/gcc/tree-ssa-math-opts.c b/gcc/tree-ssa-math-opts.c
index adeb70fd6354..dcaf272d73f9 100644
--- a/gcc/tree-ssa-math-opts.c
+++ b/gcc/tree-ssa-math-opts.c
@@ -2678,6 +2678,14 @@ convert_mult_to_widen (gimple *stmt, 
gimple_stmt_iterator *gsi)
   if (!is_widening_mult_p (stmt, , , , ))
 return false;
 
+  /* if any one of rhs1 and rhs2 is subject to abnormal coalescing,
+ avoid the tranform. */
+  if ((TREE_CODE (rhs1) == SSA_NAME
+   && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs1))
+  || (TREE_CODE (rhs2) == SSA_NAME
+ && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs2)))
+return false;
+
   to_mode = SCALAR_INT_TYPE_MODE (type);
   from_mode = SCALAR_INT_TYPE_MODE (type1);
   if (to_mode == from_mode)
-- 
2.31.1

[PATCH][Backport][GCC12] Fix SSA corruption due to widening_mul opt on conflict across an abnormal edge [PR111407]

[Qing Zhao]

This is a bug in tree-ssa-math-opts.cc, when applying the widening mul
optimization, the compiler needs to check whether the operand is in a
ABNORMAL PHI, if YES, we should avoid the transformation.

PR tree-optimization/111407

gcc/ChangeLog:

* tree-ssa-math-opts.cc (convert_mult_to_widen): Avoid the transform
when one of the operands is subject to abnormal coalescing.

gcc/testsuite/ChangeLog:

* gcc.dg/pr111407.c: New test.

(cherry picked from commit 4aca1cfd6235090e48a53dab734437740671bbf3)

bootstraped and regression tested on both aarch64 and x86.

Okay for commit to GCC12?

thanks.

Qing
---
 gcc/testsuite/gcc.dg/pr111407.c | 21 +
 gcc/tree-ssa-math-opts.cc   |  8 
 2 files changed, 29 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr111407.c

diff --git a/gcc/testsuite/gcc.dg/pr111407.c b/gcc/testsuite/gcc.dg/pr111407.c
new file mode 100644
index ..a171074753f9
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr111407.c
@@ -0,0 +1,21 @@
+/* PR tree-optimization/111407*/
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+enum { SEND_TOFILE } __sigsetjmp();
+void fclose();
+void foldergets();
+void sendpart_stats(int *p1, int a1, int b1) {
+ int *a = p1;
+ fclose();
+ p1 = 0;
+ long t = b1;
+ if (__sigsetjmp()) {
+   {
+ long t1 = a1;
+ a1+=1;
+ fclose(a1*(long)t1);
+   }
+ }
+ if (p1)
+   fclose();
+}
diff --git a/gcc/tree-ssa-math-opts.cc b/gcc/tree-ssa-math-opts.cc
index 232e903b0d25..bab0cc5aef4e 100644
--- a/gcc/tree-ssa-math-opts.cc
+++ b/gcc/tree-ssa-math-opts.cc
@@ -2681,6 +2681,14 @@ convert_mult_to_widen (gimple *stmt, 
gimple_stmt_iterator *gsi)
   if (!is_widening_mult_p (stmt, , , , ))
 return false;
 
+  /* if any one of rhs1 and rhs2 is subject to abnormal coalescing,
+ avoid the tranform. */
+  if ((TREE_CODE (rhs1) == SSA_NAME
+   && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs1))
+  || (TREE_CODE (rhs2) == SSA_NAME
+ && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs2)))
+return false;
+
   to_mode = SCALAR_INT_TYPE_MODE (type);
   from_mode = SCALAR_INT_TYPE_MODE (type1);
   if (to_mode == from_mode)
-- 
2.31.1

[PATCH][Backport][GCC13] Fix SSA corruption due to widening_mul opt on conflict across an abnormal edge [PR111407]

[Qing Zhao]

This is a bug in tree-ssa-math-opts.cc, when applying the widening mul
optimization, the compiler needs to check whether the operand is in a
ABNORMAL PHI, if YES, we should avoid the transformation.

PR tree-optimization/111407

gcc/ChangeLog:

* tree-ssa-math-opts.cc (convert_mult_to_widen): Avoid the transform
when one of the operands is subject to abnormal coalescing.

gcc/testsuite/ChangeLog:

* gcc.dg/pr111407.c: New test.

(cherry picked from commit 4aca1cfd6235090e48a53dab734437740671bbf3)

bootstraped and regression tested on both aarch64 and x86.

Okay for commit to GCC13?

thanks.

Qing
---
 gcc/testsuite/gcc.dg/pr111407.c | 21 +
 gcc/tree-ssa-math-opts.cc   |  8 
 2 files changed, 29 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr111407.c

diff --git a/gcc/testsuite/gcc.dg/pr111407.c b/gcc/testsuite/gcc.dg/pr111407.c
new file mode 100644
index ..a171074753f9
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr111407.c
@@ -0,0 +1,21 @@
+/* PR tree-optimization/111407*/
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+enum { SEND_TOFILE } __sigsetjmp();
+void fclose();
+void foldergets();
+void sendpart_stats(int *p1, int a1, int b1) {
+ int *a = p1;
+ fclose();
+ p1 = 0;
+ long t = b1;
+ if (__sigsetjmp()) {
+   {
+ long t1 = a1;
+ a1+=1;
+ fclose(a1*(long)t1);
+   }
+ }
+ if (p1)
+   fclose();
+}
diff --git a/gcc/tree-ssa-math-opts.cc b/gcc/tree-ssa-math-opts.cc
index 15eed3e960c4..ff949e4fec9c 100644
--- a/gcc/tree-ssa-math-opts.cc
+++ b/gcc/tree-ssa-math-opts.cc
@@ -2754,6 +2754,14 @@ convert_mult_to_widen (gimple *stmt, 
gimple_stmt_iterator *gsi)
   if (!is_widening_mult_p (stmt, , , , ))
 return false;
 
+  /* if any one of rhs1 and rhs2 is subject to abnormal coalescing,
+ avoid the tranform. */
+  if ((TREE_CODE (rhs1) == SSA_NAME
+   && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs1))
+  || (TREE_CODE (rhs2) == SSA_NAME
+ && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs2)))
+return false;
+
   to_mode = SCALAR_INT_TYPE_MODE (type);
   from_mode = SCALAR_INT_TYPE_MODE (type1);
   if (to_mode == from_mode)
-- 
2.31.1

Re: Frontend access to target features (was Re: [PATCH] libgccjit: Add ability to get CPU features)

[Antoni Boucher]

David: Ping.

Le 2024-03-19 à 07 h 03, Arthur Cohen a écrit :

Hi,

On 3/5/24 16:09, David Malcolm wrote:

On Thu, 2023-11-09 at 19:33 -0500, Antoni Boucher wrote:

Hi.
See answers below.

On Thu, 2023-11-09 at 18:04 -0500, David Malcolm wrote:

On Thu, 2023-11-09 at 17:27 -0500, Antoni Boucher wrote:

Hi.
This patch adds support for getting the CPU features in libgccjit
(bug
112466)

There's a TODO in the test:
I'm not sure how to test that gcc_jit_target_info_arch returns
the
correct value since it is dependant on the CPU.
Any idea on how to improve this?

Also, I created a CStringHash to be able to have a
std::unordered_set. Is there any built-in way of
doing
this?


Thanks for the patch.

Some high-level questions:

Is this specifically about detecting capabilities of the host that
libgccjit is currently running on? or how the target was configured
when libgccjit was built?


I'm less sure about this part. I'll need to do more tests.



One of the benefits of libgccjit is that, in theory, we support all
of
the targets that GCC already supports.  Does this patch change
that,
or
is this more about giving client code the ability to determine
capabilities of the specific host being compiled for?


This should not change that. If it does, this is a bug.



I'm nervous about having per-target jit code.  Presumably there's a
reason that we can't reuse existing target logic here - can you
please
describe what the problem is.  I see that the ChangeLog has:


 * config/i386/i386-jit.cc: New file.


where i386-jit.cc has almost 200 lines of nontrivial code.  Where
did
this come from?  Did you base it on existing code in our source
tree,
making modifications to fit the new internal API, or did you write
it
from scratch?  In either case, how onerous would this be for other
targets?


This was mostly copied from the same code done for the Rust and D
frontends.
See this commit and the following:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b1c06fd9723453dd2b2ec306684cb806dc2b4fbb
The equivalent to i386-jit.cc is there:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=22e3557e2d52f129f2bbfdc98688b945dba28dc9


[CCing Iain and Arthur re those patches; for reference, the patch being
discussed is attached to :
https://gcc.gnu.org/pipermail/jit/2024q1/001792.html ]

One of my concerns about this patch is that we seem to be gaining code
that's per-(frontend x config) which seems to be copied and pasted with
a search and replace, which could lead to an M*N explosion.


I think this is definitely already the case, and it would be worth 
investigating if C/C++/Rust/jit can reuse a similar set of target files, 
or how to factor them together. I imagine that all of these components 
share similar needs for the targets they support.




Is there any real difference between the per-config code for the
different frontends, or should there be a general "enumerate all
features of the target" hook that's independent of the frontend? (but
perhaps calls into it).

Am I right in thinking that (rustc with default LLVM backend) has some
set of feature strings that both (rustc with rustc_codegen_gcc) and
gccrs are trying to emulate?  If so, is it presumably a goal that
libgccjit gives identical results to gccrs?  If so, would it be crazy
for libgccjit to consume e.g. config/i386/i386-rust.cc ?


I think this would definitely make sense, and it could probably be 
extended to other frontends. For the time being I think it makes sense 
to try it out for gccrs and jit. But finding a fitting name will be hard :)


Best,

Arthur



Dave





I'm not at expert at target hooks (or at the i386 backend), so if
we
do
go with this approach I'd want someone else to review those parts
of
the patch.

Have you verified that GCC builds with this patch with jit *not*
enabled in the enabled languages?


I will do.



[...snip...]

A nitpick:


+.. function:: const char * \
+  gcc_jit_target_info_arch (gcc_jit_target_info
*info)
+
+   Get the architecture of the currently running CPU.


What does this string look like?
How long does the pointer remain valid?


It's the march string, like "znver2", for instance.
It remains valid until we free the gcc_jit_target_info object.



Thanks again; hope the above makes sense
Dave

[PATCH v2 2/2] gcc: xtensa: add xtensa*-esp*-elf multilib

[Alexey Lapshin]

gcc/
* config.gcc: Add xtensa*-esp*-elf target.
* config/xtensa/t-esp-multilib: New file.
---
 gcc/config.gcc   |  6 ++
 gcc/config/xtensa/t-esp-multilib | 20 
 2 files changed, 26 insertions(+)
 create mode 100644 gcc/config/xtensa/t-esp-multilib

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 17873ac2103..702ddf09f17 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3587,6 +3587,12 @@ xstormy16-*-elf)
 xtensa*-*-elf*)
tm_file="${tm_file} elfos.h newlib-stdint.h xtensa/elf.h"
extra_options="${extra_options} xtensa/elf.opt"
+   tmake_file="${tmake_file} xtensa/t-xtensa"
+   case ${target} in
+   xtensa*-esp-elf*)
+   tmake_file="${tmake_file} xtensa/t-esp-multilib"
+   ;;
+   esac
;;
 xtensa*-*-linux*)
tm_file="${tm_file} elfos.h gnu-user.h linux.h glibc-stdint.h 
xtensa/linux.h"
diff --git a/gcc/config/xtensa/t-esp-multilib b/gcc/config/xtensa/t-esp-multilib
new file mode 100644
index 000..dfc0ac0e04c
--- /dev/null
+++ b/gcc/config/xtensa/t-esp-multilib
@@ -0,0 +1,20 @@
+# Copyright (C) 2023 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+MULTILIB_OPTIONS = 
mdynconfig=xtensa_esp32.so/mdynconfig=xtensa_esp32s2.so/mdynconfig=xtensa_esp32s3.so
 fno-rtti
+MULTILIB_DIRNAMES = esp32 esp32s2 esp32s3 no-rtti
-- 
2.34.1

[PATCH v2 1/2] gcc: xtensa: add mdynconfig option

[Alexey Lapshin]

gcc/
* config/xtensa/elf.h (ASM_SPEC, LINK_SPEC): Pass dynconfig to
assembler/linker.
* config/xtensa/linux.h (ASM_SPEC, LINK_SPEC): Likewise.
* config/xtensa/uclinux.h (ASM_SPEC, LINK_SPEC): Likewise.
* config/xtensa/xtensa-dynconfig.cc: May build dynconfig path with
  dir in XTENSA_GNU_CONFIG and filename in mdynconfig option.
* doc/invoke.texi: Add XTENSA_GNU_CONFIG and mdynconfig doc.
---
 gcc/config/xtensa/elf.h   |  6 ++-
 gcc/config/xtensa/linux.h |  6 ++-
 gcc/config/xtensa/uclinux.h   |  6 ++-
 gcc/config/xtensa/xtensa-dynconfig.cc | 55 ++-
 gcc/config/xtensa/xtensa.opt  |  4 ++
 gcc/doc/invoke.texi   | 14 +++
 6 files changed, 83 insertions(+), 8 deletions(-)

diff --git a/gcc/config/xtensa/elf.h b/gcc/config/xtensa/elf.h
index aa14f9d0134..dd20cb310d0 100644
--- a/gcc/config/xtensa/elf.h
+++ b/gcc/config/xtensa/elf.h
@@ -49,7 +49,8 @@ along with GCC; see the file COPYING3.  If not see
   %{mauto-litpools:--auto-litpools} \
   %{mno-auto-litpools:--no-auto-litpools} \
   %{mabi=windowed:--abi-windowed} \
-  %{mabi=call0:--abi-call0}"
+  %{mabi=call0:--abi-call0} \
+  %{mdynconfig=*:--dynconfig=%*}"
 
 #undef LIB_SPEC
 #define LIB_SPEC "-lc -lsim -lc -lhandlers-sim -lhal"
@@ -69,7 +70,8 @@ along with GCC; see the file COPYING3.  If not see
   %{rdynamic:-export-dynamic} \
 %{static:-static}}} \
   %{mabi=windowed:--abi-windowed} \
-  %{mabi=call0:--abi-call0}"
+  %{mabi=call0:--abi-call0} \
+  %{mdynconfig=*:--dynconfig=%*}"
 
 #undef LOCAL_LABEL_PREFIX
 #define LOCAL_LABEL_PREFIX "."
diff --git a/gcc/config/xtensa/linux.h b/gcc/config/xtensa/linux.h
index 03ec8e7254a..5a19af13dd3 100644
--- a/gcc/config/xtensa/linux.h
+++ b/gcc/config/xtensa/linux.h
@@ -46,7 +46,8 @@ along with GCC; see the file COPYING3.  If not see
   %{mauto-litpools:--auto-litpools} \
   %{mno-auto-litpools:--no-auto-litpools} \
   %{mabi=windowed:--abi-windowed} \
-  %{mabi=call0:--abi-call0}"
+  %{mabi=call0:--abi-call0} \
+  %{mdynconfig=*:--dynconfig=%*}"
 
 #define GLIBC_DYNAMIC_LINKER "/lib/ld.so.1"
 
@@ -60,7 +61,8 @@ along with GCC; see the file COPYING3.  If not see
 %{static-pie:-static -pie --no-dynamic-linker -z text} \
 %{static:-static}} \
   %{mabi=windowed:--abi-windowed} \
-  %{mabi=call0:--abi-call0}"
+  %{mabi=call0:--abi-call0} \
+  %{mdynconfig=*:--dynconfig=%*}"
 
 #undef LOCAL_LABEL_PREFIX
 #define LOCAL_LABEL_PREFIX "."
diff --git a/gcc/config/xtensa/uclinux.h b/gcc/config/xtensa/uclinux.h
index 062e9640d64..7dd868e074a 100644
--- a/gcc/config/xtensa/uclinux.h
+++ b/gcc/config/xtensa/uclinux.h
@@ -53,13 +53,15 @@ along with GCC; see the file COPYING3.  If not see
   %{mauto-litpools:--auto-litpools} \
   %{mno-auto-litpools:--no-auto-litpools} \
   %{mabi=windowed:--abi-windowed} \
-  %{mabi=call0:--abi-call0}"
+  %{mabi=call0:--abi-call0} \
+  %{mdynconfig=*:--dynconfig=%*}"
 
 #undef LINK_SPEC
 #define LINK_SPEC \
  "%{!no-elf2flt:%{!elf2flt*:-elf2flt}} \
   %{mabi=windowed:--abi-windowed} \
-  %{mabi=call0:--abi-call0}"
+  %{mabi=call0:--abi-call0} \
+  %{mdynconfig=*:--dynconfig=%*}"
 
 #undef LOCAL_LABEL_PREFIX
 #define LOCAL_LABEL_PREFIX "."
diff --git a/gcc/config/xtensa/xtensa-dynconfig.cc 
b/gcc/config/xtensa/xtensa-dynconfig.cc
index 3bd2760e4d8..fe2559e1ed7 100644
--- a/gcc/config/xtensa/xtensa-dynconfig.cc
+++ b/gcc/config/xtensa/xtensa-dynconfig.cc
@@ -22,6 +22,7 @@
 #include "coretypes.h"
 #include "diagnostic.h"
 #include "intl.h"
+#include "options.h"
 #define XTENSA_CONFIG_DEFINITION
 #include "xtensa-config.h"
 #include "xtensa-dynconfig.h"
@@ -67,6 +68,55 @@ dlerror (void)
 
 #define CONFIG_ENV_NAME "XTENSA_GNU_CONFIG"
 
+#ifdef ENABLE_PLUGIN
+
+static char *get_xtensa_dynconfig_file (void)
+{
+  const char *xtensa_dynconfig_env = getenv (CONFIG_ENV_NAME);
+  if (!strlen (xtensa_dynconfig_file))
+{
+  if (xtensa_dynconfig_env && !strlen (lbasename (xtensa_dynconfig_env)))
+   {
+ /* XTENSA_GNU_CONFIG has directory path, but dynconfig file is not 
set */
+ return NULL;
+   }
+  else if (xtensa_dynconfig_env)
+   {
+ /* XTENSA_GNU_CONFIG has filepath */
+ return xstrdup (xtensa_dynconfig_env);
+   }
+  /* dynconfig is not set */
+  return NULL;
+}
+  if (!xtensa_dynconfig_env)
+{
+  /* XTENSA_GNU_CONFIG has filepath */
+  return xstrdup (xtensa_dynconfig_file);
+}
+  if (!strlen (lbasename (xtensa_dynconfig_env)))
+{
+  /* XTENSA_GNU_CONFIG has directory path and dynconfig file is set */
+  const size_t len = strlen (xtensa_dynconfig_env) +
+ strlen (xtensa_dynconfig_file) + 1;
+  char *path = ( char *) xmalloc (len);
+  strcpy (path, xtensa_dynconfig_env);
+  strcat (path, xtensa_dynconfig_file);
+  return path;
+}
+  if (strcmp (lbasename (xtensa_dynconfig_env),
+  

Re: [PATCH] Regenerate loongarch.opt.urls.

[Mark Wielaard]

Hi,

On Mon, Apr 01, 2024 at 11:08:08AM +0800, Lulu Cheng wrote:
> Fixes: d28ea8e5a704 ("LoongArch: Split loongarch_option_override_internal
> into smaller procedures")
> 
> gcc/ChangeLog:
> 
>   * config/loongarch/loongarch.opt.urls: Regenerate.

This looks OK to me. I cannot officially approve patches, but I think
this falls under the Obvious fixes rule.

Cheers,

Mark